Re: Persuading the apaches

[Dalibor Topic]

Martin Olsson wrote:
> Hi,
> 
> Could someone clarify the difference between GPL+Exception and ASF?

GPL+Exception is a software license, the ASF is an organisation. :)

> I'm interested both in the general differences but also specifically:
>   - Why do you guys prefer GPL+Exception over ASLv2 ?

The former is GPL-compatible, meaning it can be used directly with GPLd
software to create new works. The latter is not, due to a
patent-retailiation clause, that's formulated in a way that adds
restrictions to GPL.

See [1] for details; it essentially boils down to
a) the GPL requiring you to stop distribution when someone successfully
obtains a court decision against you wrt software patents (i.e. they
first have to drag you to court and win there with their claims),
b) while the ASL2 revokes your right to use the patent-encumbered code
as soon as you start a patent litigation (including using patent
counterclaims to yourself in court), and
c) the GPL not allowing further restrictions

The whole ASL2 attampt to retaliate on patents is a bit weird, as the
ASF does not have *any* patents it could possibly deny the license to
use in retaliation against a patent attack, anyway. Since the ASF is
championing the cause of patent-unencumbered protocols (see Sender-Id
discussions), for example, it would be pretty weird if the ASF suddendly
started to distribute patent-encumbered implementations of the same
protocols themselves.

Larry Rosen called the ASL2 "toothless" in that respect.[2]

>   - Why do the Apache guys prefer ASLv2 over GPL+Exception ?

Becuse they understand their own license better than a license from the
FSF, I guess.

For example, I don't necessarily understand all aspects of the ASL2, and
the lack of a comprehensive, exhaustive FAQ on the ASL2 is not helpful
there. I assume that the Apache guys have a similar feeling of not
understanding all the implications of the GPL+LE, so they'd prefer a
license that they understand.

Sticking with the devil one knows is pretty normal human behavior. Or
GNU/Linux would completely rule the desktop. :)

> (please tell me that there is some tangible
> difference here, and not just some NIH crap :D)

In real life, for a runtime wanting to ship a jar with class libraries,
the licenses have pretty much equivalent effect: link as much as you
want to the class library jar file without having to license your
runtime (or code running on top of it) under the license of the class
libraries.

But, for developers, GPL+LE has one clear benefit over ASL2: it is
GPL-compatible.

Given that many runtimes using GNU Classpath are licensed under the GPL
(or GPL-compatible licenses), and many authors of GNU Classpath
contribute to/use/work on GPL-licensed projects, that argument matters a
lot: it allows for unencumbered future development. Licensing GNU
Classpath under ASL2 would prohibit that, and cut a part of GNU
Classpath developers and users from further development. I.e. it would
be a pretty pointless thing to do.

See XFree86 vs X.org fork for an example of why alienating your user
base with pessimizing license changes is a bad thing to do. :)

See also the excellent essay at [3] on why GPL-compatiblity matters.

> Also, why did GNU go with GPL+Exception this time and not LGPL?

The GPL+exception concept exists since the early 90s, and has been
sucessfully used in libgcc since dinosaurs walked the earth and
mainframes ate bugs. :)

For several use cases, in particular in embedded systems, a license more
permissive than the LGPL is advantageous. Rather than creating yet
another license from scratch and contributing to the general license
polution, the FSF chose to grant a specific exception to an existing
license, GPL, to make it as permissive as necessary. The reason why GPL
is chosen, is presumably because GPL is a bit clearer, as it does not go
into the technical mess of how the linking/ creation of derived works is
performed.

On the 'GPL may be a bit clearer' part: Part of some deveopers' concerns
regarding the LGPL was the application of the rather technical terms
regarding  object file linkage and header files and all that in the LGPL
to name-lookup based use of such libraries, for example in the programs
written in the Java programming language. That prompted the
clarification of the effect of LGPL on programs written in the Java
programming language in an article by David Turner on the FSF site.[4]

cheers,
dalibor topic

[1] http://www.apache.org/licenses/GPL-compatibility.html
[2]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200504.mbox/address@hidden
see also for example his take on the funny notion of copyrightable APIs
at
http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:3266:200104:fnebghjdoohkgejjfnbd
[3] http://www.dwheeler.com/essays/gpl-compatible.html
[4] http://www.gnu.org/licenses/lgpl-java.html