CLAs, DCO & Contributor Agreements

How projects accept contributions legally — DCO sign-offs, CLA tools, and why DCO is winning in 2024–26.

Every patch you accept is someone else's copyright. CLAs and DCO are the two ways projects handle that. Pair with OSS License Selection, OSS Foundations & Fiscal Sponsors, and Code of Conduct & Governance.

DCO — Developer Certificate of Origin (start here)

★ ★ DCO — free, copy-pasteable text from developercertificate.org. Contributor adds Signed-off-by: Name <email> to each commit (git commit -s). They're certifying they have the right to submit the code. The Linux kernel uses this. No paperwork. Free.
★ DCO bot for GitHub — free OSS app from the Probot ecosystem; checks every PR commit has Signed-off-by. GitLab has a built-in equivalent.
★ GitLab DCO — built-in repo setting; no app install.

DCO is the default for community-driven OSS in 2024–26 because it's friction-free for contributors and legally sufficient for most projects.

CLA — Contributor License Agreement (when you actually need one)

CLAs are paperwork (often per-individual) granting the project broader rights than DCO — typically including a copyright assignment or relicensing power.

★ CLA Assistant — free OSS (SAP); GitHub App; bot collects signatures into a JSON file in a designated repo. Most popular OSS option.
CLA Bot (clabot.io) — alternative GitHub App; simpler.
EasyCLA (Linux Foundation) — paid / LF-membership-included; GitLab + GitHub; corporate-grade with company-CLAs.
oss-cla.fly.dev — minimal hosted CLA collector.
Salesforce CLA Assistant Lite, Google CLA tools (gerrit-based) — vendor-specific.

DCO vs CLA — when to use which

Concern	DCO	CLA
Friction for new contributors	Very low (one git flag)	High (sign + send)
Copyright assignment	No	Often yes
Right to relicense the project later	No (need every contributor's permission)	Yes (with assignment-style CLA)
Patent grant	Implicit via license	Often explicit
Default for community OSS	★ Yes	No
Default for company-backed OSS	Sometimes	★ Often
Legally sufficient for most foundations	★ Yes (LF, ASF)	Yes

Honest take (2024–26)

★ ★ DCO has won the default-for-community-OSS war. Linux Foundation, Apache (modified ICLA + DCO), Eclipse, Kubernetes, Docker, GitLab, .NET — all DCO or DCO-equivalent.
CLAs remain useful when: the project anticipates relicensing (e.g. dual-license OSS + commercial), is run by a single company, or is anchored at a foundation that requires a CCLA (corporate CLA) for company-employed contributors.
The "CLA assignment" model is on the way out for new community projects — contributors increasingly refuse to sign over copyright to a single company that may later relicense (see License Relicensing Wave).
MongoDB / Cockroach / Hashicorp's CLAs enabled their relicensings. Worth thinking about.

Practical setup (DCO route)

Add Signed-off-by requirement to CONTRIBUTING.md.
Install the DCO GitHub App or enable GitLab's DCO check.
Document git commit -s in your contributing guide.
Add a dco status check as required for merge.

Practical setup (CLA route)

Pick a CLA template — Apache ICLA / CCLA, Harmony Agreements, Project Harmony, or LF's templates.
Install CLA Assistant (free).
Configure the bot to comment on every PR; merge blocks until signed.
Decide: individual-only, or also corporate (for employees committing on company time).

Pick this if…

Default for community-driven OSS: DCO + DCO bot.
Default for company-backed OSS: start with DCO; add a CLA only if you have a concrete reason (relicensing, dual-license, foundation requirement).
You're under a foundation: check their policy first — Linux Foundation is DCO, Apache is ICLA, CNCF is DCO.
You want zero contributor-facing friction: DCO with the GitHub App.
You need a paper trail of CCLA signatures from contributing companies: CLA Assistant or EasyCLA.