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

Re: Providing an openssl-linked pycurl

В Sat, 03 Jul 2010 10:23:16 +0100, MJ Ray написа:
> Yavor Doganov wrote:
>> 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?

Well, the program can check for the presence of libcurl-gnutls and
libcurl, and conditionally link with it.  Or, in the hypothetical
case, it can conditionally use libfoo or libbar, either of which can
be linked against OpenSSL/GnuTLS/NSS/etc.

>> LuserNET doesn't use any OpenSSL functions at all.  [...]
> Then I don't see why it's a bug in LuserNET,

According to FSF's linking theory, which Debian seems to support/agree
with, it is.


Certainly, the only way to fix this issue in lusernet.app itself is
the copyright holder to grant the OpenSSL exception.  Which is
probably harder than some hacking on Pantomime :-)

> It feels more like a bug in libpantomime1.2 linking against libssl
> for SSL support even when that support is not required.

Pantomime certainly needs SSL support to call itself "framework for
mail handling".  Naturally, the library cannot anticipate what
classes/functionality applications may need.  I agree with you that it
is a bug (non-RC) in pantomime that it links against OpenSSL, because
this has the annoying effect that every GPL'ed app must come with the
OpenSSL exception.

Reply to: