212 строки
8.7 KiB
Plaintext
212 строки
8.7 KiB
Plaintext
Date: May 15, 2006
|
|
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.15.3 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
|
|
|
|
GnuTLS
|
|
|
|
With the release of libcurl 7.14.0 (May 2005), libcurl can now 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 distro to provide libcurl/GnutTLS packages.
|
|
|
|
GnuTLS vs OpenSSL
|
|
|
|
While these two libraries offer similar features, they are not equal. Both
|
|
libraries have features the other one lacks. 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 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 for more than seven (7) years.
|
|
|
|
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
|
|
|
|
The Better License, Original BSD 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 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 at least a few more Open
|
|
Source/Free SSL/TLS libraries 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
|
|
one of the SSL libs supported.
|
|
|
|
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.
|
|
|
|
Fixing the Only Problem
|
|
|
|
The only problem is thus for distributions that want to offer libcurl
|
|
versions built with more than one SSL/TLS library.
|
|
|
|
Since multiple libcurl binaries using different names are ruled out, we need
|
|
to come up with a way to have one single libcurl that someone uses different
|
|
underlying libraries. The best(?) approach currently suggested involves this:
|
|
|
|
A new intermediate library (named lib2 so far in the discussions) with the
|
|
single purpose of providing libcurl with SSL/TLS capabilities. It would have
|
|
a unified API and ABI no matter what underlying library it would use.
|
|
|
|
There would be one lib2 binary provided for each supported SSL/TLS library.
|
|
For example: lib2-openssl, lib2-gnutls, lib2-yassl, lib2-matrixssl and
|
|
lib2-nossl. Yes, take note of the last one that provides the lib2 ABI but
|
|
that lacks the actual powers.
|
|
|
|
When libcurl is built and linked, it will be linked against a lib2 with the
|
|
set ABI.
|
|
|
|
When you link an app against libcurl, it would also need to provide one of
|
|
the (many) lib2 libs to decide what approach that fits the app. An app that
|
|
doesn't want SSL at all would still need to link with the lib2-nossl lib.
|
|
|
|
GPL apps can pick the lib2-gnutls, others may pick the lib2-openssl.
|
|
|
|
This concept works equally well both for shared and static libraries.
|
|
|
|
A positive side effect of this approach could be a more generic "de facto"
|
|
standard API for SSL/TLS libraries.
|
|
|
|
When Will This Happen
|
|
|
|
This is not a problem in curl, it doesn't solve any actual technical problems
|
|
in our project. Don't hold your breath for this to happen very soon (if at
|
|
all) unless you step forward and contribute.
|
|
|
|
The suggestion that is outlined above is still only a suggestion. Feel free
|
|
to bring a better idea!
|
|
|
|
Also, to keep in mind: I don't want this new concept to have too much of an
|
|
impact on the existing code. Preferably it should be possible to build the
|
|
code like today (without the use of lib2), should you decide to ignore the
|
|
problems outlined in this document.
|
|
|
|
Work on this was suggested by Richard Atterer:
|
|
|
|
http://curl.haxx.se/mail/lib-2005-09/0066.html
|
|
|
|
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
|