Yeah, the summary pretty much sucks. Anyway, what would be *super* is if portage had the following support wrt ACCEPT_LICENSE. - Anything w/ license not in ACCEPT_LICENSE is treated as masked - Allow for masking licenses by default (RTCW-ETEULA, etc), perhaps using some kind of -$licensename syntax - Track accepted licenses somehow - --ask displays the license, asks the user to accept, and once done w/ all licenses, recalculates deps Now, the last two are optional, but would be cool to have. Anyway, ACCEPT_LICENSE="*" can not match all licenses legally. We have to have some way to restrict certain licenses (some kind of mask on *, controlled via a file in profiles would be fine) from being accepted by portage automatically. Currently, check_license allows the use of "*" to skip license checks, though it really shouldn't do so. The ideal situation would have ACCEPT_LICENSE="*" as default, with some kind of license.mask file listing licenses that require explicit approval. Also, ACCEPT_LICENSE *should* be culmative ocne all is said and done. I should be able to put ACCEPT_LICENSE="RTCW-ETEULA" to have it work. However, using ACCEPT_LICENSE="* RTCW-ETEULA" would be acceptable to me to allow for the solution for bug #17367 to be implemented easier. If there's any quaetions/concerns, please let me know. I would love to move the check_license code from the ebuilds into portage where it belongs. Luckily, even with bug #17367 resolved, things won't break for most people. They *will* break for *anyone* who has been using ACCEPT_LICENSE already. $ grep ACCEPT_LICENSE /etc/make.conf ACCEPT_LICENSE="LOKI-EULA ut2003 Army-EULA RTCW RTCW-ETEULA DOOM3 QUAKE4" Now, I won't be able to install much of anything with portage 2.1.2_pre3-r7's defaults. Neither will anyone else who has installed any license-restricted programs.
Are there likely to be several categories of license restriction? Offhand, I imagine at least 3 possible categories: 1) Interactive acceptance for each and every install. 2) Interactive acceptance required for only the first install. 3) Acceptance required at some time, but it does not need to be interactive.
From what I can see, no. There should only be one, which is acceptance of the license the first time. The licenses that I've been looking at are really vague in that they mention nothing about multiple installations. Let me put it to you in another way. In the Windows/MS world, you can take a package and repackage it (mostly) for distribution within your company. You do not need to accept the EULA more than once, since you accepted it the first time. I would liken this to be the same. Once it has been accepted, we can store that it has been accepted. Now, current check_license works in a way which we may want to emulate. If the user has ACCEPT_LICENSE="license" then the license is not displayed. If the user does not, then it is displayed every time. Now, instead of displaying the license, we should abort immediately with "Package masked by license" or some such, *unless* the user is using --ask, then we should ask. Would that work?
(In reply to comment #2) > If the user has ACCEPT_LICENSE="license" then the license is not displayed. If > the user does not, then it is displayed every time. Now, instead of displaying > the license, we should abort immediately with "Package masked by license" or > some such, *unless* the user is using --ask, then we should ask. Would that > work? I think we can do something like that The way that I imagine it, ACCEPT_LICENSE will continue to behave much like ACCEPT_KEYWORDS, and mask packages that do not have accepted licenses. For the case of restrictive licenses, we'll need some way to identify them, such as a new variable or file in the profiles. The main difference that I think we will need to have from the current check_license behavior is that the user will always be prompted at least once for a given license, even though it is already in ACCEPT_LICENSE (it must be in ACCEPT_LICENSE to avoid being masked). That way, we can even let * match restrictive licenses, since the user will still be prompted if necessary.
Well, I strongly disagree with having ACCEPT_LICENSE="*" as hardcoded default. ACCEPT_* vars are suposed to be opt-in, not opt-out settings. Actually I'd even get rid of the * value altogether, IMO it's use is questionable, has legal problems requiring special workarounds and it doesn't exist for any other portage variable. So how should this work from my POV: - if not ACCEPT_LICENSE is set anywhere all packages are masked - profiles can adjust ACCEPT_LICENSE according that their maintainers whishes (so restrictive licenses simply won't be added by them in any profile) - user can adjust it in make.conf again In other words: it should behave _exactly_ like ACCEPT_KEYWORDS (might even use a generic function for this). This might require a tiny bit more maintenance by profile maintainers/devs, but saves us from stupid workarounds for some special licenses and keeps things more consistent with ACCEPT_KEYWORDS. (In reply to comment #0) > - --ask displays the license, asks the user to accept, and once done w/ all > licenses, recalculates deps Easiest way to handle this IMO is to do it like with entries in package.mask, so if a package is masked by license portage is going to show the license text. Unmasking things automatically is just asking for trouble though.
(In reply to comment #4) > Well, I strongly disagree with having ACCEPT_LICENSE="*" as hardcoded default. > ACCEPT_* vars are suposed to be opt-in, not opt-out settings. The reason that I chose * as default is obvious: the default behavior with respect to visibility has always been to disregard licenses. It's comparable to accepting all keywords. > Actually I'd even > get rid of the * value altogether, IMO it's use is questionable, has legal > problems requiring special workarounds and it doesn't exist for any other > portage variable. The way that it's implemented, it's simply a visibility filter. It doesn't imply that the user has even read the license, only that packages using this license will be visible for dependency resolution. > So how should this work from my POV: > - if not ACCEPT_LICENSE is set anywhere all packages are masked > - profiles can adjust ACCEPT_LICENSE according that their maintainers whishes > (so restrictive licenses simply won't be added by them in any profile) > - user can adjust it in make.conf again > In other words: it should behave _exactly_ like ACCEPT_KEYWORDS (might even use > a generic function for this). I can see how it makes sense for the profile set a default keyword. Default licenses though? It seems like license filtering is entirely a user choice. > > This might require a tiny bit more maintenance by profile maintainers/devs, but > saves us from stupid workarounds for some special licenses and keeps things > more consistent with ACCEPT_KEYWORDS. The way that I think we should handle it, ACCEPT_LICENSE would be purely used for visibility filtering in dependency resolution. The interactive acceptance would be another, essentially unrelated feature.
(In reply to comment #4) > Actually I'd even get rid of the * value altogether Err, uh... If you want massive amount of users ranting about portage nagging them with stupid licenses they don't care about and want patches floating around on gentoo-wiki.com and forums.g.o. that patch away the license handling from portage, then sure. Otherwise, keep * there and make sure that you limit usage of what's currently accept_license() to the absolute minimum of cases where there's no way around it... It certainly is hard to imagine things more annoying than babysitting a long install chain to agree to every new distribution license that doesn't cover use at all - annoying like hell, breaking non-interactivity and completely retarded behaviour if you ask me. I'm also not keen on bloating make.conf with 862 licenses we currently have.
(In reply to comment #5) > (In reply to comment #4) > > Well, I strongly disagree with having ACCEPT_LICENSE="*" as hardcoded default. > > ACCEPT_* vars are suposed to be opt-in, not opt-out settings. > > The reason that I chose * as default is obvious: the default behavior with > respect to visibility has always been to disregard licenses. It's comparable > to accepting all keywords. I don't see backwards compability here as a big issue: If there is a set of default accepted licenses in base/ then users won't even notice the difference (except people using custom profiles but that's less than 1% of the userbase I'd say). And your analogy shows exactly why I consider this to be a bad and inconsistent thing. > > Actually I'd even > > get rid of the * value altogether, IMO it's use is questionable, has legal > > problems requiring special workarounds and it doesn't exist for any other > > portage variable. > > The way that it's implemented, it's simply a visibility filter. It doesn't > imply that the user has even read the license, only that packages using this > license will be visible for dependency resolution. I don't see how this addresses my points. It's a special hack asking for abuse, so needs other special hacks to prevent abuse. > > So how should this work from my POV: > > - if no ACCEPT_LICENSE is set anywhere all packages are masked > > - profiles can adjust ACCEPT_LICENSE according that their maintainers whishes > > (so restrictive licenses simply won't be added by them in any profile) > > - user can adjust it in make.conf again > > In other words: it should behave _exactly_ like ACCEPT_KEYWORDS (might even use > > a generic function for this). > > I can see how it makes sense for the profile set a default keyword. Default > licenses though? It seems like license filtering is entirely a user choice. Then why did Chris file this bug in the first place? Also this behavior together with multiple inheritance makes license groups pretty much redundant. > > This might require a tiny bit more maintenance by profile maintainers/devs, but > > saves us from stupid workarounds for some special licenses and keeps things > > more consistent with ACCEPT_KEYWORDS. > > The way that I think we should handle it, ACCEPT_LICENSE would be purely used > for visibility filtering in dependency resolution. The interactive acceptance > would be another, essentially unrelated feature. Did I say anything else? I just want to make it consistent with existing stuff. (In reply to comment #6) > (In reply to comment #4) > > Actually I'd even get rid of the * value altogether > > Err, uh... If you want massive amount of users ranting about portage nagging > them with stupid licenses they don't care about and want patches floating > around on gentoo-wiki.com and forums.g.o. that patch away the license handling > from portage, then sure. Jakub, for our all sake, shut the hell up if you don't know what you're talking about (in 50% of all cases you don't). This isn't really relevant to users at all.
(In reply to comment #7) > > I can see how it makes sense for the profile set a default keyword. Default > > licenses though? It seems like license filtering is entirely a user choice. > > Then why did Chris file this bug in the first place? > Also this behavior together with multiple inheritance makes license groups > pretty much redundant. He filed the bug because he wants emerge to have the ability to interactively prompt the user to accept licenses that require such interaction. The goal of interactive license acceptance is to satisfy the requirements of some restrictive licenses. The goal of license groups is visibility filtering for dependency resolution. It seems to me that these two goals are practically orthogonal and therefore I don't see a good reason for them to be artificially and tightly coupled together.
(In reply to comment #7) > Did I say anything else? I just want to make it consistent with existing stuff. Consistency with existing stuff is good. I guess that's fine if you want the profiles to have the ability to insert licenses or license groups into a user's settings. However, I thing that an "all" group should be available. We don't have to represent it as *. Whatever symbol makes you happy is fine with me. ;)
Personally, I'm for dropping "*" and bringing ACCEPT_LICENSE in line with ACCEPT_KEYWORDS and other incrementals. If you look on the original ACCEPT_LICENSE bug, I voiced being against it (but moreso on -dev@g.o during the same period) but there was too much resistance that I wasn't prepared to handle as a non-dev. ;) If OSI-approved licenses were thrown into the profiles, the bulk of packages in the tree would be unmasked already - not that I'm suggesting that all of / only OSI-approved licenses should be added; I don't care on that point and it's not for me to do so. As far as a users are concerned, patches aren't even necessary. `echo ACCEPT_LICENSE=\"$(ls $PORTDIR/licenses)\" >> /etc/make.conf` gives current behaviour (until some new license pops up). (If you're wondering on how having every license in ACCEPT_LICENSE would affect performance, that is exactly how I was testing that my patch didn't adversely affect performance to a great degree.) As for interactive acceptance and possible adjusting of make.conf or package.*, I think that this is a good thing. But! If it's done for licenses, it really should be done for all types of package masking as well. If the point of this bug is that portage needs to provide a way to enforce that users are reading licenses, we cannot do it. Even Microsoft eventually learned this - you no longer need to scroll through the entire license in order to accept it when installing XP.
(In reply to comment #2) > From what I can see, no. There should only be one, which is acceptance of the > license the first time. The licenses that I've been looking at are really > vague in that they mention nothing about multiple installations. Let me put it > to you in another way. In the Windows/MS world, you can take a package and > repackage it (mostly) for distribution within your company. You do not need to > accept the EULA more than once, since you accepted it the first time. I would > liken this to be the same. Once it has been accepted, we can store that it has > been accepted. > > Now, current check_license works in a way which we may want to emulate. > > If the user has ACCEPT_LICENSE="license" then the license is not displayed. If > the user does not, then it is displayed every time. Now, instead of displaying > the license, we should abort immediately with "Package masked by license" or > some such, *unless* the user is using --ask, then we should ask. Would that > work? > To try and minimize code here; are there specific legal requirements regarding this issue? For OSI licenses, I (as a user) don't need to read the license to do much of anything. Gentoo as a distro needs to distribute the license (which we do with our tree, so we are covered there). The final "set" of licenses includes what one typically calls commercial licenses. So what are the *legal* requirements here. Must the user be shown the license? What is legally considered "accepting"? From many of the licenses I've read using the software is implicitly accepting it's license. Is this the case for all licenses, even licenses one has never read? I dislike just writing a bunch of code where there is shaky or zero legal precident here; just because we will end up rewriting it later. So what is Gentoo obligated by law to do?
I am concerned with not losing functionality that we currently have. As it stands right now, I have reduced functionality from portage due to it defaulting to ACCEPT_LICENSE="*" and ACCEPT_LICENSE not being culmative. Can we do something like allow the "default" to be ACCEPT_LICENSE="*" than also have some form of mask file where we can add license names to not allow to be implicitly accepted? This means that if RTCW-ETEULA were listed in ${PORTDIR}/profiles/license.mask, and I had ACCEPT_LICENSE="RTCW-ETEULA" in make.conf, it would equal something like this: Allow all licenses -> mask licenses in license.mask -> Allow RTCW-ETEULA at user's request Portage wouldn't need to do anything special, wrt displaying the license, though that would be *super* if it could. Again, my main concern is loss of current functionality. As for what we are required to do by law, allow me to quote RTCW-ETEULA: "This Limited Use Software License Agreement (this "Agreement") is a legal agreement between you, the end-user, and Id Software, Inc. ("ID"). BY CONTINUING THE DOWNLOAD OR INSTALLATION OF THE GAME PROGRAM ENTITLED WOLFENSTEIN: ENEMY TERRITORY (THE "SOFTWARE"), BY LOADING OR RUNNING THE SOFTWARE, OR BY PLACING OR COPYING THE SOFTWARE ONTO YOUR COMPUTER HARD DRIVE, COMPUTER RAM OR OTHER STORAGE, YOU ARE AGREEING TO BE BOUND BY THE TERMS OF THIS AGREEMENT." Also... "For purposes of the first sentence of this section, "use" means loading the Software into RAM and/or onto computer hard drive, as well as installation of the Software on a hard disk or other storage device, and means the uses permitted in sections 2 and 4 hereinbelow." Here's the real catch... "You agree to use your best efforts to see that any user of the Software licensed hereunder, or the New Creations, complies with this Agreement." ...and finally... "YOU ACKNOWLEDGE THAT YOU HAVE READ THIS AGREEMENT, YOU UNDERSTAND THIS AGREEMENT, AND UNDERSTAND THAT BY CONTINUING THE DOWNLOAD OR INSTALLATION OF THE SOFTWARE, BY LOADING OR RUNNING THE SOFTWARE, OR BY PLACING OR COPYING THE SOFTWARE ONTO YOUR COMPUTER HARD DRIVE OR RAM, YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS OF THIS AGREEMENT. YOU FURTHER AGREE THAT, EXCEPT FOR WRITTEN SEPARATE AGREEMENTS, IF ANY, BETWEEN ID AND YOU, THIS AGREEMENT IS A COMPLETE AND EXCLUSIVE STATEMENT OF THE RIGHTS AND LIABILITIES OF THE PARTIES HERETO, RELATING TO THE SUBJECT MATTER HEREOF. THIS AGREEMENT SUPERSEDES ALL PRIOR ORAL AGREEMENTS, PROPOSALS OR UNDERSTANDINGS, AND ANY OTHER COMMUNICATIONS, IF ANY, BETWEEN ID AND YOU RELATING TO THE SUBJECT MATTER OF THIS AGREEMENT." Now, while it does not explicitly say anywhere that the license must be displayed, it pretty much says that we must do what is deemed our best effort. This means displaying the license. Also, due to their definition of "use" portage/Gentoo is considered a user just as much as the end-user. Quite simply, I don't care nearly as much about backwards compatibility as I do about the Foundation not being sued. For now, nothing is really changed, but we should determine what should be done with licenses and properly implement it before removing check_license from any ebuilds.
(In reply to comment #7) > (In reply to comment #6) > > Err, uh... If you want massive amount of users ranting about portage nagging > > them with stupid licenses they don't care about and want patches floating > > around on gentoo-wiki.com and forums.g.o. that patch away the license handling > > from portage, then sure. > > Jakub, for our all sake, shut the hell up if you don't know what you're talking > about (in 50% of all cases you don't). This isn't really relevant to users at > all. Sigh... Sorry for voicing my opinion on nagging users with irrelevant junk. Once again, vast majority of licenses covers distribution _only_ and doesn't restrict use in any way. Don't nag me with such crap, I don't care. I don't care as a lawyer, because it's irrelevant junk. If it doesn't affect users, you need to explain better what are you trying to do here, because the thing you've suggested (as I've read it) is one hell annoying to users. Don't want to be forced to click-thru GPL to be able to install something, sorry... Make such annoyances opt-in, not opt-out.
As I said, you don't understand it.
(In reply to comment #14) > As I said, you don't understand it. Thanks for "explanation"; really "helped"... Unless you have something better, maybe don't comment.
Jakub: Could you for once keep your nose out of something you don't understand? Please? In case you have not noticed, I am working to try to provide a solution that doesn't negatively impact our users and also keeps us in the legal clear. However, I want you to know that my NUMBER ONE priority is our legal standing. That means if we end up with something inconvenient to our users *as the only outcome*, we're still going to do it. Our legal standing is priority one with this. No amount of complaining or commenting on this or any othe rbug is going to change this. Now, if you have something to add to the technical discussion, then by all means. Otherwise, please BACK OFF and let us work out the technical details to ensure that we remain within the letter of the law. If you want to turn a bug into yet another "Jakub bitching" session, then go somewhere else. It isn't wanted nor necessary on this bug report which deals entirely with the legal ramifications of ACCEPT_LICENSE, portage, and the Gentoo Foundation. As an elected trustee, this is my *job* not yours. Once you have a firm grasp of the US legal system, feel free to come back and help with technical points on how we can achieve a proper balance of making things easy for the users and still remain on solid legal ground.
(In reply to comment #16) > In case you have not noticed, I am working to try to provide a solution that > doesn't negatively impact our users and also keeps us in the legal clear. Wasn't replying to your post at all... Was a reaction to the "STFU and go away" posted here by genone in Comment #7. > Now, if you have something to add to the technical discussion, then by all > means. Otherwise, please BACK OFF and let us work out the technical details to > ensure that we remain within the letter of the law. Yah, my technical point has been - why the heck are you going to bloat profiles with tons of whitelisted licenses instead of blacklisting the few that need to remain "interactive" or explicitely accepted or whatever you call that. (I.e. wth are you trying to kill the ACCEPT_LICENSE="*"); but oh well, I'm apparently missing the point, so I'm outta this bug, ktnxbye...
(In reply to comment #12) > I am concerned with not losing functionality that we currently have. As it > stands right now, I have reduced functionality from portage due to it > defaulting to ACCEPT_LICENSE="*" and ACCEPT_LICENSE not being culmative. In portage-2.1.2_pre3-r8, ACCEPT_LICENSE is again just a cumulative variable that is otherwise ignored. It wasn't my intention to break your existing usage of that variable. > Can we do something like allow the "default" to be ACCEPT_LICENSE="*" than also > have some form of mask file where we can add license names to not allow to be > implicitly accepted? This means that if RTCW-ETEULA were listed in > ${PORTDIR}/profiles/license.mask, and I had ACCEPT_LICENSE="RTCW-ETEULA" in > make.conf, it would equal something like this: > > Allow all licenses -> mask licenses in license.mask -> Allow RTCW-ETEULA at > user's request I'm not sure if a license.mask is really necessary. In GLEP 23 it says that the default ACCEPT_LICENSE should be set to @NON-INTERACTIVE, which would mean that any interactive licenses are already "masked" by default, simply because they're not explicitly listed in ACCEPT_LICENSE. I'm not sure if we all have the idea about the meaning of licenses that are listed in ACCEPT_LICENSE. Does having an interactive license listed in there imply that one has read and accepted the license? That seems to be the assumption that check_license currently makes. However, you've asked that portage "Track accepted licenses somehow" and I thought that's already been fulfilled by the ACCEPT_LICENSE variable. When I read over the discussion, this is a major point of ambiguity for me: does ACCEPT_LICENSE track accepted licenses or not? If it really does track accepted licenses, then I can see why the * license group is certainly unwanted. If we want emerge to handle the job that check_license currently does, I see at least a few tasks that need to be taken care of: 1) Define a file format for representation of license groups in the profile (GLEP 23 does not currently specify a format). 2) Populate the @NON-INTERACTIVE group and add it to ACCEPT_LICENSE in the base profile. 3) Enable portage to recognize and expand license groups in profiles. We need to get 1) taken care of before we can proceed with the rest. The other 2 will be easy to complete after that's done.
For 1), do we want a description for license groups? If not it could simply be <group-name> <license1> ... <licenseN> Such a line based format however doesn't work well if we want additional metadata for groups (like a description).
We probably also want the format of the license group file to allow one group to include on or more other groups. That way @NON-INTERACTIVE could simply pull in a bunch of other groups instead of having to list individual licenses explicitly. I imagine that we will probably want to attach more metadata than just the list of licenses. The description is one thing. Maybe we also need some metadata to represent certain types of restrictions that apply to a group as a whole, such as the restriction that the user must actually read the EULA in order to use the software.
Hmm, time to use ConfigParser?
(In reply to comment #18) > In portage-2.1.2_pre3-r8, ACCEPT_LICENSE is again just a cumulative variable > that is otherwise ignored. It wasn't my intention to break your existing usage > of that variable. I didn't suspect it was which was why I mentioned it. > I'm not sure if a license.mask is really necessary. In GLEP 23 it says that > the default ACCEPT_LICENSE should be set to @NON-INTERACTIVE, which would mean > that any interactive licenses are already "masked" by default, simply because > they're not explicitly listed in ACCEPT_LICENSE. That would be perfectly fine. I would also suggest that ACCEPT_LICENSE by culmative. This would mean if I had ACCEPT_LICENSE="RTCW-ETEULA", portage would get ACCEPT_LICENSE="@NON-INTERACTIVE RTCW-ETEULA" which would satify me, for sure. > I'm not sure if we all have the idea about the meaning of licenses that are > listed in ACCEPT_LICENSE. Does having an interactive license listed in there > imply that one has read and accepted the license? That seems to be the > assumption that check_license currently makes. However, you've asked that > portage "Track accepted licenses somehow" and I thought that's already been > fulfilled by the ACCEPT_LICENSE variable. When I read over the discussion, > this is a major point of ambiguity for me: does ACCEPT_LICENSE track accepted > licenses or not? If it really does track accepted licenses, then I can see why > the * license group is certainly unwanted. I apologize. Having portage track the licenses itself really is another request for another time. For now, let's stick with replicating the current behavior within portage. Adding some kind of --ask capability can be done at a later time. ACCEPT_LICENSE should be the list of accepted licenses. > 1) Define a file format for representation of license groups in the profile > (GLEP 23 does not currently specify a format). I'd agree with Marius. I think a single line format should be fine. groupname license1 license2 group1 group2 license3 I'm not sure that a description is necessary. If people deem it necessary, does it need to be in the same file as the group definitions? Could it be more like use.desc? > 2) Populate the @NON-INTERACTIVE group and add it to ACCEPT_LICENSE in the base > profile. Yes. I can help with this. All I need really is for someone to come up with #1 and I can complete this. Should we take #1 to gentoo-dev for discussion? Is it necessary? The nice thing about portage support is it could be completely backwards-compatible. As soon as a portage version that supports ACCEPT_LICENSE comes about, it'll allow @NON-INTERACTIVE by default. Only interactive licenses will not be accepted, and only interactive licensed packages use check_license currently. People using these packages are already using ACCEPT_LICENSE, such as myself. Eventually, check_license goes away. Most people won't ever know that this has been implemented, as they'll see no difference in behavior, which is always the best kind of change. =] I'm not sure that any further restrictions would be necessary. The only reason that I can think of that we would have a license not accepted by default is because it requires user approval. Without any kind of --ask support, this should be simple. ACCEPT_LICENSE="-* @NON-INTERACTIVE" emerge enemy-territory Calculating dependencies !!! All ebuilds that could satisfy "enemy-territory" have been masked. !!! One of the following masked packages is required to complete your request: - games-fps/enemy-territory-2.60b (masked by: license) For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. ACCEPT_LICENSE="RTCW_ETEULA" emerge enemy-territory Installs as "normal" to the system. How does that sound?
(In reply to comment #22) > I'd agree with Marius. I think a single line format should be fine. > > groupname license1 license2 group1 group2 license3 > > I'm not sure that a description is necessary. If people deem it necessary, > does it need to be in the same file as the group definitions? Could it be > more like use.desc? That sounds nice. If we split things into separate files where appropriate, then it can make it easier for people to parse it if they want to. > Should we take #1 to gentoo-dev for discussion? Is it necessary? Yeah, we need lots of peers to review something like this before it gets implemented. This feature is going to affect lots of ebuild devs because whenever they add a new license they are going to be responsible for adding it to the appropriate license group(s) so that packages using it will have appropriate visibility. > For more information, see MASKED PACKAGES section in the emerge man page or > refer to the Gentoo Handbook. > > ACCEPT_LICENSE="RTCW_ETEULA" emerge enemy-territory > > Installs as "normal" to the system. So, the user will look in the appropriate section of the man page or handbook and it will tell them that when a package masked by license it means that they should go read the license before they attempt to unmask it? I guess that's fine.
(In reply to comment #23) > > Should we take #1 to gentoo-dev for discussion? Is it necessary? > > Yeah, we need lots of peers to review something like this before it gets > implemented. This feature is going to affect lots of ebuild devs because > whenever they add a new license they are going to be responsible for adding it > to the appropriate license group(s) so that packages using it will have > appropriate visibility. OK. Who's going to bring it up? Do you want to? If not, I'll do it. > So, the user will look in the appropriate section of the man page or handbook > and it will tell them that when a package masked by license it means that they > should go read the license before they attempt to unmask it? I guess that's > fine. Why not? It's what we do for every single other masking type. It only makes sense to be consistent.
(In reply to comment #23) > So, the user will look in the appropriate section of the man page or handbook > and it will tell them that when a package masked by license it means that they > should go read the license before they attempt to unmask it? I guess that's > fine. Actually I'm currently working on a patch to show the license directly when emerge encounters a license masked package (or point to the filename if the text exceeds a certain size) as mentioned in comment #4
I suggest only showing it with --ask and simply showing the normal "masked package" output without --ask, to retain consistency with every other masking type.
(In reply to comment #26) > I suggest only showing it with --ask and simply showing the normal "masked > package" output without --ask, to retain consistency with every other masking > type. Uhm, I don't think that's a very bright idea. Most licenses are horribly long, so if you install a new app with a bunch of dependencies and those contain, say fex 3 licenses you didn't approve yet, your screen is filled with lawyers' shit. IMO --ask should be the same as --pretend with the addition of 'do you want me to merge this list?'.
(In reply to comment #26) > I suggest only showing it with --ask and simply showing the normal "masked > package" output without --ask, to retain consistency with every other masking > type. I'm not making it conditional on --ask as there is nothing to ask here. Also this actually makes it consistent with the "masked by: package.mask" message.(In reply to comment #27) > (In reply to comment #26) > > I suggest only showing it with --ask and simply showing the normal "masked > > package" output without --ask, to retain consistency with every other masking > > type. > > Uhm, I don't think that's a very bright idea. Most licenses are horribly long, > so if you install a new app with a bunch of dependencies and those contain, say > fex 3 licenses you didn't approve yet, your screen is filled with lawyers' > shit. IMO --ask should be the same as --pretend with the addition of 'do you > want me to merge this list?'. Yeah, realized that it's not such a good idea for long licenses, so added a size limitation: if a license text is longer than 2000 chars only the filename for the license is shown. Also the 'masked by' message only applies to a single package, and even if it would apply to multiple packages each license would only shown once, so the risk of spamming the screen is quite limited. There is one potential problem remaining however with the existance of licenses in binary formats, e.g. PDF. But I think the current size check will cover those too (and they are a questionable exception anyway).
(In reply to comment #24) > > Yeah, we need lots of peers to review something like this before it gets > > implemented. This feature is going to affect lots of ebuild devs because > > whenever they add a new license they are going to be responsible for adding it > > to the appropriate license group(s) so that packages using it will have > > appropriate visibility. > > OK. Who's going to bring it up? Do you want to? If not, I'll do it. I'm unsure of the reaction that people will have to this new visibility requirement being a mandatory consideration for all licenses. I'd rather not bring it up myself because I don't feel prepared to vigorously promote and defend the idea (though I personally think the idea is workable and has some advantages over the alternatives).
OK. This makes a lot more sense now. I wasn't following before. So why show the license text, at all? Most licenses are going to break the 2000 character mark pretty easily. Why not be consistent and just show: masked by: license RTCW-ETEULA And let the user read it themselves?
(In reply to comment #30) > OK. This makes a lot more sense now. I wasn't following before. So why show > the license text, at all? Most licenses are going to break the 2000 character > mark pretty easily. Why not be consistent and just show: > > masked by: license RTCW-ETEULA Well, that's shown anyway. Let me attach an example how it looks like. > And let the user read it themselves? *shrug*, does it hurt to display the license directly?
Created attachment 100553 [details] Example of license display
Created attachment 100557 [details] Example of license display fix formatting and clean it up
Harm? No. It just seems like a lot of information that can confuse users.
(In reply to comment #28) > There is one potential problem remaining however with the existance of licenses > in binary formats, e.g. PDF. But I think the current size check will cover > those too (and they are a questionable exception anyway). There is also the problem of encodings. Licenses are not necessarily in English and are not necessarily in the same encoding (or a subset thereof) as the user's terminal. Likewise, I think that the license should never be output to the screen by emerge - at least until binary formats can be killed and encodings unified in licenses/.
In trunk we currently have support for license_groups files in the profile, as described in GLEP 23. The groups can include other groups by specifying @groupname in the same place that licenses go. Before we release a version of portage which supports this, we need to have an appropriate license_groups file in the base base profile, as well as a default ACCEPT_LICENSE value which includes all licenses that do not require explicit acceptance. We also need to update our policy docs to indicate that ebuild devs will be responsible for updating license_groups whenever they add a new license that does not require explicit acceptance (so that it will be automatically accepted/unmasked).
(In reply to comment #36) > In trunk we currently have support for license_groups files in the profile, > as described in GLEP 23. license_groups files currently are used when they exist in e. g. ${PORTDIR}/profiles or /etc/portage, but license_groups in /etc/portage/profile isn't used. For consistency I suggest that /etc/portage/profile/license_groups should be used and /etc/portage/license_groups shouldn't be used.
(In reply to comment #37) > (In reply to comment #36) > > In trunk we currently have support for license_groups files in the profile, > > as described in GLEP 23. > > license_groups files currently are used when they exist in e. g. > ${PORTDIR}/profiles or /etc/portage, but license_groups in /etc/portage/profile > isn't used. For consistency I suggest that /etc/portage/profile/license_groups > should be used and /etc/portage/license_groups shouldn't be used. That would actually be inconsistent with other files in $PORTDIR/profiles.
(In reply to comment #38) Sorry for inaccurate check of consistency. But now, could somebody create license_groups file?
Is anybody working on this? And is anybody working on cleaning up licenses in ebuilds? Many packages have separate license files and license files only different in 'copyright by' part... (X.Org comes to mind). If no one is doing this, I could try to help you and do FSF-APPROVED set and clean up some redundancy in license files.
(In reply to comment #40) > Is anybody working on this? And is anybody working on cleaning up licenses in > ebuilds? No, nobody appears to be working on this stuff. However, we do have at least a partially defined GPL-COMPATIBLE group: http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/license_groups?view=markup Patches to that file would be appreciated. As said in comment #36, eventually we'll have to establish a formal policy for license maintenance (such policies need to be approved by the council prior to being implemented).
Created attachment 185634 [details, diff] FSF-APPROVED
Created attachment 185635 [details, diff] OSI-APPROVED Lists are not complete, mostly because packages use wrong licenses (usually BSD instead of their own licenses) or a license is listed multiple times under different names and I've listed only licenses that are in portage. > eventually we'll have to establish a > formal policy for license maintenance This bug is already quite old. When is this formal policy to be expected?
(In reply to comment #43) > Created an attachment (id=185635) [edit] > OSI-APPROVED Thanks I've committed both of your patches. > > eventually we'll have to establish a > > formal policy for license maintenance > This bug is already quite old. When is this formal policy to be expected? Today or tomorrow I'll send an email to the gentoo-dev mailing list, in order to explain the proposed policy changes and get some feedback.
To summary where we are right now: - Anything w/ license not in ACCEPT_LICENSE is treated as masked -> this is in portage-2.2 - Allow for masking licenses by default (RTCW-ETEULA, etc), perhaps using some kind of -$licensename syntax -> default license with @EULA group default masked as been voted by council. AFAIK, it needs to be populated and next portage release will have ACCEPT_LICENSE="* -@EULA" as default behavior. - Track accepted licenses somehow - --ask displays the license, asks the user to accept, and once done w/ all licenses, recalculates deps -> these two things haven't been implemented, afaik @zmedico: is it scheduled ?
(In reply to comment #45) > -> default license with @EULA group default masked as been voted by council. > AFAIK, it needs to be populated and next portage release will have > ACCEPT_LICENSE="* -@EULA" as default behavior. The ACCEPT_LICENSE="* -@EULA" setting will go in profiles/base/make.defaults. > - Track accepted licenses somehow > - --ask displays the license, asks the user to accept, and once done w/ all > licenses, recalculates deps > -> these two things haven't been implemented, afaik > @zmedico: is it scheduled ? This seems like it would require emerge to modify user configuration files, which it has never done up to this point. I'm not sure if we really need/want to integrate this kind of thing into emerge. We could, but it could be a job for an external tool, similar to autounmask. An alternative approach might be for emerge to allow interactive license acceptance without any configuration file changes. In this case, the acceptance would simply be non-persistent, so the user could be prompted again in the future for the same license.
This is fixed in portage-2.1.7. The default ACCEPT_LICENSE value is "* -@EULA", set in /usr/share/portage/config/make.globals.
