[Cogl] Proposal for re-licensing to MIT license

[Robert Bragg]

On Mon, Dec 2, 2013 at 8:25 PM, Owen Taylor <otaylor at redhat.com> wrote:
> 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
>
>

Hi Owen,

Thanks for the reply.

With regards to Emscripten, sorry if I gave the impression that I
thought the LGPL licensing concerns were insurmountable. I don't want
to discredit Emscripten which I think is a really interesting
technology and I don't believe it's incompatible with the LGPL or
other copyleft licenses, but I do think it opens up some tricky
questions about how exactly someone would manage their compliance with
the LGPL in particular. The GPL as another copyleft license seems like
it would be comparatively straight forward. This may just be because
its new ground and there are currently no established and accepted
practices here.

On the face of it, it seems similar to the difficulty of distributing
binaries that are statically linked with LGPL code and so I assume you
would need to somehow also distribute the llvm bitcode for any
non-lgpl parts so that someone could recompile the lgpl code and re
"link" by generating new javascript code. I believe people already
routinely ship statically linked LGPL code on embedded devices and go
to the extent of providing these intermediate files for compliance so
it's not entirely unprecedented.

I have some concern that I don't really know for sure whether that's
enough as I'm not a lawyer but also that this seems disproportionately
complex. Ideally I'd like to aim for a situation where the number of
developers using Cogl or Rig outnumbers how many contribute directly
to them. Considering that all our development is done in the open
using public git repositories where access to the source code for
anyone interested doesn't seem like a problem, I not sure that causing
extra work for those developers only interesting in using Cogl or Rig
without modifying them is really going to do much in practice to
protect any freedom.

I'm starting to think that in some use cases, simpler more permissive
licenses can be a bigger boon to free software than using legalise to
force people to behave in a certain way, especially if the legalise
worries or confuses people and that ends up driving developers away. I
see the trade off though and using a permissive license does open up
the potential risk for abuse, but I suppose that risk currently seems
very minimal in comparison to the risk that people might actively
avoid the technology because they aren't sure of the licensing
implications.

I was really happy with the choice of LGPL for Cogl up until very
recently. I think my change of heart does largely stem from these
static linking like use cases I've been looking at that I feel will
impose too much on downstream developers relative to the freedom
actually being preserved.

In practice it seems there is no perfect license and we have to choose
from only a small set licenses that are well known and respected so
there's probably always going to be a compromise. I have some concerns
about the risk of not using a copyleft license and I hope that in
practice that doesn't get abused. For a while I was really tempted to
aim for the Apache 2 license for the patent clauses, but being
incompatible with the LGPL 2 could be a problem if we want to maintain
optional features in Cogl that use LGPL code. The MPL 2.0 is tempting
since it has a copyleft element, patent clause and the burden on
downstream developers would be much less than for the LGPL. I think I
would still prefer to go with the MIT license though because it is so
widely known for its simplicity, while relatively few people are
familiar with the MPL. In the case of Emscripten and the MPL I think
it would still require all developers to make provisions on their
website for informing users of where to find the source code. Since
I'm personally mostly just concerned about developers making changes
to Cogl or Rig contributing them back to the project I don't really
want to impose anything on developers who are just using Cogl or Rig
and more so don't want to impose anything on the users of whatever
sites those developers create.

In terms of free software in general I don't think I can really claim
this will make much difference since we're only talking about 2 small,
little known projects using the LGPL which already limits their impact
on other projects. Ultimately I hope that this will be a positive for
Cogl and Rig which continue to be free software and my hope is that
the benefit of simplifying the license to remove any restrictions on
people using our code will outweigh the risk that someone will hoard
changes to its code and may help encourage sharing code with other
free software projects.

Philosophically I'd like people to have all the freedoms you listed,
but maybe one difference is that I'm not sure its always necessary
these days to force peoples hand into preserving those freedoms.

kind regards,
Robert