| 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 |