Viral licenses (was: wxWindows library...)

[Alexander Terekhov]

Arnoud Engelfriet wrote:
[...]
> If you distribute a work that is a derivative of GPL-licensed
> code, and you do not comply with the GPL, you simply violate
> the license. ...

Yeah. Simple.

www.linuxdevices.com/files/misc/asay-paper.pdf 

<quote>

The Lesser GPL, or LGPL, is a second software license written 
by the Free Software Foundation. It sheds some light on the 
FSF's view of linking and derivative works, both for the GPL 
and LGPL: 

  When a program is linked with a library, whether 
  statically or using a shared library [i.e., dynamically], 
  the combination of the two is legally speaking a combined 
  work, a derivative of the original library. The ordinary 
  General Public License therefore permits such linking only 
  if the entire combination fits its criteria of freedom. The 
  Lesser General Public License permits more lax criteria for 
  linking other code with the library. 

In other words, dynamic linking is permissible under the LGPL, 
but not under the GPL. Whether one links to GPL code 
dynamically or statically, one creates a derivative work. As 
Lisa Green and Heather Meeker point out, software that 
contains small portions of a copyrighted work that are 
functional in nature (e.g., a "do loop" that efficiently can 
only be written in one way) is generally not considered to be 
a derivative work, but might be according to the GPL. 

The GPL's language, then, tries to swallow every piece of 
software that incorporates a GPL program or portions of it. 
However, it probably cannot do so under the copyright law it 
purports to follow. This definition of a derivative work 
proves highly controversial in the software world, and may 
not stand up in court. Regardless, however, it has spawned 
fear in the closed-source world of software development, for 
fear that linking to GPL code in any manner will cause the 
closed-source code to be deemed a derivative, and hence 
subject to the GPL's "open source" requirement. 

This fear has inhibited scores of computer companies from 
embracing Linux. This fear has been caused in large part by 
the Free Software Foundation's inability or unwillingness to 
clarify its position on derivative works. I asked two 
prominent representatives of the Free Software 
Foundation -- Eben Moglen, general counsel, and Richard 
Stallman, founder -- to clarify thorny issues of linkage to 
GPL code, and came up with two divergent opinions on 
derivative works in specific contexts. Their responses (to 
the question of whether or not they would consider the 
following derivative works) are recorded below:

A driver loaded as a module into the Linux kernel?

  Moglen: No

  Stallman: Yes. I think Linus made a mistake when he said 
  he would interpret the GPL so as to regard these as NOT 
  extensions to Linux.

A module written to be plugged into an API defined 
specifically to support dynamic loading?

  Moglen: No.

  Stallman: It depends on the detailed circumstances.

A program which uses a library? (i.e., Would it be fair 
to say that this is generally not a derivative work of 
that library?)

  Moglen: This depends. Code statically linked to other 
  code is a derivative work of the code with which it is 
  linked, as far as we are concerned. But what follows 
  from that depends on the license involved. That's the 
  difference between the GPL and the LGPL, which is 
  designed to permit proprietary code to be linked and 
  distributed with free libraries.

  Stallman: I think that depends on the detailed 
  circumstances.

A library linked to a program? (i.e., Is this a derivative 
work of the program?)

  Moglen: Code statically linked to code constitutes a 
  derivative work of the code to which it is linked, 
  without question, regardless of license terms. More 
  specifically, now regarding licensing as well as the 
  status of the work, code that cannot be used at all 
  unless dynamically linked to GPL'd code, and which is 
  distributed along with that GPL'd code, must be 
  distributed under the terms of the GPL. This provides 
  a competitive advantage to free software, requiring 
  those who wish to make unfree software to undertake 
  proprietary reimplementation of feature sets only 
  available in GPL'd libraries, such as GNU readline.

  Stallman: That is normally true, but it one needs to 
  be careful drawing conclusions from it. Also, there 
  can be ambiguity in the definition of "library" which 
  can cause confusion about this.

A program running as a process on a Linux system? (A 
derivative work of the Linux kernel?)

  Moglen: Certainly not a derivative work of the kernel, 
  or of anything else, simply by virtue of executability 
  on free software systems, whether the kernel they 
  employ is Linux, the Hurd, or some other kernel.

  Stallman: I agree here [that the program running as 
  a process on a Linux system creates a derivative 
  work] -- except that it's a misnomer to speak of "a 
  Linux system". Linux is the kernel; the system is 
  really the GNU operating system, modified to use 
  Linux as the kernel.

</quote>

So basically in the "FSF world", your car is a derivative 
work of its gas pedal. Give me a break.

regards,
alexander.

P.S. 

cyber.law.harvard.edu/is02/resources/GPL-Palfrey-analysis.DOC

<quote>

Judge Saris focused primarily on the questions of: 1) whether 
Gemini constitutes an independent or a derivative work; 

[...]

Experts -- none of whom were permitted to testify today, 
though Columbia Law School's Eben Moglen, perhaps among 
others, was in the room -- had filed what the Judge called 
"classic book-ends," or perfectly conflicting reports, on 
some of the core questions, including the issue of the 
derivative work. 

[...]

She seemed to be moved by the NuSphere argument that there 
was no "co-mingling" of the source code and that "linking" 
to another program did not equate to creation of a 
derivative work. 

[...]

All in all, it appears that this federal court considers 
the GPL to be a valid license, albeit with a somewhat 
ambiguous clause about the obligations that arise when you 
distribute code that combines both GPL code with code that 
was developed independently.  The outcome of this dispute 
could have enormous implications.  A victory for MySQL 
would favor what some consider the spirit of the GPL: the 
notion that code inspired by open source works should stay 
open source.  A victory for NuSphere, on the other hand, 
might cut in favor of what some view as the long-term 
success of the open source movement, by ensuring that 
those who build off of open source materials can earn a 
profit.

</quote> 

P.P.S.

www.theregister.co.uk/content/4/24286.html
(Judge blocks route to GPL legal test case)

www.newsforge.com/article.pl?sid=01/07/12/2142237
(NuSphere: MySQL.org needed because MySQL AB won't accept code)

--
sources.redhat.com/ml/pthreads-win32/2003/msg00110.html
sources.redhat.com/ml/pthreads-win32/2003/msg00125.html

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3