mjg59 | Not all CLAs are equal

Entry tags:

advogato,
fedora

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.

Flat | Top-Level Comments Only

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.

switch what to Qt?

He probably means the Gnome desktop. I'm not sure that Gnome is basically a 100% Red Hat project. I think not.

> He probably means the Gnome desktop.

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.

>> He probably means the Gnome desktop.

> 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?

*whooooosh*

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.

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

> Obviously you have not read the source code of any GNOME application.

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.

Qt has CLA but it doesn't put the code under the danger of being closed because of the KDE agreement with Trolltech.
Digia can change the license but the code at the moment of the change can be released by KDE under BSD.
http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php

Exactly that. This agreement does in fact force Digia to keep on to develop and release under LGPLv2. Once that stops its all BSD. Win-win.

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

It's certainly not an invention of Canonical (the Qt case predates Canonical even existing), but no, it's not common.

(Same poster as the "Google CLA is similar to the Apache CLA and Chromium uses the BSD license" reply below. Still not speaking for Google or giving legal advice; still not a lawyer.)

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.

JBoss is actually an odd case. The startup used a sort of no-op CLA in which the contributor gives JBoss permission to use the software under the LGPL or GPL -- this was when all JBoss-initiated software was licensed under LGPL or GPL. This contributor agreement is still in use for at least a plurality of the universe of present-day JBoss projects, at least in theory, initially for accidental reasons. In 2009 I recommended replacing this with use of Apache-style CLAs but by 2010 I publicly noted (I think this was in a LinuxCon talk) that this was just a 'stopgap measure'. For unintended reasons only certain JBoss projects actually switched to the Apache-style CLA. Once I realized that both contributor agreements were in simultaneous use (depending on choice of project lead), by that point I had come to realize the problems associated with Apache-style CLAs, mainly from experience with Fedora (plus I was deeply influenced by Michael Meeks' essay from around that time on copyright assignment). So I saw some benefit to continued experimentation with the two types of contributor agreements.

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

The Google-authored parts of Chromium are under a BSD license, which is even more permissive of proprietary derivatives than the Apache license Matthew discussed. Also, if you compare Google's CLA to Apache's, you might be be pleasantly surprised.

The short version: contributing under the Google CLA to a BSD-licensed or Apache-licensed Google project is much more like the Apache Software Foundation case than the Canonical case, despite Google being for-profit.

Full disclosure: I work for Google, but I'm not speaking for my employer and this is not legal advice, nor am I a lawyer. Google's license choices and Apache-style CLA text are not just my opinion as a Googler; feel free to look yourself and come to your own conclusions.

"We're only as bad at this stuff as Google" is not exactly what you want as a rallying cry. ;)

Google's terrible at F/OSS, at least when they're running a project. Android is a code-over-the-wall project; no-one else gets to contribute, their bug tracker is a wasteland, and they're engaged in closing as much of it as they feasibly can at present. Chromium is an awful, awful F/OSS project, whatever its merits as browser. Just ask Tom Callaway.

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.

Like Lennart did? SCNR.

Like Go-oo did.

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.

I don't think there was any discussion by Canonical of the choice. It occurred shortly after the Harmony agreements were released. The interesting thing about the choice is that Canonical chose not to pick a copyright assignment Harmony variety, which would have been the closest thing to its earlier contributor agreement. I suspect this is because Canonical realized that there was some nontrivial subset of critics of its copyright assignment agreement who might find a comparable CLA more palatable, and also that such a CLA gave Canonical just about everything it thought it was getting out of the copyright assignment agreement. But this admittedly is speculation.

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.

You got it wrong.
KDE receives(well, it always has it in the archives) the code and has the right to release it under BSD. The foundation doesn't have to "buy" anything.
This agreement is kept even in a buy-out, like the acquisition by Digia from Nokia.

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

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?

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

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.

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.

Flat | Top-Level Comments Only

Not all CLAs are equal

Qt

Re: Qt

Re: Qt

Re: Qt

Re: Qt

Re: Qt

Re: Qt

Re: Qt

Re: Qt

Re: Qt

Re: Qt

google's CLA

Re: google's CLA

Re: google's CLA

Re: google's CLA

Re: google's CLA

Re: google's CLA

Existing proprietary licensees at Qt

solution

Re: solution

Re: solution

Gossip

no subject

no subject

Qt CLA

Re: Qt CLA

no subject

no subject

FSF & Apache vs Cannonical

Playing devils advocate

Re: Playing devils advocate

Re: Playing devils advocate

Free-Qt fundation

Much ado about nothing