Contributor License Agreement landscape
In which I survey the landscape of Contributor License Agreement practices.
Motivation
This post is supporting background for some conversation and formation of opinions. This post isn't those conversations or opinions.
See also
- Analysis of Apache Foundation practices around CLAs
- Proposal to adjust Apereo ICLA policy to match Apereo policy
- Suggestion that open source adopters typically don't much care whether an open source project requires its contributors to physically sign CLAs, or indeed whether it requires CLAs of its contributors at all
- Why bother reducing CLA burdens if feasible
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:
Silence
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 .
This work is licensed under a Creative Commons Attribution 4.0 International License.
Post image drawn by the author.