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

Threaded | Flat

From: (Anonymous)

I'm wondering, whether Qt's CLA was the main reason for Red Hat to not switch from Gtk to Qt, even when it became available under LGPL in 2009.

It's quite comparable to Google's CLA for Chromium, though, right? Isn't this common for open-source product that are mainly developed by and for a company? Not that I am fond of this practice, but I'd say it's not exactly an invention of Canonical.

https://developers.google.com/open-source/cla/individual

From:

dmarti.myopenid.com

Qt was originally a proprietary product, and it has long-term proprietary licensees who signed up in the expectation that they would get the code with no copyleft.

The choice when they took it open source would have been (1) cut off the existing proprietary licensees from new versions by using copyleft for everyone, (2) go with a non-copyleft license and lose at least some of the license revenue (probably most of it) or (3) require outside contributions to use a CLA that allows their work to go proprietary.

So Qt probably did the best it could considering the existing customer base, even if that meant losing some potential contributors. The situation was different from a green field project with no licensees.

The best way to fight a CLA that you don't agree with is to right some really good patches and refuse to sign the CLA. Either you end up with a superior fork of the original project which other outside developers join. Or the original project realises how it could benefit from dropping the CLA and using your patches.

A friend who works for Canonical claims the reasoning is to give Canonical a higher valuation. Being able to take many things proprietary means more to a potential acquirer. Someone investing would get less of the company the higher the valuation it has.

You write "deliberate choice"; do you have a link where Mark/Canonical list the options and explicitly reject the inbound/outbound option?

To be clear I'm not suggesting it is not deliberate and not suggesting it's accidental!

I would just like to read their reasoning if it exists.

I presume they do it for commercial reasons (company worth) as someone else suggested.

You bring up a good point with the Qt CLA specifying that contributions will go toward the commercial edition, but there's one very big caveat to that: The KDE-Free Qt Foundation.

The agreement between the old Trolltech and KDE e.V. is still active today, and specifies in essence that if Digia stops developing and releasing the Free edition of Qt, that the Foundation can buy out the Qt code and release it under the open-source license they prefer.

It helps to think of the overall package as being one of a quasi-BSD license: Your contributions support proprietary and Free software development, with an added escape clause to ensure the Free part can be forked if needed.

vaurora

Nmap is another project that requires contributors to give them the right to relicense the code under a proprietary license:

https://svn.nmap.org/nmap/COPYING

reddragdiva

I note this Simon Phipps post on OOo contributor agreements, in direct response to Mark Shuttleworth.

The reason I object to the Cannonical CLA and not the ones from the FSF and Apache foundation is because Cannonical is a for-profit corporation. I'm not going to contribute code to a company that's going to make money off it without sharing the source. If my code is going to be sold as part of a closed source product, I expect to be paid.

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?

Additionally Qt has an agreement with KDE that ensures that Qt will stay open at least on a number of platforms
http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php

There is a very simple way to disagree with Canonical's CLA: don't contribute.

Why it is worthwhile to write essays and talk endlessly on this 1985-era subject? Because too many people feel better if they can disagree with someone bigger than they are (in this case, Mark Shuttleworth) than they feel for actually getting down to some actual work.

If you do not like CLAs, don't sign them. Nobody is forcing you to contribute to Mir. Now go do something productive.

Not all CLAs are equal

About Matthew

Page Summary

Expand Cut Tags