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
  converted license.

* 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
  MPL.

* 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
  that risk.

  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-library