Date: Thu, 2 Nov 2000 09:44:21 +0100 (MET)
On Wed, 1 Nov 2000, JAmes Atwill wrote:
(Cross-posted to both curl mailing lists, since I think this is an important
issue. Further discussions on this is better held in the main curl list.)
> libcurl is great. It's easy to use, it's got great support for SSL, it's
> like the swiss army knife of transfers.
> But when I ask why other people don't use it, they throw "It's not GPL'd!"
> at me.
> So, I ask, without wanting to start a flame war, is there a reason why
> libcurl isn't LGPL'd? Or is it simply a "haven't gotten around to it"?
I think this is a fair question that requires a good answer. Let me do the
lengthy version to straighten out several things at once. This contains
opinions, they are mine. It also contains facts, those I believe are true no
matter what my opinions are.
* I am not a license export and nor am I a lawyer. Feel free to object to
anything I might say that seems wrong.
* I licensed curl under MPL since that license appealed the most to be at the
time of chosing. I did not consider "GPL compatibility" then and I wasn't
even aware of those problems until years later. (Possibly because it took
years before any GPL-programs wanted to use it! ;-)
MPL is what a GNU persons would call "weak copyleft". Copyleft (explained
to somone not very into this kind of stuff) in the sense that it forces
anyone doing changes to the sources to give out those changes. MPL only
requires changes to the actual product (curl and libcurl) to be relased.
GPL requires that all parts of a distributed program is "compatible" with
it, and they say MPL isn't compatible. GPL is "strong copyleft" in that
sense, it spreads and make demands on other parts of a program that uses a
single GPLed part. MPL doesn't.
GPL people says that is good since it helps making the entire program free.
I think its bad since I don't want my project to impose anything on other
parts of an application.
I want to be able to use curl and libcurl in closed-source projects.
* Curl has truely been a work of many independent contributors. I have
gathered the names of the people that have done "non-trivial" improvments
in the bottom of the man page, and I believe it currently lists 54 names.
To change the license completely, I need the permission of all authors or I
need to rewrite the parts I don't get permission for. I can't change
license as I please.
MPL allows me to sublicense the work, and thus I can dual-license curl
using a different license at the same time while offering it as MPL. This
will allow me to continue business as usual while moving towards a full
* LGPL you might say as a general answer to plain GPL doubts. LGPL doesn't
spread to other parts of an application and it does allow being linked with
closed-source programs. LGPL is "compatible" with GPL in the sense that you
can, at your option, convert a LGPLed program to a GPL one any time you
want. Such a change is irreversible. This is what I call GPL-hijacking. For
a small project, this is a risk. If a truly skilled person adds a lot of
functionality and relicense curl to GPL, the LGPLed one would swiftly be
abandoned and the GPL-changes cannot be applied back in the LGPL version.
* Where lies this license problem? MPL itself has no problems with the LGPL
or GPL licenses, the problem is on the GNU side. GPL has a problem with
* Then what I am gonna do? Well, to be honest, I'd wish the RMS/FSF/GNU guys
would come to their senses and proclaim MPL to be GPL compatible.
They won't, so I'm not gonna sit back and wait for that to happen.
I'm working on a new curl license. I want it to be based on the extremely
liberal X11-license (a BSD derivate without the announce clause). It
basically allows anyone to do anything with the sources as long as the
copyright text in them are left intact. There's no copyleft at all involved
and there's this risk people will grab all the sources, make private
changes and release closed-source projects using this. I'm willing to take
Since I can dual-license curl without the consent of all the authors, this
can be done relatively soon. I just need a lot of input from people and
advice from friends. I don't want to make unnecessary mistakes. I will thus
also continue offering curl/libcurl as MPL to commit to the commitment
people have contributed code to.
* Will this do? This would make curl/libcurl compatible with all known
free software licenses. Including GPL, LGPL and MPL.
Perhaps the license is too liberal for the people contributing with code,
resulting in less contributors and thus a poorer product.
Of course I need input on this. Changing stuff to the way I imagine things
aren't really useful unless I have people behind me on this. Curl is not
"my project", I just try to steer this boat!
Please flood me with your responses. I'll read them all, thoroughly.
-- Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/ _______________________________________________ Curl-library mailing list Curl-library_at_lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/curl-libraryReceived on 2000-11-02