Time to retire Contributor License Agreements

Imposing Contributor License Agreements (CLAs) on open source contributors inadvertently imposes unnecessary legal risk on the people gifting software to humankind. It’s time to:

• Update the legal advice from foundations,
• Update license terms of hosting platforms,
• And help open source communities avoid wasting energy on CLAs.

Reading time: 6 mins

What are CLAs?

Contributor License Agreements (CLAs) are “inbound licenses” - providing a license from a contributor into a project. This contrasts to “outbound” open source licenses such as the GPL or Apache licenses, which provide a license from a project to users. There are multiple individually crafted CLAs (which is a problem in itself), which typically consist of a combination of:

• Individual Contributor License Agreements (ICLA): An individual asserts that they license their contributions to the project, and they have the right to do so.
• Corporate Contributor License Agreements (CCLA): A corporation asserts their employees may contribute to the project.
• Copyright Assignments (CA): Contributors assign copyright to the project’s owners (typically a not-for-profit organization).

What are the arguments for CLAs?

Proponents for CLAs often argue that CLAs add licensing rigor and help protect a project and its end users from being sued by bad actors. For instance, the Ubuntu/Canonical FAQ notes:

Q: Why do you ask contributors to send in the [contributor license] agreement?

A: We need to make sure that we ‐ and the users of our software ‐ are legally entitled to distribute your contributed code, anywhere in the world.

Why the Free Software Foundation gets copyright assignments from contributors:

In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer. That way we can be sure that all the code in FSF projects is free code, whose freedom we can most effectively protect, and therefore on which other developers can completely rely.

What’s wrong with CLAs?

The problem with Contributor License Agreements (CLAs) are that they:

• Are at best legal voodoo. In the current unformed state of intellectual property law, CLAs don’t provide a water-tight defense against the legal attack they are theoretically supposed to prevent.
• Are arguably unnecessary, now that “inbound=outboud license terms” have started being woven into some hosting platform Terms of Service.
• Shift legal risk to contributors.
  • CLAs shift the legal risk for copyright infringement, patent infringement or other bad acts,
    • From the project and end users (the entities best positioned to defend a legal claim, and often the ones most directly benefiting financially),
    • To the contributor (the one in at the least advantaged negotiation position, often volunteering their time for the project’s benefit).
• Rely on our Don't Read & Click ‘Agree’ culture — tricking contributors into bearing legal risk.
• Create a contribution-hostile environment. CLAs require that the first interaction between an open source project and a potential contributor involves a formal and complex legal agreement which signs away their legal rights — not exactly a warm welcome.
• Require significant administrative overhead. The project needs to stand up a system to track every potential contributor that has signed the agreement.

Alternative 1: Do nothing

If your project has selected an open source license, and you are using a platform like Github, which includes an “inbound=outbound” clause in its terms of service, then your project is likely covered to the same extent as you get from a CLA.

Alternative 2: Simple statement

You can add a simple statement to your project’s contributor guidelines. Erik S. Raymond suggests:

By submitting patches to this project you agree to allow them to be redistributed under the project's license, according to the normal forms and usages of the open-source community.

Alternative 3: Developer Certificate of Origin

You can reference the Developer Certificate of Origin (DCO) in your project’s contributor guidelines:

By contributing to this project we expect you to agree to the Developer Certificate of Origin (DCO).

The (DCO) provides a simpler alternative to CLAs. It is a simple statement that a contributor agrees to share their contribution under the project’s license terms, and has the rights to do so. It’s advantages are:

• It is short, simple and easy to understand.
• It can be referenced by any project without customisation.
• It can be set up without engaging a lawyer.
• It is used by trusted open source foundations, giving it credibility within open source communities.
• It has negligible project management overhead. Tracking of agreements is managed by the code versioning system.
• It doesn’t introduce a copyright assignment, which is a barrier for some contributors.

Possible disadvantages are:

• Like CLAs, DCOs don’t provide a water-tight defense against the legal attack.
• It could be argued that a simpler statement of “inbound licenses = outbound licenses” provides the same purpose as the DCO, but does so more elegantly.
• While the DCO can be applied without explicit signatures for each commit, some projects, such as the Linux Foundation, require each commit to be electronically signed. The electronic signature adds a technical overhead which can deter some contributors.
• Some entities (such as not-for-profit organizations) might be concerned that copyright is not assigned to their entity.

What should projects do?

Adopt one of the three alternatives above.

What should open source foundations do?

Open source foundations have earned a position of trust, respect and influence within software communities.

It is important for these foundations to:

1. Research and understand the problems associated with CLAs.
2. Revisit and ideally migrate off CLAs for projects within their foundation.
3. Collaborate and adopt common language around the replacement to CLAs.
4. Provide prominent advice to communities against the use of CLAs.

What should software hosting platforms do?

Software hosting platforms should follow the lead of Github and legally protect the projects they host. Add “inbound=outbound” to their license terms of service.