Affero GPL 2(d)

[Alex Rousskov]

On Fri, 13 Aug 2004, Eben Moglen wrote:

> Henri has reminded me of an overdue obligation to respond to
> discussion of the Affero GPL as a potential candidate for OSI
> approval.  One issue that was raised in the course of the
> conversation is the technologically non-neutral form of Affero GPL
> 2(d).  This is a drafting error for which I was responsible.  Our
> current projected 2(d) for use in a modified Affero GPL or other
> similar license is:
>
>    d) If the Program as you received it is intended to interact with
>    users through a computer network and if, in the version you received,
>    any user interacting with the Program was given the opportunity to
>    request transmission to that user of the Program's complete source
>    code, you must not remove that facility from your modified version of
>    the Program or work based on the Program, and must offer an equivalent
>    opportunity for all users interacting with your Program through a
>    computer network to request immediate transmission of the complete
>    source code of your modified version or other derivative work by the
>    same communication protocol used for other user interaction with the
>    Program.

The above restrictions are still technologically non-neutral, IMO,
because the license still requires derivative works to:

	1) Preserve functionality that may have nothing to do
	   with the derivative work but may render derivative work
	   technologically impossible. For example, consider a
 	   derivative work that uses portions of existing code
	   for embedded software or nano devices. With preserved
	   functionality, the derivative work may not fit into
	   memory available for that derivative work. Thus, the
	   license would effectively limit derivative works
	   to technologies where executable size is unimportant.

	2) Implement source download functionality for
	   communication protocols that may not support such
	   functionality. If original work was communicating via HTTP
	   and my derived work is communicating to users via FooBarP,
	   I have to implement additional FooBarP functionality to
	   let users request source code. Doing so may be impossible
	   for some protocols, for purely technical reasons. Thus,
	   the license would effectively limit derivative works
	   to protocols were "source code download" is possible.

	3) Immediately respond to user requests. Not all communication
	   protocols can provide immediate responses. In some cases,
	   the speed or even existence of a response depends on
	   the response size, network status, or other technical
	   factors. Thus, the license would effectively limit
	   derivative works to protocols were "immediate response" is
	   possible. (Here, I assume the license text will be fixed to
	   talk about immediate responses, not just requests for
	   them).

There are other technical problems. For example, it is not clear
whether the user has to be able to get the source code. What if all
supported user agents do not have enough memory to receive source code
and that technical limitation prevents the derivative work from making
the source code available for download? Is that a license violation?

These are not "theoretical" arguments. I can imagine very real cases
where the use of the proposed license would prevent open source
developers to reuse licensed code, something OSI certification is
supposed to ensure.

IMO, the license is intended to define and preserve (restrict,
mandate, whatever)  some rather specific software functionality. It is
not possible to do that without becoming technology-specific. A very
different mechanism needs to be invented to remain OSI compliant.

> It has also been suggested that the license fails because it would
> not be violated by returning a protocol-acceptable but uncooperative
> response to a request for source code.  I don't think that objection
> is well-founded.  Responding "Good luck" is not an "equivalent
> opportunity [for] transmission of the complete source code," which
> the license requires.

First of all, responding with "good luck" is an extreme example. I
would not recommend using it to word or defend the license. I would
suggest considering a "Please download from https://host.com/download"
response instead (and there are many other variations on the theme
like "Please download from
ourotherprotocol://host.com/download-after-signing-in").

Second, the current wording does not require "opportunity [for]
transmission". It requires "opportunity to request transmission",
which is a very different requirement IMO.

> For clarity's sake, however, one would meet this objection in
> amending the license text, by s/request immediate/request and
> receive immediate/. I see no legal risk that would be created by the
> addition of those words.

Agreed. Other problems mentioned above would remain though.

HTH,

Alex.