diff options
Diffstat (limited to 'libs/libcurl/docs/DISTRO-DILEMMA')
| -rw-r--r-- | libs/libcurl/docs/DISTRO-DILEMMA | 176 |
1 files changed, 176 insertions, 0 deletions
diff --git a/libs/libcurl/docs/DISTRO-DILEMMA b/libs/libcurl/docs/DISTRO-DILEMMA new file mode 100644 index 0000000000..108e6bad12 --- /dev/null +++ b/libs/libcurl/docs/DISTRO-DILEMMA @@ -0,0 +1,176 @@ + 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/GnutTLS + 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 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 + + 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: + + http://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] = 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 |