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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
