diff options
Diffstat (limited to 'docs/DISTRO-DILEMMA')
| -rw-r--r-- | docs/DISTRO-DILEMMA | 176 |
1 files changed, 0 insertions, 176 deletions
diff --git a/docs/DISTRO-DILEMMA b/docs/DISTRO-DILEMMA deleted file mode 100644 index 2d317fdb..00000000 --- a/docs/DISTRO-DILEMMA +++ /dev/null @@ -1,176 +0,0 @@ - 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 |