Affero GPL 2(d)

[Eben Moglen]

On Friday, 13 August 2004, Alex Rousskov wrote:

  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).

Is this the test for technological neutrality?  Existing OSI-approved
licenses contain requirements prohibiting removal of copyright
notifications during interactive use, which are analytically very
closely related to Affero 2(d), and may have nothing to do with a
derivative's function, etc.

  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.
  
It is not the case that every reuse is guaranteed by free software
licenses.  GPL section 7 prevents redistributions arising out of
technological limitations, for example.  More than that has to be
said.
  
  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").

This is the point of the protocol reqiurement, which establishes that
the intention is prompt and convenient access to source code.  Of all
the problems that worry me about license enforcement, convincing a
judge that the above modalities infringe is not one of them.
  
  Second, the current wording does not require "opportunity [for]
  transmission". It requires "opportunity to request transmission",
  which is a very different requirement IMO.

I want to emphasize again that strict literal interpretation, with
minimal context, comes naturally to programmers but not to judges and
lawyers.  Less mechanistic reading is helpful here, but we have in any
event agreed on a preferred wording.