DISTRO-DILEMMA: removed

  Date: February 11, 2007

  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.16.1 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

 Some people claim that this paragraph cannot be exploited this way by a Linux

 distro, but I am not a lawyer and that is a discussion left outside of this

 document.

GnuTLS

 Since May 2005 libcurl can 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 (only?) distro that provides libcurl/GnuTLS

 packages.

yassl

 libcurl can get also get built to use yassl for the TLS/SSL layer. yassl is a

 GPL[3] licensed library.

GnuTLS vs OpenSSL vs yassl

 While these three libraries offer similar features, they are not equal.

 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

 and yassl 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 since 1999.

 GnuTLS

   - LGPL licensed

   - 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 licensed

   - 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

 yassl

   - GPL licensed

   - much untested and unproven in the real work by (lib)curl users so we don't

     know a lot about restrictions or benefits from using this

The Better License, Original BSD, GPL 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 GPL and 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:

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

More SSL Libraries

 In libcurl, there's no stopping us here. There are more Open Source/Free

 SSL/TLS libraries out there 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

 OpenSSL or GnuTLS.

 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.

Footnotes

 [1] = http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6

 [2] = https://www.gnu.org/philosophy/bsd.html

 [3] = https://www.gnu.org/licenses/gpl.html

 [4] = http://curl.haxx.se/docs/copyright.html

 [5] = https://www.openssl.org/source/license.html

 [6] = https://www.gnu.org/licenses/gpl.html end of section 3

 [7] = https://www.gnu.org/licenses/lgpl.html

 [8] = https://en.wikipedia.org/wiki/OpenSSL_exception

Feedback/Updates provided by

 Eric Cooper

EXTRA_DIST = MANUAL BUGS CONTRIBUTE FAQ FEATURES INTERNALS SSLCERTS	\

 README.win32 RESOURCES TODO TheArtOfHttpScripting THANKS VERSIONS	\

 KNOWN_BUGS BINDINGS $(man_MANS) $(HTMLPAGES) HISTORY INSTALL		\

 $(PDFPAGES) LICENSE-MIXING README.netware DISTRO-DILEMMA INSTALL.devcpp \

 MAIL-ETIQUETTE HTTP-COOKIES SECURITY RELEASE-PROCEDURE  \

 SSL-PROBLEMS HTTP2.md ROADMAP.md CODE_OF_CONDUCT.md

 $(PDFPAGES) LICENSE-MIXING README.netware INSTALL.devcpp		\

 MAIL-ETIQUETTE HTTP-COOKIES SECURITY RELEASE-PROCEDURE SSL-PROBLEMS	\

 HTTP2.md ROADMAP.md CODE_OF_CONDUCT.md

MAN2HTML= roffit < $< >$@