[cairo] License for cairo changed to LGPL

Carl Worth cworth at east.isi.edu
Mon Aug 2 13:13:39 PDT 2004

The license for cairo has now changed to the LGPL.

The possibility of this change was originally discussed on this mailing
list beginning in November 2003, though there was not obvious consensus
from the members of the mailing list at that time, (fortunately, there
was also no flame war).

Beginning in February 2004, I contacted every cairo author[1] and asked
if they were willing to accept a change in the cairo license from the
MIT license to the LGPL. I've quoted below the rationale[2] I provided
to those authors at that time.

Some people didn't understand the "fear of forks" language I used
below. Let me take this chance to put my reasoning into other words.
I think Free Software is important, and it's important for cairo to remain
Free Software. I do not want to see non-free modifications made to
cairo. At the same time, I don't see a need to restrict the use of
cairo. Of well-used Free Software license, I think the LGPL best
captures the principles I want applied to libraries that I create.

I'm pleased to report that there is unanimous consensus among the
authors of cairo in favor of the LGPL. Distributing cairo under the LGPL
also has official sanction by the USC office of technology and
licensing, (which is significant since USC holds copyright interest in a
majority of the files in the cairo implementation).

I have committed changes to the licensing blurb for all files in the
cairo and libsvg-cairo modules in which USC has an exclusive
copyright. I encourage all authors that have copyright in portions of
cairo or in software such as language-bindings for cairo, to also change
to the LGPL, so that all users of cairo can use it under consistent
licensing terms.

Please note that software that sits under cairo, (such as libpixman and
glitz), need not necessarily change to the LGPL. In fact, it is likely
better for these libraries to remain under the MIT license as there are
plans to use them from the X server.


[1] In constructing the recipient list of "authors", I tried to err on
the safe side by defining that term as broadly as possible. The list
should include anyone that has made an accepted contribution to cairo or
other cairo-using software hosted at cairographics.org (as measured by
the occurrence of email addresses in the ChangeLog). If I missed anyone,
please let me know and accept my apologies.

[2] Some of the rationale I provided in favor of the license change to
authors of cairo.

Why use the LGPL for cairo instead of the MIT license?
I am interested in seeing cairo mature into the best quality, free
software drawing library available. It would be unfortunate if the
code were to split into multiple, uncooperative forks that were each
of lesser quality than an ideal, unified code base. Empirical evidence
from existing large-scale projects suggests that MIT-licensed projects
are more prone to this kind of negative forking than LGPL-licensed

Why change the license of cairo at all?
Changing licenses is not pleasant. Adding new restrictions to
previously released software seems especially unfair to users who
already have expectations about the things they can do with that

So how can we justify a change in cairo licensing? 1) cairo has never
been "released" so the strength of the promise already made to users
is relatively low. 2) I do not want to proceed with a license change
until we have strong consensus as the community of cairo developers.

Finally, it may be worth mentioning that I would have preferred to
start cairo under the LGPL in the first place. I did not in a
mistaken attempt to maintain license compatibility with X
libraries. This was a mistake because 1) monolithic distribution of X
libraries is no longer interesting, and 2) cairo can now be compiled
independently of X, (unlike initial versions).

Why were some people opposed to the change?
I would like to describe and address the primary concerns that were
raised in the replies I received regarding the possible license change.

1) Ambiguity of the LGPL

   Concern: The LGPL is unclear, even worse than the GPL. The best
	    thing that can be done is for the copyright holder to
	    resort to a personal interpretation of what it means.

   Response: This sounds like license FUD to me. I think the LGPL has
	     been well tested by successful use in many large
	     projects. And, as mentioned above, the results achieved
	     by such projects are part of the reason the LGPL is
	     appealing. Finally, the opinion of the copyright holder
	     on the interpretation of the license is actually a
	     relevant issue. After all, the copyright holder is the
	     only entity that can instigate legal action with regard
	     to violation of the license.

2) Potential problems with embedded devices

   Concern: The LGPL can cause difficulties with embedded devices, and
	    other cases where the user can't use a replacement library
	    even if they have the source.

   Response: I don't have a perfect answer for this. I do a lot of
             embedded development and I am encouraged by how
             reprogrammable almost anything can be. Of course, it
             would be my preference to purchase embedded devices for
             which LGPL compatibility was straightforward.

	     My feeling is that the "good citizens" who want to comply
	     with the license will be able to be clever enough to find
	     a way to do so. If there does arise a situation where
	     someone wants to comply with the license, but feels
	     unable to do so for some reason, the best advice I have
	     is to bring the issue forward to the authors. Paragraph
	     14 of the LGPL suggests precisely this and explicitly
	     states that even the FSF sometimes makes exceptions. That
	     seems a very reasonable stance to take.

3) Compatibility problems with mozilla.

   Concern: The mozilla project wants all of the code in its tree to
            be tri-licensed under the MPL, GPL, and LGPL. This means
            that the MIT license is compatible with this three-headed
            beast, but the LGPL alone is not, (bizarre, but true).

   Response: Mozilla is an important customer of cairo, especially
	     with the recent work to get mozilla/SVG working with
	     cairo. Mozilla is already using LGPL libraries such as
	     GTK+, so we should strive to let mozilla use cairo in the
	     same way. I think this means getting cairo stable and
	     into distributions so that mozilla does not find it
	     necessary to snapshot the cairo source code into its own
	     tree. Fortunately, the cairo API is stabilizing, and
	     packages are already in Debian/unstable. So, I'm
	     optimistic that this problem will be resolved without too
	     much difficulty.

More information about the cairo mailing list