[General] Re: Relicensing of Chandler source code

[Phillip J. Eby]

At 03:07 PM 5/4/2006 +0000, Zak Greant wrote:
>Ted Leung <twl at ...> writes:
> > 2. We want to reduce the proliferation of licenses used by OSAF
> > projects.  All the rest of our server code is licensed under the
> > Apache 2.0 license, and some of our other projects are licensed under
> > the MIT license.
>
>This is a sensible goal. Unfortunately, due to the useful anti-patent 
>clauses in
>version 2.0 of the Apache License, it is not compatible with version 2.0 
>of the
>GPL. However, the MIT license is GPL v2.0-compatible. Additionally, I believe
>that version 3.0 of the GPL will be compatible with version 2.0 of the Apache
>License.

Like the term "intellectual property", the term "GPL compatible" can be 
confusing to the uninitiated.

As best as I can tell from the FSF website, a license is "GPL compatible" 
if it allows you to create a *GPL fork* of a program under that license, 
such that the original copyright holder would be prohibited from using any 
enhanced version without complying with GPL terms.

So, in the spirit of "Treacherous Computing", perhaps a better phrase for 
licensors to understand the consequences of using a "GPL compatible" 
license would be "GPL forkable".  Since the FSF believes it's important for 
people to understand the impact of software licenses, I'm sure they'll 
start using this new term immediately.  ;-)

Myself, I don't mind using GPL-forkable licenses, but I don't consider it 
an important goal to allow for it when choosing a license.  hat most of my 
software is released under such forkable licenses is purely coincidental, 
and if I had happened to choose a non-forkable license that met my needs 
for other reasons, it's unlikely that I would change merely because 
somebody thinks (incorrectly) that it keeps them from developing *their* 
code under the GPL (and if necessary, adding an exception clause to allow 
linking with my work).

IMO, calling it "compatibility" creates the same kind of confusion that 
"intellectual property" or "trusted computing" does, i.e., the illusion 
that it's something you *want*, even if it's the very opposite.  :)


> > [Various large amounts of supposing about the GPL, the FSF and 
> copyright law]
>
>Don't write too many words into the FSF's metaphorical mouth. Check the
>http://fsf.org/ to see exactly what beliefs are held as an organization - 
>if you
>talk to individual FSF people about these issues you will get at least one set
>of opinions per person.

Actually, almost half of my message consisted of direct quotes from 
fsf.org, but perhaps you weren't talking about that message.  :)


> > I would like parcel  writers to have their choice of licenses.  If 
> Chandler
> > is GPL'ed, then my understanding of the GPL is that parcels would have 
> to be
> > GPL'ed.
>
>It is very easy to ensure that parcel writers have a choice of license - 
>simply
>add an exception to your instance of the GPL.

That's certainly a fair way to do it, if OSAF prefers to stick with the GPL 
for Chandler itself.  However, the proposal on the table is to move away 
from the GPL.  I think it's important to point out that this exception 
capability cuts *both* ways -- if a parcel developer doesn't think the ASF 
license is sufficient to show the independence of their code, they can 
always write the same exception for *their* parcel, to allow "linking" to 
Chandler.

Of course, that's complete nonsense, since Python "linking" does not 
involve any code inclusion, and so can't create a derivative work due to 
the absence of copying -- even transformative copying.  (And as a core 
Python developer who's done some work on its import machinery among other 
things, I'd be able to testify as an expert witness to that absence of 
copying in the case of Python modules.)

In any case, there are at *least* three independent bases on which it can 
be established that using the ASF license for Chandler wouldn't interfere 
with GPL-ing a parcel:

1. The ASF license allows derivative works to be licensed such that an 
identifiable contributed portion could be under the GPL.

2. The parcel's copyright holder(s) can exempt Chandler linkage from the 
GPL's restrictions

3. Parcels by themselves aren't derivative works if they don't contain code 
that's copied from somewhere else that contains expressive elements 
protectable under copyright law