Contributor License Agreements (CLAs): Friend, Foe, or Necessary Evil?

Contributor License Agreements (CLAs) are a type of licensing agreement that governs how people contribute to open-source software or developments.

They can help intellectual property rights between developers and distributors to be clarified, and can ensure that contributed content is clearly licensed. However, they can also leave developers vulnerable to further re-licensing of their contributions without recourse.

This article will cover what CLAs are and what they cover, the benefits and downsides, and go through some example clauses in CLAs. Then, we'll briefly touch on some alternatives to using CLAs.

Let's get started.

What are Contributor License Agreements?

A Contributor License Agreement (CLA) is a type of agreement used when people contribute to a collaborative project, such as open-source software.

It creates a licensing agreement between the original creator, e.g. of copyrighted content, and the distributor of the software. A license means you are given permission to use something. A CLA makes sure that the copyrighted work is shared, used, and distributed with permission.

What is Covered by a CLA?

A CLA covers the extent of the license, the relevant parties, the copyrighted work, and the rights and responsibilities of the parties to the agreement.

For example, a CLA would cover a grant of a copyright license or patent license, warranties and representations (such as that you have the legal standing to grant the relevant license), limitations on the license, and notice that needs to be given if circumstances change.

Additionally, you may want to verify that disclaimers about warranties and liabilities comply with consumer protection and software support obligations in your jurisdiction, particularly if you plan to distribute commercial versions later on.

Importantly, CLAs are not standard. This means you need to read any specific CLA that you sign. If you're drafting one, you'll need to determine carefully what legal rights you are asking for from the contributor.

It's also important to consider whether local laws protect moral rights that cannot be fully waived, which can affect your rights to repurpose or modify the source code. For instance, in some jurisdictions, creators retain certain moral rights even if they sign a broad license.

Many projects have individual CLAs as well as corporate CLAs. Corporate CLAs are for when an employee makes a contribution on behalf of a business or "entity" that is not a legal person, or when a business or entity makes contributions itself.

For example, the Google corporate CLA states that "This version of the Agreement allows an entity (the "Corporation") to submit Contributions to Google, to authorize Contributions submitted by its designated employees to Google, and to grant copyright and patent licenses thereto."

What are the Benefits of Using CLAs?

Many open-source community members are against CLAs. However, they do have a number of benefits. One of the main benefits of a CLA is that it clarifies the legal situation in a collaborative project, and to prevent lawsuits or other intellectual property disputes that could arise.

For projects, this can minimise the legal risk from an intellectual property perspective.

Julian Ponge, a computer science professor and commentator, also notes that using CLAs is "a sign [from the project owner] that you intend to sustain your project in the long run with responsible practices regarding intellectual property management." You can see his statement in support of CLAs below:

In addition, CLAs allow the project to relicense under different terms at a later date. For example, if the project was initially licensed under the LGPL, the project owner could relicense it later as proprietary.

For developers, CLAs can provide some legal clarity about how the intellectual property in their contribution is governed. In addition, there is a formal recognition of the developer's contributions, and many CLA terms include protections from liability for developers.

Nonetheless, there are a number of issues with CLAs, particularly viewed from the developer perspective. Let's take a look at those now.

What are the Downsides of and Concerns About CLAs?

CLAs are viewed negatively in many respects by the open-source software development community. One of the initial concerns about CLAs is that they can be intimidating, or even discouraging, for open-source contributors that may otherwise want to contribute.

In addition, personal information needs to be provided for them to be signed, which many people do not want to provide.

They also create extra administrative overhead for projects which then need to manage numerous contracts, personal information, and other details.

CLAs add an extra barrier and can make projects seem more intimidating, which discourages open-source development and the growth of the community more generally.

Another, more significant issue is that once a CLA is granted, often the overall project can be relicensed further without the permission of the original copyright granter.

For example, if a software developer grants unrestricted republishing rights to the project, the project can then further license the project and the software developer has limited recourse.

Three notable examples of this are the MongoDB program, Elastic, and Redis Labs, all of which used CLAs and then modified licenses to their products. This was viewed very negatively by the open-source community.

MongoDB switched from GNU AGPLv3 licensing to the Service Side Public License (SSPL) in 2018. The SSPL is a license that is not considered to be an open-source license by the Open Source Initiative. Elastic also switched to using the SSPL from the Apache license.

The OSI states that "the hallmark of a fauxpen source license is that those who made the switch claim that their product continues to remain "open" under the new license, but the new license actually has taken away user rights." You can see this in their press release below:

For more context, you can review OSI's official commentary on why the SSPL does not meet the criteria for open-source status.

In 2024, Redis Labs switched from using BSD to a dual-license model using RSALv2 and SSPLv1. Neither of these are considered to be open-source licenses.

These changes mean that an originally open-source project using CLAs to gain licenses from developers, could decide to relicense itself as a non-open-source.

LWN.net explained that to become a contributor to MongoDB (at the time of writing) "a developer must first sign MongoDB's contributor agreement, which assigns copyright ownership to MongoDB. Those contributors all gave MongoDB the right to relicense their code in this manner — a permission that some of them may be reconsidering now."

Some community contributors like this explicitly warn others against signing CLAs, highlighting instances of open-source projects like the above becoming relicensed under proprietary terms.

Real Life Examples of CLAs

While each CLA is unique, there are some that are frequently used, and sections that are common across CLAs.

One example of a commonly-used CLA is the Apache Individual Contributor License Agreement.

You can see above the Apache CLA grant of copyright license. This grants a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable license, to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute contributions to the project.

Google open-source projects also model their CLAs on the Apache CLA. For example, you can see below the section for granting a copyright license, which is identical to the Apache section.

Here's another example from Odoo, which shows again the basic parameters of what is covered by the copyright license.

Note that Odoo explicitly states that the user retains copyright in the contributions. In addition, the Odoo action includes a right to sublicense the rights to the contributions, which goes further than the Apache example.

In the section below, you can see Apache's sections on representations. These are often included in CLAs to provide an assurance to the project that the contributor has the rights to the contributions.

In this example from Odoo, contributors should confirm that they own the copyright and patent claims that are relevant to the contribution they are making:

This example from Jetbrains also shows the representations that contributors must agree to:

In addition, the Apache CLA states that contributors do not have to provide support for their contributions. They can do so freely if they wish. Contributions are also provided on an "as is" basis, without warranties or conditions of any kind.

Similarly, the Odoo CLA includes a disclaimer section, in which contributions are also provided "as is" without warranties:

You can see in this example below from Threema that the software that is made from the contribution can be licensed "under any license, including copyleft, permissive, commercial, or proprietary licenses."

Note particularly that the CLA allows contributions to be licensed under commercial or proprietary licenses. You can see a similar term from Jetbrains, claiming the same rights in its CLA:

This is one of the major downsides that the open-source development community considers in relation to CLAs.

Alternatives to CLAs

There are a few different alternatives that you can use instead of a CLA. Some mechanisms are particularly popular in the open-source community. The primary alternatives include:

• Use a Developer Certificate of Origin (DCO)
• Keep work under a permissive open-source license
• Work on the CLA terms themselves

Let's take a look at each of those.

Developer Certificate of Origin (DCO)

The Developer Certificate of Origin (DCO) is one important and frequently-used alternative to a CLA. In the developer community this is seen as a much better choice compared to using CLAs.

If you'd like to learn more about the exact terms of the Developer Certificate of Origin, you can check out the official text, which explains the basic legal assurances contributors make when submitting code.

The DCO is a statement that was originally created by the Linux Foundation. You can read the text of the DCO below:

This DCO text can be added to code that is contributed to a project. It is much simpler than a CLA, but still provides an indicator of who is responsible (legally) for the code.

A DCO is preferred as it offers a lower barrier to entry when submitting code, it doesn't require the inclusion of personal information (it's optional), and it doesn't grant relicensing rights to the project owner.

Permissive Open-Source Licenses

Permissive open-source licenses are another alternative to CLAs that can support the contribution process and provide some certainty of terms, without the same potential encroachment of relicensing issues.

For example, developers can submit contributions under the license that the project is based on, such as the Apache 2.0 or BSD license. Permissive open-source licenses also allow code to be later used for proprietary or commercial projects. Developers would be aware of this when they submit their code at the outset.

Include Specific CLA Terms

One way to approach the issue is to amend the terms of any CLA to ensure that relicensing under a permissive license is not permitted.

Here's one example from Odoo, which includes a clause that Odoo agrees to keep the contributions licensed under whatever license was being used when the contributions were made.

You can see that the clause states "We agree to license the Contribution only under the terms of the license or licenses which We are using on the Submission Date for the Material or any licenses which are approved by the Open Source Initiative on or after the Effective Date, including both permissive and copyleft licenses."

This is related to what is commonly known as "inbound = outbound", which is the idea that content licensed into an open-source project should have the same license applied as whatever is already on the project.

Here's an example of this type of clause from Github.

You can see that the Github clause tries to make it explicit that any inbound content will have the license applied that was already existing on the repository.

So Are CLAs Necessary?

In short, no, CLAs are not necessary. A majority of open-source projects do not use CLAs, although a large minority do. They are more likely with large projects or large pieces of software that are intended to be commercially used.

Still, it's worth noting that smaller projects might also opt for CLAs to ensure ownership clarity or secure the ability to incorporate contributions into proprietary releases down the line, depending on their specific business or community objectives.

The Software Freedom Conservancy provides an explanation with a "summary on the basics of why CLA's aren't necessary, and on Conservancy's typical recommendations to its projects regarding the issue."

You can see their explanation of why CLAs aren't necessary below:

Notably, they explain that "CLAs simply shift legal blame for any patent infringement, copyright infringement, or other bad acts from the project (or its legal entity) back onto its contributors … [and] twist the empowering, community-oriented, enjoyable experience of FLOSS [Free/Libre Open-Source Software] contribution into an annoying exercise in pointless bureaucracy."

Summary

Contributor License Agreements (CLAs) are a common but controversial agreement applied in the open-source development community, most often by large projects looking to protect themselves legally.

The open-source development community views CLAs in a primarily negative light, and believes that they both discourage contributions, add unnecessary overhead to projects, transfer risks onto contributors, and often end with projects taking open-source contributions and relicensing them as proprietary and commercial.

CLAs are helpful for projects that want to minimise legal risks, but are not necessary from a project perspective, nor a community one, and they may discourage contribution altogether.