Home | History | Annotate | Download | only in docs
      1   Date: February 11, 2007
      2   Author: Daniel Stenberg <daniel (a] haxx.se>
      3   URL: http://curl.haxx.se/legal/distro-dilemma.html
      4 
      5 Condition
      6 
      7  This document is written to describe the situation as it is right now.
      8  libcurl 7.16.1 is currently the latest version available. Things may of
      9  course change in the future.
     10 
     11  This document reflects my view and understanding of these things. Please tell
     12  me where and how you think I'm wrong, and I'll try to correct my mistakes.
     13 
     14 Background
     15 
     16  The Free Software Foundation has deemed the Original BSD license[1] to be
     17  "incompatible"[2] with GPL[3]. I'd rather say it is the other way around, but
     18  the point is the same: if you distribute a binary version of a GPL program,
     19  it MUST NOT be linked with any Original BSD-licensed parts or libraries.
     20  Doing so will violate the GPL license. For a long time, very many GPL
     21  licensed programs have avoided this license mess by adding an exception[8] to
     22  their license. And many others have just closed their eyes for this problem.
     23 
     24  libcurl is MIT-style[4] licensed - how on earth did this dilemma fall onto
     25  our plates?
     26 
     27  libcurl is only a little library. libcurl can be built to use OpenSSL for its
     28  SSL/TLS capabilities. OpenSSL is basically Original BSD licensed[5].
     29 
     30  If libcurl built to use OpenSSL is used by a GPL-licensed application and you
     31  decide to distribute a binary version of it (Linux distros - for example -
     32  tend to), you have a clash. GPL vs Original BSD.
     33 
     34  This dilemma is not libcurl-specific nor is it specific to any particular
     35  Linux distro. (This article mentions and refers to Debian several times, but
     36  only because Debian seems to be the only Linux distro to have faced this
     37  issue yet since no other distro is shipping libcurl built with two SSL
     38  libraries.)
     39 
     40 Part of the Operating System
     41 
     42  This would not be a problem if the used lib would be considered part of the
     43  underlying operating system, as then the GPL license has an exception
     44  clause[6] that allows applications to use such libs without having to be
     45  allowed to distribute it or its sources. Possibly some distros will claim
     46  that OpenSSL is part of their operating system.
     47 
     48  Debian does however not take this stance and has officially(?) claimed that
     49  OpenSSL is not a required part of the Debian operating system
     50 
     51  Some people claim that this paragraph cannot be exploited this way by a Linux
     52  distro, but I am not a lawyer and that is a discussion left outside of this
     53  document.
     54 
     55 GnuTLS
     56 
     57  Since May 2005 libcurl can get built to use GnuTLS instead of OpenSSL. GnuTLS
     58  is an LGPL[7] licensed library that offers a matching set of features as
     59  OpenSSL does. Now, you can build and distribute an TLS/SSL capable libcurl
     60  without including any Original BSD licensed code.
     61 
     62  I believe Debian is the first (only?) distro that provides libcurl/GnuTLS
     63  packages.
     64 
     65 yassl
     66 
     67  libcurl can get also get built to use yassl for the TLS/SSL layer. yassl is a
     68  GPL[3] licensed library.
     69 
     70 
     71 GnuTLS vs OpenSSL vs yassl
     72 
     73  While these three libraries offer similar features, they are not equal.
     74  libcurl does not (yet) offer a standardized stable ABI if you decide to
     75  switch from using libcurl-openssl to libcurl-gnutls or vice-versa. The GnuTLS
     76  and yassl support is very recent in libcurl and it has not been tested nor
     77  used very extensively, while the OpenSSL equivalent code has been used and
     78  thus matured since 1999.
     79 
     80  GnuTLS
     81    - LGPL licensed
     82    - supports SRP
     83    - lacks SSLv2 support
     84    - lacks MD2 support (used by at least some CA certs)
     85    - lacks the crypto functions libcurl uses for NTLM
     86 
     87  OpenSSL
     88    - Original BSD licensed
     89    - lacks SRP
     90    - supports SSLv2
     91    - older and more widely used
     92    - provides crypto functions libcurl uses for NTLM
     93    - libcurl can do non-blocking connects with it in 7.15.4 and later
     94 
     95  yassl
     96    - GPL licensed
     97    - much untested and unproven in the real work by (lib)curl users so we don't
     98      know a lot about restrictions or benefits from using this
     99 
    100 The Better License, Original BSD, GPL or LGPL?
    101 
    102  It isn't obvious or without debate to any objective interested party that
    103  either of these licenses are the "better" or even the "preferred" one in a
    104  generic situation.
    105 
    106  Instead, I think we should accept the fact that the SSL/TLS libraries and
    107  their different licenses will fit different applications and their authors
    108  differently depending on the applications' licenses and their general usage
    109  pattern (considering how GPL and LGPL libraries for example can be burdensome
    110  for embedded systems usage).
    111 
    112  In Debian land, there seems to be a common opinion that LGPL is "maximally
    113  compatible" with apps while Original BSD is not. Like this:
    114 
    115         https://lists.debian.org/debian-devel/2005/09/msg01417.html
    116 
    117 More SSL Libraries
    118 
    119  In libcurl, there's no stopping us here. There are more Open Source/Free
    120  SSL/TLS libraries out there and we would very much like to support them as
    121  well, to offer application authors an even wider scope of choice.
    122 
    123 Application Angle of this Problem
    124 
    125  libcurl is built to use one SSL/TLS library. It uses a single fixed name (by
    126  default) on the built/created lib file, and applications are built/linked to
    127  use that single lib. Replacing one libcurl instance with another one that
    128  uses the other SSL/TLS library might break one or more applications (due to
    129  ABI differences and/or different feature set). You want your application to
    130  use the libcurl it was built for.
    131 
    132 Project cURL Angle of this Problem
    133 
    134  We distribute libcurl and everyone may build libcurl with either library at
    135  their choice. This problem is not directly a problem of ours. It merely
    136  affects users - GPL application authors only - of our lib as it comes
    137  included and delivered on some distros.
    138 
    139  libcurl has different ABI when built with different SSL/TLS libraries due to
    140  these reasons:
    141 
    142  1. No one has worked on fixing this. The mutex/lock callbacks should be set
    143     with a generic libcurl function that should use the proper underlying
    144     functions.
    145 
    146  2. The CURLOPT_SSL_CTX_FUNCTION option is not possible to "emulate" on GnuTLS
    147     but simply requires OpenSSL.
    148 
    149  3. There might be some other subtle differences just because nobody has yet
    150     tried to make a fixed ABI like this.
    151 
    152 Distro Angle of this Problem
    153 
    154  To my knowledge there is only one distro that ships libcurl built with either
    155  OpenSSL or GnuTLS.
    156 
    157  Debian Linux is now (since mid September 2005) providing two different
    158  libcurl packages, one for libcurl built with OpenSSL and one built with
    159  GnuTLS. They use different .so names and can this both be installed in a
    160  single system simultaneously. This has been said to be a transitional system
    161  not desired to keep in the long run.
    162 
    163 Footnotes
    164 
    165  [1] = http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6
    166  [2] = https://www.gnu.org/philosophy/bsd.html
    167  [3] = https://www.gnu.org/licenses/gpl.html
    168  [4] = http://curl.haxx.se/docs/copyright.html
    169  [5] = https://www.openssl.org/source/license.html
    170  [6] = https://www.gnu.org/licenses/gpl.html end of section 3
    171  [7] = https://www.gnu.org/licenses/lgpl.html
    172  [8] = https://en.wikipedia.org/wiki/OpenSSL_exception
    173 
    174 Feedback/Updates provided by
    175 
    176  Eric Cooper
    177