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 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).
If that's really what was intended, then, yes, it is quite problematic
and too big a burden.
>>> 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".
Yes, and the similarity comes from replacing "legally" by
"technically".
> Not technically feasible would mean you have technical requirement such that:
> 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?
> 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, ...).
--
Lionel
Reply to: