docs/DISTRO-DILEMMA

   1   Date: February 11, 2007
   2   Author: Daniel Stenberg <daniel@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         http://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] = http://www.fsf.org/licensing/essays/bsd.html
 167  [3] = http://www.fsf.org/licensing/licenses/gpl.html
 168  [4] = http://curl.haxx.se/docs/copyright.html
 169  [5] = http://www.openssl.org/source/license.html
 170  [6] = http://www.fsf.org/licensing/licenses/gpl.html end of section 3
 171  [7] = http://www.fsf.org/licensing/licenses/lgpl.html
 172  [8] = http://en.wikipedia.org/wiki/OpenSSL_exception
 173
 174 Feedback/Updates provided by
 175
 176  Eric Cooper