Date: August 31, 2005 Author: Daniel Stenberg URL: Condition This document is written to describe the sitution as it is right now. libcurl 7.14.0 is currently the latest version available. Things may (or perhaps will) 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-licenced 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. Part of the Operating System This would not be a problem if the used lib would be considered part of the uderlying 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 Debian-legal In August 2004 I figured I should start pulling people's attention to this to see if anyone has any bright ideas or if they would dismiss my worries based on some elegant writing I had missed somewhere: My post to debian-legal on August 12 2004: http://lists.debian.org/debian-legal/2004/08/msg00279.html Several people agreed then that this is a known and rather big problem, but the following discussion didn't result in much. GnuTLS With the release of libcurl 7.14.0 (May 2005), it can now get built to use GnuTLS instead of OpenSSL. GnuTLS is a LGPL[7] licensed library that offers a matching set of features as OpenSSL does. Now, you can build and distribute an 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. In August 2005, the debian-devel mailing list discovered the license issue as a GPL licensed application wanted SSL capabilities from libcurl and thus was forced to use the GnuTLS powered libcurl. For a reason that is unknown to me, the application authors didn't want to or was unable to add an exception to their GPL license. Alas, the license problem hit the fan again. 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. In the Debian camp they frawn upon OpenSSL's BSD license, but that seems to merely stem from the general FSF friendliness and GPL bigotry than based on a sane and proper analysis (assuming such a one is even possible within an area as filled with religion and personal preferences such as this). This is however not a subject suitable for this document. 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 can be burdonsome for embedded systems usage). 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), 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. Distro Angle of this Problem A distro can provide separate libcurls built with different SSL/TLS libraries to work around this, but at least Debian seems to be very hostile against such an approach, probably since it makes things like devel packages for the different libs collide since they would provide the same include files and man pages etc. 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. When Will This Happen Note again that 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. 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