curl-7.25.0/docs/DISTRO-DILEMMA - nest-learning-thermostat/5.1.3/curl - Git at Google

   Date: February 11, 2007
   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.16.1 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

  Some people claim that this paragraph cannot be exploited this way by a Linux
  distro, but I am not a lawyer and that is a discussion left outside of this
  document.

 GnuTLS

  Since May 2005 libcurl can 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 (only?) distro that provides libcurl/GnutTLS
  packages.

 yassl

  libcurl can get also get built to use yassl for the TLS/SSL layer. yassl is a
  GPL[3] licensed library.


 GnuTLS vs OpenSSL vs yassl

  While these three libraries offer similar features, they are not equal.
  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
  and yassl 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 since 1999.

  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

  yassl
    - GPL licensed
    - much untested and unproven in the real work by (lib)curl users so we don't
      know a lot about restrictions or benefits from using this

 The Better License, Original BSD, GPL 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 GPL and 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 more Open Source/Free
  SSL/TLS libraries out there 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
  OpenSSL or GnuTLS.

  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.

 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
	Date: February 11, 2007
	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.16.1 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

	Some people claim that this paragraph cannot be exploited this way by a Linux
	distro, but I am not a lawyer and that is a discussion left outside of this
	document.

	GnuTLS

	Since May 2005 libcurl can 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 (only?) distro that provides libcurl/GnutTLS
	packages.

	yassl

	libcurl can get also get built to use yassl for the TLS/SSL layer. yassl is a
	GPL[3] licensed library.


	GnuTLS vs OpenSSL vs yassl

	While these three libraries offer similar features, they are not equal.
	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
	and yassl 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 since 1999.

	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

	yassl
	- GPL licensed
	- much untested and unproven in the real work by (lib)curl users so we don't
	know a lot about restrictions or benefits from using this

	The Better License, Original BSD, GPL 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 GPL and 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 more Open Source/Free
	SSL/TLS libraries out there 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
	OpenSSL or GnuTLS.

	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.

	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