Developer Certificate of Origin (DCO)

The **Developer Certificate of Origin (DCO)** is a short legal statement — ~170 words — that open-source contributors attest to with each commit. It says, in effect: 'I have the right to submit this code under the project's license.' The attestation is made by adding a `Signed-off-by:` line in the git commit trailer. ## Origin Introduced by **Linus Torvalds** in May 2004 during the **SCO lawsuits** — the multi-year litigation where SCO Group claimed IBM had put proprietary Unix code into Linux. To defend the kernel against future provenance disputes, Torvalds introduced the DCO as a per-commit attestation mechanism that could be referenced if anyone challenged where code came from. ## The text (DCO 1.1) > By making a contribution to this project, I certify that: > > (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or > > (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or > > (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. > > (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is recorded and maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. ## How you sign off ``` git commit -s ``` Appends a `Signed-off-by: Name <email>` line to your commit message. Projects enforce via commit hooks or CI checks that every merged commit has a valid Signed-off-by. ## DCO vs CLA **Contributor License Agreement (CLA)** — used by Apache Foundation, Google, many corporate-led OSS projects. - **Grants additional rights** to the project owner (usually a patent license, sometimes unilateral relicensing authority). - Usually signed once per contributor, sometimes per-company. - Centralized record keeping. - Some developers object on principle (especially to unilateral relicensing clauses). **DCO** — used by Linux, Git, Docker, Kubernetes, many community-led projects. - **Does not grant additional rights** — purely an attestation of provenance. - Signed per-commit (via `-s` flag). - No central registry — it's in the git history. - Lower friction; preferred by many individual contributors. Both approaches are legally reasonable. The choice is cultural and governance-structure-dependent. ## Projects using DCO - Linux kernel - Git - Docker / Moby - Kubernetes - Containerd - Prometheus - GitLab - Many Linux Foundation projects - Nextcloud, Chef, Fedora, OpenZFS (partial), and hundreds more ## Enforcement in practice - **GitHub DCO check app** — CI integration that blocks PRs without signed commits. - **GitLab**: built-in DCO enforcement option. - **Kernel mailing list**: maintainers reject patches without Signed-off-by. ## DCO and AI-assisted code The 2026 Linux Kernel AI Coding Assistants Policy (2026) explicitly states: **AI agents cannot add Signed-off-by tags.** The DCO requires a human with legal standing to make the attestation. An AI cannot 'certify I have the right to submit' because it has no legal personhood, cannot hold rights, and cannot be held accountable if the attestation is wrong. The human developer who uses AI assistance is the one who signs the DCO — and therefore the one who takes responsibility for ensuring the AI-assisted code doesn't embed copyright-infringing material from training data. An `Assisted-by` tag was recommended (but not mandated) to document AI assistance without conflating it with the human's certification. This is the cleanest legal framing so far for AI-assisted OSS contribution: the human is always the contributor of record; the AI is a tool they used. ## Why the DCO is elegant - Short enough to read in 60 seconds. - Doesn't require central records or lawyers. - Legally binding at the commit level rather than project level. - Distributed attestation — lives in the git history forever, cannot be altered. - No unilateral-relicensing clause to object to. - Assumes contributors are operating in good faith; catches the one who explicitly lies. ## Limitations - **Depends on truthful attestation** — doesn't actually prevent copyright infringement, just creates a paper trail if it happens. - **Doesn't address patent claims** explicitly (CLAs usually do). - **International enforceability** varies — US courts respect it, others untested at scale. - **Doesn't solve the AI provenance problem** — the DCO puts responsibility on the human, but the human often can't verify what's in the LLM's training data. ## Related - Linux Kernel AI Coding Assistants Policy (2026) — the current application of DCO reasoning to AI contributions. - Contributor License Agreement (CLA) — the alternative approach.