Re: libreadline
On Sat, May 04, 2002 at 07:40:59PM +0200, Gregor Hoffleit wrote:
> * Brian May <bam@snoopy.apana.org.au> [020504 06:09]:
> > For instance, I asked on debian-legal, and was told that no program may
> > link both with libreadline and openssl because the licenses of these two
> > packages are incompatible (if you disagree, please bring it up on
> > debian-legal, not here).
True so far as it goes. Any derivative work of libreadline, which
includes but is not limited to things linked against it, must be
licensed under the GPL, and you cannot use libopenssl in a vanilla GPL
program.
> As Matthias already wrote, python2.1 is a package which contains a
> Python interpreter and several extension modules. Technically, the
> extension modules are shared objects (.so). Among these extension
> modules is a readline module
> (/usr/lib/python2.1/lib-dynload/readline.so) which is linked with
> libreadline.so.4. There's another extension module in the package,
> (/usr/lib/python2.1/lib-dynload/_socket.so), which is linked with
> libssl.so.0.9.6.
Hmm, I would be inclined to think this means the readline module is
licensed under the GPL. (One could make a case for the entirity of
python being GPLed by this, but I'm not going to. You might want to
try and get python upstream to break the readline module out from the
core tree to remove this confusion).
> A switch to editline (if it was feasible technically) is no solution,
> since it is well possible that there are/will be other Python extension
> modules in Debian which link with other GPL libraries. This is a
> fundamental problem.
>
> Again, I see that there's a potential problem, but where exactly is the
> borderline (I guess that means where do we want to draw a borderline?).
If a given program is a "derivative work" of the readline module (this
is commonly interpreted to mean "needs this code in order to provide
useful functionality"), then it is licensed under the GPL and you
cannot include openssl at all (even optionally). An example of this
would be an application that requires readline for console input; an
example of a case where it does not apply would be an application that
can use an alternative (presumably lesser) system for console input if
readline is not available.
That's how I'd interpret the GPL in this case, anyway; this seems to
be how the FSF interpret it, but you may want to ask them (since it's
their opinion that counts, as copyright holders for libreadline).
> (1) How about this: I ship two versions of _socket.so in the python2.1
> package: One is linked with OpenSSL, the other doesn't include the SSL
> support. Upon loading, socket.py decides whether the interpreter is
> already linked with libreadline, and if that's the case, it imports the
> SSL-less _socket.so. Vice-versa with the readline module: It checks
> whether the interpreter is linked with the libssl, and if that's the
> case, it fails to import.
>
> This would legally and morally satisfy the GPL, right ?
Well, python doesn't seem to be violating it directly (assuming you
consider the readline module to be a discrete component with its own
license), but this would prevent python programs from violating it.
You'd want to taint the interpreter as "GPL" or "GPL-incompatible"
when loading the relevant modules; if it is possible to unload the
modules, this should not un-taint the interpreter.
> (2) If we shipped python2.1 with an SSL-less _socket.so, and
> alternatively distributed a python2.1-ssl package, which provides a
> SSL-enabled _socket.so, would that change anything ?
I don't think so, it's the readline module that has the "viral"
license.
> (2b) If the python2.1-ssl package included a note of warning, and
> perhaps a description how to optionally (!) disable the readline module,
> would that be better than (2) ?
If a python application would work fine without the readline module
enabled, that would be fine. If it would not, the situation is
unchanged.
(IANAL, etc. Get the opinion of the copyright holders of all relevant
GPLed code)
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ | Dept. of Computing,
`. `' | Imperial College,
`- -><- | London, UK
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: