[personal profile] mjg59
Contributor License Agreements ("CLAs") are a mechanism for an upstream software developer to insist that contributors grant the upstream developer some additional set of rights. These range in extent - some CLAs require that the contributor reassign their copyright over the contribution to the upstream developer, some merely provide the upstream developer with a grant of rights that aren't explicit in the software license (such as an explicit patent grant for a contribution licensed under a BSD-style license).

CLAs aren't new. FSF-copyrighted projects have been using copyright assignment since at least 1985 - in return, the FSF promise that the software will always be distributed under a copyleft-style license. For over a decade, Apache Software Foundation projects have required that contributors sign a CLA that allows them to retain copyright, but grants the ASF the right to relicense the work as it wishes. For the most part, this hasn't been terribly controversial.

So why do people object so much when Canonical do it? I've written about this in the context of Mir before, but it's worth expanding on the general case. The FSF's copyright assignment ensures that contributions to GPLed software will only be distributed under GPL-style licenses. The Apache CLA permits the ASF to relicense a contribution under a proprietary license, but the Apache license allows anyone to do that anyway. Going through Wikipedia's list of CLA users, the majority cover projects that are under BSD- or Apache-style licenses, with a couple of cases covering GPLed projects with a promise that any contributions will only be distributed under GPL-like licenses[1]. Either everyone can produce proprietary derivative works, or nobody can.

In contrast, Canonical ship software under the GPLv3 family of licenses (GPL, AGPL and LGPL) but require that contributors sign an agreement that permits Canonical to relicense their contributions under a proprietary license. This is a fundamentally different situation to almost all widely accepted CLAs, and it's disingenuous for Canonical to defend their CLA by pointing out the broad community uptake of, for instance, the Apache CLA.

Canonical could easily replace their CLA with one that removed this asymmetry - Project Harmony, the basis of Canonical's CLA, permits you to specify an "inbound equals outbound" agreement that prevents upstream from relicensing under a proprietary license[2]. Canonical's deliberate choice not to do so just strengthens the argument that the CLA is primarily about wanting to produce proprietary versions of software rather than wanting to strengthen their case in any copyright or patent disputes. It's unsurprising that people feel disinclined to contribute to projects under those circumstances, and it's difficult to understand why Canonical simultaneously insist on this hostile behaviour and bemoan the lack of community contribution to Canonical projects.

[1] The one major exception is the Digia/Qt project CLA, which covers an LGPLed work but makes it entirely clear that Digia will ship your contributions under proprietary licenses as well. At least they're honest.

[2] See the various options in section 2.1(d) here. Canonical chose option five. If they'd chosen option one instead, this wouldn't be a problem.

Re: Qt

Date: 2014-01-21 01:39 am (UTC)
From: (Anonymous)
Da fuq? Ximian Desktop != Gnome Desktop. Ximian was a gnome enhancement and gave birth to mono and evolution, which was then acquired by Novell...who then later switched their default desktops to KDE. Go figure. ;)

Redhat is a heavy contributor to Gnome. Then again, Redhat is a heavy contributor to many things.

To make this relevant to the discussion, Fedora has no CLA like Ubuntu so if you feel like making patches to a more free OS, try there.

Re: Qt

Date: 2014-01-21 05:30 pm (UTC)
From: (Anonymous)
> Da fuq? Ximian Desktop != Gnome Desktop. Ximian was a gnome enhancement and gave birth to mono and evolution, which was then acquired by Novell...who then later switched their default desktops to KDE. Go figure. ;)

that is a radical reinterpretation of the history of Ximian.

Ximian — nee Helix Code, nee International GNOME Support — was a company that worked on supporting GNOME and providing an integrated GNOME desktop for corporate users. it got acquired by Novell, and kept working on corporate UX, especially when it came to Evolution and OpenOffice and integration of Linux/GNOME in a Windows network. as a side project, the Novell-Ximian team worked on Mono, a reimplementation of the C# runtime and core libraries.

after the Novell buy-out, the team got spun off into its own company, Xamarin.

the Wikipedia page on Xamarin is okay-ish, in terms of references.

Novell, in the meantime, acquired SUSE, which was making a distribution that supported KDE and GNOME. to be fair, SUSE is actually supporting GNOME really well as a first class citizen, so they didn't "switch".


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags