Not all CLAs are equal
Jan. 20th, 2014 10:45 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Contributor 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: Qt
Date: 2014-01-20 09:29 pm (UTC)Re: Qt
Date: 2014-01-20 09:33 pm (UTC)yes, because GNOME can be "switched" to Qt, and Red Hat can do that.
> I'm not sure that Gnome is basically a 100% Red Hat project. I think not.
yeah, don't think so too. otherwise I might have missed a memo.
Re: Qt
Date: 2014-01-20 10:12 pm (UTC)> yes, because GNOME can be "switched" to Qt, and Red Hat can do that.
Obviously you have not read the source code of any GNOME application.
>> I'm not sure that Gnome is basically a 100% Red Hat project. I think not.
> yeah, don't think so too. otherwise I might have missed a memo.
Were are you two be living the last 15 years? Under a rock? GNOME is *not* a Red Hat project. It was started by Miguel de Icaza as the business of his startup Ximian. When that business went bust, the whole package was given to the care of the GNOME Foundation.
Has Red Hat invested a large sum of money and human resources into it in the last ten years? Yes. But they do not own the project. Did I mention the GNOME Foundation?
I'm interested in psychedelics research, care to recommend your preferences?
Re: Qt
Date: 2014-01-20 11:33 pm (UTC)Re: Qt
Date: 2014-01-21 01:39 am (UTC)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)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".
Re: Qt
Date: 2014-01-21 05:24 pm (UTC)I know this is a case of "on the internet nobody knows you're a dog", but you should not make this kind of assumptions. I am a GNOME maintainer, and I work on the core GNOME platform — and have been doing so for the past 10+ years, without ever being employed by Red Hat. I'm also on the Board of directors of the GNOME Foundation, so I actually know the history of the project I've been contributing to.
not that I should justify myself to ${RANDOM_ANONYMOUS} on Matthew's blog, but still it's probably better to write it down.
> Were are you two be living the last 15 years? Under a rock? GNOME is *not* a Red Hat project.
that was my point, admittedly made within tags.
ciao,
Emmanuele.