Re: GR proposal: the AGPL does not meet the DFSG (take 2)
On Thu, Nov 19, 2009 at 11:59:54AM +0100, Wouter Verhelst wrote: On Sun, Nov 15, 2009 at 02:37:51PM +0100, Bill Allombert wrote: Hello, I would like to move the discussion to debian-vote where it belongs. I'd like to apologize to have started this cross-post in the first place. (please CC me). Actually, I'm thinking it's probably more on-topic on -legal in this stage. But whatever. Well, I already sent a previous answer to debian-legal (by mistake, but still). On Sun, Nov 15, 2009 at 04:04:49AM +0100, Wouter Verhelst wrote: The idea was that if you distribute it in source form, someone else might start to run the software on the public internet and then the 'your modified version must offer' clause take effect. Indeed. So if you are a service provider, is the AGPL trivially bypassable by 1) not accepting it and 2) having someone else doing the modification for you but never actually providing any service themself? I'm not sure, but I'm also not sure how that is relevant to the discussion of whether the AGPL is or is not free? If this requirement cannot be bypassed, then the clause does apply and any argument on the freeness of the license that is based on such bypassing cannot be valid. My point was that compliance with section 13. lay squarely on the shoulder of the developer modifying the software since it is obvious that the AGPL drafters did not intent to put any liability to the service provider, and so my objections 2.2 and 2.3 stand. In particular, the developer has to offer the source code for as long as a service provider is using it, even if the developer is unaware of it. So it is not with every network conversation, but it is all users. Indeed. I guess the wording could/should be modified. If the license were to say that the offer must not be removed, and must be put in an appropriate place that is available to all users interacting with it and should not be hidden from view, that would probably be better. Then again, that's quite a convoluted to say something like that. Having said that, I'm not convinced it makes the license non-free. If you use a license on a piece of software that it was not meant for in the first place, then of course it will cause problems. AIUI, the AGPL was written for web apps, not for general-purpose software, and in that context this phrasing causes no ill effects. There is nothing fundamental in webapps which make webapps code improper for use in non-webapps applications. The right to take code in a project and reuse it for a totally different purpose is a fundamental free software right. If someone were to use the AGPL on a web server, that would be a problem. But I don't think that's the case, is it? Someone might want to reuse code in an AGPL software inside a webserver, but the AGPL prevent that. How a license that disallow use in web servers can be more free than a license that disallow use in genetic research ? How can it satisfy DFSG 6 ? In any case, thanks a lot for your contribution to the debate. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
On Sun, Nov 15, 2009 at 02:37:51PM +0100, Bill Allombert wrote: Hello, I would like to move the discussion to debian-vote where it belongs. I'd like to apologize to have started this cross-post in the first place. (please CC me). Actually, I'm thinking it's probably more on-topic on -legal in this stage. But whatever. On Sun, Nov 15, 2009 at 04:04:49AM +0100, Wouter Verhelst wrote: If you modify a GPL-licensed software and distribute the modified version in source form only, you do not have any long standing obligation. This is not the case here. That's not true. It says 'your modified version must offer', it does not say 'you must offer'. In other words, if you don't run it on the public Internet, there is no problem. The idea was that if you distribute it in source form, someone else might start to run the software on the public internet and then the 'your modified version must offer' clause take effect. Indeed. So if you are as service provider, is the AGPL trivially bypassable by having someone doing the modification for you but never actually provide any service ? After thinking about this a bit more, I'm actually not entirely sure about my previous statement here anymore. Indeed, you would probably need to be providing the source of the version you're running, even if you did not make any local modifications yourself. I strongly doubt that the AGPL put any kind of limitation/liability on merely running the software, for various reasons: 1) Philosophy: the FSF stance is that * The freedom to run the program, for any purpose (freedom 0). 2) Copyright law: mere copyright law do not allow to limit use of the software once you legally have a copy, so you do not have to agree with the AGPL in order to merely use the software, and so the AGPL cannot impose any condition upon you. 3) the AGPL text: Section 9: 9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. So if you are a service provider, is the AGPL trivially bypassable by 1) not accepting it and 2) having someone else doing the modification for you but never actually providing any service themself? I'm not sure, but I'm also not sure how that is relevant to the discussion of whether the AGPL is or is not free? If the requirement that such modifications are made available in a particular way can be bypassed, then it can be assumed to not apply and thus cannot cause the license to be non-free. If this requirement cannot be bypassed, then the clause does apply and any argument on the freeness of the license that is based on such bypassing cannot be valid. Assume this is web server. Are you suggesting it modify the page it serve to add the notice ? It says in a prominent place, not with every network conversation. It does not say either of that, it says 'your modified version must prominently offer all users interacting with it remotely through a computer network'. So it is not with every network conversation, but it is all users. Indeed. I guess the wording could/should be modified. If the license were to say that the offer must not be removed, and must be put in an appropriate place that is available to all users interacting with it and should not be hidden from view, that would probably be better. Then again, that's quite a convoluted to say something like that. Having said that, I'm not convinced it makes the license non-free. If you use a license on a piece of software that it was not meant for in the first place, then of course it will cause problems. AIUI, the AGPL was written for web apps, not for general-purpose software, and in that context this phrasing causes no ill effects. If someone were to use the AGPL on a web server, that would be a problem. But I don't think that's the case, is it? -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Hello, I would like to move the discussion to debian-vote where it belongs. I'd like to apologize to have started this cross-post in the first place. (please CC me). On Sun, Nov 15, 2009 at 04:04:49AM +0100, Wouter Verhelst wrote: If you modify a GPL-licensed software and distribute the modified version in source form only, you do not have any long standing obligation. This is not the case here. That's not true. It says 'your modified version must offer', it does not say 'you must offer'. In other words, if you don't run it on the public Internet, there is no problem. The idea was that if you distribute it in source form, someone else might start to run the software on the public internet and then the 'your modified version must offer' clause take effect. ... So if you are as service provider, is the AGPL trivially bypassable by having someone doing the modification for you but never actually provide any service ? After thinking about this a bit more, I'm actually not entirely sure about my previous statement here anymore. Indeed, you would probably need to be providing the source of the version you're running, even if you did not make any local modifications yourself. I strongly doubt that the AGPL put any kind of limitation/liability on merely running the software, for various reasons: 1) Philosophy: the FSF stance is that * The freedom to run the program, for any purpose (freedom 0). 2) Copyright law: mere copyright law do not allow to limit use of the software once you legally have a copy, so you do not have to agree with the AGPL in order to merely use the software, and so the AGPL cannot impose any condition upon you. 3) the AGPL text: Section 9: 9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. So if you are a service provider, is the AGPL trivially bypassable by 1) not accepting it and 2) having someone else doing the modification for you but never actually providing any service themself? Assume this is web server. Are you suggesting it modify the page it serve to add the notice ? It says in a prominent place, not with every network conversation. It does not say either of that, it says 'your modified version must prominently offer all users interacting with it remotely through a computer network'. So it is not with every network conversation, but it is all users. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. signature.asc Description: Digital signature
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
On Fri, Nov 13, 2009 at 02:24:38PM +0100, Bill Allombert wrote: On Wed, Nov 11, 2009 at 11:11:40PM +0100, Wouter Verhelst wrote: On Wed, Nov 11, 2009 at 08:52:23PM +0100, Bill Allombert wrote: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software might require you to write a substantial amount of extra code to comply with this clause. How is this any different from the requirement in the regular GPL to provide source at no cost? Often this is done through website, too. If you modify a GPL-licensed software and distribute the modified version in source form only, you do not have any long standing obligation. This is not the case here. That's not true. It says 'your modified version must offer', it does not say 'you must offer'. In other words, if you don't run it on the public Internet, there is no problem. 2.2 This clause forces the developer modifying the software to incur cost. A developer modifying the software and distributing the modified version need to incur the cost of providing access to the Corresponding Source from a network server as long as at least one person is using the software and this for all published modifications, even long after the developer stopped using and/or distributing the software. Actually, that's not true. This clause applies to service providers who provide a service based upon a slightly modified piece of AGPL software. The requirement to The clause apply to whoever made the modification, not whoever provide the service. They might be different people, and the modifier should not be responsible for what the service provider do. Do you agree ? No, I do not agree. Similarly to how the regular GPL only triggers when you distribute software, this clause only triggers when the software is run. Indeed, the developer modifying the code should not be responsible for what the service provider does, but it is perfectly possible for such a developer to add a fill in the blanks type of hyperlink to the application, which the service provider must then replace with a hyperlink to the actual source that they're using (presumably on their own server). The clause says the software must provide a link to the source. It does not say the developer must make the source available. distribute the modifications only applies to your service: if you modify the program, your modified version must [...] offer [...] an opportunity to receive the Corresponding Source of your version It does not say that you must distribute the Corresponding Source for all eternity. The license does not specify a limitation of time. There is no time limitation, indeed, but it only applies for as long as users can get at an instance of the software as you are running it. Once you stop doing that, the requirement will automatically go away, too. Compliance with this clause can be accomplished by simply adding a hyperlink to a .tar.gz with your source on an appropriate place. This require you for keeping the .tar.gz online for as long a people are providing services using your modified software, which can be a long time after you stopped distributing it and stopped to care about it. Again, there is no such requirement for the developer. It is perfectly possible for a developer to provide instructions in an INSTALL file or something similar that explains that anyone installing the software must put the source tarball online along with the installed program. That does require you to have proper procedures in place to make sure the .tar.gz is always up-to-date with regards to the 'released' version of your service, but this is no different from doing the same with releasing embedded hardware that uses GPL software, for instance. Not really: with the GPL, you can just ship a CD-ROM with the source code with each embedded devices. At this point your have no further obligation. (I bought several devices which provided such CD-ROM. This is far from hypothetical.) In that case, the CD-ROM needs to contain the right version of the source code (and not the version that was used until three hours before release, when a final critical bug was found). That requires proper procedures to be in place, in much the same way as the AGPL requires you to have proper procedures to be in place. [...] -- A user of the modified version can mis-install it, mis-configure it or run it in an untested environment where it does not comply with this clause. -- A user of the modified version can use it in a configuration that cause it to fail to comply with this clause (for example using a reverse proxy that remove link to the source code from the html output). No. If you do not modify the software _yourself_, you do not need to publish such a link. Only if you have local modifications is
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
On Wed, Nov 11, 2009 at 11:11:40PM +0100, Wouter Verhelst wrote: On Wed, Nov 11, 2009 at 08:52:23PM +0100, Bill Allombert wrote: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software might require you to write a substantial amount of extra code to comply with this clause. How is this any different from the requirement in the regular GPL to provide source at no cost? Often this is done through website, too. If you modify a GPL-licensed software and distribute the modified version in source form only, you do not have any long standing obligation. This is not the case here. 2.2 This clause forces the developer modifying the software to incur cost. A developer modifying the software and distributing the modified version need to incur the cost of providing access to the Corresponding Source from a network server as long as at least one person is using the software and this for all published modifications, even long after the developer stopped using and/or distributing the software. Actually, that's not true. This clause applies to service providers who provide a service based upon a slightly modified piece of AGPL software. The requirement to The clause apply to whoever made the modification, not whoever provide the service. They might be different people, and the modifier should not be responsible for what the service provider do. Do you agree ? distribute the modifications only applies to your service: if you modify the program, your modified version must [...] offer [...] an opportunity to receive the Corresponding Source of your version It does not say that you must distribute the Corresponding Source for all eternity. The license does not specify a limitation of time. Compliance with this clause can be accomplished by simply adding a hyperlink to a .tar.gz with your source on an appropriate place. This require you for keeping the .tar.gz online for as long a people are providing services using your modified software, which can be a long time after you stopped distributing it and stopped to care about it. That does require you to have proper procedures in place to make sure the .tar.gz is always up-to-date with regards to the 'released' version of your service, but this is no different from doing the same with releasing embedded hardware that uses GPL software, for instance. Not really: with the GPL, you can just ship a CD-ROM with the source code with each embedded devices. At this point your have no further obligation. (I bought several devices which provided such CD-ROM. This is far from hypothetical.) 2.2. While this clause does restrict mere use of the software, instead it creates liabilities for people modifying the software, even if they distributed their modified version in source form, with respect to the way the software perform on user systems. -- Modifying the software can unwillingly introduce a bug that cause it not to comply with this clause. That hardly matters; bugs can be fixed. If you bring someone to court because they introduced a bug in their software, I'm sure the judge will punish you for wasting the court's time. On the other hand, if such a bug were to exist and the developers would seem unwilling to fix the issue in a reasonable timeframe upon being notified of the problem, then that would mean they simply do not comply with the requirements of this license, and should be sued. The developer might release a fixed version of the software (and thus a new Corresponding Source) without being able to force the service provider to switch to that new version, which has no legal obligation. -- A user of the modified version can mis-install it, mis-configure it or run it in an untested environment where it does not comply with this clause. -- A user of the modified version can use it in a configuration that cause it to fail to comply with this clause (for example using a reverse proxy that remove link to the source code from the html output). No. If you do not modify the software _yourself_, you do not need to publish such a link. Only if you have local modifications is this necessary. So if you are as service provider, is the AGPL trivially bypassable by having someone doing the modification for you but never actually provide any service ? 3. This clause is incompatible with Section 6. of the Debian Free Software Guideline. 3.1 This clause does not allow you to modify the software to perform tasks where complying with it is not technically feasible, for example: -- The code is modified to run on an embedded system with tight size limit. -- The code is modified to interact with the user using a network connection with extremely low throughput. Nowhere does that clause say that
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Russell Coker wrote: On Thu, 12 Nov 2009, Wouter Verhelst wou...@debian.org wrote: First, network protocols that do not allow to display anything are abundant, since no network protocol displays anything -- clients that use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot. If you connect to my SMTP server you will see a legal disclaimer (which I claim to be as valid as any that you may see in a .sig). [..] Now in terms of granting rights, if my mail server contained AGPL code and this was displayed in the SMTP protocol then a user could connect to it and discover whether I was using code for which they could demand the source. I disagree with your interpretation. The AGPL states prominently offer all users, displaying at protocol level doesn't comply with either prominently nor with all users (because only a few sysadmins will telnet to port 25.) Such offer should be on SMTP *and* on the website offering this service. (Would you consider it valid if the offer were included in HTTP headers?) /me don't like AGPL, especially due to the way linked/combined code is contaminated. I hate the way FSF made an exception for GPL-v3, and not for any compatible license. That's proprietary sh*t. Regards, Franklin -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Frank Lin PIAT a écrit : Russell Coker wrote: On Thu, 12 Nov 2009, Wouter Verhelst wou...@debian.org wrote: First, network protocols that do not allow to display anything are abundant, since no network protocol displays anything -- clients that use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot. If you connect to my SMTP server you will see a legal disclaimer (which I claim to be as valid as any that you may see in a .sig). [..] Now in terms of granting rights, if my mail server contained AGPL code and this was displayed in the SMTP protocol then a user could connect to it and discover whether I was using code for which they could demand the source. I disagree with your interpretation. The AGPL states prominently offer all users, displaying at protocol level doesn't comply with either prominently nor with all users (because only a few sysadmins will telnet to port 25.) Such offer should be on SMTP *and* on the website offering this service. I fail to see how it would be more prominently offered. At least tcp/25 is related to the service itself, a website has nothing to do with it. (I mean, there /might/ be a website offering the service, but in most cases there is not). Cheers, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Hi, On Wed, 11.11.2009 at 23:46:59 +0100, Martin Langhoff martin.langh...@gmail.com wrote: Yes, this is one of the awkward things I find in the AGPL. If it's not a webapp, what then? please see this: http://www.fsf.org/licensing/licenses/gpl-faq.html#AGPLv3InteractingRemotely It could eg. also be network file system software (NFS, AFS, SMB, etc.). If the software uses some other protocol that doesn't allow you to do some lay-out like HTTP does, then you simply need to make sure that people using your software are informed out-of-band. That would be complying with the spirit of the license, but not the actual clause AFAICS. Ok. I'd say that this should have been an oversight in the formulation of the license, but maybe consulting the original discussions when the license was in the making, could be enlightening. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
On Thu, Nov 12, 2009 at 1:24 PM, Toni Mueller t...@debian.org wrote: Hi, On Wed, 11.11.2009 at 23:46:59 +0100, Martin Langhoff martin.langh...@gmail.com wrote: Yes, this is one of the awkward things I find in the AGPL. If it's not a webapp, what then? please see this: http://www.fsf.org/licensing/licenses/gpl-faq.html#AGPLv3InteractingRemotely It could eg. also be network file system software (NFS, AFS, SMB, etc.). Yes, I am aware of that. What I was trying to say is how do we comply, then? That would be complying with the spirit of the license, but not the actual clause AFAICS. Ok. I'd say that this should have been an oversight in the formulation of the license, but maybe consulting the original discussions when the license was in the making, could be enlightening. Yes, it will help us understand the spirit better. But we are looking at what the license actually says. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
GR proposal: the AGPL does not meet the DFSG (take 2)
Dear developers, I respectfully submit this general resolution proposal to your consideration. (this GR proposal supersedes the proposal in 20090318235044.ga30...@yellowpig) Asking for seconds, (please CC me) Bill. ballo...@debian.org This General Resolution is made in accordance with Debian Constitution 4.1.5, however it overrides a decision of the FTP masters made in 87k5aovzzi@delenn.ganneff.de [1]. [1] http://lists.debian.org/debian-legal/2008/11/msg00097.html = Text of the GR === The Debian project resolves that softwares licensed under the GNU Affero General Public License are not free according to the Debian Free Software Guideline. = End of the text == RATIONALE (to be amended if necessary): 1. The GNU Affero General Public License (AGPL) is essentially the GNU General Public License with the following additional clause reproduced below. See http://www.fsf.org/licensing/licenses/agpl.html for the full text of the license. 13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License. 2. This clause is incompatible with Section 3. of the Debian Free Software Guideline: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software might require you to write a substantial amount of extra code to comply with this clause. 2.2 This clause forces the developer modifying the software to incur cost. A developer modifying the software and distributing the modified version need to incur the cost of providing access to the Corresponding Source from a network server as long as at least one person is using the software and this for all published modifications, even long after the developer stopped using and/or distributing the software. 2.2. While this clause does restrict mere use of the software, instead it creates liabilities for people modifying the software, even if they distributed their modified version in source form, with respect to the way the software perform on user systems. -- Modifying the software can unwillingly introduce a bug that cause it not to comply with this clause. -- A user of the modified version can mis-install it, mis-configure it or run it in an untested environment where it does not comply with this clause. -- A user of the modified version can use it in a configuration that cause it to fail to comply with this clause (for example using a reverse proxy that remove link to the source code from the html output). 3. This clause is incompatible with Section 6. of the Debian Free Software Guideline. 3.1 This clause does not allow you to modify the software to perform tasks where complying with it is not technically feasible, for example: -- The code is modified to run on an embedded system with tight size limit. -- The code is modified to interact with the user using a network connection with extremely low throughput. -- The code is modified to interact with the user using a network protocol that does not allow to display a prominent offer. signature.asc Description: Digital signature
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Bill Allombert wrote: 13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. This is obviously only relevant if the software is interacted with remotely which is made cristal clear with the '(if your version supports such interaction)'. 2. This clause is incompatible with Section 3. of the Debian Free Software Guideline: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software might require you to write a substantial amount of extra code to comply with this clause. Not at all unless the modified version is interacted with remotely which should make providing the source trivial AFAICS? 2.2 This clause forces the developer modifying the software to incur cost. A developer modifying the software and distributing the modified version need to incur the cost of providing access to the Corresponding Source from a network server as long as at least one person is using the software and this for all published modifications, even long after the developer stopped using and/or distributing the software. As long as the users are using it by interacting remotely with it... 2.2. While this clause does restrict mere use of the software, instead it creates liabilities for people modifying the software, even if they distributed their modified version in source form, with respect to the way the software perform on user systems. If you distribute it in source form, there are no users interacting with it remotely AFAICS? -- Modifying the software can unwillingly introduce a bug that cause it not to comply with this clause. How so? -- A user of the modified version can mis-install it, mis-configure it or run it in an untested environment where it does not comply with this clause. Yes, that's the same for many other software where you for instance need to show a disclaimer. -- A user of the modified version can use it in a configuration that cause it to fail to comply with this clause (for example using a reverse proxy that remove link to the source code from the html output). Same as above. 3. This clause is incompatible with Section 6. of the Debian Free Software Guideline. 3.1 This clause does not allow you to modify the software to perform tasks where complying with it is not technically feasible, for example: -- The code is modified to run on an embedded system with tight size limit. And there will be users remotely interacting with it? While possible, it's something to consider when using it on an embedded device. Though the same is true for huge applications. -- The code is modified to interact with the user using a network connection with extremely low throughput. Why would that cause any problem? It's not because one needs to provide the source that it has to be downloaded AFAICS? -- The code is modified to interact with the user using a network protocol that does not allow to display a prominent offer. Any example of this? Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
On Wed, Nov 11, 2009 at 08:52:23PM +0100, Bill Allombert wrote: Dear developers, I respectfully submit this general resolution proposal to your consideration. (this GR proposal supersedes the proposal in 20090318235044.ga30...@yellowpig) Asking for seconds, (please CC me) Bill. ballo...@debian.org This General Resolution is made in accordance with Debian Constitution 4.1.5, however it overrides a decision of the FTP masters made in 87k5aovzzi@delenn.ganneff.de [1]. [1] http://lists.debian.org/debian-legal/2008/11/msg00097.html = Text of the GR === The Debian project resolves that softwares licensed under the GNU Affero General Public License are not free according to the Debian Free Software Guideline. = End of the text == RATIONALE (to be amended if necessary): 1. The GNU Affero General Public License (AGPL) is essentially the GNU General Public License with the following additional clause reproduced below. See http://www.fsf.org/licensing/licenses/agpl.html for the full text of the license. 13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License. 2. This clause is incompatible with Section 3. of the Debian Free Software Guideline: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software might require you to write a substantial amount of extra code to comply with this clause. How is this any different from the requirement in the regular GPL to provide source at no cost? Often this is done through website, too. 2.2 This clause forces the developer modifying the software to incur cost. A developer modifying the software and distributing the modified version need to incur the cost of providing access to the Corresponding Source from a network server as long as at least one person is using the software and this for all published modifications, even long after the developer stopped using and/or distributing the software. Actually, that's not true. This clause applies to service providers who provide a service based upon a slightly modified piece of AGPL software. The requirement to distribute the modifications only applies to your service: if you modify the program, your modified version must [...] offer [...] an opportunity to receive the Corresponding Source of your version It does not say that you must distribute the Corresponding Source for all eternity. Compliance with this clause can be accomplished by simply adding a hyperlink to a .tar.gz with your source on an appropriate place. That does require you to have proper procedures in place to make sure the .tar.gz is always up-to-date with regards to the 'released' version of your service, but this is no different from doing the same with releasing embedded hardware that uses GPL software, for instance. 2.2. While this clause does restrict mere use of the software, instead it creates liabilities for people modifying the software, even if they distributed their modified version in source form, with respect to the way the software perform on user systems. -- Modifying the software can unwillingly introduce a bug that cause it not to comply with this clause. That hardly matters; bugs can be fixed. If you bring someone to court because they introduced a bug in their software, I'm sure the judge will punish you for wasting the court's time. On the other hand, if such a bug were to exist and the developers would seem unwilling to fix the issue in a reasonable timeframe upon being notified of the problem, then that would mean they simply do not comply with the requirements of this license, and should be sued. -- A user of the modified version can mis-install it,
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
On Wed, Nov 11, 2009 at 11:11 PM, Wouter Verhelst wou...@debian.org wrote: -- The code is modified to interact with the user using a network protocol that does not allow to display a prominent offer. This is actually your best argument so far, but I don't think it's completely true either. Yes, this is one of the awkward things I find in the AGPL. If it's not a webapp, what then? If the software uses some other protocol that doesn't allow you to do some lay-out like HTTP does, then you simply need to make sure that people using your software are informed out-of-band. That would be complying with the spirit of the license, but not the actual clause AFAICS. your modified version must prominently offer all users interacting with it [...] I don't think that must necessarily be interpreted into saying that it must be done by the software itself, Well, it sounds like it does mean exactly that. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
On Thu, 12 Nov 2009, Wouter Verhelst wou...@debian.org wrote: First, network protocols that do not allow to display anything are abundant, since no network protocol displays anything -- clients that use the protocol do. This is true for HTTP, FTP, SMTP, and whatnot. If you connect to my SMTP server you will see a legal disclaimer (which I claim to be as valid as any that you may see in a .sig). The fact that the vast majority of SMTP clients don't check for such things should have the exact same amount of legal relevance as the fact that most Microsoft customers don't read their EULA. Now in terms of granting rights, if my mail server contained AGPL code and this was displayed in the SMTP protocol then a user could connect to it and discover whether I was using code for which they could demand the source. It would be entirely reasonable and plausible for someone to admire some features that were in a running mail server, connect to port 25 with nc or telnet, see a notification of AGPL code, and then demand a copy of the source. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Mon, Apr 06, 2009 at 09:27:06AM +0200, Lionel Elie Mamane wrote: On Mon, Apr 06, 2009 at 02:02:42AM +0200, Bill Allombert wrote: On Sat, Apr 04, 2009 at 02:27:10PM +0200, Lionel Elie Mamane wrote: On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote: RATIONALE (to be amended if necessary): 2. This clause is incompatible with section 3. of the Debian Free Software Guideline: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software can require you to write a substantial amount of extra code to comply with this clause. No, it does not. Merely modifying the software does not trigger the clause. It is triggered only if you offer a service to third parties using your modified version, or distribute it to others that do. The latter part (distribute to others that do) is unfortunate; I expect it is not the intention of the AGPL writers. As written, suppose you modify it and distribute it (in source form) Exactly: modify _and_ distribute. Modify alone is not a trigger (to fall back to math jargon, it is not a sufficient condition). and it reachs the original copyright holder, they can run it and complains if it does not prominently offer all users interacting with it remotely through a computer network. So in practice the clause is triggered as soon as your version supports such interaction. _If_ you distribute it (or run it so that others can interact with it). Similarly, clauses 5c, 5d, 6 of the GNU GPL gets triggered on distribution, not on modification alone. You are correct. I misread what you wrote (specifically or distribute it to others that do). Distribution is the same trigger than what triggers the copyleft clauses of the ordinary GPL; so that trigger cannot in itself be a problem for DFSG freedom. The trigger seems to be modification rather than distribution. No, conjunction of the two (or conjunction of modification and letting others interact with it). So to summary the trigger is: 1) Modification and distribution (even in source form). or 2) Modification and use it so that others can interact with it remotely through a computer network. There is a big uncertainty there what interacting with the user means; a library of mathematical functions clearly would not. A complete PHP-style application like mailman, imp, ... clearly would. But a PHP library that produces chunks of HTML to be displayed to the user by the caller? I don't know. This one of several uncertainty with this license which make me really uncomfortable. Free softwares licenses should not require you to be a lawyer to understand them. 1) your program must fit in 8kB or Why is that not a problem for clause 5d of the GNU GPL v3 (clause 2d of version 2), which we do consider free? Imagine a GPLed program whose interactive user interfaces _do_ display Appropriate Legal Notices. Damn, you want to squeeze within a small size, and the Appropriate Legal Notices make you go over the limit. How is that situation different from the AGPL one? I am not necessarily a fan of that particular clause of the GPL because it interfers with DFGS-3, but it reads: d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. which is much less obnoxious than the AGPL. At least you can remove the interactive user interfaces and then remove the Appropriate Legal Notices. 2) your program interact with users in a low-level way that preclude from proheminently offering or I'm not sure I understand what that means. Very low-level would be... e.g. blinking lights and switches, like very early hobbyist computers? Then the user is assumed to be understanding some protocol over these blinking lights. But that protocol may not be rich enough for an URL or similar (e.g. the protocol is just one 8-bit number in base two through eight non-blinking lights). Yes, OK, that's a clear-cut (if corner) case where it is a real problem. 3) your program can send notice of offering source but clients programs for this protocol generally never display such notice, so it is not proheminent or (e.g. a pop3 server can display a message when you telnet to it, but almost nobody ever does that). Is a POP3 server, when not being used through telnet / nc / ..., interacting with a user? It seems to me it is not; it is interacting with the user's mail retrieval agent (fetchmail, icedove, ...). What would you say if a CGI script was offering source by means of HTTP headers instead of in the HTML code ? Maybe the POP3 server is required to create an email containing the offer and push it to the user. In any case, thanks for your contribution to this discussion. Cheers, -- Bill. ballo...@debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Mon, Apr 06, 2009 at 02:02:42AM +0200, Bill Allombert wrote:
On Sat, Apr 04, 2009 at 02:27:10PM +0200, Lionel Elie Mamane wrote:
On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote:
RATIONALE (to be amended if necessary):
2. This clause is incompatible with section 3. of the Debian Free Software
Guideline:
2.1 This clause restricts how you can modify the software.
Doing a simple modification to a AGPL-covered software can require you
to
write a substantial amount of extra code to comply with this
clause.
No, it does not. Merely modifying the software does not trigger the
clause. It is triggered only if you offer a service to third parties
using your modified version, or distribute it to others that do. The
latter part (distribute to others that do) is unfortunate; I expect it
is not the intention of the AGPL writers.
As written, suppose you modify it and distribute it (in source form)
Exactly: modify _and_ distribute. Modify alone is not a trigger (to
fall back to math jargon, it is not a sufficient condition).
and it reachs the original copyright holder, they can run it and
complains if it does not prominently offer all users interacting
with it remotely through a computer network. So in practice the
clause is triggered as soon as your version supports such
interaction.
_If_ you distribute it (or run it so that others can interact with
it). Similarly, clauses 5c, 5d, 6 of the GNU GPL gets triggered on
distribution, not on modification alone.
Distribution is the same trigger than what triggers the copyleft
clauses of the ordinary GPL; so that trigger cannot in itself be a
problem for DFSG freedom.
The trigger seems to be modification rather than distribution.
No, conjunction of the two (or conjunction of modification and letting
others interact with it).
Even if the clause is triggered, the most additional extra amount
of code you have to write is provide a link to a download
location.
This assumes the program is a CGI script or at least can display
text content to the users interacting with it through a network.
Well, the clause applies only to versions that interact with users; so
we place ourselves in the case where the program is interacting with
the user in some way. So it is giving the user messages in some form,
be it text, hypertext, audio, pictures, ... _And_ the user is giving
messages to the program, in some form such as following links, mouse
clicks, keyboard key presses, ... So if it has to obey this clause, it
has the ability to convey some content to the user. If the only
content it can convey is audio, then read an URL aloud slowly enough
so that a normal person can follow.
Interaction is necessarily bidirectional in my understanding; the
program can communicate to the user and the user can communicate
(usually give orders) to the program.
Adding exactly one string in a relatively prominent place. That's
not a substantial amount, especially as typically an AGPL-covered
software will already have the download link or mechanism, you only
have to change the URL or something like that. I'd
be sympathetic to a statement along the lines of:
Software licensed under the AGPL, that does not itself provide an
opportunity to receive the Corresponding Source in the meaning
of clause 13, or is structured such that changing this opportunity
to the source of modified version is not easy, is non DFSG-free,
if it is not free for other reasons (e.g. dual license BSD /
AGPL).
What if you are reusing only part of the software ?
If that part interacts with the user, the clause applies, but you
interact with the user, so you can. If that part does not interact
with the user, you are off the hook.
There is a big uncertainty there what interacting with the user
means; a library of mathematical functions clearly would not. A
complete PHP-style application like mailman, imp, ... clearly
would. But a PHP library that produces chunks of HTML to be displayed
to the user by the caller? I don't know.
What if your version (but not the original) implement a limited
protocol that does not allow to convey arbitrary messages to the
users ?
You are designing the protocol anyway; add one message to your
protocol that says full sources available at... / do ${ACTION} to get
the sources, ...
But what if you cannot chose the protocol, but want to be a drop-in
replacement for another program (e.g. some non-free program)? Yes,
that can be a real problem.
2.2 This clause forces the developer modifying the software to incur the
cost
of providing access to the Corresponding Source from a network server
as long as at least one person is using the software and this for
all published modifications, even long after the developer stopped using
the software.
Ah, I see. That's probably unfortunate wording; the onus should be on
the person providing a service to third parties through the software,
not the developer
Re: GR proposal: the AGPL does not meet the DFSG
On Mon, Apr 06, 2009 at 06:49:57AM +0300, Aigars Mahinovs wrote: 2009/3/19 Bill Allombert bill.allomb...@math.u-bordeaux1.fr: Dear developers, I respectfully submit this general resolution proposal to your consideration. Asking for seconds. - - - - - - - General Resolution made in accordance with Debian Constitution 4.1.5: The Debian project resolves that softwares licensed under the GNU Affero Public License are not free according to the Debian Free Software Guideline. - - - - - - - I second the above proposal. gpg: BAD signature from Aigars Mahinovs aigar...@debian.org Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Sat, Apr 04, 2009 at 02:27:10PM +0200, Lionel Elie Mamane wrote: On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote: RATIONALE (to be amended if necessary): First of all, thanks a lot for your helpful contribution to this discussion. 2. This clause is incompatible with section 3. of the Debian Free Software Guideline: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software can require you to write a substantial amount of extra code to comply with this clause. No, it does not. Merely modifying the software does not trigger the clause. It is triggered only if you offer a service to third parties using your modified version, or distribute it to others that do. The latter part (distribute to others that do) is unfortunate; I expect it is not the intention of the AGPL writers. As written, suppose you modify it and distribute it (in source form) and it reachs the original copyright holder, they can run it and complains if it does not prominently offer all users interacting with it remotely through a computer network. So in practice the clause is triggered as soon as your version supports such interaction. Distribution is the same trigger than what triggers the copyleft clauses of the ordinary GPL; so that trigger cannot in itself be a problem for DFSG freedom. The trigger seems to be modification rather than distribution. Even if the clause is triggered, the most additional extra amount of code you have to write is provide a link to a download location. This assumes the program is a CGI script or at least can display text content to the users interacting with it through a network. Adding exactly one string in a relatively prominent place. That's not a substantial amount, especially as typically an AGPL-covered software will already have the download link or mechanism, you only have to change the URL or something like that. I'd be sympathetic to a statement along the lines of: Software licensed under the AGPL, that does not itself provide an opportunity to receive the Corresponding Source in the meaning of clause 13, or is structured such that changing this opportunity to the source of modified version is not easy, is non DFSG-free, if it is not free for other reasons (e.g. dual license BSD / AGPL). What if you are reusing only part of the software ? What if your version (but not the original) implement a limited protocol that does not allow to convey arbitrary messages to the users ? 2.2 This clause forces the developer modifying the software to incur the cost of providing access to the Corresponding Source from a network server as long as at least one person is using the software and this for all published modifications, even long after the developer stopped using the software. Ah, I see. That's probably unfortunate wording; the onus should be on the person providing a service to third parties through the software, not the developer having made the modification. But indeed, the latter seems to be what the license is technically saying. I am unsure it is unfortunate wording: copyright law does not permit to impose arbitrary restriction on usage, and generally free software avoid to restrict usage. Thus they can only restrict distribution (usual) or modification (here). 3. This clause is incompatible with section 6. of the Debian Free Software Guideline. 3.1 This clause does not allow you to modify the software to perform tasks where complying with it is not technically feasible. I have difficulties imagining a scenario where complying with it is not technically feasible; also, it seems similar to the GPL's mechanism of if you cannot legally obey both the GPL and patent law / a contract you have signed / ..., then you are not allowed to distribute at all. That would be not legally feasible. Not technically feasible would mean you have technical requirement such that: 1) your program must fit in 8kB or 2) your program interact with users in a low-level way that preclude from proheminently offering or 3) your program can send notice of offering source but clients programs for this protocol generally never display such notice, so it is not proheminent or 4) etc. (e.g. a pop3 server can display a message when you telnet to it, but almost nobody ever does that). Cheers, Bill signature.asc Description: Digital signature
Re: GR proposal: the AGPL does not meet the DFSG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2009/3/19 Bill Allombert bill.allomb...@math.u-bordeaux1.fr: Dear developers, I respectfully submit this general resolution proposal to your consideration. Asking for seconds. - - - - - - - General Resolution made in accordance with Debian Constitution 4.1.5: The Debian project resolves that softwares licensed under the GNU Affero Public License are not free according to the Debian Free Software Guideline. - - - - - - - I second the above proposal. For me the whole reason of the DFSG is so that our user would be able to take all the software in main, use it, change it and distribute it with minimal legal hassle. Due to reasons other people voiced in the thread, I do not think GNU AGPL fulfill the implicit 'no legal surprises' criteria. - -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--# -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5) iEYEARECAAYFAknZe9AACgkQMzCiFWcgm94RGQCePG2uVJv1aZpYtCFEIBLsZYMy 8kEAmgNQLXJy3zR9IzUSG7KSEqB12+LY =mERC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote: RATIONALE (to be amended if necessary): 2. This clause is incompatible with section 3. of the Debian Free Software Guideline: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software can require you to write a substantial amount of extra code to comply with this clause. No, it does not. Merely modifying the software does not trigger the clause. It is triggered only if you offer a service to third parties using your modified version, or distribute it to others that do. The latter part (distribute to others that do) is unfortunate; I expect it is not the intention of the AGPL writers. Distribution is the same trigger than what triggers the copyleft clauses of the ordinary GPL; so that trigger cannot in itself be a problem for DFSG freedom. Even if the clause is triggered, the most additional extra amount of code you have to write is provide a link to a download location. Adding exactly one string in a relatively prominent place. That's not a substantial amount, especially as typically an AGPL-covered software will already have the download link or mechanism, you only have to change the URL or something like that. I'd be sympathetic to a statement along the lines of: Software licensed under the AGPL, that does not itself provide an opportunity to receive the Corresponding Source in the meaning of clause 13, or is structured such that changing this opportunity to the source of modified version is not easy, is non DFSG-free, if it is not free for other reasons (e.g. dual license BSD / AGPL). 2.2 This clause forces the developer modifying the software to incur the cost of providing access to the Corresponding Source from a network server as long as at least one person is using the software and this for all published modifications, even long after the developer stopped using the software. Ah, I see. That's probably unfortunate wording; the onus should be on the person providing a service to third parties through the software, not the developer having made the modification. But indeed, the latter seems to be what the license is technically saying. 3. This clause is incompatible with section 6. of the Debian Free Software Guideline. 3.1 This clause does not allow you to modify the software to perform tasks where complying with it is not technically feasible. I have difficulties imagining a scenario where complying with it is not technically feasible; also, it seems similar to the GPL's mechanism of if you cannot legally obey both the GPL and patent law / a contract you have signed / ..., then you are not allowed to distribute at all. -- Lionel -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: - - - - - - - General Resolution made in accordance with Debian Constitution 4.1.5: The Debian project resolves that softwares licensed under the GNU Affero Public License are not free according to the Debian Free Software Guideline. - - - - - - - I second the above Resolution, although I note it is missing the world General before Public. My personal rationale is three-fold: firstly, the uncertainty about whether we have to ensure availability of the whole software or only our modifications (in other words, whether our app should go offline if savannah, debian or whatever upstream hosting service goes offline to our users) could be a significant cost of use (this is broadly Bill Allombert's point 2.2); secondly, the AGPL contradicts the freedom to distribute when you wish which I always thought was a fundamental part of free software. It has often been mentioned by RMS and others, in speeches such as http://fsfeurope.org/documents/rms-fs-2006-03-09.en.html and some forced-publication licences (such as Reciprocal Public License) have been listed on http://www.fsf.org/licensing/licenses/index_html#NonFreeSoftwareLicense finally, the AGPL is grounded in the self-contradicting idea of being specifically designed to ensure cooperation as described in its preamble (which also differs from the GNU GPL). I believe cooperation is necessarily voluntary (and I am not alone in that - see http://www.ica.coop/coop/principles.html#1) and that ensured cooperation is coercion, not freedom. This is broadly in line with debian's constitutional idea that A person who does not want to do a task which has been delegated or assigned to them does not need to do it. I hope that others will support this debian and co-op view. Regards, - -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFJx3v4mUY5euFC5vQRAq4PAKCAILfH4vqC9mNfZEisA89K1bOtjQCgmKeh Z+cEKLJLzYnqDSMKBXZuXY8= =7dWJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Mon, Mar 23, 2009 at 12:09:39PM +, MJ Ray wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Allombert bill.allomb...@math.u-bordeaux1.fr wrote: - - - - - - - General Resolution made in accordance with Debian Constitution 4.1.5: The Debian project resolves that softwares licensed under the GNU Affero Public License are not free according to the Debian Free Software Guideline. - - - - - - - I second the above Resolution, although I note it is missing the world General before Public. My personal rationale is three-fold: Thanks! I like to say that I am in the process of improving the wording of this GR, to address issues raised on this list. In particular, I am considering making the rationale part of the GR text (to make it a position statement from the project), but we would need more discussion on this topic so we can agree on a rationale. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
MJ Ray m...@phonecoop.coop writes: I hope that others will support this debian and co-op view. I continue to object to this GR as currently worded because it is a stealth delegate override that doesn't clearly state its implications and effects. I encourage all DDs to not second it until it's been fixed, even if you agree with the substance. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Mon, Mar 23, 2009 at 12:31:01PM -0700, Russ Allbery wrote: MJ Ray m...@phonecoop.coop writes: I hope that others will support this debian and co-op view. I continue to object to this GR as currently worded because it is a stealth delegate override that doesn't clearly state its implications and effects. I encourage all DDs to not second it until it's been fixed, even if you agree with the substance. +1 -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
Russ Allbery r...@debian.org wrote: MJ Ray m...@phonecoop.coop writes: I hope that others will support this debian and co-op view. I continue to object to this GR as currently worded because it is a stealth delegate override that doesn't clearly state its implications and effects. I encourage all DDs to not second it until it's been fixed, even if you agree with the substance. Did the delegates decide this particular matter or was Bug #495721 merely a summary of current practice? The statement there seemed incomplete in significant ways. Also, I think we should let the secretary to decide if a GR proposal modifies some foundation document, overrides a delegate decision, or requires amendment to be valid, rather than withholding seconds. I'm not that great at bureaucracy, so I think it's better that only the secretary decides the rules, rather than having every DD try to use the rule book as a weapon. Hope that explains, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
MJ Ray wrote: Russ Allbery r...@debian.org wrote: MJ Ray m...@phonecoop.coop writes: I hope that others will support this debian and co-op view. I continue to object to this GR as currently worded because it is a stealth delegate override that doesn't clearly state its implications and effects. I encourage all DDs to not second it until it's been fixed, even if you agree with the substance. Did the delegates decide this particular matter or was Bug #495721 merely a summary of current practice? The statement there seemed incomplete in significant ways. Yes, they did. Also, I think we should let the secretary to decide if a GR proposal modifies some foundation document, overrides a delegate decision, or requires amendment to be valid, rather than withholding seconds. I'm not that great at bureaucracy, so I think it's better that only the secretary decides the rules, rather than having every DD try to use the rule book as a weapon. I think it's wrong to leave the decision on whether a GR proposal modifies a foundation document to the secretary. I do think it's a good idea to request withholding seconds if anything is unclear. Cheers Luk -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
MJ Ray m...@phonecoop.coop writes: Did the delegates decide this particular matter or was Bug #495721 merely a summary of current practice? The statement there seemed incomplete in significant ways. The ftpmaster statement about the AGPL was remarkably explicit. recently we, your mostly friendly Ftpmaster and -team, have been asked about an opinion about the AGPL in Debian. The short summary is: We think that works licensed under the AGPL can go into main. (Provided they don't have any other problems). I'm not sure what requirements you have, but I have a hard time imagining much done in the project that is more obviously a delegate decision. Also, I think we should let the secretary to decide if a GR proposal modifies some foundation document, overrides a delegate decision, or requires amendment to be valid, rather than withholding seconds. I don't think the secretary currently has that power under the Constitution. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Mon Mar 23 15:08, Russ Allbery wrote: Also, I think we should let the secretary to decide if a GR proposal modifies some foundation document, overrides a delegate decision, or requires amendment to be valid, rather than withholding seconds. I don't think the secretary currently has that power under the Constitution. (sorry to hijack the thread) this is exactly what I want to clarify in the other thread over - there about constitutional issues. And why I was trying to get that in _first_ Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: GR proposal: the AGPL does not meet the DFSG
On Mon, Mar 23, 2009 at 12:31:01PM -0700, Russ Allbery wrote: MJ Ray m...@phonecoop.coop writes: I hope that others will support this debian and co-op view. I continue to object to this GR as currently worded because it is a stealth delegate override that doesn't clearly state its implications and effects. I encourage all DDs to not second it until it's been fixed, even if you agree with the substance. The options I can see that might end up on the ballot would include: - 4.1.3: override a delegate [1:1] - 4.1.5: position statement about the AGFL [1:1] (Either the same as ftp-master, or the opposite.) - 4.1.5.3: override a foundation document [3:1] The last option is probably unlikely. The problem I see with a position statement is that it's non-binding and that the delegate's decission would still hold. What ftp-master does with that is up to them. I currently see no problem putting it under both of them, and would like to see that clearly in the text of the proposal. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Wed, Mar 18, 2009 at 07:32:48PM -0700, Russ Allbery wrote: Bill, could you please change the GR to explicitly say that it's overriding a delegate decision so that it's clear in its implications and motivation? I proposed my resolution explicitly under 4.1.5, not under 4.1.3. The purpose of this GR is to take a public stance whether or not the AGPL meet DFSG. I am pretty confident that the FTP master will comply with the outcome of such determination, and I think it would be uselessly confrontational to draft it as overriding them. My view is that the FTP masters are delegated the power to decide which software belong in the archive at any given time. They are also required to make this determination in a limited timeframe and with limited resource than might be insufficient for the most complex issues. As long as this proposal is not calling explicitely for packages such-and-such to be moved in or out of the archive, it does not override them. Of course, had the FTP master rejected packages under the AGPL from the archive, I would not have bothered with a GR. However I would like this GR to be considered independently of the FTP master resolution. They are not the target, the AGPL is. (For those of you who believe in Montesquieu separation of powers, the FTP masters delegated power is executive while a GR under 4.1.5 is legislative. For the others, thanks for reading so far.) Cheers, -- Bill. ballo...@debian.org (Please CC me) Imagine a large red swirl here. signature.asc Description: Digital signature
Re: GR proposal: the AGPL does not meet the DFSG
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: I proposed my resolution explicitly under 4.1.5, not under 4.1.3. The purpose of this GR is to take a public stance whether or not the AGPL meet DFSG. I am pretty confident that the FTP master will comply with the outcome of such determination, and I think it would be uselessly confrontational to draft it as overriding them. I believe that you're mistaken in your belief that it's less confrontational to override their decision without saying so. However, I will defer to the FTP team; if they see this distinction and agree with it, I withdraw my objection. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
Of course, had the FTP master rejected packages under the AGPL from the archive, I would not have bothered with a GR. However I would like this GR to be considered independently of the FTP master resolution. They are not the target, the AGPL is. It is not seperate. You do want to override a decision from us, which is that the AGPL is fine for packages in our archive. You do want Debian to decide that this is not true and the AGPL is not ok. Fine, have it, if you find seconders, but clearly name it after what it is please. -- bye, Joerg Some NM: A developer contacts you and asks you to met for a keysign. What is your response and why? Do you like beer? When do we meet? [...] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
On Thu, Mar 19, 2009 at 12:50:45AM +0100, Bill Allombert wrote: Dear developers, I respectfully submit this general resolution proposal to your consideration. Please make clear what is part of the proposal and what is not. Kurt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
GR proposal: the AGPL does not meet the DFSG
Dear developers, I respectfully submit this general resolution proposal to your consideration. Asking for seconds. - - - - - - - General Resolution made in accordance with Debian Constitution 4.1.5: The Debian project resolves that softwares licensed under the GNU Affero Public License are not free according to the Debian Free Software Guideline. - - - - - - - RATIONALE (to be amended if necessary): 1. The GNU Affero General Public License (AGPL) is essentially the GNU General Public License with the following additional clause reproduced below. See http://www.fsf.org/licensing/licenses/agpl.html for the full text of the license. 13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License. 2. This clause is incompatible with section 3. of the Debian Free Software Guideline: 2.1 This clause restricts how you can modify the software. Doing a simple modification to a AGPL-covered software can require you to write a substantial amount of extra code to comply with this clause. 2.2 This clause forces the developer modifying the software to incur the cost of providing access to the Corresponding Source from a network server as long as at least one person is using the software and this for all published modifications, even long after the developer stopped using the software. 3. This clause is incompatible with section 6. of the Debian Free Software Guideline. 3.1 This clause does not allow you to modify the software to perform tasks where complying with it is not technically feasible. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. signature.asc Description: Digital signature
Re: GR proposal: the AGPL does not meet the DFSG
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: - - - - - - - General Resolution made in accordance with Debian Constitution 4.1.5: The Debian project resolves that softwares licensed under the GNU Affero Public License are not free according to the Debian Free Software Guideline. - - - - - - - What is the current ftpmaster ruling on this license? Possibly the same question in other words: why are you proposing this as a GR, when that's not normally how license evaluation is done? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG
Felipe Augusto van de Wiel (faw) f...@funlabs.org writes: On 18-03-2009 20:55, Russ Allbery wrote: Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: General Resolution made in accordance with Debian Constitution 4.1.5: The Debian project resolves that softwares licensed under the GNU Affero Public License are not free according to the Debian Free Software Guideline. What is the current ftpmaster ruling on this license? Possibly the same question in other words: why are you proposing this as a GR, when that's not normally how license evaluation is done? FTP Master team had announced their position on debian-legal: | The short summary is: We think that works licensed under the AGPL can | go into main. (Provided they don't have any other problems). Quoted from: http://lists.debian.org/debian-legal/2008/11/msg00097.html Ah, so this is actually a delegate override. Bill, could you please change the GR to explicitly say that it's overriding a delegate decision so that it's clear in its implications and motivation? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
