Re: Providing an openssl-linked pycurl
В 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.
Reply to: