curl/docs/DISTRO-DILEMMA

  Date: May 15, 2006
  Author: Daniel Stenberg <daniel@haxx.se>
  URL: http://curl.haxx.se/legal/distro-dilemma.html

Condition

 This document is written to describe the situation as it is right
 now. libcurl 7.15.3 is currently the latest version available. Things may of
 course change in the future.

 This document reflects my view and understanding of these things. Please tell
 me where and how you think I'm wrong, and I'll try to correct my mistakes.

Background 

 The Free Software Foundation has deemed the Original BSD license[1] to be
 "incompatible"[2] with GPL[3]. I'd rather say it is the other way around, but
 the point is the same: if you distribute a binary version of a GPL program,
 it MUST NOT be linked with any Original BSD-licensed parts or libraries.
 Doing so will violate the GPL license. For a long time, very many GPL
 licensed programs have avoided this license mess by adding an exception[8] to
 their license. And many others have just closed their eyes for this problem.

 libcurl is MIT-style[4] licensed - how on earth did this dilemma fall onto
 our plates?

 libcurl is only a little library. libcurl can be built to use OpenSSL for its
 SSL/TLS capabilities. OpenSSL is basically Original BSD licensed[5].

 If libcurl built to use OpenSSL is used by a GPL-licensed application and you
 decide to distribute a binary version of it (Linux distros - for example -
 tend to), you have a clash. GPL vs Original BSD.

 This dilemma is not libcurl-specific nor is it specific to any particular
 Linux distro. (This article mentions and refers to Debian several times, but
 only because Debian seems to be the only Linux distro to have faced this
 issue yet since no other distro is shipping libcurl built with two SSL
 libraries.)

Part of the Operating System

 This would not be a problem if the used lib would be considered part of the
 underlying operating system, as then the GPL license has an exception
 clause[6] that allows applications to use such libs without having to be
 allowed to distribute it or its sources. Possibly some distros will claim
 that OpenSSL is part of their operating system.

 Debian does however not take this stance and has officially(?) claimed that
 OpenSSL is not a required part of the Debian operating system

GnuTLS

 With the release of libcurl 7.14.0 (May 2005), libcurl can now get built to
 use GnuTLS instead of OpenSSL. GnuTLS is an LGPL[7] licensed library that
 offers a matching set of features as OpenSSL does. Now, you can build and
 distribute an TLS/SSL capable libcurl without including any Original BSD
 licensed code.

 I believe Debian is the first distro to provide libcurl/GnutTLS packages.

GnuTLS vs OpenSSL

 While these two libraries offer similar features, they are not equal. Both
 libraries have features the other one lacks. libcurl does not (yet) offer a
 standardized stable ABI if you decide to switch from using libcurl-openssl to
 libcurl-gnutls or vice versa. The GnuTLS support is very recent in libcurl
 and it has not been tested nor used very extensively, while the OpenSSL
 equivalent code has been used and thus matured for more than seven (7) years.

 GnuTLS
   - LGPL licensened
   - supports SRP
   - lacks SSLv2 support
   - lacks MD2 support (used by at least some CA certs)
   - lacks the crypto functions libcurl uses for NTLM

 OpenSSL
   - Original BSD licensened
   - lacks SRP
   - supports SSLv2
   - older and more widely used
   - provides crypto functions libcurl uses for NTLM
   - libcurl can do non-blocking connects with it in 7.15.4 and later

The Better License, Original BSD or LGPL?

 It isn't obvious or without debate to any objective interested party that
 either of these licenses are the "better" or even the "preferred" one in a
 generic situation.

 Instead, I think we should accept the fact that the SSL/TLS libraries and
 their different licenses will fit different applications and their authors
 differently depending on the applications' licenses and their general usage
 pattern (considering how LGPL libraries for example can be burdensome for
 embedded systems usage).

 In Debian land, there seems to be a common opinion that LGPL is "maximally
 compatible" with apps while Original BSD is not. Like this:

        http://lists.debian.org/debian-devel/2005/09/msg01417.html

More SSL Libraries

 In libcurl, there's no stopping us here. There are at least a few more Open
 Source/Free SSL/TLS libraries and we would very much like to support them as
 well, to offer application authors an even wider scope of choice.

Application Angle of this Problem

 libcurl is built to use one SSL/TLS library. It uses a single fixed name (by
 default) on the built/created lib file, and applications are built/linked to
 use that single lib. Replacing one libcurl instance with another one that
 uses the other SSL/TLS library might break one or more applications (due to
 ABI differences and/or different feature set). You want your application to
 use the libcurl it was built for.

Project cURL Angle of this Problem

 We distribute libcurl and everyone may build libcurl with either library at
 their choice. This problem is not directly a problem of ours. It merely
 affects users - GPL application authors only - of our lib as it comes
 included and delivered on some distros.

 libcurl has different ABI when built with different SSL/TLS libraries due to
 these reasons:

 1. No one has worked on fixing this. The mutex/lock callbacks should be set
    with a generic libcurl function that should use the proper underlying
    functions.

 2. The CURLOPT_SSL_CTX_FUNCTION option is not possible to "emulate" on GnuTLS
    but simply requires OpenSSL.

 3. There might be some other subtle differences just because nobody has yet
    tried to make a fixed ABI like this.

Distro Angle of this Problem

 To my knowledge there is only one distro that ships libcurl built with either
 one of the SSL libs supported.

 Debian Linux is now (since mid September 2005) providing two different
 libcurl packages, one for libcurl built with OpenSSL and one built with
 GnuTLS. They use different .so names and can this both be installed in a
 single system simultaneously. This has been said to be a transitional system
 not desired to keep in the long run.

Fixing the Only Problem

 The only problem is thus for distributions that want to offer libcurl
 versions built with more than one SSL/TLS library.

 Since multiple libcurl binaries using different names are ruled out, we need
 to come up with a way to have one single libcurl that someone uses different
 underlying libraries. The best(?) approach currently suggested involves this:

 A new intermediate library (named lib2 so far in the discussions) with the
 single purpose of providing libcurl with SSL/TLS capabilities. It would have
 a unified API and ABI no matter what underlying library it would use.

 There would be one lib2 binary provided for each supported SSL/TLS library.
 For example: lib2-openssl, lib2-gnutls, lib2-yassl, lib2-matrixssl and
 lib2-nossl. Yes, take note of the last one that provides the lib2 ABI but
 that lacks the actual powers.

 When libcurl is built and linked, it will be linked against a lib2 with the
 set ABI.

 When you link an app against libcurl, it would also need to provide one of
 the (many) lib2 libs to decide what approach that fits the app. An app that
 doesn't want SSL at all would still need to link with the lib2-nossl lib.

 GPL apps can pick the lib2-gnutls, others may pick the lib2-openssl.

 This concept works equally well both for shared and static libraries.

 A positive side effect of this approach could be a more generic "de facto"
 standard API for SSL/TLS libraries.

When Will This Happen

 This is not a problem in curl, it doesn't solve any actual technical problems
 in our project. Don't hold your breath for this to happen very soon (if at
 all) unless you step forward and contribute.

 The suggestion that is outlined above is still only a suggestion. Feel free
 to bring a better idea!

 Also, to keep in mind: I don't want this new concept to have too much of an
 impact on the existing code. Preferably it should be possible to build the
 code like today (without the use of lib2), should you decide to ignore the
 problems outlined in this document.

 Work on this was suggested by Richard Atterer:

        http://curl.haxx.se/mail/lib-2005-09/0066.html

Footnotes

 [1] = http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6
 [2] = http://www.fsf.org/licensing/essays/bsd.html
 [3] = http://www.fsf.org/licensing/licenses/gpl.html
 [4] = http://curl.haxx.se/docs/copyright.html
 [5] = http://www.openssl.org/source/license.html
 [6] = http://www.fsf.org/licensing/licenses/gpl.html end of section 3
 [7] = http://www.fsf.org/licensing/licenses/lgpl.html
 [8] = http://en.wikipedia.org/wiki/OpenSSL_exception

Feedback/Updates provided by

 Eric Cooper