[Cogl] Proposal for re-licensing to MIT license

[Robert Bragg]

On Tue, Dec 3, 2013 at 3:59 PM, Robert Bragg <robert at sixbynine.org> wrote:
> 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

Hi all,

I wanted to follow up a bit more on Owen's suggestion of considering
the MPL to explain further why it doesn't look like it would work well
for Cogl and Rig...

If I could create my ideal license for Cogl and Rig I think it would
look something like the MPL 2.0 license. I'd take the MPL 2.0 but
somehow limit (for practical reasons, I'll cover below) the
requirement within section 3.2. a) that "You must inform recipients of
the Executable Form how they can obtain a copy of such Source Code
Form by reasonable means in a timely manner" to only apply when that
source code has been modified.

That requirement looks like it could be quite impractical to comply
with for use cases I'm hoping we can support with Rig. I think it
likely that it would discourage designers and artists from using Rig
as it would have such a direct impact on everything created. In the
cases where Cogl and Rig haven't been modified, anyone can easily use
Google to find the code, so the requirement wouldn't appear to protect
much.

Rig is a UI technology that includes an interactive editor that builds
on a rendering engine which utilizes Cogl. We are looking to support
native UI development on platforms like Android, but I have also been
looking at supporting web UI development via Emscripten and WebGL.
Just as reference points, it could be compared in some ways with
technologies like Adobe Edge, Google Web Designer or the Unity3D game
engine.

I'm concerned about how our choice of license will impact designers
and artists using Rig to, for example, create part of a website. As
noted above the MPL license requires that these UI components would
need to "inform recipients of the Executable Form how they can obtain
a copy of such Source Code Form by reasonable means in a timely
manner". In this use case the UI might not represent a full website
(where you might be able to incorporate a "licence information" page
somewhere) but rather a re-usable element that may be used in one or
more places across multiple sites. Each artist and designer would have
to come up with some unobtrusive way of incorporating a suitable
notice for this requirement.

I think it's fair to assume that many of the designers that might be
interested in using a tool like Rig won't have heard of the MPL and
aren't considering contributing code to Cogl or Rig. This requirement
doesn't seem to strike the right balance between protecting the code
and keeping the tool usable in these cases.

The requirement is going to affect every user of the Rig design tool
and in all the cases where they aren't modifying Rig or Cogl (expected
to be the majority) then it's for little benefit because our code is
already easy to find.

The final reality it looks like I'm faced with here is that deriving a
custom license from the MPL 2.0 isn't a real option and the only other
well-known license that seems to fall between this and the MIT license
is the Apache 2.0 license which isn't copyleft and is incompatible
with the LGPL 2 which wouldn't allow us to maintain optional build
time features that use LGPL 2 code.

I hope this better explains why I don't feel that the MPL is the best
licensing option for Cogl.

Kind regards,
Robert