Contributor License Agreements (CLAs)

In addition to (or, in some cases, in place of) the DCO, an open source project may elect to use Contributor License Agreements, or CLAs, as a requirement for receiving contributions.

What are CLAs?

Unlike the DCO, a CLA is a legal agreement between a contributor and the project.

More specifically, a CLA is an agreement that sets forth the terms and conditions of the license grant made by the contributor to the project for what they are contributing. It typically sets forth language explicitly licensing the intellectual property embodied in the contribution to the project, for the purpose of enabling the project to incorporate it into the project’s open source codebase for broad redistribution.

Unlike the DCO, there are many different CLA texts. Each CLA is a separate legal document with its own text, and each could impose different commitments and license grants. Contributors may need to review each CLA carefully to understand the scope of rights being granted.

Many projects in fact use two separate CLAs:

  • a Corporate Contributor License Agreement, or CCLA, for contributions made on behalf of companies and other organizations; and

  • an Individual Contributor License Agreement, or ICLA, for contributions made by an individual on their own behalf.

Some projects may use either, or both, a CCLA and an ICLA. And contributions from a particular person could be made under either, or both. For example, an individual might make some contributions under a CCLA on behalf of their employer during their day job, and others under an ICLA on their own behalf during their own time. Persons may also make contributions under multiple CCLAs over time, for example when a contributor leaves one employer and moves to another.

What does a CLA mean?

Unfortunately, because each CLA has its own text, there is no single answer to this question. Most CLAs have at least the following characteristics:

  • The contributor retains ownership of the copyrights in their contributions. (If they don’t, it’s an assignment agreement rather than a license agreement.)

  • The contributor grants a license to the project of certain rights.

  • The license is explicitly scoped so that both parties know what its specific terms are.

The most commonly used CLAs are those published by the Apache Software Foundation, which are often used as templates for non-ASF projects. A few additional key items in these CLAs are:

  • The contributor grants a broad copyright license which is more expansive than the project’s open source license. (In other words, it is not an “outbound == inbound” model.)

  • The contributor grants a license to patents practiced by their contribution.

  • The contributor represents that they are legally entitled to grant these licenses. - In particular, using the CCLA may help establish that a contribution made on behalf of a company is actually authorized under that company’s corporate authority.

Not all CLAs include these concepts. For example, some CLAs simply document the “outbound == inbound” model in a formal legal agreement. Some in fact may just act as a “signed wrapper” around the DCO itself.

This is why just knowing that a project uses a CLA is not enough; you (or your legal counsel) should read and understand the particular CLA before proceeding to contribute.

How does a project use a CLA?

As with the DCO, when an LF-hosted project community desires to use a CLA model for receiving contributions, the intellectual property policy in the project’s charter would state this.

In practice, implementing and using a CLA properly can be more challenging that it seems on the surface. The key requirement is that, before a contribution can be accepted and merged into the project codebase, it needs to be authorized under a signed CLA.

However, this is not as straightforward as it might seem. In all but the smallest companies, the person writing and submitting code to the project likely is not authorized to sign license agreements on behalf of their employer. Under each company’s own policies, formal agreements licensing the company’s intellectual property might require signature by a senior member of the company’s leadership. That signatory also might not be the day-to-day manager responsible for tracking which individual employees are authorized to contribute to which particular projects.

For the LF’s projects that use CLAs, the LF’s EasyCLA tool implements a workflow that is aimed at handling these complications. Although the CLA process inherently adds complexity, EasyCLA helps to enforce the requirement that contributions to the project will be blocked until they are submitted by an authorized contributor under a signed CLA.

A project that chooses to use a CLA typically does so because they want to receive the potential benefits from its use. Establishing workflows that support appropriate processes is key. And doing so at scale (rather than relying on time-consuming and error-prone manual tracking) is essential for projects with large contributor communities.

Why would a project use a CLA?

Some project communities might choose to use a CLA as a contribution mechanism because:

  • they prefer having a formal legal agreement signed by contributors

  • they feel that the intellectual property commitments may be more reliable when backed by a signed CLA

  • they desire for the project to have the ability to change to a different open source license in the future

What complications can arise from using a CLA?

Some complications can include:

  • increased friction and slower onboarding of new contributors

  • potential for mistrust due to no standard CLA

  • complexities of maintaining an appropriate CLA management workflow (or, misplaced trust in a CLA tool that doesn’t implement an appropriate workflow)

  • ability to relicense in the future may not be seen as a benefit by contributors

Resources