mirror of
https://github.com/moparisthebest/curl
synced 2024-11-11 20:15:03 -05:00
DISTRO-DILEMMA: removed
Out of date and not kept accurate. It was sort of a problem of the past anyway.
This commit is contained in:
Daniel Stenberg
parent
ca20ca54b2
commit
ea2c959db4
@ -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
|
|
||||||
@ -36,9 +36,9 @@ CLEANFILES = $(GENHTMLPAGES) $(PDFPAGES)
|
|||||||
EXTRA_DIST = MANUAL BUGS CONTRIBUTE FAQ FEATURES INTERNALS SSLCERTS \
|
EXTRA_DIST = MANUAL BUGS CONTRIBUTE FAQ FEATURES INTERNALS SSLCERTS \
|
||||||
README.win32 RESOURCES TODO TheArtOfHttpScripting THANKS VERSIONS \
|
README.win32 RESOURCES TODO TheArtOfHttpScripting THANKS VERSIONS \
|
||||||
KNOWN_BUGS BINDINGS $(man_MANS) $(HTMLPAGES) HISTORY INSTALL \
|
KNOWN_BUGS BINDINGS $(man_MANS) $(HTMLPAGES) HISTORY INSTALL \
|
||||||
$(PDFPAGES) LICENSE-MIXING README.netware DISTRO-DILEMMA INSTALL.devcpp \
|
$(PDFPAGES) LICENSE-MIXING README.netware INSTALL.devcpp \
|
||||||
MAIL-ETIQUETTE HTTP-COOKIES SECURITY RELEASE-PROCEDURE \
|
MAIL-ETIQUETTE HTTP-COOKIES SECURITY RELEASE-PROCEDURE SSL-PROBLEMS \
|
||||||
SSL-PROBLEMS HTTP2.md ROADMAP.md CODE_OF_CONDUCT.md
|
HTTP2.md ROADMAP.md CODE_OF_CONDUCT.md
|
||||||
|
|
||||||
MAN2HTML= roffit < $< >$@
|
MAN2HTML= roffit < $< >$@
|
||||||
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user