1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
|
Date: October 27, 2005
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.15.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-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
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.
GnuTLS
- LGPL licensened
- supports SRP
- lacks SSLv2 support
- lacks MD2 support (used by at least some CA certs)
OpenSSL
- Original BSD licensened
- lacks SRP
- supports SSLv2
- older and more widely used
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.
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 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 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.
libcurl has different ABI when built with different SSL/TLS libraries due to
two 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.
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.
Debian is now (since mid September 2005) providing two different devel
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 previously been said as a transitional system not
desired to keep in the long run.
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.
A positive side effect of this approach could be a more generic "de facto"
standard API for SSL/TLS 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.
Update: Work on this has been initiated by Richard Atterer:
http://curl.haxx.se/mail/lib-2005-09/0066.html
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
|
