[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.

Playing devils advocate

Date: 2014-01-21 08:38 am (UTC)
From: (Anonymous)
I am confused about the FSF contributor license agreement.

As far as I can see the FSF is required to release their code under a version the GPL, but the FSF is also the author of the GPL. Would it be possible for the FSF to change the GPL into a non-free license and start releasing the GNU-code as non-free code? How does this situation differ from Canonical?

Re: Playing devils advocate

Date: 2014-01-21 09:26 am (UTC)
From: [identity profile] http://openid-provider.appspot.com/paolo.bonzini
The FSF's copyright assignment mentions that all distribution of assigned work "shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work [...] to redistribute copies of the work to anyone on the same terms. These terms shall not restrict which members of the public copies may be distributed to. These terms shall not restrict a member of the public to pay any royalty to FSF or to anyone else for any permitted use of the work they apply to, or to communicate with FSF or its agents or assignees in any way either when redistribution is performed or on any other occasion".

This would not prevent the FSF from relicensing the code to a more permissive license (and it happened sometimes that GPL code was relicensed to LGPL, in fact; for example, GMP used to be under the GPL). But the GPL cannot be "cracked" by the FSF either; it says explicitly that "new versions will be similar in spirit to the present versions, but may differ in detail to address new problems or concerns".

Re: Playing devils advocate

Date: 2014-01-22 01:42 pm (UTC)
From: (Anonymous)
You clearly haven't read the full trext of FSF's copyright assginment. It was carefully written to bind them too. I've not seen as much effort put into a copyright assignment as that one to make sure that they would also be bound by it and could not wiggle out. Even if they could find a way, distributing proprietary software would be against their non-profit mission. As a 501(c)(3) they're legally obligated to operate in the public interest or risk their non-profit status. Even if they were willing to give up their non-profit status and still turned it into non-free software, I would encourage everyone with a copyright assignment on file to start a lawsuit over breach of contract. Remember that they made the promise (that people relied on) to keep the software free as a condition of people transferring their copyright to the FSF in the first place. In that event I'd be one of the first in line. So, in the FSF, there are multiple levels of defenses in place to make sure that they FSF remains a trustworthy copyright steward. This isn't usually the case when people point to the FSF's copyright assignment process as a justification for their own.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at CoreOS. Member of the Free Software Foundation board of directors. 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