Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: "Tim Peters" <tim DOT one AT home DOT com>
To: "Jason Tishler" <Jason DOT Tishler AT dothill DOT com>
Cc: "DJ Delorie" <dj AT delorie DOT com>, <cce AT clarkevans DOT com>,
        <cygwin AT sources DOT redhat DOT com>
Subject: RE: Cygwin Python Distribution GPL Licensing Issue?
Date: Mon, 23 Apr 2001 04:11:57 -0400
Message-ID: <LNBBLJKPBEHFEDALKOLCGEBCJOAA.tim.one@home.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <20010423002816.C431@dothill.com>

[Jason Tishler]
> After digesting what Tim and DJ had to say on this matter, my
> interpretation is that my Cygwin Python distribution is OK from the
> Python and Cygwin licensing points of view.

Mine too, but IANAL.

> However, Tim is correct that Cygwin Python's readline module:
>
>     /usr/lib/python2.1/lib-dynload/readline.dll
>
> links against the GNU readline library.  So, it seems like there may be
> a GPL issue after all (with this one file).

This is hard to say.  The GPL doesn't prevent an end user from linking Python
(or anything else!) to GPL'ed components themselves and running them, it only
prevents people from *distributing* the result unless the whole of the
combined work is under the GPL too.

Now the FSF has taken a, umm, "creative" position here, maintaining that if
you distribute a program that uses an API *unique* to a GPL'ed component,
then even if you don't ship that GPL'ed component with your program, the
GPL'ed component is "effectively" being shipped anyway because your program
can't run without it.  And therefore distributing your program is illegal
unless it's under a GPL-compatible license.

GNU readline has been the poster child for this in the past, since readline
is useful for any app doing cmdline interaction, and

    http://www.fsf.org/philosophy/why-not-lgpl.html

explains why the FSF doesn't release readline under the LGPL instead (they
want to force apps that want to use readline to be released under
GPL-compatible terms too).

However, the FSF's argument falls apart at the starting gate if other,
non-GPLed libraries with the same API are available.  Then there's not even a
fanciful sense in which your program can be claimed to violate the GPL.  For
that reason, projects have sprung up like

    http://sourceforge.net/projects/editline/

which duplicate all or some of GNU readline's functionality but are not
GPL'ed (editline in particular is under the BSD license).

I see DJ suggested a good test too:  it is indeed the case that Python
doesn't *require* GNU readline to function normally.  If it's not available,
Python adjusts.

Clear as mud yet <wink>?

I personally don't like these shenanigans:  if, given their present position
on the Python license, the FSF would merely *prefer* that Python not use
readline, I personally want to respect that, and *just* because it's their
code (the untested legal claims don't interest me).  But I haven't heard from
the FSF what their preference on this is, so that's an unknown too.

> Although probably not relevant, I would like to point out that the
> Cygwin GNU readline library is actually a DLL.  So, when Cygwin Python's
> readline module links with GNU readline, it is really linking against
> an import library and not a static library that contains code.  Hence,
> AFAICT, my distribution does not contain GNU readline code -- just some
> references to its code.

As above, the FSF hasn't bought that argument in the past.  But the essay at
the link above hasn't been changed in over two years, and I haven't seen
anything from them about how, or whether, the existence of projects like
editline affects what RMS wrote then.

> Nevertheless, I am willing to remove this offending file from my
> distribution, but I loath to do so.  Is this really necessary?  If so,
> it will be ironic (and sad) that I will not be using (precisely) the
> same distribution that I contribute to Cygwin.  Sigh...

You're not alone!  Python ships with readline.c on every flavor of Unix, so
even *if* the FSF objects to it (unknown to me), their first target won't be
Cygwin.  I don't think they have enforceable grounds for objecting anymore
(readline's API isn't unique to GPL'ed libraries anymore, and Python doesn't
require it anyway), but legal enforceability has never had much to do with
license politics.

*You* didn't do anything special to get readline.dll compiled anyway, right?
Unless I'm mistaken, you inherited that part of the make process from us.  So
your ass is covered 10 ways from Sunday <wink>:  if the FSF objects, they
should object to us, I'll argue to respect their wishes and disable readline
support everywhere, in the end I'll get out-voted, and then there will be
another long semi-public fight that never gets resolved because neither side
will be willing to push it too far.  See?  In every respect, just life as
usual <0.9 wink>.


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple