В 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. > In the pycurl scenario, the GPL program is derived from pycurl. The > difference is that the GPL-using programmer need not know about > OpenSSL's functions, so I don't see how it can be said to be derived > from it. It would even be written the same in a world without OpenSSL, > as long as pycurl is the same whether it's a version derived from > OpenSSL or a version derived from GNUTLS. > > Can you explain why the GPL program using pycurl is derived from > OpenSSL, please? 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. Now, it would be fairly trivial to modify the program to add NNTPS support, without resorting to OpenSSL, and without even using Pantomime's SSL-specific methods. 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. The programmer need not know about OpenSSL/GnuTLS functions per se. This is practically the same situation as the one you describe for pycurl. > So, as long as debian usually installs the gnutls-linked variant, no > problem, right? > > It's up to the user if they want to modify their system to install the > variant that may cause distribution/licensing problems. Merely having > it available doesn't seem like a problem to me. Yes, this issue is a real problem only for distributors. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i0kck7$1k...@dough.gmane.org