Re: Providing an openssl-linked pycurl
Yavor Doganov wrote:
> Thu, 01 Jul 2010 20:09:19 +0100, MJ Ray
> > Yavor Doganov wrote:
> >> I see no difference between this scenario and a classic C program that
> >> supports both OpenSSL and GnuTLS via #ifdef's and `configure' options.
> >
> > In the C-ifdef scenario, the GPL program is derived from both OpenSSL
> > and GnuTLS. That is, its programmer obviously knows about OpenSSL's
> > functions.
>
> Not necessarily. The program may not be using OpenSSL/GnuTLS
> functions at all; it may link with another library (or 2 different
> libraries) which hide/abstract these.
If the GPL program links with another library, why does it need ifdefs
or configure options? Surely that's left to the library?
> [...] Consider a real world example. lusernet.app links against
> libpantomime1.2, which links against libssl for SSL support.
>
> $ ldd /usr/bin/LuserNET | grep ssl
> libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb6dc2000)
>
> This is a serious bug in my book.
>
> LuserNET doesn't use any OpenSSL functions at all. [...]
Then I don't see why it's a bug in LuserNET, nor how LuserNET is derived
from OpenSSL. It feels more like a bug in libpantomime1.2 linking
against libssl for SSL support even when that support is not required.
> [...] On the other hand, Pantomime can be ported to GnuTLS (it's
> in my TODO actually, because of the above issue), in which case it
> matters not from the app author's view how the library implements
> internally TCP connection, SSL handshake, etc. [...]
That would be a great thing to do. More power to your elbow!
Thanks
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: