Safeguard
Compliance•

Developer Certificate of Origin: what a sign-off certifies

The Developer Certificate of Origin is four statements a contributor certifies with a sign-off. Here is what each one means and how it differs from a CLA.

Safeguard Security Team
3 min read

The Developer Certificate of Origin 1.1 is a short text with four points. When a contributor signs off a change, they certify that they wrote it or have the right to submit it under the project's license, and that they understand the contribution becomes part of a public record.

The four points

In plain words, version 1.1 says:

  • (a) You created the contribution entirely or partly yourself, and you have the right to submit it under the open source license named in the file.
  • (b) The contribution builds on earlier work that you believe is covered by a suitable open source license, and you may submit it with your changes under that same license unless you are permitted to use a different one.
  • (c) Someone else gave you the contribution after certifying (a), (b) or (c), and you have not changed it.
  • (d) You understand the project and your contribution are public, a permanent record is kept including your personal information and sign-off, and it may be redistributed.

The text itself does not prescribe the format of the sign-off line. Projects that use it set their own convention in contributing guidelines.

What it protects

Point (a) and (b) are about provenance. If a project later finds that a contribution contained code copied from an incompatible source, the sign-off shows who made the claim. That helps the maintainers trace and fix the problem. It also nudges contributors to stop and think before pasting code from elsewhere.

Point (d) is about transparency. Contributors know their name and email will be in the history.

How it differs from a CLA

A contributor license agreement is a separate agreement, often signed once, that can grant additional rights to the project or its steward. The DCO is a statement attached to each contribution and grants nothing beyond what the license in the file already allows. Projects pick one or the other based on how they want to manage rights. For a closer look at agreements, see reviewing contributor license agreements.

If you are a company with staff who contribute

  1. Tell staff what the sign-off means before they use it.
  2. Confirm your employment terms allow contributions to the project, because point (a) requires the right to submit.
  3. Have a short approval path for contributions, especially for work done on company time.
  4. Remind staff not to paste code from other sources without checking its license.

Your contributors are also carrying your supply chain risk. See contributing to open source securely.

If you maintain a project

Decide whether you need the DCO, a CLA, or neither, and say so in CONTRIBUTING. Whatever you pick, keep the instructions short. Complex contribution steps add load to a maintainer who is already stretched, and they discourage the casual fixes that keep a project alive.

Safeguard's SBOM and dependency scanning help you see what your project pulls in, and you can try a free scan.

Quick check

Does a sign-off transfer copyright?

No. The text certifies the right to submit under the file's license. It does not assign copyright.

Is the DCO a legal contract with the project?

It is a certification by the contributor. Ask counsel how it applies to your situation.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.