Re: libreadline
* Brian May <bam@snoopy.apana.org.au> [020504 06:09]:
> It has come to my attention that a number of packages may be breaching
> the GPL by linking with libreadline instead of libeditline.
>
> 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).
>
> However, a number of programs do exactly this. Probably the most popular
> package is python2.1.
Brian, I think this information is too vague to make a decision based on
it. I need a clear legal advice on how Debian is violating which
license by distributing the current python2.1 packages.
To be clear: I understand the problem, but I have no idea at which point
we would agree that it is resolved.
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.
The Python interpreter loads extension modules at runtime when it hits
an "import" command (where loading means linking the modules' code into
the interpreter).
The _socket.so module ought to be imported from the socket.py module,
which can be imported with the Python command "import socket". This is
done in many modules of Python's network code.
The readline module will be imported on startup of Python by default, if
available, but only in interactive sessions:
if ((inspect || (command == NULL && filename == NULL)) &&
isatty(fileno(stdin))) {
PyObject *v;
v = PyImport_ImportModule("readline");
if (v == NULL)
PyErr_Clear();
else
Py_DECREF(v);
}
Therefore, as long a user doesn't import the socket module in an
interactive session, it never happens that both the readline library
and the OpenSSL library are linked into the same program.
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 ?).
A few questions:
(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 ?
(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 ?
(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) ?
(2c) If the installation of python2.1-ssl would remove the readline
module, that should definitely satisfy the GPL, correct ?
AFAICS, the strange situation is that the user would never violate the
GPL (he is free to do with the code what he wants, as long as he doesn't
redistribute this). Only the distributor (i.e. me or Debian as a whole)
could violate the GPL. Now where's the border ? How many provisions do
we have to take to "inhibit" a user from linking GPL stuff with
incompatible stuff ?
I would be glad about some guidelines.
Gregor
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: