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 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 ?
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.
Having said that, if you install the software in a way that causes it to
fail so that a user would not be able to download the software, then
that would probably be a bug in your instance of the installation. The
key word here is 'intent' -- if a service provider did this
intentionally and is unwilling to fix the problem when told about it,
they should be sued. If they do so unintentionally, and make a best
effort to fix the issue once it's pointed out, it should not be a
problem.
> > > 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 you need to put the code on the same
> > device as the one you're running it on; size limits and network
> > throughput issues should therefore not be an issue.
>
> Yes, but you still have to display a proeminent offer. This can still be too
> much, if the display is just a pair of digits.
If the only interface is a display with a pair of digits (i.e., there's
no network interface), then the AGPL does not apply.
If the system is used over the network, then the network protocol or the
place where you sign up or something similar would need to contain the
relevant offer. The embedded display would then just be using the
protocol.
> > > -- 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.
> >
> > 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.
>
> Agreed. What if the client cannot be expected to display such notice ?
If you are developing a network protocol, you really cannot be expected
to be able to control what the client can and cannot do -- even an HTTP
browser could hide parts of a webpage, without the server being able to
do anything about that.
I think that if you provide instructions to the source in whatever is
sent over the network, preferably in such a way that it would be
displayed by default (but in comment headers if that's not possible),
you'd be fine.
> > This clause requires that the user be informed about the fact that the
> > software is modified. In a piece of software that uses HTTP, this is
> > simple -- just add a link to the website, and you're done.
>
> 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".
For instance, the link to the source could be part of the 403 error
pages.
--
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
Reply to: