On Sat, May 04, 2002 at 07:40:59PM +0200, Gregor Hoffleit wrote:
> 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 ?
(3) Link _socket.so with GnuTLS instead of OpenSSl. I don't know how
feasible this is.
Jeroen Dekkers
--
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.orghttp://www.gnu.org
IRC: jeroen@openprojects