1
Date: February 11, 2007
2
2
Author: Daniel Stenberg <daniel@haxx.se>
3
3
URL: http://curl.haxx.se/legal/distro-dilemma.html
7
This document is written to describe the situation as it is right
8
now. libcurl 7.15.3 is currently the latest version available. Things may of
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
9
course change in the future.
11
11
This document reflects my view and understanding of these things. Please tell
48
48
Debian does however not take this stance and has officially(?) claimed that
49
49
OpenSSL is not a required part of the Debian operating system
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
With the release of libcurl 7.14.0 (May 2005), libcurl can now get built to
54
use GnuTLS instead of OpenSSL. GnuTLS is an LGPL[7] licensed library that
55
offers a matching set of features as OpenSSL does. Now, you can build and
56
distribute an TLS/SSL capable libcurl without including any Original BSD
59
I believe Debian is the first distro to provide libcurl/GnutTLS packages.
63
While these two libraries offer similar features, they are not equal. Both
64
libraries have features the other one lacks. libcurl does not (yet) offer a
65
standardized stable ABI if you decide to switch from using libcurl-openssl to
66
libcurl-gnutls or vice versa. The GnuTLS support is very recent in libcurl
67
and it has not been tested nor used very extensively, while the OpenSSL
68
equivalent code has been used and thus matured for more than seven (7) years.
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.
62
I believe Debian is the first (only?) distro that provides libcurl/GnutTLS
67
libcurl can get also get built to use yassl for the TLS/SSL layer. yassl is a
68
GPL[3] licensed library.
71
GnuTLS vs OpenSSL vs yassl
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.
82
92
- provides crypto functions libcurl uses for NTLM
83
93
- libcurl can do non-blocking connects with it in 7.15.4 and later
85
The Better License, Original BSD or LGPL?
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
100
The Better License, Original BSD, GPL or LGPL?
87
102
It isn't obvious or without debate to any objective interested party that
88
103
either of these licenses are the "better" or even the "preferred" one in a
91
106
Instead, I think we should accept the fact that the SSL/TLS libraries and
92
107
their different licenses will fit different applications and their authors
93
108
differently depending on the applications' licenses and their general usage
94
pattern (considering how LGPL libraries for example can be burdensome for
95
embedded systems usage).
109
pattern (considering how GPL and LGPL libraries for example can be burdensome
110
for embedded systems usage).
97
112
In Debian land, there seems to be a common opinion that LGPL is "maximally
98
113
compatible" with apps while Original BSD is not. Like this:
102
117
More SSL Libraries
104
In libcurl, there's no stopping us here. There are at least a few more Open
105
Source/Free SSL/TLS libraries and we would very much like to support them as
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
106
121
well, to offer application authors an even wider scope of choice.
108
123
Application Angle of this Problem
137
152
Distro Angle of this Problem
139
154
To my knowledge there is only one distro that ships libcurl built with either
140
one of the SSL libs supported.
142
157
Debian Linux is now (since mid September 2005) providing two different
143
158
libcurl packages, one for libcurl built with OpenSSL and one built with
145
160
single system simultaneously. This has been said to be a transitional system
146
161
not desired to keep in the long run.
148
Fixing the Only Problem
150
The only problem is thus for distributions that want to offer libcurl
151
versions built with more than one SSL/TLS library.
153
Since multiple libcurl binaries using different names are ruled out, we need
154
to come up with a way to have one single libcurl that someone uses different
155
underlying libraries. The best(?) approach currently suggested involves this:
157
A new intermediate library (named lib2 so far in the discussions) with the
158
single purpose of providing libcurl with SSL/TLS capabilities. It would have
159
a unified API and ABI no matter what underlying library it would use.
161
There would be one lib2 binary provided for each supported SSL/TLS library.
162
For example: lib2-openssl, lib2-gnutls, lib2-yassl, lib2-matrixssl and
163
lib2-nossl. Yes, take note of the last one that provides the lib2 ABI but
164
that lacks the actual powers.
166
When libcurl is built and linked, it will be linked against a lib2 with the
169
When you link an app against libcurl, it would also need to provide one of
170
the (many) lib2 libs to decide what approach that fits the app. An app that
171
doesn't want SSL at all would still need to link with the lib2-nossl lib.
173
GPL apps can pick the lib2-gnutls, others may pick the lib2-openssl.
175
This concept works equally well both for shared and static libraries.
177
A positive side effect of this approach could be a more generic "de facto"
178
standard API for SSL/TLS libraries.
180
When Will This Happen
182
This is not a problem in curl, it doesn't solve any actual technical problems
183
in our project. Don't hold your breath for this to happen very soon (if at
184
all) unless you step forward and contribute.
186
The suggestion that is outlined above is still only a suggestion. Feel free
187
to bring a better idea!
189
Also, to keep in mind: I don't want this new concept to have too much of an
190
impact on the existing code. Preferably it should be possible to build the
191
code like today (without the use of lib2), should you decide to ignore the
192
problems outlined in this document.
194
Work on this was suggested by Richard Atterer:
196
http://curl.haxx.se/mail/lib-2005-09/0066.html
200
165
[1] = http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6
added
removed
docs/DISTRO-DILEMMA
