Every project that accepts contributions from outside developers should have a legal mechanism in place that allows those contributions to become part of the main code base for further development and/or distribution, and avoids any possible future legal issues that could arise. The Developer Certificate of Origin with signoffs embedded into Git commits messages is becoming the preferred way to approach these circumstances, and is being adopted by important open source projects.
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 license0 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 contributions3,5.
To address the problems with CLAs and other similar approaches, the Linux Foundation introduced the Developer Certificate of Origin (DCO) in 20046.
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 <email@example.com>
This "sign-off" implies that the developer is asserting the terms of the DCO7 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.
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 Kernel8 and, more recently, the source code for GitLab itself 3,4. In addition, the Linux Foundation's CII Best Practices Badge Program9 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)7, 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.10
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 -S11.
(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 12.
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
Tools are available to assert that all commits in a GitHub Pull Request (PR) contain the
(Note that tools to automate the signing of CLAs for GitHub PRs also exist if one wants to automate CLA signoffs as well14.)
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.
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.
- 0An Introduction to Software Licensing
- 1Contributor Agreements
- 2Contributor License Agreement
- 3GitLab: We're switching to a DCO for source code contributions
- 4GitLab: MEMO CLA vs DCO + License
- 5The power of open source: Why GitLab’s move to a Developer Certificate of Origin benefits the developer community
- 6CLA vs. DCO: What's the difference?
- 7Developer Certificate of Origin
- 8Linux Kernel Git Repository
- 9CII Best Practices
- 10CII Best Practices [dco]
- 11Git Tools - Signing Your Work
- 12Developer Certificate of Origin versus Contributor License Agreements
- 13Github DCO App
- 14Handling CLAs and DCOs via GitHub Action