[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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. <ballombe@debian.org>

Imagine a large red swirl here. 

Attachment: signature.asc
Description: Digital signature


Reply to: