[cairo] Re: License for cairo changed to LGPL

[Carl Worth]

[M., Please pardon me for adjusting the text I've quoted from your
message to use more columns and fewer lines.]

On Tue, 03 Aug 2004 18:54:20 -0700, "M. Evans" wrote:
> Not even the GPL itself prevents forking. I do not see how an open
> source license prevents forking.  GNOME recently forked.

Nope. It can't prevent all forking. Nor would I even want a license that
does that. The freedom to fork is important. I want a license that
prevents changes from being locked away.

> Anyway, I am also an embedded developer.

I am as well. And I can imagine a lot of useful ways that cairo could be
used in embedded systems.

> I do see a big problem with LGPL in this domain.  Generally source
> code release is not something a developer decides.  That big-think
> percolates right up the management chain, and if management says "no,"
> that pretty much kills the choice off.  It doesn't matter if the
> engineer is willing and able to be very, very clever about releasing
> his source code.  It's just not his call. That has been my experience.

I don't see any distinction in the above that is specific to embedded
systems, but I'll comment anyway.

That a management chain might be reluctant to release source code is the
very reason I prefer licenses such as the GPL and LGPL over the MIT
license. If there is a compelling reason for the developer involved to
use cairo, then with the LGPL there is real pressure for management to
decide to release necessary modifications to cairo rather than violating
the license, or rewriting the program to not need cairo, (or to not need
the modifications).

> Now of course some changes are always required to get any code
> functional on embedded systems, because each one is so unique.

Sure, and those changes should be released to the cairo community. The
remainder of the source code in the embedded system need not be
released, (as it can be a "work that uses the Library" and released
under terms of the licensee's choice according to section 6 of the
LGPL). If the developers can't abide by this, then they don't get to use
cairo.

> I do not think it is FUD to raise these issues.  They are quite valid.

I said "FUD" because I heard people making vague suggestions about
problems the LGPL might cause, without specific examples. You have
actually supplied something specific, by showing 3 solutions below to
problems perceived by others. I wasn't aware of those, and I appreciate
you bringing them up.

> In fact three GUI toolkits use LGPL with special binary linkage
> exception clauses. R. Stallman has reviewed and OK'd the wxWindows
> version.  These licenses were developed after lots of debate, hashing,
> etc., over years.  Here are the links. Read and enjoy.  Cairo might
> consider something close.

Thanks for sharing these. Here are my initial impressions to each.

> http://www.wxwindows.org/newlicen.htm

This one seems to take all the teeth out of the LGPL. At least to me, it
seems to say that anyone can distribute a modified version of the
library in binary-only form. That would allow changes to get locked
away, which is what I don't want. Now, if the exception had said, "works
that use the library" rather than "works based on the library" it would
be much more acceptable.

> http://www.fltk.org/faq.php?3
> http://www.fox-toolkit.org/license.html

Both of these are more careful in the exception than the wxWindows
license, limiting it to static linking with an unmodified version of the
library.

The Fox license addendum has an unfortunate clause in which it
prescribes an exact phrase that must be used to identify the use of the
library. This is problematic for translations.

Otherwise, I prefer the language of the Fox addendum over the FLTK
language, (it's more careful and tighter).

Both also provide an explicit allowance for subclassing, (which
obviously isn't necessary for a C library like cairo).

OK. So the concern addressed by these modifications to the LGPL is to
make explicit an allowance for static linking of proprietary software
with an unmodified library. I would probably be willing to accept an
addendum to allow this explicitly, but here are the barriers I see:

	1) It would have to be written carefully, and should be reviewed
           by an attorney with experience in such matters.
           Unfortunately, none of the example exceptions above are
           acceptable to me without changes.

	2) Besides my approval, we would also need to get the approval
           of all 30 or so people that have contributed to cairo
           already. I received approval from all of them for the LGPL,
           but not for the LGPL with any exceptions.

	3) I'm not convinced it's actually necessary or beneficial. It
	   seems to me that the LGPL already makes sufficient provision
	   for static linking. It simply requires the distributor to
	   provide (or make a written offer to provide) object code so
	   that the user can relink with a modified version of the
	   library, (see 6.a).

	   Can someone show me an actual case where that burden is so
	   onerous as to outweigh any advantage that might come from
	   using cairo?

	   The rationale after the Fox addendum says that they regard
	   static linking as " functionally equivalent to dynamic
	   linking". However, the LGPL actually guarantees that the user
	   gets functionally equivalent freedoms in either case. This
	   seems a definite feature to me.

-Carl