I realize I am opening a can of worms here, but I believe this is something that needs to be brought up and discussed. The AGPL cannot be considered a Free Software license, as it imposes requirements on users beyond "all rights reserved". Thus, it belongs in @EULA, and users need to explicitly read and accept it (in particular Paragraph 13) if they wish to install software distributed under it. Otherwise, they might find themselves in accidental violation of the license by mere usage, not distribution. Reproducible: Always Steps to Reproduce: 1. emerge www-apps/nextcloud Notice that no explicit license unmasking is required. 2. webapp-config -h <hostname> -d nextcloud -I nextcloud <version> 3. Configure a web server to offer access to the instance to the internet 4. Make a single change to a php file in /var/www/<hostname> (or whatever the installation path is) Actual Results: I am now in violation of the license, unless I package my change, and advertise it to all Internet users who might access my web server, even the login page (e.g. by including it in the footer of all pages). There was no warning to me that I was required to do this, and no way for me to know in advance without being aware of both the fact that Nextcloud is AGPL-licensed, and exactly what Paragraph 13 of the AGPL says and what requirements it imposes on me. Expected Results: No license violation has occurred Among all the licenses approved by OSI, the AGPL stands out as a strange beast. It is not merely a copyright license, but also imposes requirements on mere users of the software, that would not exist for purely copyright-protected software (i.e. it is, in its Paragraph 13, imposing restrictions beyond "all rights reserved", even as the rest of the license grants other rights). This means it does not follow Freedom Zero (The freedom to run the program for any purpose.), as it imposes some restrictions on exactly how you must run the program. I believe its classification as a Free Software license is incorrect. Unfortunately, it seems this fact is mostly being swept under the rug (even though it has been brought up in passing [1]) by distributions, mainly because they go by the FSF approved license list, and the OSI approved license list. The FSF list is meaningless in this case, as this is their own license, and they have ulterior motives to promote it regardless of its flaws and cannot be considered impartial; of course they would say their own license is a Free Software license. Meanwhile, the OSI definition only covers redistribution and source, and does not cover usage, which means that, paradoxically, a license can be simultaneously @OSI-APPROVED and @EULA, which is the case here. [1] https://bugs.gentoo.org/676248#c5
(In reply to Hector Martin from comment #0) > The AGPL cannot be considered a Free Software license, as it imposes > requirements on users beyond "all rights reserved". Thus, it belongs in > @EULA, and users need to explicitly read and accept it (in particular > Paragraph 13) if they wish to install software distributed under it. > Otherwise, they might find themselves in accidental violation of the license > by mere usage, not distribution. Not true. There is no need to accept the license if you exercise only your statutory rights, which in many jurisdictions includes the right to run the program and to patch it if necessary (e.g., for compatibility with other programs). Apart from that, we follow the accepted definition of free software (i.e., the four freedoms). As long as the AGPL-3 is approved by both FSF and OSI, we will list it in the @FSF-APPROVED and @OSI-APPROVED license groups, from where it is propagated to @FREE. Note that the Gentoo Social Contract [2] also mentions FSF and OSI approval. Also, our license list in @FREE is only a default. Users who disagree with it can ignore it and either override it with their own list in the ACCEPT_LICENSE variable, or exclude specific licenses, e.g., by specifying "@FREE -AGPL-3 -AGPL-3+". > Among all the licenses approved by OSI, the AGPL stands out as a strange > beast. It is not merely a copyright license, but also imposes requirements > on mere users of the software, that would not exist for purely > copyright-protected software (i.e. it is, in its Paragraph 13, imposing > restrictions beyond "all rights reserved", even as the rest of the license > grants other rights). This means it does not follow Freedom Zero (The > freedom to run the program for any purpose.), as it imposes some > restrictions on exactly how you must run the program. Again, that is not true. Running the program (freedom 0) is always allowed and doesn't even require acceptance of the license. The AGPL itself confirms this in section 9. I don't see any problem with freedoms 1, 2, or 3 either; the license allows modification as well as distribution without or with modification. > I believe its classification as a Free Software license is incorrect. > > Unfortunately, it seems this fact is mostly being swept under the rug (even > though it has been brought up in passing [1]) by distributions, mainly > because they go by the FSF approved license list, and the OSI approved > license list. Exactly, and the issue isn't specific to any single distribution, therefore Gentoo bugzilla isn't the best place to report it. Certainly we won't come up with our own definition of free software and disagree with everyone else. I'd suggest that you discuss it with FSF or OSI if you want them to reconsider their classification of the AGPL-3. Disclaimer: I am not a lawyer. This is no legal advice. > [1] https://bugs.gentoo.org/676248#c5 [2] https://www.gentoo.org/get-started/philosophy/social-contract.html
CC mgorny, who previously opined on this subject. > Not true. There is no need to accept the license if you exercise only your statutory > rights, which in many jurisdictions includes the right to run the program and to patch > it if necessary (e.g., for compatibility with other programs). Are you saying that the stated steps to reproduce, i.e. hosting an (even slightly) patched Nextcloud, do not infringe on the AGPL? If so, then the AGPL is unenforceable and equivalent to the GPL. If not, how do you expect Gentoo users to find out about their obligation to offer source for merely hosting a modified copy (which no other free software license requires), if not via explicit action by unmasking a license? > Also, our license list in @FREE is only a default. Users who disagree with it can ignore it > and either override it with their own list in the ACCEPT_LICENSE variable, or exclude > specific licenses, e.g., by specifying "@FREE -AGPL-3 -AGPL-3+". The point here is this will catch users who don't know about this by surprise. It caught me; I didn't know Nextcloud was AGPLed when I first installed it, and I had a few dumb patches in while I was debugging a problem. Those were temporary and are now gone, but for that time, I was in violation of its license, unknowingly. > Again, that is not true. Running the program (freedom 0) is always allowed and doesn't > even require acceptance of the license. Running the program as a network server isn't allowed if you have modified it and neglected to inform your users of that fact, and offer source. Read the paragraph carefully: > if you modify the Program, your modified version must prominently offer all users > interacting with it remotely through a computer network [...] an opportunity to > receive the Corresponding Source of your version [...] Note how it says *all users interacting with it remotely* - it does not specify *direct* interaction, but rather ought to be read to include indirect users. This makes sense, because otherwise you could just stick a proxy server in front that removes the source code offer. But that also means you are responsible for keeping your users informed, *regardless of what your stack looks like*. So if you do have a proxy server in front that, due to whatever it does to the protocol, does not automatically propagate the source code offer, then you are responsible for making sure it is included. Thus, a restriction on usage. Furthermore, the license is incredibly vague as to what happens when these modified versions are further distributed. Barring copyright assignment style setups, it would seem this requirement to inform the software's remote users of the opportunity to receive the source would propagate upstream and be a requirement, ever since the very first patch contribution. After all, nothing in the license says it goes away when changes are upstreamed, and upstreaming has no special meaning in copyright law. If you instead interpret the clause to mean that *literally only the person making the changes* is required to enforce any of this, then the AGPL has no teeth, because I could just patch some AGPLed software, give it to you (but not host it), and then you could host it free of any obligations to notify users of the patches. So, pick your poison. Either the AGPL has a viral clause that imposes restrictions on usage on its users, or it is completely pointless and there are several ways to work around it and host modified versions without offering source. I'm sure AGPLed project authors and the FSF would like to hear if you think the second interpretation is correct :-) > The AGPL itself confirms this in section 9. Section 13 starts with "Notwithstanding any other provision of this License", so whatever section 9 says does not matter here. > Note that the Gentoo Social Contract [2] also mentions FSF and OSI approval. I already explained how a license can be OSI approved and still be an EULA; and Gentoo has a definition of EULA that includes the AGPLv3 as I explained (adds restrictions beyond "all rights reserved", assuming you interpret it in a way that does not completely invalidate its purpose). So which is it: does an EULA being OSI and FSF approved mean it does not have to be listed as @EULA and users do not need to explicitly agree to it, even though it is an EULA? Think practically about Gentoo users' responsibilities. I'm not asking Gentoo to remove AGPLed software, I'm asking Gentoo to ensure its users are informed about their obligations when they choose to use such software. > Exactly, and the issue isn't specific to any single distribution, therefore Gentoo > bugzilla isn't the best place to report it. I cited a bug report about licensing, and I'm a Gentoo user, so I reported it to Gentoo. Who is "upstream" here? The FSF? Obviously they aren't going to change the categorization of their own license. OSI? I already explained how their open source definition does not cover this issue. By marking this UPSTREAM, you are basically saying Gentoo does not care about its users being informed about licensing obligations, without allowing for any kind of discussion. Please reopen.
I don't think it's correct to make it @EULA but I'm all for disallowing it by default. Except it's gonna be pain due to mupdf.
(In reply to Hector Martin from comment #2) > CC mgorny, who previously opined on this subject. > > > Not true. There is no need to accept the license if you exercise only your statutory > > rights, which in many jurisdictions includes the right to run the program and to patch > > it if necessary (e.g., for compatibility with other programs). > > Are you saying that the stated steps to reproduce, i.e. hosting an (even > slightly) patched Nextcloud, do not infringe on the AGPL? If so, then the > AGPL is unenforceable and equivalent to the GPL. If not, how do you expect > Gentoo users to find out about their obligation to offer source for merely > hosting a modified copy (which no other free software license requires), if > not via explicit action by unmasking a license? > > > Also, our license list in @FREE is only a default. Users who disagree with it can ignore it > and either override it with their own list in the ACCEPT_LICENSE variable, or exclude > > specific licenses, e.g., by specifying "@FREE -AGPL-3 -AGPL-3+". > > The point here is this will catch users who don't know about this by > surprise. It caught me; I didn't know Nextcloud was AGPLed when I first > installed it, and I had a few dumb patches in while I was debugging a > problem. Those were temporary and are now gone, but for that time, I was in > violation of its license, unknowingly. > > > Again, that is not true. Running the program (freedom 0) is always allowed and doesn't > > even require acceptance of the license. > > Running the program as a network server isn't allowed if you have modified > it and neglected to inform your users of that fact, and offer source. Read > the paragraph carefully: > > > if you modify the Program, your modified version must prominently offer all users > > interacting with it remotely through a computer network [...] an opportunity to > > receive the Corresponding Source of your version [...] > > Note how it says *all users interacting with it remotely* - it does not > specify *direct* interaction, but rather ought to be read to include > indirect users. This makes sense, because otherwise you could just stick a > proxy server in front that removes the source code offer. But that also > means you are responsible for keeping your users informed, *regardless of > what your stack looks like*. So if you do have a proxy server in front that, > due to whatever it does to the protocol, does not automatically propagate > the source code offer, then you are responsible for making sure it is > included. Thus, a restriction on usage. > > Furthermore, the license is incredibly vague as to what happens when these > modified versions are further distributed. Barring copyright assignment > style setups, it would seem this requirement to inform the software's remote > users of the opportunity to receive the source would propagate upstream and > be a requirement, ever since the very first patch contribution. After all, > nothing in the license says it goes away when changes are upstreamed, and > upstreaming has no special meaning in copyright law. > > If you instead interpret the clause to mean that *literally only the person > making the changes* is required to enforce any of this, then the AGPL has no > teeth, because I could just patch some AGPLed software, give it to you (but > not host it), and then you could host it free of any obligations to notify > users of the patches. > > So, pick your poison. Either the AGPL has a viral clause that imposes > restrictions on usage on its users, or it is completely pointless and there > are several ways to work around it and host modified versions without > offering source. I'm sure AGPLed project authors and the FSF would like to > hear if you think the second interpretation is correct :-) > > > The AGPL itself confirms this in section 9. > > Section 13 starts with "Notwithstanding any other provision of this > License", so whatever section 9 says does not matter here. > > > Note that the Gentoo Social Contract [2] also mentions FSF and OSI approval. > > I already explained how a license can be OSI approved and still be an EULA; > and Gentoo has a definition of EULA that includes the AGPLv3 as I explained > (adds restrictions beyond "all rights reserved", assuming you interpret it > in a way that does not completely invalidate its purpose). So which is it: > does an EULA being OSI and FSF approved mean it does not have to be listed > as @EULA and users do not need to explicitly agree to it, even though it is > an EULA? Think practically about Gentoo users' responsibilities. I'm not > asking Gentoo to remove AGPLed software, I'm asking Gentoo to ensure its > users are informed about their obligations when they choose to use such > software. > > > Exactly, and the issue isn't specific to any single distribution, therefore Gentoo > > bugzilla isn't the best place to report it. > > I cited a bug report about licensing, and I'm a Gentoo user, so I reported > it to Gentoo. Who is "upstream" here? The FSF? Obviously they aren't going > to change the categorization of their own license. OSI? I already explained > how their open source definition does not cover this issue. > > By marking this UPSTREAM, you are basically saying Gentoo does not care > about its users being informed about licensing obligations, without allowing > for any kind of discussion. Please reopen. If you don't like the license, feel free to, as Ulm already suggested set your ACCEPT_LICENSES="@FREE -AGPL-3 -AGPL-3+" If you don't think the AGPL license is "FREE", please discuss with UPSTREAM; e.g. go file a bug with the OSI and convince them of your argument. We are unlikely to deviate from the OSI definitions; so I think you *actually* care about licensing your best impact would be to discuss with the OSI and FSF. -A
(In reply to Alec Warner from comment #4) > If you don't think the AGPL license is "FREE", please discuss with UPSTREAM; > e.g. go file a bug with the OSI and convince them of your argument. We are > unlikely to deviate from the OSI definitions; so I think you *actually* care > about licensing your best impact would be to discuss with the OSI and FSF. The AGPL license is "FREE" by the OSI definition of "FREE". I'm saying that definition is not useful, because it does not say anything about the freedom to use the software without limitations. Seriously, read the OSI free software definition. It doesn't talk at all about this, it's all about distribution and discrimination and other stuff. I could write in "you are not allowed to have more than two simultaneous remote users of the software" into my license and that would still be OSI-compliant, while blatantly an EULA. So if prefer to frame it this way, I'm asking Gentoo to consider not blanket allowing everything OSI labels as "free" by default, because that label includes licenses that users explicitly need to agree to before using the software without fear of violating the license.
(In reply to Hector Martin from comment #5) > (In reply to Alec Warner from comment #4) > > If you don't think the AGPL license is "FREE", please discuss with UPSTREAM; > > e.g. go file a bug with the OSI and convince them of your argument. We are > > unlikely to deviate from the OSI definitions; so I think you *actually* care > > about licensing your best impact would be to discuss with the OSI and FSF. > > The AGPL license is "FREE" by the OSI definition of "FREE". I'm saying that > definition is not useful, because it does not say anything about the freedom > to use the software without limitations. Seriously, read the OSI free > software definition. It doesn't talk at all about this, it's all about > distribution and discrimination and other stuff. I could write in "you are > not allowed to have more than two simultaneous remote users of the software" > into my license and that would still be OSI-compliant, while blatantly an > EULA. And again, this is a great conversation to have...with OSI :) > > So if prefer to frame it this way, I'm asking Gentoo to consider not blanket > allowing everything OSI labels as "free" by default, because that label > includes licenses that users explicitly need to agree to before using the > software without fear of violating the license. - All of this arguing should happen at the upptream level (e.g. argue with the OSI and FSF as to what should be included or not.) - We will generally follow the community definitions of free from the above entities. - We do this because it is useful to have consistency between distributions and many other distributions also follow these definitions. - We do this because its often a waste of time to have the same arguments in multiple venues; I'm usually pretty happy with the OSI and FSF definitions and I don't really believe having the discussions in Gentoo adds significant value. This is why we continue to keep this as RESOLVED UPSTREAM.
(In reply to Alec Warner from comment #6) > And again, this is a great conversation to have...with OSI :) I'm a Gentoo user, not an OSI user. OSI isn't software, and Gentoo and its packages aren't a derivative work of OSI :-) > - All of this arguing should happen at the upptream level (e.g. argue with > the OSI and FSF as to what should be included or not.) Obviously arguing with the FSF is moot here, as it is about their own license. So that's not an actionable thing you're asking of me here. That's just dismissing the problem by asking me to do the impossible. (I also happen to think the FSF's own policies are, these days, detrimental to the cause of free software, and some of their other actions are actively hostile towards users freedom in other ways which I can go into detail of if you're interested in the subject, so let's just say I'm not exactly interested in reaching out to them to change their mind about their own license. That would just be an enormous waste of everyone's time.) While OSI, well, they don't even *talk* about free software. They specifically talk about "open source" software, which is not the same thing. So I'm not sure how you expect me to convince them to completely rewrite their philosophy. They have a definition, and it's useful in some ways, but it's not useful to determine what licenses should not require user consent before installation, which is how Gentoo is using it. > - We will generally follow the community definitions of free from the above > entities. Which I've just explained puts users at risk, the way it is being used to decide the default ACCEPT_LICENSE. > - We do this because it is useful to have consistency between distributions > and many other distributions also follow these definitions. Right, when everyone's wrong, everyone's happy :-) (nevermind that most distros don't even *have* a concept like ACCEPT_LICENSE, they usually just have coarse repo selection if that). > - We do this because its often a waste of time to have the same arguments > in multiple venues; I'm usually pretty happy with the OSI and FSF > definitions and I don't really believe having the discussions in Gentoo adds > significant value. I'm bringing up how those definitions are not satisfactory in this case, and therefore Gentoo may not want to use them. Why immediately dismiss the argument and close the bug? > This is why we continue to keep this as RESOLVED UPSTREAM. And thus Gentoo continues to put its users at risk of unknowingly violating default-accepted languages with innocuous usage.
(In reply to Hector Martin from comment #2) > Furthermore, the license is incredibly vague as to what happens when these > modified versions are further distributed. Barring copyright assignment > style setups, it would seem this requirement to inform the software's remote > users of the opportunity to receive the source would propagate upstream and > be a requirement, ever since the very first patch contribution. After all, > nothing in the license says it goes away when changes are upstreamed, and > upstreaming has no special meaning in copyright law. > > If you instead interpret the clause to mean that *literally only the person > making the changes* is required to enforce any of this, then the AGPL has no > teeth, because I could just patch some AGPLed software, give it to you (but > not host it), and then you could host it free of any obligations to notify > users of the patches. IANAL, but in my opinion the wording in section 13 is clear: "... if *you* modify the Program ...". If you just run the unmodified version that you've received then you've no such obligation. As I said in comment #1, running the unmodified version doesn't even require acceptance of the license. > Section 13 starts with "Notwithstanding any other provision of this License", > so whatever section 9 says does not matter here. See above, if you neither modify nor distribute the program then you need not accept the license. Section 9 simply confirms what copyright law says, and section 13 cannot override this. > I cited a bug report about licensing, and I'm a Gentoo user, so I reported > it to Gentoo. Who is "upstream" here? The FSF? Obviously they aren't going > to change the categorization of their own license. OSI? I already explained > how their open source definition does not cover this issue. Whatever upstream applies. FSF, OSI, or upstream of any specific package. Our labels simply (try to) state the fact that the package is distributed under a specific license, which only upstream can change. Similarly, our license groups @FSF-APPROVED and @OSI-APPROVED state the fact that a set of licenses has been approved by these organisations. > By marking this UPSTREAM, you are basically saying Gentoo does not care > about its users being informed about licensing obligations, without allowing > for any kind of discussion. Please reopen. I am saying that discussion at the distro level is pointless because we shall change neither the Free Software Definition nor the Open Source Definition. (In reply to Hector Martin from comment #5) > So if prefer to frame it this way, I'm asking Gentoo to consider not blanket > allowing everything OSI labels as "free" by default, because that label > includes licenses that users explicitly need to agree to before using the > software without fear of violating the license. Once again, you don't need to agree unless you modify or distribute the software.
(In reply to Michał Górny from comment #3) > I don't think it's correct to make it @EULA but I'm all for disallowing it > by default. Except it's gonna be pain due to mupdf. Heh, I don't like the AGPL either. Still, I believe that we should not open that can of worms, because our default would then be different from the generally accepted definition and from the default of most other distros.
(In reply to Ulrich Müller from comment #8) > IANAL, but in my opinion the wording in section 13 is clear: "... if *you* > modify the Program ...". If you just run the unmodified version that you've > received then you've no such obligation. As I said in comment #1, running > the unmodified version doesn't even require acceptance of the license. Sure, but every other Free license does not have this restriction on modification. Users can reasonably expect to be able to patch a php file of a free software webapp without running into license compliance issues... except for AGPLed software. This is not a negligible difference. It's something that *will* bite people, as it bi me. In particular, I would wager that of all people, Gentoo users are more likely to be patching some of the software they run. > > Section 13 starts with "Notwithstanding any other provision of this License", > > so whatever section 9 says does not matter here. > > See above, if you neither modify nor distribute the program then you need > not accept the license. Section 9 simply confirms what copyright law says, > and section 13 cannot override this. Yes, we're talking about modification here, which is something no other free license attempts to control when not followed by distribution. > Whatever upstream applies. FSF, OSI, or upstream of any specific package. > Our labels simply (try to) state the fact that the package is distributed > under a specific license, which only upstream can change. Similarly, our > license groups @FSF-APPROVED and @OSI-APPROVED state the fact that a set of > licenses has been approved by these organisations. To be more explicit here: I object to this configuration: /usr/portage/profiles/base/make.defaults:ACCEPT_LICENSE="-* @FREE" And specifically how it trickes down via: /usr/portage/profiles/license_groups:FREE @FREE-SOFTWARE @FREE-DOCUMENTS /usr/portage/profiles/license_groups:FREE-SOFTWARE @FSF-APPROVED @OSI-APPROVED @MISC-FREE Into @FSF-APPROVED @OSI-APPROVED unconditionally. I'm not asking that those two sets not accurately represent the FSF and OSI-approved license sets, I'm asking for the AGPL to be excluded from the default ACCEPT_LICENSE, regardless of mechanism. > I am saying that discussion at the distro level is pointless because we > shall change neither the Free Software Definition nor the Open Source > Definition. And I am saying that defaulting to blanket allowing software that follows those definitions to be installed (or, more specifically, that follows the Open Source Definition and that the FSF likes to claim follows the Free Software Definition, though that is disputable, but there is no way we can action that with them) puts users at risk when it comes to AGPLed software. > Once again, you don't need to agree unless you modify or distribute the > software. And lots of people modify open source software, that's why it's open source, and most people do not expect to be bound by distribution requirements for merely starting a server daemon or bringing up a webapp and making a change to the code.
Please read comment #9 again.
So this boils down to "we're just going to do what everyone else does" then. When everyone follows what everyone else is doing, no progress can be made. Sometimes you have to be first in pointing out a problem and taking action. Anyway, I would like to clarify some things before I give up pushing on this. 1. Do you agree that my original bug report is accurate, as far as the "steps to reproduce/results" section goes? 2. If so, do you think it's reasonable for all Gentoo users who might install AGPLed packages to be aware of this requirement of the AGPL, before making a local code change or adding an epatch_user patch to those packages, without engaging in redistribution (just running a service), and without any notice or explicit action required by portage? If this is going to come down to "the current situation is bad/dangerous for users but Gentoo refuses to do anything about it because it's a can of worms and nobody else has opened it yet" then I would like that on the record.
Oh, and one more thing I just realized. There are, by a quick count, ~49 ebuilds in portage which list an AGPL license, and apply patches. The act of emerging those ebuilds constitutes modifying the source code of an AGPL package, and thus the user is obligated to notify all network users of that fact, and link to the patch. Presumably none of those patches introduce the required notification themselves. This means that every single user of those ebuilds is in violation of the license if they operate it as a network server. I see one of those packages is =mail-filter/dspam-3.10.2-r3, which *I* happen to run on my email server, and which I didn't have the slightest clue was AGPLed, nevermind being patched by Gentoo. Great, now I am in violation of the AGPL again. Should I open a bug for each of those packages now, to add explicit links to the Gentoo portage github in their respective network protocols? What about packages that aren't inherently network servers but users might choose to operate as such in some fashion? Do you see how much of a giant mess this is?
(In reply to Hector Martin from comment #12) > 1. Do you agree that my original bug report is accurate, as far as the > "steps to reproduce/results" section goes? > > 2. If so, do you think it's reasonable for all Gentoo users who might > install AGPLed packages to be aware of this requirement of the AGPL, before > making a local code change or adding an epatch_user patch to those packages, > without engaging in redistribution (just running a service), and without any > notice or explicit action required by portage? The Gentoo Handbook already warns users not to rely on ACCEPT_LICENSE or the LICENSE variable: "[...] check the package itself in depth, including all files that you use." https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Optional:_Configuring_the_ACCEPT_LICENSE_variable (In reply to Hector Martin from comment #13) > Oh, and one more thing I just realized. There are, by a quick count, ~49 > ebuilds in portage which list an AGPL license, and apply patches. The act of > emerging those ebuilds constitutes modifying the source code of an AGPL > package, and thus the user is obligated to notify all network users of that > fact, and link to the patch. No, the user hasn't modified the program. The author of the patch has. That the resulting source code is distributed in separate files is merely a technical detail. (Similarly, applying another's patch doesn't make the user a copyright holder of the modified version.) The exact scenario of a user running a modified program from a distro has been discussed on the debian-legal mailing list some time ago: https://lists.debian.org/debian-legal/2013/07/msg00035.html (Richard Fontana is a lawyer and one of the main authors of the GPL-3, so he should have some authority there.) > [...]
(In reply to Ulrich Müller from comment #14) > The Gentoo Handbook already warns users not to rely on ACCEPT_LICENSE or the > LICENSE variable: > "[...] check the package itself in depth, including all files that you use." > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Optional: > _Configuring_the_ACCEPT_LICENSE_variable Nice disclaimer, but I don't think it's reasonable for users to be aware of the licensing intricacies of *every single package they install*, and the whole point of the default is that for normal usage they don't have to care for @FREE packages... except for AGPLed packages, which step outside reasonable expectations. That's why EULAs are something you accept, while the BSD and the GPL are not, as a user. > No, the user hasn't modified the program. The author of the patch has. That > the resulting source code is distributed in separate files is merely a > technical detail. (Similarly, applying another's patch doesn't make the user > a copyright holder of the modified version.) > > The exact scenario of a user running a modified program from a distro has > been discussed on the debian-legal mailing list some time ago: > https://lists.debian.org/debian-legal/2013/07/msg00035.html > > (Richard Fontana is a lawyer and one of the main authors of the GPL-3, so he > should have some authority there.) Debian isn't Gentoo, and a source-based metadistro isn't the same as a binary repository distro. If you want to make this argument, you're going to have to get legal opinion on that re-interpretation being valid, and the technical detail not being legally relevant. I do not see anything in the linked email that implies it extends to Gentoo too, which works *very* differently from Debian and other such distros.
(In reply to Hector Martin from comment #15) > (In reply to Ulrich Müller from comment #14) > > The Gentoo Handbook already warns users not to rely on ACCEPT_LICENSE or the > > LICENSE variable: > > "[...] check the package itself in depth, including all files that you use." > > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Optional: > > _Configuring_the_ACCEPT_LICENSE_variable > > Nice disclaimer, but I don't think it's reasonable for users to be aware of > the licensing intricacies of *every single package they install*, and the > whole point of the default is that for normal usage they don't have to care > for @FREE packages... except for AGPLed packages, which step outside > reasonable expectations. That's why EULAs are something you accept, while > the BSD and the GPL are not, as a user. > > > No, the user hasn't modified the program. The author of the patch has. That > > the resulting source code is distributed in separate files is merely a > > technical detail. (Similarly, applying another's patch doesn't make the user > > a copyright holder of the modified version.) > > > > The exact scenario of a user running a modified program from a distro has > > been discussed on the debian-legal mailing list some time ago: > > https://lists.debian.org/debian-legal/2013/07/msg00035.html > > > > (Richard Fontana is a lawyer and one of the main authors of the GPL-3, so he > > should have some authority there.) > > Debian isn't Gentoo, and a source-based metadistro isn't the same as a > binary repository distro. If you want to make this argument, you're going to > have to get legal opinion on that re-interpretation being valid, and the > technical detail not being legally relevant. I do not see anything in the > linked email that implies it extends to Gentoo too, which works *very* > differently from Debian and other such distros. So my concern is that this is just a never-ending conversation. I understand you disagree with our position (and I empathize) but I'm not really sure more conversation will somehow change how we view the situation. What I've said (and I think ulm@ has also said; but feel free to disagree ulm@) is that: - This problem is likely not specific to Gentoo. - It should be raised in a broader context where it can be addressed in a cross-distribution fashion. - Its likely Gentoo would adopt whatever that consensus ends up being, because we want to avoid inconsistency with other distributions and we want to use existing (well argued) legal arguments. That is how I see this matter progressing. I don't expect much value to come from continued conversations on this bug, sorry. -A
(In reply to Alec Warner from comment #16) > - This problem is likely not specific to Gentoo. Sure, I'd just appreciate it if we agree that this *is* a problem, regardless of whether Gentoo chooses to address it now or not. And that the source patches distributed as ebuilds scenario *is* quite specific to Gentoo and may, possibly, create problems with the AGPL specific to Gentoo; we would need legal opinion to clarify that.
