Hi Phillip,
Thanks for taking the time to respond. I would almost get the
impression that you have gone around on these issues once or twice. ;)
On May 4, 2006, at 09:46PDT (CA), Phillip J. Eby wrote:
At 03:07 PM 5/4/2006 +0000, Zak Greant wrote:
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.
That is one option. Very permissive Free Software/Open Source
licenses allow forks to have different licenses, be they copyleft or
proprietary or what have you.
It is easy enough (and, IMHO, good form) to ensure that the original
author gains access to most or all enhancements under their original
license even when a derivative work is formed from the work and a
GPL'd work. (A relevant snippet from section 2 of GPL v2 is this
"Thus, it is not the intent of this section to claim rights or
contest your rights to work written entirely by you; rather, the
intent is to exercise the right to control the distribution of
derivative or collective works based on the Program.")
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. ;-)
Heh. Perhaps we could arrange for you to chat about this with
Richard. ;)
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. :)
I think that the FSF's statement is fairly clear here. On page http://
www.fsf.org/licensing/licenses, regarding GPL compatibility, the FSF
says: "This means you can combine a module which was released under
that license with a GPL-covered module to make one larger program."
Pointing out that you can fork a permissive license seems a bit
gratuitous.
> [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. :)
Half is still a heck of a lot of interpolation. :)
> 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.
Right. Oddly enough, I didn't write to help further that proposal.
Instead, I hope that Chandler can stay GPL'd.
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.)
As mentioned, I have no idea of how parcels fit into Chandler. I
don't want to imply that I believe that an exception /would(n't)?/ be
needed. Also, please don't read my comments on this thread as meaning
that I think (or that the FSF thinks) that an expansive
interpretation of copyright or an expansion of copyright is a good or
needed thing.
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:
It is very clear that a parcel can be GPL'd in many cases.
I would still hope that the Chandler team considers one of these
options:
a) staying with the GPL
b) using a GPL-forkable ;) license
c) engaging in multi-licensing
Cheers!
--zak
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "General" mailing list
http://lists.osafoundation.org/mailman/listinfo/general
