# Contributor License Agreements (CLAs) > What contributor license agreements do — CLAs vs the DCO, why projects use them, and how they keep your open-source IP clean. Guide | Author: Lidiia Levitska | Source: Intellectual Property Law (outsideipcounsel.com) Canonical: https://outsideipcounsel.com/guides/contributor-license-agreements/

Quick answer: A contributor license agreement (CLA) is a contract that outside contributors sign before their code is merged into a project. It gives the project a clear copyright license — and usually an explicit patent grant — to use, modify, redistribute, and relicense the contribution. Most CLAs (like the Apache model) let the contributor keep ownership; only rarer assignment CLAs transfer it. The lighter-weight alternative is the Developer Certificate of Origin (DCO), a per-commit "Signed-off-by" certification that adds almost no friction but grants no separate rights. Companies use CLAs to keep their open-source IP clean — which matters most in an acquisition, when buyers verify the code is really theirs to ship.

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](https://www.copyright.gov/what-is-copyright/) 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](https://www.law.cornell.edu/uscode/text/17/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](/guides/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](/guides/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 ` 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**](https://www.law.cornell.edu/uscode/text/17/201), 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](/guides/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](/guides/open-source-risk-in-due-diligence/), and the broader diligence picture in [IP in fundraising due diligence](/guides/ip-in-fundraising-due-diligence/). To see how courts treat open-source and copyright license disputes, browse our [copyright case archive](/topics/copyright/). ## 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.* ## Frequently asked questions ### What is a contributor license agreement (CLA)? A CLA is a contract that a contributor signs before their code is merged into an open-source project. It grants the project a clear copyright license (and usually a patent license) to use, modify, and redistribute the contribution — including the right to release it under the project's chosen license. CLAs don't take away the contributor's ownership; they simply give the project documented permission so it can safely ship and relicense the combined codebase. ### What is the difference between a CLA and the DCO? A CLA is a signed contract that grants the project a license or assignment to your contribution. The Developer Certificate of Origin (DCO) is a lightweight alternative: instead of signing an agreement, you add a 'Signed-off-by' line to each commit, certifying you have the right to submit that code. The DCO is far less friction but grants no separate license or patent rights — it relies on the project's inbound license instead. ### Do I keep the copyright to code I contribute under a CLA? Under a license-style CLA — like the Apache Individual CLA that most projects use — yes. You retain ownership of your contribution and grant the project a broad, irrevocable license to use it. Only a copyright-assignment CLA actually transfers ownership to the project, and those are far rarer (the Free Software Foundation is the best-known example). Always read whether your CLA is a license or an assignment before signing. ### Why do acquirers care about CLAs in due diligence? When someone buys a software company, their lawyers verify the company actually owns or is licensed to ship every line of its code. A project with no CLA or DCO may contain contributions with unclear rights — an ownership gap that can lower the price, trigger indemnities, or hold up the deal. A clean CLA record shows every outside contribution came in with documented permission, which makes the codebase far easier to diligence.