Contributor License Agreement and Developer Certificate of Origin references

In the last few years I have come across the CLA topic several times. It is and will be a popular topic in automotive the coming years, like in any industry that moves from being an Open Source Producer towards becoming an Open Source Contributor.

In my experience, many organizations take the CLA as a given by looking at the google, microsoft or intels of the world and replicate their model. But more and more organizations are learning about alternatives, even if they do not adopt them.

What I find interesting about discussing the alternatives is that it brings to the discussion the contributor perspective and not just the company one. This enrichs the debate and, in some cases, leads to a more balanced framework between any organization behind a project and the contriibutor base, which benefits both.

Throughout these years I have read a lot about it but I have never written anything. It is one of those topics I do not feel comfortable enough to write about in public probably because I know lots of people more qualified than I am to do so. What I can do is to provide some articles and links that I like or that have been recommended to me in the past.

Articles

• “Why you probably shouldn’t add a CLA to your open source project“, written by Ben Alter back in 2018 is a must read. Ben is a United States-based lawyer who works for GitHub as their “evangelist” to government agencies.
  • “CLAs are Not a Sham” by Kyle E. Mitchell, a lawyer, is a respond to the previous article.
• “The trouble with Harmony: Part 1 and Part 2″ by Richard Fontana 2011, a Red Hat lawyer. He came back to the topic this year (2019) in his article “Why CLAs aren’t good for open source” summarising Red Hat’s position.
• “Why Your Project Doesn’t Need a Contributor Licensing Agreement” by by Bradley M. Kuhnon June 9, 2014. Bradley is a well known member of the Software Freedom Conservancy.
• “Contributor Agreements Considered Harmful” by Eric S. Raymond on July 8, 2019, represents a clear view from the individual contributors perspective on the CLA topic.
• “Community contributions and copyright assignment” By Jonathan Corbet, October 28, 2009. This article analyses from the contributor’s perspective the Canonical Ltd CLA which started a heated debate back then, leading to the Harmony project creation first and the initiative by the Mark Shuttleworth Foundation later on, two of the main attempts to standardise CLAs up to date.
• “Some thoughts on Copyright Assignment” by Michael Meeks, 2011, is still one of the most relevant articles on the topic, covering not just the theory but also putting examples of how harmful unbalanced relations with an entity that controls an Open Source project might be for contributors. Specially relevant has been over time the Recommendations section of this article.

DCO

It is impossible nowadays to talk about CLAs without talking about DCO (Developer Certificate of Origin). Here are some articles that I find interesting:

1. Ben’s Cotton article “CLA vs DCO What’s the difference“, from 2018 is a good article to read because it does not favour one over the other one.
2. I like the article “CLAs and using DCO clearly” from Hen written back in 2018 because it summarises well the costs associated to CLAs and how they (do not apply) apply to the DCO.
3. It is worth reading the summary of James talk at Linux Foundation Collaboration Summit 2014, “The most powerful contributor agreement” done by Jonathan Corbet.
4. Julien Ponge wrote “Developer Certificate of Origin versus Contributor License Agreements” back in 2016.

For companies that “do not buy into the anti-CLA” case, R. Fontana propose another two options:

1. Eclipse Contributor Agreement
2. The Software Freedom Conservancy’s Selenium CLA, which are not proper CLAs but DCOs in his view.

FLA

It is always interesting to learn about the Fiduciary License Agreement FLA, developed by the FSFE:

1. Fiduciary Programme
2. FLA FAQ
3. FLA-2.0 announcement.

Inbound = outbound

A serious conversation about CLA requires to understand the concept of inbound=outbound:

GitHub explains inbound=outbound as:

• “outbound licensing”, refers to granting a licence to another party to use, copy, distribute…. (depending on the license) your intellectual property.
• ”inbound licensing” means obtaining a licence from another party, to use, copy, distribute…. (depending on the license) its IP for your own consumption (distribution, etc. again depending on the license).

GitHub explains inbound=outbound as:

“Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms.[…]“

In the CLA discussion context, the general idea behind inbound=outbound is that the project should make evident to every contributor the contribution conditions, including those related with licenses rights and restriction. The contributor will then contributes her code with the same license, giving little room for later claims, either by the project, the contributor or third parties, based on those conditions being unclear or not easily reachable.

The project license and its description should be prominent and located at least where it is common practice in Open Source to find them. The same applies to all the assumptions and conditions affecting the contributors and the project in this area.

Common practice, many will claim, but sadly some projects are better than others on this.

Who is doing what?

In CLA discussions, it helps to know what others are doing. Here you have some links I have collected over the years and I still find relevant. I have to recognise that in a couple of cases cases I do not remember exactly why they called my attention at the time.

Company driven projects:

• Chef: Introducing DCO
• GitLab: Moving from CLA to DCO
• Docker: Introducing the Docker DC
• Nextcloud: Why I forked my own project and my own company.

Consortium driven projects:

• CNCF:
  • “Now DCO is preferred except for Kubernetes and gRPC.”
  • “Helm, for instance, also moved to DCO.”
• Hyperledger
  • Contribution policy
  • DCO v1.1
• Openstack: “General information about why a not CLA and why yes to a DCoOUS”
• Node.js: Announcement of removing the CLA
• Linux Container Project: LXD requires DCO

Community driven projects

• Eclipse: Eclipse Contribution agreement (a DCO de facto).
• KDE eV FLA.

Organizations with different agreements for individuals and entities:

• GENIVI uses a CLA only for entities and a DCO for individuals.
• OASIS uses a form for the same purpose.
• VMWare CLA FAQ
• Canonical: Individual CLA, Entity CLA and FAQ.
• IBM, for Swift, also uses a different CLA for individuals and for entities.
• Facebook

Organizations with CLA:

• Google
• Microsoft (.pdf)
• Check Wikipedia for more.

Additional links

And finally, I have several links that I think are worth reading for different reasons:

1. Project Harmony is worth investigating as an interesting attempt to standardize CLAs:

• Guide to the contributor agreement.
• How to use the contributor agreement.

2. GitHub uses an Individual and an entity CLA. It is interesting their CLA-assistant.

3. James Bottomley’s ideas about the Corporate Contribution Pledge published back in 2016 as complement to the DCO are worth reading.

Additional suggestions from readers

I hope my effort triggers the contributor in you so you provide additional links or challenge the ones above. I will substitute this text for those links you provide, obviously giving you credit by default. It would be a great way to help others in the future. Thank you very much in advance.