Contributor License Agreement landscape

Contributor License Agreement landscape

In which I survey the landscape of Contributor License Agreement practices.


This post is supporting background for some conversation and formation of opinions. This post isn't those conversations or opinions.

See also

What is a Contributor License Agreement?

What is a CLA anyway?

A Contributor License Agreement is a legal agreement whereby an open source Contributor licenses their Contributions to others.

All open source licenses provide that the open source Work is licensed, by its contributors, to its consumers, under such-and-such terms, terms that never require paying money, and that always allow redistributing the Work to others under the same terms.

A Contributor License Agreement is an additional asymmetric license agreement whereby contributors make additional assurances not necessarily made to them by the open source license under which they consume the Work.

A continuum of practices

Practice in the field seems to be all over the place. Ranging from lightest to heaviest processes:


Zurb Foundation is a popular front-end responsive web framework. Its contributing documentation is entirely silent as to licensing.

Offering code implies general agreement

Bootstrap is another popular front-end responsive web framework. Its contributing documentation simply states that by contributing you in general license your contribution.

By contributing your code, you agree to license your contribution ...

Offering code implies specific agreement

Ghost is no-hassle

Ghost is a blogging platform. (The platform used by this blog, in fact).

Its contributing documentation states that by contributing you specifically agree to a very broad Contributor License Agreement.

By contributing your code to Ghost you grant the Ghost Foundation a ... license ... to ... distribute and publicly perform and display the Contributions on any licensing terms, including without limitation: (a) open source licenses like the MIT license; and (b) binary, proprietary, or commercial licenses.

GitLab is no-hassle

GitLab is an alternative to GitHub. (GitLab is the platform used for the private ideation and drafting behind this blog, in fact.)

Its contributing documentation states that by contributing you specifically agree to the relevant contributor license agreement.

Liferay is no-hassle (at least insofar as ICLA hoop-jumping)

While everything else about Liferay may seem a hassle, giving them your copyrights is pretty easy.

Note that Liferay is not really open source in the sense that only its proprietary "Enterprise edition" is plausibly appropriate for adoption.

Liferay's contributor agreement doesn't just grant license, it doesn't just jointly grant ownership -- no, it cedes ownership entirely, with Liferay owning the contribution and licensing it back to the contributor. (And then licensing it back to you at a proprietary software license cost and with your rights restricted in their "enterprise" products, of course.)

But at least it's no hassle.

The effective date of this Agreement shall be the date Contributor clicks "Accept" in the Liferay Issue Tracker

Node.js is no-hassle

Node.js, a JavaScript runtime or something like that, once had a CLA requirement, thought better of it, and removed it, in favor of contributing documentation stating that by contributing the developer certifies as to the appropriate origin of the contribution.

Click-through, online, low hassle CLA process

AngularJS is low-hassle

Google's AngularJS requires a Contributor License Agreement of its contributors. There's an easy, web-based process for ICLA signing. A bot pre-processes pull requests to vet their ICLA compliance status.

Chef is low-hassle

Note that Chef initially required a printed and faxed CLA and subsequently moved to an all-online process.

Mattermost is low-hassle

Mattermost is a Slack clone. Its contributor agreement process is fully online, just one simple form.

Ubuntu is low-hassle

Ubuntu is a Linux distribution.

Its CLA submission process is fully online, with PDF paper forms also available.

Microsoft is moderate hassle

Microsoft's CLA submission process is fully online, albeit through DocuSign so it feels more like signing a document.

Clojure is moderate hassle

Clojure requires contributors to jointly assign their copyright on contributed code to Rich Hickey, but at least doing so is low hassle, through an online echosign form.

Paper CLA process with maximum hassle

Apache is maximum hassle but only for committers

Apache requires that PDF contributor license agreements be

  • physically printed and signed, then submitted by fax or scanned and emailed, or
  • digitally signed and emailed

but Apache only requires Contributor License Agreements of committers, not of all Contributors.

Apereo is maximum hassle

Status quo Apereo is maximum hassle.

Apereo requires that an ICLA be physically printed and signed. Manual process feeds this into a roster of signatories. Committers are responsible for manually verifying the ICLA status of contributors before accepting their contributions.

The process does not capture the GitHub identity (or email address, or other technical identity) of signatories in a way that is usefully presented to committers, so that manual checking involves an extra layer of assuming in mapping from say GitHub identity to human name to ICLA records.

Proposed policy changes would bring Apereo more in line with Apache levels of hassle.

Django is maximum hassle

Gotta print, sign, scan, and email the PDF license agreement documents.

Duraspace is maximum hassle

Duraspace requires PDF contributor license agreements, presumably printed, signed, scanned, and then emailed.

Proprietary product processes

Instructure Canvas community edition is an open source product (AGPL), but the edition one actually typically adopts is proprietary. The terms of the AGPL, the whole point, is that if I license you my code under AGPL, you can use it, you can redistribute it, but you cannot redistribute it or even operate it for the use of others (offer it "in the cloud") without sharing publicly under AGPL your modifications to it.

Which is to say: if Instructure consumed my contribution under the license through which I consume the community edition product, Instructure would not be permitted to use my contribution in their proprietary product just as I'm not permitted to use their contributions to the community edition in my proprietary product. This is the AGPL doing what it's supposed to do, applying pressure to keep things open. Free. Libre, even.

Instructure gets around this by requiring contributors to sign an ICLA that doesn't just license the contribution -- it grants ownership in the contribution.

So, yes, Instructure is requiring an ICLA for contributions to Canvas. But there's this wrinkle, this extra reason for ICLA gravitas. The purpose of the ICLA in this context is to asymmetrically grant Instructure additional rights to use the contribution in a not-open-source proprietary product.

Writings about Contributor License Agreements

A survey of writings about navigating Contributor License Agreement tradeoffs.

In favor of contributor license agreements:

Against contributor license agreements:

Other background

Conference presentation

See John Lewis's 2014 Apereo conference presentation on open source licensing in Apereo and beyond.

Link tag clouds

See also my relevant Pinboard tagged links.

Post copyright and license

Copyright Andrew Petro 2016 .

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Post image drawn by the author.