![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Not all CLAs are equal
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.
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: google's CLA
(Anonymous) 2014-01-20 08:15 pm (UTC)(link)I have no idea which is more common among for-profit company-backed projects, but there are plenty of examples (Opscode, Puppet Labs, Cyanogen, MongoDB and basically all other for-profit AGPL projects, all the ones that show up in a web search for "Contributor License Agreement"), but like the many nonprofit CLA-using projects that show up online, many are using licenses at least as permissive as Apache, not GPL-style strong copyleft. That said, a fair bunch do use GPL/LGPL/AGPL: in addition to Mongo and Digia/Qt, other prominent ones include SugarCRM, JBoss, Funambol, and of course the Oracle-inherited OpenJDK and MySQL.
I agree it's less common for companies these days to try the strong copyleft and CLA model, but it's also less common for them to use strong copyleft in general.
Re: google's CLA
(Anonymous) 2014-01-21 02:47 am (UTC)(link)One of the reasons I had urged a shift to Apache-style CLAs for JBoss projects was that we were at the beginning of a general license migration of JBoss projects away from the LGPL, towards the Apache License, and the old JBoss agreement was obviously unsuitable, while dispensing with a CLA altogether was considered (at least I assumed at the time) a bit drastic despite the fact that most of the jillions of projects launched by Red Hat developers in scope of employment did not use CLAs and that this was quite clearly the preference of the developers of those projects.
The trend away from LGPL licensing is still going on in JBoss and may take another decade or three but once projects switch away from LGPL I don't see any particular legal benefit to using a CLA. There is some legal benefit to using the Apache-style CLA for present-day LGPL JBoss projects because it eases the relicensing task. But this is a highly unusual case for Red Hat, where it's kind of clear that LGPL is an increasingly dated license for the sort of ecosystem those developers are living in. I went into this issue a bit when I was interviewed for the JBoss Asylum podcast a few months ago.
At Red Hat, the strong copyleft + Apache-style CLA model was basically unheard of, though, the closest thing being Fedora's pre-2010 CLA. Not counting Cygwin (which uses copyright assignment), the model of which was inherited from Cygnus and continued unchanged. Cygwin's continuation of its historical approach incidentally reflects the strong wish of the project leads.
- Richard Fontana