[cairo] License for cairo changed to LGPL
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 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 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
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.
 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.
 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
More information about the cairo