DISTRO-DILEMMA: removed

Out of date and not kept accurate. It was sort of a problem of the past
anyway.

1 files changed, 0 insertions, 176 deletions

diff --git a/docs/DISTRO-DILEMMA b/docs/DISTRO-DILEMMA
deleted file mode 100644
index 2d317fdb0..000000000
--- 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