On Thu, 25 Aug 2005, Richard Atterer wrote:

>> Instead, we could just make a new lib (let's call it lib2) that libcurl
>> requires to do SSL, that has a standard API/ABI. lib2 can be linked with
>> one out of a wide selection of SSL libs. So, when you link your app that
>> uses libcurl to do SSL, you link with libcurl, lib2 and the underlying
>> SSL lib.
>
> I think that is a nice idea! Similar to my "libcurl-ssldummy" proposal,
> it'll use curl-config to do the "linking magic", but additionally it doesn't
> require an empty dummy library.

Right. Without an SSL library present, or if disabled, there would be no lib2
with SSL powers.

There could of course be a lib2 version provided that just returns "no
capabilities" when asked what it supports, as that way the libcurl internals
would be identical no matter if SSL is supported or not by lib2.

>> In Debian, you'd have lib2-openssl and lib2-gnutls installed, but only one
>> single libcurl. Each app will then depend on libcurl and one of the lib2
>> versions.
>
> Oh, it'll be OK to have just one libcurl package which contains both the
> OpenSSL lib2 and the GnuTLS one. AFAICT there's no legal problem with this.

True. As the legal problems are not within the curl package, it could indeed
contain the lot. Only a binary distribution of a GPL application would have to
be restricted to not include the lib2-openssl lib, or at least the actual
openssl libs.

>> But I don't really see why the plugin concept or the lib2 concept is much
>> better than the two libcurl versions concept...
>
> If you as upstream mandate different library names for the two variants,
> this would be OK WRT cross-platform compatibility. Hm, but then you'd need
> *three* different names; one more for the libcurl without any SSL support.
> In the future, you'd need yet more names for further backends.

Right. The current problem with OpenSSL vs GnuTLS in Debian land has in fact
has existed (in only a slightly different form) since several years back.
Applications that are GPL licensed (without an exception clause) have linked
with the OpenSSL-built libcurl for eons. I once pointed this out on the debian
legal list, but the subject was not really picked up or understood.

This issue does not only affect Debian, it affects all Linux distributions
that ship binary versions of GPL apps using OpenSSL-powered libcurl.

Now, however, when there's a viable SSL alternative called GnuTLS it has
suddently come to the surface again and now the issue seems to be considered
important enough to actually do something about. Or at least to discuss about
doing something about.

I guess that in general people don't care, as the OpenSSL people seem to not
care very much if people obey the announce clause of their license, and GPL
app authors seem reluctant to overlook this little detail in the license.

> This is a somewhat weak argument, but personally I feel that it's "not nice"
> to have the code duplicated in 3 or more libraries.

I agree with that. But as a short to mid term solution, I think that's the
only way to go.

But let's go back to the lib2 concept!

  Are there any (major) drawbacks?

  Would it be a good solution for Debian and other Linux distributions?

  Are there other/better ways to reach the same goals?

  Anyone has a better name than lib2 to suggest?

  Anyone feels like taking a stab to work on this?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html