[cairo] Cairo license change follow-up

[Carl Worth]

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
ramifications.

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
	  mechanism.

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
       embedded systems).

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
       embedded systems).

Response: That's true, (and is even specifically stated in the LGPL, "It
	  may happen that this requirement contradicts the license
	  restrictions...").

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
	  possible.

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

	  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
	  talk.

Respectfully,

-Carl