[Cogl] Proposal for re-licensing to MIT license

[Owen Taylor]

On Mon, 2013-12-02 at 18:06 +0000, Robert Bragg wrote:
> 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.

Hi Robert -

First, I and Red Hat as a company don't have sufficient authorship in
Cogl to justify opposing relicensing of Cogl as the primary authors see
fit, so you can count this as being permission to relicense the portions
of Cogl copyright by Red Hat to the MIT license.

That being said, speaking for myself personally, am troubled by the
Emscripten argument you make above. If Emscripten as a technology is
entirely incompatible with copyleft-style licenses, then we should be
trying to discourage authors from using Emscripten, not encourage it by
relicensing our code to a weak license.

If someone takes my library code, possibly modifies it, combines it with
proprietary code, and then ships an impenetrable binary blob to the
user, the user might as well not be using free software at all.

I don't have an exact idea how the full sense of the LGPL would work
with server-side deployed applications - giving the user the ability to
replace bundled libraries with improved versions would seldom be
practically useful - but the freedoms to inspect the source code
including modifications, understand how it works, and reuse the code or
their own purposes should be preserved at a minimum.

What do you see as benefits to free software from this move? Have you
considered somewhat less weak licenses like the MPL?

- Owen