Gregor Hoffleit <email@example.com> wrote:
> * Brian May <firstname.lastname@example.org> [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.
If I understand how Python works, when Python is compiled, there is an
option to include readline headers. Therefore, when you make the
Python binary, you are including GPL'd code. That means that
everything that includes those readline files must be distributable
under the GPL.
The _socket.so code includes the OpenSSL headers. This places the
binary under the OpenSSL license. They also included the generic
python headers. So, in doing that inclusion, does that also pull in
the readline headers? I don't think it does, but if so, then Debian
can't distribute the _socket.so binaries.
If it doesn't, then the OpenSSL code, by itself, does not touch any
GPL'd code. The interpreter, which includes GPL code, does not touch
any OpenSSL code. We have one program that calls another program
through well-documented interfaces. I don't think that there is any
problem with distributing them as two separate entities.
There might be a problem if you distribute them together. To allay
any concerns, I would recommend splitting python into 2 packages.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org