At 03:07 PM 5/4/2006 +0000, Zak Greant wrote:
Ted Leung <[EMAIL PROTECTED]> 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
