DCO vs CLA: Managing Contribution Agreements in Open Source¶

When you accept code contributions to an open-source project, you are entering a legal relationship with every contributor. Who owns the code? Do you have the right to relicense it? What happens if a contributor later claims you do not have permission to use their work? Two mechanisms exist to answer those questions before they become problems: the Contributor License Agreement (CLA) and the Developer Certificate of Origin (DCO).

This post takes a thorough look at both: what they are, how they work, the tradeoffs involved, and the tooling available to automate enforcement on GitHub.

Disclaimer

This post is for informational purposes only and does not constitute legal advice. The author is not a lawyer. The information reflects a general understanding of open-source contribution mechanisms and is intended to help you understand the options available. Before adopting a CLA or making decisions with legal implications for your project or organization, consult a qualified attorney.

What Is a Contributor License Agreement (CLA)?¶

A Contributor License Agreement (CLA) is a legal document in which a contributor grants the project maintainer (or their organization) explicit rights to use their contribution. CLAs originated in the world of large open-source foundations and enterprise software companies, and they remain common in projects where a for-profit entity is the primary steward.

What a CLA Covers¶

A well-drafted CLA typically grants the following:

Copyright license: The contributor grants the project a broad, irrevocable, worldwide, royalty-free, perpetual license to reproduce, modify, distribute, and sublicense the contribution under any terms the project chooses.
Patent license: The contributor grants the project a license to any patents they hold that are necessarily infringed by the contribution.
Warranties and representations: The contributor attests that they have the right to grant those licenses (they authored the contribution, or they have appropriate permissions from their employer).

Some CLAs go further and include:

An assignment of copyright (full transfer rather than just a license)
Permission to relicense the project to a different open-source license
Permission to release the project under a proprietary license alongside the open-source one (dual licensing)

Types of CLAs¶

There are two standard forms.

Individual CLA (ICLA): Signed by a single contributor, covering their personal contributions. The contributor attests that they are the sole author and that no employer has a claim to the work.

Corporate CLA (CCLA): Signed by an authorized representative of a company, covering contributions made by that company's employees. The CCLA authorizes a list of individuals whose work-related contributions are covered.

Many projects require both: a CCLA at the organization level, plus individual acknowledgment for each contributor.

What the Grant Looks Like¶

The Apache Software Foundation (ASF) popularized the ICLA/CCLA model. The key grant in the Apache Individual CLA reads:

Subject to the terms and conditions of this Agreement, You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.

Google uses CLAs for most of its open-source projects. Microsoft requires them for contributions to projects like the .NET ecosystem.

How the CLA Process Works¶

The classic CLA workflow:

A contributor opens a pull request.
A bot (or manual check) determines whether the contributor has already signed the CLA.
If not, the bot posts a comment directing the contributor to a signing portal.
The contributor signs electronically, via DocuSign, GitHub OAuth, or a similar service.
The signature is recorded in a database or a GitHub gist.
The bot marks the CLA check as passed and the pull request can proceed.

What Is a Developer Certificate of Origin (DCO)?¶

The Developer Certificate of Origin (DCO) is a lightweight alternative that emerged from the Linux kernel community in 2004. Rather than requiring contributors to sign a separate legal document, the DCO asks contributors to certify with each commit that they have the right to submit the code.

The DCO v1.1 Text¶

The full text of the current DCO v1.1, published at developercertificate.org, is:

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 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
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

How It Works¶

The DCO is enforced through a Signed-off-by trailer in the commit message. Every commit submitted to a DCO-required project must include this line:

Signed-off-by: Ryan Johnson <[email protected]>

The name and email must match the commit author's identity. Git has built-in support for adding this trailer automatically with the --signoff (or -s) flag:

git commit --signoff -m "feat: add support for dark mode"

The resulting commit message looks like:

feat: add support for dark mode

Signed-off-by: Ryan Johnson <[email protected]>

Notable Examples¶

The DCO was created by the Linux Foundation and is used by:

The Linux kernel
The Git project itself
The Cloud Native Computing Foundation (CNCF) project family (Kubernetes, Prometheus, Envoy, and many others)
Many other projects sponsored by the Linux Foundation

DCO vs CLA: A Side-by-Side Comparison¶

Aspect	CLA	DCO
Legal mechanism	Separate signed agreement	Per-commit attestation in commit message
What it covers	Copyright license, patent license, warranties	Certification of origin and right to submit
Who acts	Contributor (and employer) sign once	Contributor attests in each commit
Legal weight	Contractual agreement	Conduct-based certification
Patent grant	Explicit in most CLAs	No explicit patent grant
Relicensing	Often permitted by CLA terms	Not permitted without additional agreement
Contributor friction	High: requires out-of-band signing	Low: a single `git commit -s` flag
Employer involvement	Required for corporate contributors	Not typically required
Enforcement tooling	CLA bots, signing portals	DCO bots, GitHub Actions
Projects using it	Apache, Google, Microsoft, Salesforce	Linux kernel, CNCF, Git

Pros and Cons¶

Contributor License Agreement¶

Advantages

Provides a formal, enforceable contractual agreement with each contributor.
Includes an explicit patent grant, reducing the risk of contributor patent claims.
Allows the project to relicense the codebase without revisiting every contributor.
Enables dual licensing: releasing the project under both an open-source license and a commercial license simultaneously.
Gives the company or foundation a strong legal basis for defending the project.
A signed CLA is harder to dispute than a per-commit attestation.

Disadvantages

Creates friction for new contributors: someone who wants to fix a typo must first complete a signing workflow.
Often alienates contributors who are uncomfortable with the breadth of rights granted.
Some developers view CLAs as a signal that the project may eventually go proprietary.
Corporate CLAs require HR and legal involvement at the contributing company, slowing down first contributions.
Maintaining signature records and ensuring CCLA coverage is current requires ongoing administrative work.
The Linux kernel community rejected CLAs in favor of the DCO, and some open-source advocates view CLAs as incompatible with collaborative community norms.

Developer Certificate of Origin¶

Advantages

Zero additional friction: git commit -s is all that is required.
Contributors retain full copyright in their work: they are certifying that they have the right to submit it, not transferring any rights.
No out-of-band signing portal, no accounts, no email confirmation.
Widely understood in the Linux kernel and CNCF communities.
Easy to automate enforcement with lightweight, open tooling.
The DCO text is short, plain-language, and easy for any contributor to read.

Disadvantages

Provides no patent grant: if a contributor holds patents covering their contribution, the DCO does not obligate them to license those patents to the project.
Does not permit relicensing: if you want to change the project's license later, the DCO does not authorize that change.
Enforcement is conduct-based, not contractual. This is generally sufficient for community projects but may not satisfy enterprise legal requirements.
Squashing commits during a pull request merge can drop the Signed-off-by trailer. Maintainers must handle this carefully (see Rebase. Squash. Merge. Repeat.).
No mechanism to confirm that a corporate contributor's employer approves the contribution.

Decision Points: Which Should You Choose?¶

Neither mechanism is universally correct. The right choice depends on the project's purpose, governance structure, and legal requirements.

Choose a CLA When¶

You need the ability to relicense. If there is any chance you will ever change the project's license (moving from Apache 2.0 to a more restrictive license, or releasing a commercial edition), a CLA is the only mechanism that grants you that right without going back to every contributor individually.

Explicit patent grants are required. Enterprise environments where patent risk is a primary concern, and foundation-managed projects where contributors may hold relevant patents, benefit from the explicit patent grants that a CLA includes.

You operate under a business model that requires a commercial edition. Dual-licensing requires the ability to license contributions under proprietary terms, which only a CLA (or full copyright assignment) provides.

Your organization's legal team requires it. Some corporate legal departments will not approve contributions to projects without a CLA on file. If your team is on the receiving end of enterprise contributions, a CLA may be the only path forward.

Choose a DCO When¶

Minimizing contributor friction is a priority. Community projects with many casual contributors benefit significantly from removing the signing step. The difference between "one commit flag" and "complete this form and wait for approval" is measurable in contributor retention.

Your project is governed by a neutral foundation. CNCF projects use the DCO because the foundation's governance model does not require relicensing rights or commercial exploitation of contributions.

You follow Linux kernel community norms. If your project is part of the Linux ecosystem or aims to attract kernel developers, the DCO is the expected mechanism.

The license is permissive and stable. If you are releasing under MIT or Apache 2.0 with no plans to relicense, the DCO provides sufficient coverage for most projects.

A Note on Copyleft Licenses¶

Projects using strong copyleft licenses such as GPL-3.0 have a different calculus. The GPL's copyleft provisions ensure that derivative works remain open, and the license grants downstream users broad rights. Some legal experts argue that strong copyleft projects need a CLA less urgently than permissive projects because the license itself provides structural protections. Others disagree. If your project uses a copyleft license, consulting legal counsel before deciding is especially worthwhile.

Tooling and Automation¶

Enforcement of either mechanism is straightforward with the right tooling. All of the options below integrate with GitHub's required status checks, which means a pull request cannot be merged until the check passes.

Probot DCO (GitHub App)¶

Probot DCO is a GitHub App that checks every commit in every pull request for a valid Signed-off-by trailer. When a commit is missing the trailer, the DCO check fails and the pull request is blocked from merging (assuming branch protection rules are configured).

Installation: Navigate to the Probot DCO GitHub App and install it on your account or organization. Select which repositories should be covered.

Optional configuration (.github/dco.yml):

allowRemediationCommits:
  individual: true  # allow a single remediation commit to cover prior commits in the PR
  organization: false

The default behavior requires every commit in the pull request to carry a valid Signed-off-by matching the author's email. The allowRemediationCommits.individual flag is useful during the initial rollout: it lets a contributor add a single signed commit at the end of a pull request to cover earlier commits that were made before the policy was in place.

Behavior: When all commits pass, the DCO check turns green. When any commit is missing a Signed-off-by, the bot posts a detailed comment identifying the specific commits that need remediation and how to fix them.

CLA Assistant (GitHub App)¶

CLA Assistant is a free GitHub App backed by SAP that manages the CLA signing workflow. It stores signed CLAs in a GitHub gist you own, records which GitHub users have signed, and posts a comment with a signing link on any pull request from an unsigned contributor.

Setup:

Sign in at cla-assistant.io with your GitHub account.
Create a gist containing your CLA text and copy its URL.
In CLA Assistant, configure the repositories or organization you want to protect and paste the gist URL.

Workflow:

A contributor opens a pull request.
CLA Assistant checks whether the contributor's GitHub username has previously signed.
If not, it posts a comment: "Please sign our CLA before we can accept this contribution."
The contributor clicks the link, reviews the CLA, and signs via GitHub OAuth.
The signature is stored in the configured gist.
CLA Assistant marks the check as passed.

EasyCLA (Linux Foundation)¶

EasyCLA is an enterprise-grade CLA management platform operated by the Linux Foundation. It is designed for projects that need:

Separate handling of individual CLAs and corporate CLAs
CCLA manager workflows (allowing a company's designated manager to approve contributors without the company signing again for each one)
Integration with Gerrit as well as GitHub
Audit trails suitable for foundation governance requirements

EasyCLA is used by Linux Foundation-hosted projects including OpenDaylight and OPNFV. It is more complex to configure than Probot DCO or CLA Assistant, but provides significantly more governance capabilities and is the right choice for foundation-stewarded projects with active enterprise contributors.

Practical DCO Setup¶

For step-by-step instructions on configuring Signed-off-by trailers, including prepare-commit-msg hooks (per-repository and global), using git commit -s, amending existing commits, and signing off with an interactive rebase, see Signing Your Git Commits: From Zero to Verified.

For documenting the requirement for contributors, see CONTRIBUTING.md: Writing Practical Contribution Guidelines for GitHub Repositories.

Summary¶

Both CLAs and DCOs solve the same fundamental problem: establishing that contributors have the right to submit their work and that the project has the right to use it. The difference is in scope, legal weight, and contributor friction.

	CLA	DCO
Friction	High	Low
Patent grant	Yes	No
Relicensing	Permitted	Not permitted
Legal weight	Contractual	Conduct-based
Best for	Commercial stewardship, dual licensing	Community projects, foundations

If you are building a community project with no commercial ambitions and no plans to relicense, the DCO is the simpler, lower-friction choice and the one that aligns with community expectations in the Linux and CNCF ecosystems.

If your project is stewarded by a company that intends to retain commercial rights, needs patent protection, or operates in a regulated industry where formal agreements are required, a CLA is the more appropriate choice despite the added friction.

When in doubt: DCO for community, CLA for company.