[Cogl] Proposal for re-licensing to MIT license

[Robert Bragg]

Hi all,

I wanted to let everyone know that I've been thinking a lot recently
(and discussing with Neil Roberts who co-maintains Cogl with me) about
trying to re-license Cogl to use a simpler and more permissive MIT
license. I'm also looking at doing the same for the Rig project I'm
working on that uses Cogl which I mention here because it doesn't have
its own development mailinglist currently and I expect some of the
same copyright owners to be involved.

Currently most of Cogl and Rig are licensed under the LGPLv2.1+ with
just a few files under more permissive licenses like MIT.

Given what will be involved in re-licensing these projects I think
it's only right to try and explain why we think it's worth the effort
and what the concerns with the current license are:

Firstly; I've recently been investigating using Cogl with Emscripten
to enable WebGL accelerated development of client-side web
applications. In the spirit of the LGPL I'd like to allow developers
to write applications based on this with the freedom to chose any
license for the applications themselves. Please note at this point, I
am definitely not a lawyer but it seems pretty tricky to me to imagine
how people will manage their compliance with the license in this use
case. Emscripten essentially translates llvm bitcode into a monolithic
piece of javascript that can be downloaded and run in a standard
browser. To comply with the LGPL, web applications using this would
presumably somehow need to advertise within the application itself
some way to access the intermediate bitcode before it was compiled
into javascript to enable people to rebuild the LGPL bits. Presumably
it would then need to be possible to run that re-generated javascript
in a browser in the context of any webservice it was originally
created for. That seems like quite a complex requirement to me.

We also want to use Cogl with Rig which is a UI technology that will
support building and bundling complete applications for deployment on
operating systems like Android. We ideally want to be able to
statically link the Rig rendering engine with the user's compiled UI
logic as well as statically link with Cogl. Rig is aimed at
application designers and developers that are likely to have little to
no understanding of the LGPL. Personally for me at least, one of the
reasons I like the LGPL is that it gives people downstream freedom to
use whatever licenses they like for their applications. The emphasis
is on ensuring that if developers modify the library itself then they
should make those changes open for others. In this use case where the
designers and application developers may have never heard of the LGPL
I have no particular interest in forcing them all to learn and care
since they are also unlikely to care about changing Cogl or Rig. In
this case though the LGPL requirements to ensure downstream recipients
of binaries can re-link those binaries after recompiling the LGPL
parts means all these application developers will have to learn how to
properly comply with the LGPL. IMHO this is making the situation
overly complex for downstream developers not involved in Cogl
development and I can't personally see many people ever benefiting
from that particular guarantee.

Finally I see some potential for better code sharing with projects
like Wayland and Weston that have some overlap with Cogl (such as with
matrix handling) but have chosen to limit themselves to permissive
licenses like the MIT license. Perhaps in the future they might be
interested in borrowing bits from Cogl's quaternion api or matrix
stack code which would be possible if we had the same license.

Hopefully that explains a bit about where my concerns are coming from.
Although I conceptually like the reciprocal spirit of the LGPL that
ensures those that would make changes to Cogl should keep those
changes open, I also see it as being rather complex for downstreams to
manage their compliance and see people turning away from LGPL
technology (especially in embedded development use cases) because they
are worried or confused by their obligations.

Switching to the MIT license means we can no longer force Cogl changes
to be kept open, but I think we gain simplicity and legal clarity for
some awkward use cases that actually matter to us. Personally I think
that these days a lot more people understand the real value you can
get from collaborating on open source software that I'm less concerned
about the possibility of developers taking and not giving back. I'm
also inclined to think we're more likely to get valuable contributions
anyway from developers that are genuinely interested in giving
something back than from developers only reluctantly giving back
because they are forced to. A bigger concern for me is that people
simply avoid using my code at all because they're put off by a complex
license.

My plan now is to start auditing Cogl's git history to determine the
current copyright holders for the code base so that we can start
asking for permission to re-license it.

So far it looks Neil Roberts, myself and others working at
Intel/OpenedHand wrote the large majority of the Cogl and Rig code,
but we do also have some notable contributions from Red Hat and
Collabora such as Owen's recent CoglOutput changes and Daniel Stone's
fence api. Originally Havoc also wrote our matrix stack code though
that did recently get re-written and I'm not sure a.t.m whether any of
the original code remains.

In Rig we used a copy of clutter-text.c which was mostly written by
Øyvind Kolås and Emmanuele Bassi while at OpenedHand or Intel but
there were also a number of other smaller contributions made by
various people which we'll need to unravel. Another awkward one in Rig
is that we took a copy of gtk_distribute_natural_allocation which was
written by Tristan Van Berkom at Openismus and so I'm hoping we can
get an ok to re-license that, otherwise we'll need to rewrite it.

An area where we have lots of small contributions is for translations
of our error messages where the copyright status seems a bit confusing
to me. A lot of them have notices like "Copyright (C) 2011 THE
PACKAGE'S COPYRIGHT HOLDER" and even more strangely a lot of them
claim that the Free Software Foundation owns the copyright. I can try
and get an ack from as many contributors of translations as possible,
but where that's not possible it's likely that we'll drop some of
them.

I think the next step is for me to start contacting copyright holders
individually and hopefully use this thread to track our progress.

kind regards,
Robert