When a person writes a piece of software, they own the copyrights in that software by default, unless it is a "work for hire". In that case, their employer owns it, or those rights are conveyed to some other legal entity by a written agreement. Even if that person provides that source code with the implied intent to make it part of some existing software project or otherwise give it away (i.e. place it in the public domain), legal experts may differ as to whether that by itself is enough to allow the receiving project to modify and distribute the contribution along with the rest of the project. For some experts, contributions are implicitly offered under the same licensing terms as the code base to which the contribution is being made. Others prefer to have the owner of the copyright in new contributions explicitly state that they are providing the software (or a modification to an existing piece of software) to a project in accordance with some specific software license⁰ associated with the project. It is the process by which a person provides an (updated) contribution to an existing project that has an existing software license that serves as the focus of this article.

Until fairly recently, Contributor License Agreements (CLAs)^1,2 have been the industry standard way to accept such contributions. CLAs can be signed by individual contributors or by organizations (to cover all of its members). While CLAs have a number of advantages for a project from a legal standpoint (such as facilitating later re-licensing), they are unpopular with some developers and developer communities, and are seen by many as an impediment to accepting contributions^3,5.

To address the problems with CLAs and other similar approaches, the Linux Foundation introduced the Developer Certificate of Origin (DCO) in 2004⁶. The DCO is a lightweight approach where developers "sign" every Git commit with a Signed-off-by line in the commit message:

This is the commit message

Signed-off-by: First M. Last <first.last@someurl.org>

This "sign-off" implies that the developer is asserting the terms of the DCO⁷ which, as of Version 1.1, states:

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.

This Signed-of-by line can be added to the Git commit log automatically using the standard -s option with git commit -s (using information already registered with Git locally).

Some major projects are using the DCO with Git commit sign-offs for handling contributions, including the Linux Kernel⁸ and, more recently, the source code for GitLab itself ^3,4. In addition, the Linux Foundation's CII Best Practices Badge Program⁹ contains the Silver-level item:

• The project SHOULD have a legal mechanism where all developers of non-trivial amounts of project software assert that they are legally authorized to make these contributions. The most common and easily-implemented approach for doing this is by using a Developer Certificate of Origin (DCO)⁷, where users add "signed-off-by" in their commits and the project links to the DCO website. However, this MAY be implemented as a Contributor License Agreement (CLA), or other legal mechanism.¹⁰

A few issues must be considered when adopting the DCO for accepting contributions. First, since anyone can use any committer name and email address they want with a Git commit (e.g. using git commit --amend --author "<any-author>" and therefore impersonate someone else), greater assurance that the person signing off on the DCO is actually the author of the commit can be added by requiring commits to be GPG signed using the -S option with git commit -s -S¹¹. (However, requiring GPG signing of all commits adds a lot of extra overhead and complexity, which may be too much for many developers and, therefore, more limited usages of GPG signing are possible to provide some elevated assurances ¹². It is unclear if any major project requires GPG signing of all commits to assert the DCO.)

Second, for the DCO to be effective, every commit that contains a nontrivial contribution needs to contain the Signed-off-by line. Tools are available to assert that all commits in a GitHub Pull Request (PR) contain the Signed-off-by line¹³. (Note that tools to automate the signing of CLAs for GitHub PRs also exist if one wants to automate CLA signoffs as well¹⁴.)

In summary, using a Developer Certificate of Origin (DCO) is a lightweight legal approach to provide cover in accepting contributions. However, it does come at the cost of requiring every nontrivial commit from a Pull Request for a proposed contribution to be signed-off by an outside contributor (and the process to go back and fix unsigned commits can be quite cumbersome for some people with poor Git knowledge and skills, or depending on how those commits and branches were constructed). Therefore, for some developer communities, the upstream technical overhead and mechanics of applying the DCO may be more of an impediment to accepting outside contributions than the barriers to getting outside contributors or organizations to sign CLAs.

Disclaimer

This is not legal advice. Consult your own lawyer before any action that may have legal consequences. The article is based on U.S. copyright law; other countries may differ.

References

• ⁰An Introduction to Software Licensing
• ¹Contributor Agreements
• ²Contributor License Agreement
• ³GitLab: We're switching to a DCO for source code contributions
• ⁴GitLab: MEMO CLA vs DCO + License
• ⁵The power of open source: Why GitLab’s move to a Developer Certificate of Origin benefits the developer community
• ⁶CLA vs. DCO: What's the difference?
• ⁷Developer Certificate of Origin
• ⁸Linux Kernel Git Repository
• ⁹CII Best Practices
• ¹⁰CII Best Practices [dco]
• ¹¹Git Tools - Signing Your Work
• ¹²Developer Certificate of Origin versus Contributor License Agreements
• ¹³Github DCO App
• ¹⁴Handling CLAs and DCOs via GitHub Action