Contributor License Agreements (CLAs)

Open source runs on contributions from strangers. That is its superpower and, legally, its soft spot: every time you merge someone else’s pull request, you are folding their copyrighted work into your codebase. A CLA is the paper trail that says the project actually has permission to do that. This guide explains what CLAs do, how they differ from the DCO, when a company should require one, and why the answer shows up years later in an acquisition data room.

What is a contributor license agreement?

A contributor license agreement is a contract between a project (or the company or foundation that stewards it) and a person or organization contributing code, documentation, or other material. The contributor agrees, in advance, to grant the project the rights it needs to incorporate the contribution.

A well-drafted CLA typically covers three things:

• A copyright license. The contributor grants a broad, perpetual, irrevocable, worldwide, royalty-free license to reproduce, modify, distribute, and sublicense the contribution (see the copyright owner’s exclusive rights in 17 U.S.C. § 106).
• A patent license. The contributor grants a license to any of their patents that the contribution would otherwise infringe — so the project can’t be sued later by someone whose own code it merged.
• Representations. The contributor confirms the work is original (or that they have the right to submit it) and that they are legally able to grant these rights.

Crucially, most CLAs are license grants, not ownership transfers. Under the widely used Apache Software Foundation Individual CLA, for example, you keep the copyright to what you wrote and simply license it to the project. That distinction matters — see the assignment discussion below.

CLAs are one piece of a broader open-source hygiene picture. For the full lifecycle of using and releasing open code, start with our open source and software IP hub.

Why do projects and companies require a CLA?

At first glance a CLA looks like bureaucracy. But it solves real problems that only surface once a project matters.

• Clear chain of title. Without a signed grant, the legal status of an outside contribution is ambiguous. A CLA replaces that ambiguity with a documented, enforceable license from every contributor.
• The right to relicense. This is the big one for companies. If a project is released under, say, the MIT license today but the maintainer later wants to add a commercial edition, dual-license it, or move to Apache 2.0, they need permission from every copyright holder. Merging thousands of un-CLA’d contributions makes that nearly impossible. A CLA that grants a broad license — or the right to sublicense — keeps that door open.
• Explicit patent protection. Permissive licenses like MIT and BSD say little or nothing about patents. A CLA can add the express patent grant those licenses lack, closing a gap that acquirers and enterprise adopters worry about.
• Enforcement standing. A project that holds broad rights is in a stronger position to enforce its license against violators.

For a company building a business around an open-source project — the “open core” and single-vendor models — these rights are strategic, not cosmetic. We cover that business model in depth in building a company on open source.

What is the “inbound = outbound” model?

Many projects skip a CLA entirely and rely on a principle called inbound = outbound: the license under which a contribution comes in is the same license under which the project goes out. If the project is Apache 2.0 and you submit a pull request, you are understood to be contributing under Apache 2.0.

The phrase was popularized by open-source lawyer Richard Fontana, and it is baked into how platforms operate. GitHub’s Terms of Service state that when you contribute to a public repository, you contribute under the same license terms as that repository, absent a separate agreement.

Inbound = outbound is elegant because it requires no signatures and no friction. Its limits are the flip side of the CLA’s strengths:

• It gives the project no right to relicense beyond what the outbound license already allows.
• It provides only the patent terms the outbound license contains — which for permissive licenses may be none.
• The “you agreed by contributing” theory is legally thinner than a signed contract.

For a permissive, community-run project with no relicensing ambitions, inbound = outbound is often plenty. For a company that may need to change licenses or wants airtight rights, it usually isn’t.

CLA vs. the DCO: which should a project use?

The Developer Certificate of Origin (DCO) is the most popular middle path, and the choice between a CLA and the DCO is the central decision for most maintainers.

The DCO is a short, fixed statement — version 1.1, originated by the Linux kernel community in 2004 — that a contributor certifies rather than signs. In practice you add a line to each commit:

Signed-off-by: Jane Developer <jane@example.com>

By signing off, you certify that you wrote the code or otherwise have the right to submit it under the project’s open-source license. Here is how the two approaches compare:

• What it grants. A CLA is an affirmative license (and often patent) grant to the project. The DCO grants nothing extra — it is a certification of origin that relies on the project’s existing inbound license.
• Friction. A CLA usually requires a one-time signature, often automated by a bot. The DCO requires only a git commit -s per commit and no separate account or signature.
• Contributor trust. Some contributors — and some employers’ legal teams — refuse to sign corporate CLAs. The DCO is generally seen as contributor-friendly and lower-commitment.
• Relicensing power. A broad CLA can enable relicensing; the DCO cannot.

The Linux kernel, GitLab, and many others use the DCO. The Apache Software Foundation, Google, and many single-vendor companies use CLAs. There is no universally “correct” choice — it is a trade-off between the rights the project needs and the friction it can afford.

What is the difference between individual and corporate CLAs?

Most CLA programs come in two flavors, and serious contributors often need both.

• Individual CLA (ICLA). Signed by a person contributing on their own behalf. It covers contributions the individual owns.
• Corporate CLA (CCLA). Signed by an employer. Because in the U.S. code an employee writes within the scope of employment is usually a work made for hire owned by the company, the individual often can’t grant rights to their work code — the employer has to. A CCLA lets a company authorize its employees (frequently listed by name or by domain) to contribute, and grants the project rights in that company-owned code.

This is why large tech employers maintain corporate CLAs with the projects their engineers touch: without the CCLA, an engineer’s “personal” contribution of code they wrote on the clock could be an ownership defect. If you are unsure who owns a given piece of work, our guide on who owns startup IP walks through the work-for-hire and assignment rules that drive this.

What about copyright assignment instead of a license?

A small number of projects go further than a license and ask contributors to assign copyright — to actually transfer ownership of the contribution to the project. The Free Software Foundation is the classic example, having long requested assignment for GNU projects it stewards so it can enforce the GPL uniformly.

Assignment gives the project the strongest possible position: it becomes the sole owner and can license, relicense, and enforce without consulting anyone. But it is also the most controversial:

• Contributors give up ownership entirely, which deters many from participating.
• Corporate legal teams often flatly refuse assignment.
• It concentrates enormous control in whoever holds the copyrights.

Most projects that once used assignment have shifted to broad license-style CLAs precisely because assignment scares off contributors. When you sign any CLA, read the operative verb carefully: license keeps your ownership; assign does not.

How are CLAs collected and enforced in practice?

The friction of a CLA is mostly an implementation problem, and tooling has largely solved it. Common approaches:

• CLA bots. Tools like CLA Assistant (open-sourced by SAP) and the Linux Foundation’s EasyCLA hook into pull requests. When a first-time contributor opens a PR, the bot blocks the merge until they click through and sign the CLA, then records the signature against their GitHub identity.
• Signature records. The project keeps a durable record of who signed which version of the CLA and when — the evidence a future diligence team will want.
• Versioning. If the CLA text changes, contributors may need to re-sign. Keeping old versions matters.

The enforcement point is subtle: the CLA doesn’t stop bad code from being submitted; it ensures that whatever is merged came with documented, defensible rights. That record is only useful if it is complete, which is why partial or abandoned CLA programs can be worse than none — they create the appearance of coverage without the substance.

Why do CLAs matter in an acquisition or investment?

For founders, this is where CLAs earn their keep. When a company is acquired or raises a serious round, the buyer’s or investor’s counsel runs IP due diligence — and open-source contributions are a standard area of scrutiny.

The core question is whether the company actually owns or is properly licensed to ship every line it distributes. Outside contributions with unclear rights are an ownership gap. Diligence teams look for:

• Whether the project used a CLA or DCO at all.
• Whether the signature/sign-off record is complete and covers material contributions.
• Whether any contribution carries a conflicting or copyleft license that could infect the product.

A clean CLA record is a strong answer: it demonstrates that every external contribution entered with documented permission. A missing or spotty one can force reps and warranties, escrow holdbacks, price reductions, or a scramble to collect retroactive signatures. We break down exactly what buyers hunt for in open-source risk in due diligence, and the broader diligence picture in IP in fundraising due diligence. To see how courts treat open-source and copyright license disputes, browse our copyright case archive.

The bottom line

A CLA is not paperwork for its own sake — it is the mechanism that turns a pile of strangers’ pull requests into a codebase a company can confidently own, ship, relicense, and eventually sell. Decide early: a permissive community project can often live on inbound = outbound or the low-friction DCO, while any company that might relicense, needs explicit patent grants, or plans to be acquired should adopt a broad CLA — with a corporate CLA for employer-owned contributions — and automate collection with a bot. Whatever you choose, apply it consistently from day one, because the value of the record is entirely in its completeness.

This guide is general education, not legal advice, and does not create an attorney-client relationship. Whether a CLA, DCO, or assignment fits your project depends on your license, your business model, and your governance — consult an attorney licensed in your jurisdiction before adopting or signing one.