[cairo] Cairo license change follow-up
cworth at east.isi.edu
Fri Aug 13 11:45:55 PDT 2004
I just got back from a week's vacation, so I missed the majority of the
license change thread I started just before I left.
I've read through everything now (phew!), and I won't bother going back
to respond to each individual message, but I did want to collect some of
my opinions here.
Primarily, I want to thank everybody. There are a fair number of
subscribers on this list, so I think we've received a lot of silent
support for the change, (or most of you are bored and are redirecting
cairo mail to the same place as all your SPAM). I'm also grateful for
everyone that provided feedback, particularly those that pointed out
potential problems with the license. It's very good to go into something
like this with as clear an understanding as possible about the possible
Cairo is licensed under the LGPL now. The license can be changed in the
future, but a change will always require the unanimous consent of all
copyright holders. This process is intentionally "hard", (but not
impossible as demonstrated by this recent change). I expect the
difficulty of change to grow as the number of contributors increases
from the current number of about 30.
For people that are already using or considering cairo, and for whom the
license change is an actual problem, please keep talking to me to try to
see if there's a way we can find to let you continue to use cairo after
the license change.
I can't speak for all contributors to cairo, but I will give some of my
opinions below, (which are relevant insofar as I am one of the
contributors that will need to be convinced to make any change). I've
tried to phrase these opinions as responses to issues that have been
raised on the list. And I've tried to be thorough, so I apologize in
advance for the length.
Issue: It's harder to comply with the LGPL than with the MIT license.
Response: Yes, and this is largely intentional. Distributing free
software using cairo/LGPL should not be any harder than
distributing the same software with cairo/MIT. Distributing
proprietary software using cairo/LGPL does require more than
using cairo/MIT, but inasmuch as this results in the
publication of more modifications to cairo, it is an important
reason the change was made.
Issue: The LGPL is too vague to be useful.
Response: This complaint is too vague for me to respond to.
Issue: The LGPL is too vague --- it is based on fuzzy distinctions
between static and dynamic linking.
Response: The LGPL is actually quite carefully not based on any
distinction here, referring in almost all cases to "linking"
with no distinction at all between static and dynamic
linking. In fact, the only time the letters "static" appear in
the license is in the Preamble where it describes a legal
consequence of linking a program with the library "whether
statically or using a shared library".
Within the terms and conditions, there is a single occurrence
of "shared library" in paragraph 6.b. This term does rely on a
distinction of a "shared library mechanism", but also provides
a careful definition with two conditions that a shared library
mechanism must meet to qualify as "suitable". If these
conditions are not met, the license does not fall apart, and
the exception granted in section 6 is still available via any
one of the 4 remaining lettered terms in section 6. Note that
this version of 6.b first appeared in LGPL 2.1 which is the
reason I specifically chose this version over 2.0. Section 6.b
does make things significantly easier for distributors that
are comfortable that they are using a suitable shared library
Issue: The LGPL doesn't work for embedded systems.
Response: This argument is specious, or at the very least it is too
imprecise to be of much value. There is a large variety in the
capabilities of embedded systems. I've personally used cairo
on an embedded Linux system (with dynamic linking) since
roughly the beginning of cairo. Within this system, it's
trivially easy to fulfill the requirements of the LGPL, (using
section 6.b). So there's a counter example to this claim.
A better argument would point out the specific characteristic
of the embedded system that causes difficulty, (such as static
linking or what have you). These issues are discussed below.
Issue: The LGPL doesn't allow static linking, (which is required by some
Response: False. As discussed above, section 6.b is the only term in the
LGPL specific to using shared libraries. And this term is optional.
Issue: The LGPL doesn't allow static linking with proprietary software,
(again, required by some embedded systems).
Response: False. Section 6 is the exception that allow a combined work
to be released "under terms of your choice". With static
linking, 6.b is not available, but only one of 6.a - 6.e needs
to be satisfied.
Issue: The LGPL doesn't allow static linking with proprietary software
for which I don't have the license necessary to release object
code suitable for linking, (again, this may be required for some
Response: That's true, (and is even specifically stated in the LGPL, "It
may happen that this requirement contradicts the license
Issue: The LGPL is impossible to satisfy with an embedded system that
uses a ROM, (or has some other technical measure preventing
modification of the code within a device).
Response: My opinion is that the LGPL doesn't say anything about
technical measures that might prevent the user from modifying
the device. After all, I've never heard anyone complain about
the GPL because users might receive GPL software on a
read-only CD-ROM. The LGPL does say that the distribution
terms must "permit modification for the customer's own use and
reverse engineering for debugging such modifications" and I
see that as a good thing.
So, this might be regarded as a technical loophole in the
freedoms that the LGPL is trying to guarantee. But I don't see
it as preventing someone who wants to "play fair" from doing
so, which is what I am more concerned about.
Issue: Here's an exception to add to the license that fixes all the
problems with the LGPL. What do you think?
Response: I honestly appreciate the thought, the intent, and the
effort. But one thing I do not want to compromise on is the
desire to use a well-used, well-accepted, and well-tested
license. In addition to matching my goals, the ideal license
will be considered a Free Software license by the FSF,
approved by the OSI, or considered by Debian to adhere to the
Debian Free Software Guidelines---and preferably all
three. After that, the license should be as simple as
The concept here is that I want to reduce unintended
consequences from new language, and I want to reduce the
barriers needed for users to evaluate and approve cairo's
For now, the best license I can find for those criteria is the
LGPL 2.1. If, in the future, a new license becomes well-
accepted that better meets my goals, I will gladly look at it
then. So, keep up the effort, just talk to someone like OSI or
the FSF first.
Maybe a statement of intent next to the license would help?
But, with no legal significance, maybe not.
Issue: I want to statically link with incompatibly licensed code... [OR]
I just don't trust the LGPL... [OR]
The LGPL scares my lawyer/cousin/astrologist... [OR]
I sick of this license discussion...
...so I am not going to use any LGPL-licensed version of cairo.
Response: I'm sorry to hear that. But this is your choice, (it's all
about freedom remember?). I do hope my comments above helped
clarify things, and if there's something I can do to help you
be able to continue to use cairo, please let's continue to
More information about the cairo