* Jeroen Dekkers <email@example.com> [020505 20:33]:
> On Sat, May 04, 2002 at 07:40:59PM +0200, Gregor Hoffleit wrote:
> > 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 ?
> (3) Link _socket.so with GnuTLS instead of OpenSSl. I don't know how
> feasible this is.
>From a first look, GNU TLS has a very different API. The current code in
the socket module won't work with GNU TLS.
Furthermore, replacing OpenSSL with GNU TLS won't resolve the
fundamental dilemma. We would face the same situation for any other
package that includes a Python extension module with a GPL-incompatible,
but DFSG-free license. If this is the last word, then Debian could only
ship GPL-compatible Python modules (and the same was true for all
derived distributions). This seems to be in conflict with the Social
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com