[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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!

My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct

Reply to: