Developer Certificate of Origin (DCO)

Many open source software projects—and virtually all of those hosted and supported by the LF—use the Developer Certificate of Origin, or DCO, as a requirement for receiving contributions.

What is the DCO?

The DCO is a short certification or affirmation, made by each individual developer at the time that they contribute code to a project. A contributor’s DCO sign-off statement is typically bundled together alongside the code contribution itself, in the same email or commit message.

There is exactly one DCO text, which is available at https://developercertificate.org, and is reproduced in full below:

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

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.

It’s helpful to understand what the DCO is not:

  • The DCO is not a contract. It is not an agreement between two different people or entities. Rather, it is a one-way statement made as an assertion by the individual contributor.

  • The DCO is not itself a license. It does not contain a grant of license rights.

Rather, the DCO is a certification or affirmation from the developer who is making the contribution. It is a statement by the developer, at the time they make the contribution, certifying that the text of the DCO applies to it.

What does the DCO mean?

When a contributor provides a DCO sign-off statement (described below), they certify that the DCO text applies to their contribution.

This means that either (a), (b), or (c) applies to their contribution. The contributor is not required to specify which of the three applies.

Items (a) and (b) each refer to the open source license that is “indicated in the file.” Item (c) applies when the contributor is passing along an unmodified contribution that was provided directly by someone else who themselves made a DCO sign-off, so it iteratively builds upon (a) and (b).

At its core, then, these options essentially involve the contributor asserting that they have the right to submit the contribution to the project under the open source license that is indicated in the file. (This is also another reason why it can be extremely important and helpful to specify the applicable license in each project source code and documentation file. SPDX short-form license IDs can help to make this process less painful.)

This is sometimes referred to an “inbound == outbound” model of licensing: The project community receives from the contributor the same scope of license rights as the project makes available to the rest of the world for that contribution.

Item (d) was added in v1.1 of the DCO text. It is separate from the (a), (b) and (c) assertions. Its purpose is to be explicitly clear that the record of the contribution, including any submitted personal information, is intended to be maintained perpetually as part of the public open source project’s records. This sign-off is very helpful in establishing the contributors’ reasonable expectations when it comes to participating in a public open source community, especially in light of regulations such as the EU’s General Data Protection Regulation (GDPR).

How does a project use the DCO?

Most LF-hosted projects’ charters specify that contributions are to be accompanied by a DCO sign-off within the project’s source code management system.

The standard method for submitting that sign-off is to include in each commit message a statement in the following format:

Signed-off-by: Your Name <your-email-address@example.com>

This is the traditional and standard method for communicating a DCO sign-off. It is so common that it is built into the command-line Git tool by using the -s argument to the git commit command. Tooling such as the GitHub DCO bot enables automated checking to ensure that submitted commits contain a DCO sign-off statement in this form before merging the PR.

That said, even if particular tooling expects this format, the DCO itself does not mandate that this specific statement be used to indicate certification of the DCO text. Projects have sometimes taken other approaches to record DCO sign-off assertions, in particular when making such an assertion in connection with past commits or non-standard activities such as relicensing (here is one example).

A separately-documented sign-off for commits that were originally made without sign-offs may also be useful when a contributor wants to certify the DCO while merging a collection of third-party commits that originated elsewhere without DCO sign-offs. In appropriate cases, a project using the DCO as its contribution framework may choose to set automated tooling to pass where the DCO assertion is separately documented within the repo.

Where did the DCO come from?

The Developer Certificate of Origin originated from the Linux kernel contributor community. During the SCO litigation in the early 2000s, SCO Group asserted (among other claims) that its code was incorporated into the Linux kernel sources without its permission. The kernel maintainers established the DCO text and the traditional “Signed-off-by” process with two primary goals:

  • make explicit the personal trust among contributors that they have the right to provide what they’re submitting; and

  • provide a documented chain for who submitted which patches.

Although this process was originally designed for the kernel developers’ email-driven contribution model, the same concepts can and do apply similarly to open source projects developed via other SCM systems.

Why would a project use the DCO?

Reasons to use the DCO as a contribution mechanism include:

  • it was designed by developers, is short, and minimizes legalese

  • it reflects mutual commitments and trust as a good participant in the community

  • it is lightweight and easy to implement, requiring a single line of text or a -s command-line flag per-commit

  • it doesn’t change from project to project, reducing friction and surprises

  • its “outbound == inbound” model reflects mutuality, as the project receives the same rights as anyone else (potentially limiting ability to relicense in the future)

What complications can arise from using the DCO?

Some complications can include:

  • for contributions made using an SCM’s user interface (e.g., GitHub web site) rather than command-line interface, contributors may need to remember to manually insert their Signed-off-by: statement

  • contributions of a pre-existing set of commits without DCO sign-offs may require alternate means of documenting the contributor’s own sign-off, together with an exception to the DCO bot tooling

Resources