curl folder renamed

git-svn-id: http://svn.miranda-ng.org/main/trunk@6858 1316c22d-e87f-b044-9b9b-93d7a3e3ba9c

1 files changed, 176 insertions, 0 deletions

diff --git a/plugins/FTPFileYM/curl/docs/DISTRO-DILEMMA b/plugins/FTPFileYM/curl/docs/DISTRO-DILEMMA
new file mode 100644
index 0000000000..108e6bad12
--- /dev/null
+++ b/plugins/FTPFileYM/curl/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