Your side project just passed 500 stars, and a stranger has opened the first serious pull request: 2,000 lines that fix a problem you have been avoiding for months. You want to click merge. But before you do, ask the uncomfortable question: do you actually have the legal right to ship that code — and to keep shipping it under your license, forever, no matter who that contributor works for?
If your repository has no contribution policy, the honest answer is that you are not sure. The contributor still owns the copyright on every line they wrote, and your project's license alone does not always settle who granted what to whom. That uncertainty stays invisible until the day it matters: a relicense, an acquisition, a corporate user doing license due diligence, or a contributor's employer claiming the work was theirs all along.
Two mechanisms solve this problem, and nearly every open source project picks one of them: the Contributor License Agreement (CLA) and the Developer Certificate of Origin (DCO). Both exist to establish that a contributor is allowed to make the contribution and that the project has the right to distribute it. They differ enormously in weight, friction, and what they let you do later. This guide explains how each one works, when to choose which, and how to set up your choice in an afternoon.
Why Your Project Needs a Contribution Policy at All
Copyright attaches automatically. The moment someone writes code, they own it — no registration, no copyright notice required. When they submit it to your project, your open source license covers a lot, but it leaves gaps that only a contribution policy closes:
- The inbound grant. Your outbound license (MIT, Apache-2.0, GPL) tells users what they may do with your code. A contribution policy makes explicit that incoming contributions arrive under compatible terms, so you can distribute the combined work without tracking per-file provenance by hand.
- Employer claims. Most employment contracts assign side-project IP to the employer, at least for work related to the employee's job. A policy that asks contributors to confirm they have the right to submit puts that responsibility — and the paper trail — on the contributor.
- Relicensing optionality. If you ever want to change licenses, add a commercial edition, or donate the project to a foundation, you need rights from every contributor. Gathering that permission retroactively from dozens of past contributors is somewhere between painful and impossible. A policy chosen on day one decides whether that door stays open.
- Patent protection. Code contributions can carry patent rights with them. Some policies include an explicit patent grant; others do not, which matters more than most maintainers realize.
None of this requires a law firm on retainer. It requires picking CLA or DCO, writing it down in your repository, and enforcing it automatically. Here is what each choice entails.
What Is a Contributor License Agreement (CLA)?
A Contributor License Agreement is a signed legal document between the contributor and the project (or the company or foundation behind it). The contributor signs once, and that signature covers all of their future contributions.
Unlike open source licenses, CLAs are not standardized. Each project writes its own, but most fall into two familiar shapes:
Individual vs. corporate CLAs
- Individual CLA (ICLA): signed by a person contributing on their own behalf. It typically grants the project a broad copyright license and often a patent license, while the contributor keeps their own copyright.
- Corporate CLA (CCLA): signed by a company, authorizing its employees to contribute. The company grants the same rights for work its people submit. Projects that accept corporate contributions without a CCLA are trusting that every employee's manager knows — and approves — which is exactly the kind of trust that evaporates during due diligence.
License grant vs. copyright assignment
Most modern CLAs are license grants: the contributor keeps ownership and gives the project a perpetual, worldwide, royalty-free license — often one broad enough to permit relicensing. The Apache Software Foundation's ICLA is the canonical example.
A minority of projects use copyright assignment, where the contributor transfers ownership outright (the Free Software Foundation's approach). Assignment gives the project maximum freedom to enforce and relicense, but it asks the most of contributors and has fallen out of favor with community-driven projects.
What a CLA costs you and your contributors
The trade-off is friction. A first-time contributor must leave the pull request, read a legal document, sign it (usually electronically), and wait for the status check to turn green before a maintainer will review their code. Tooling has made this nearly painless — bots like CLA Assistant comment on the pull request with a signing link and record the signature automatically — but it is still a gate between "I fixed your bug" and "you can merge my fix." Some drive-by contributors bounce off it.
In exchange, the project gets a signed, auditable record: this person, on this date, granted these rights. For corporate-backed projects, dual-licensed projects, and anything that might one day be acquired, that paper trail is worth real money.
What Is the Developer Certificate of Origin (DCO)?
The Developer Certificate of Origin was introduced by the Linux Foundation in 2004 for the Linux kernel, precisely to avoid the weight of a CLA. It is not a contract a contributor signs and files away. It is a short certification — five paragraphs, version 1.1 — that the contributor affirms with every commit by adding a Signed-off-by line to the commit message:
Fix off-by-one error in retry backoff calculation
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
Signed-off-by: Alex Rivera <[email protected]>Adding the line is one flag: git commit -s appends it automatically using your configured Git identity. By signing off, the contributor certifies that:
- They created the contribution (in whole or in part) and have the right to submit it under the project's open source license, or
- Their contribution is based on prior work already under an appropriate open source license that permits this submission, or
- They received the contribution from someone else who certified one of the above, and they did not modify it, and
- They understand the contribution and its record — including their sign-off — are public and kept indefinitely.
That is the whole mechanism. No separate document, no account linking, no per-project onboarding. Enforcement is a status check: the DCO app or an equivalent check verifies that every commit in the pull request carries a valid sign-off, and maintainers merge only when it is green.
The DCO's deliberate limitations
Notice what the DCO does not do. It grants no license beyond what the project's outbound license already conveys — it relies on the contribution arriving under the project's license terms. It contains no patent grant. And because nothing is signed and filed per contributor, there is no central registry of who agreed to what; the git history itself is the record.
Advocates consider this a feature: the DCO's low barrier is the point. The Linux kernel, GitLab (which switched from a CLA in 2017), and Chef (which switched in 2016) all concluded that per-commit attestation gives them the provenance they need without taxing every contributor. OpenStack's Technical Committee resolved in 2025 to replace its CLA with the DCO for all contributions. The industry trend is unmistakable — but a trend is not a verdict for your project, as the next sections explain.
CLA vs. DCO Side by Side
| Dimension | CLA | DCO |
|---|---|---|
| Legal mechanism | Signed agreement, filed once per contributor | Per-commit attestation in the commit message |
| What the contributor does | Signs a document (usually via a bot link) | Adds Signed-off-by with git commit -s |
| Copyright handling | Explicit license grant (or assignment) to the project | Contribution arrives under the project's license; no separate grant |
| Patent grant | Usually included | None |
| Relicensing freedom | Broad grants often permit it | No extra rights; relicensing needs every contributor's consent |
| Contributor friction | Higher: read, sign, wait for the check | Minimal: one Git flag |
| Enforcement tooling | CLA Assistant, EasyCLA, custom bots | DCO app, commit-message checks |
| Record of consent | Signature database | Git history itself |
| Employer coverage | Corporate CLA covers employees explicitly | Contributor self-certifies they have the right to submit |
| Best fit | Corporate-backed, dual-licensed, or acquisition-relevant projects | Community projects where contribution friction matters most |
When a CLA Is the Right Call
Choose the CLA when the project's future might depend on rights the DCO does not capture:
- You plan to dual-license or relicense. If a commercial edition, a license change, or a move from copyleft to permissive licensing is even remotely plausible, a CLA with a broad license-back is the only lightweight way to keep that option open. Reconstructing consent years later is the nightmare scenario.
- A company stands behind the project. Corporate sponsors, acquirers, and enterprise customers doing IP due diligence want a signature registry, not archaeology. Google, Apache projects, and Canonical all use CLAs for exactly this reason.
- Patents matter in your domain. Codecs, wireless protocols, ML model architectures — in patent-heavy fields, the CLA's explicit patent grant is doing real work the DCO silently skips.
- A foundation requires it. Some foundations mandate their CLA as a condition of hosting or graduation. Check before you assume the DCO suffices.
If you go this route, keep the CLA itself standard and boring: start from the Apache ICLA or a Harmony template rather than drafting from scratch, publish both individual and corporate versions, and wire up a signing bot on day one so the friction is one click, not a PDF round trip.
When the DCO Wins
Choose the DCO when contributions are the lifeblood and friction is the enemy:
- Community projects with many casual contributors. Documentation fixes, typo corrections, small bug patches — the contributions most likely to bounce off a signing gate are also the ones a DCO handles gracefully.
- Permissive license, no relicensing plans. If the project will stay MIT or Apache-2.0 forever and there is no commercial edition on the roadmap, the CLA's extra rights buy you little.
- Solo maintainers and small teams. The DCO needs no signature infrastructure, no legal entity to hold agreements, and no process for countersigning corporate forms. It is governance you can run from a
CONTRIBUTING.mdfile and a status check. - Maximum-compatibility posture. Some contributors — particularly those employed by large companies with strict IP policies — can sign off on a DCO but cannot sign an outside CLA without legal review. The DCO keeps that door open.
Whichever you choose, write the decision down. A CONTRIBUTING.md that states the policy, shows the exact sign-off or signing flow, and links the full text removes the most common source of confusion: contributors guessing at requirements from a failing status check.
5 Mistakes That Undermine Either Choice
1. Saying both. The most common real-world failure is a CONTRIBUTING.md that demands DCO sign-offs in one paragraph and CLA signatures in another — usually after a half-finished migration. Contributors follow one instruction, the other check fails, and maintainers merge anyway, which voids the point of both. Pick one mechanism, enforce it, and delete every trace of the other.
2. No automated enforcement. A policy stated only in prose is a suggestion. Wire the check into your pull request workflow as a required status check — the DCO app for sign-offs, CLA Assistant or EasyCLA for signatures — so an un-agreed contribution cannot merge by accident or maintainer fatigue.
3. Ignoring corporate contributors. If companies use and patch your project, employees will submit code on work time. Under a CLA policy, that means getting the CCLA signed early, while the relationship is warm. Under a DCO policy, it means making sure the sign-off requirement is visible enough that nobody's first contribution becomes an IP incident.
4. Assuming employment contracts allow contributing. Flip side of the same coin: if you contribute to other projects, check your own employment agreement first. Many assign work-related side-project IP to the employer by default. The DCO's certification ("I have the right to submit this") is only true if that paperwork says so.
5. No policy for AI-assisted code. Machine-generated contributions raise provenance questions neither the 2004-era DCO text nor most CLA templates anticipated. Decide your stance — allowed with review, disclosed, or prohibited — and state it in CONTRIBUTING.md alongside your CLA/DCO policy, before your first AI-generated pull request arrives rather than after.
Don't Forget the Money Side of Your Project
Here is the part maintainers postpone until tax season: the moment your project earns its first dollar — GitHub Sponsors payouts, Open Collective donations, a consulting engagement that arrived because of your README — it has finances, and finances need books.
The same discipline that makes contribution provenance auditable makes project money manageable. Track sponsorship income separately from your salary so you know what is taxable self-employment income. Log project expenses — domain renewals, CI minutes, the afternoon a lawyer spent reviewing your CLA — in their own accounts so deductions do not evaporate into personal card statements. If the project grows into an LLC or joins a fiscal host, clean historical records make the transition boring instead of forensic.
Plain-text accounting fits this workflow unusually well: your ledger lives in version control next to your code, every entry has a history, and nothing hides in a proprietary format. Our docs walk through getting a first ledger running in minutes.
Keep Your Project's Books as Clean as Its Git History
Choosing between a CLA and a DCO takes an afternoon; untangling provenance or project finances years later takes weeks. Make the contribution decision now, automate its enforcement, and give the project's money the same care you give its commits. Beancount.io provides plain-text accounting that gives you complete transparency and control over your financial data — no black boxes, no vendor lock-in. Get started for free and see why developers and finance professionals are switching to plain-text accounting.
