Open Source Stack Exchange is a question and answer site for people organizing, marketing or licensing open source development projects. It only takes a minute to sign up.
Sign up to join this community
If my project has a lax license (like Expat/MIT), I can enforce "inbound=outbound" by requiring that contributors sign off their commits in order to acknowledge the Developer Certificate of Origin.
I've identified (to my own satisfaction) that contributions to an Apache or GPL-family project are automatically "inbound=outbound".
Is there any benefit to requiring DCO sign-offs on contributions to an Apache or GPL-family project?
"inbound=outbound" might not require any extra procedures. If a someone contributes to a project that is clearly under some license, you can assume in good faith that they have the right to publish this contribution and that they implicitly agree to the license. To remove any question of doubt for projects on their platform, the GitHub terms of service explicitly specify inbound=outbound as the default.
A Developer Certificate of Origin is not a license. It merely certifies that the contributor has the right to contribute a contribution. The DCO does not grant any extra rights that wouldn't already be granted. Instead, this creates a paper trail that protects the project. If the project is accused of infringement (e.g. because a contribution was provided without having the right to do so), the project can demonstrate that they exercised due diligence, and can name the source of each contribution.
Therefore: whether a DCO is needed does not depend on the project license, assuming there is an obvious license. A DCO is sensible for all projects that are at risk of being accused of copyright infringement. These are particularly larger projects with many contributors, or open-source projects that compete with proprietary offerings. A project may not want to implement a DCO because this extra bureaucracy turns off potential contributors, and signing a DCO could make pseudonymous contributions impossible. Maintaining records of the signed DCOs could make the project subject to privacy regulations such as the EU-GDPR.
Some projects have a DCO as part of their Contributor License Agreement (CLA) which does specify licensing terms (typically, a less restricted inbound license).
GitLab had MIT and Apache codebases both covered by a CLA. They switched to the DCO for both, citing ease-of-use and honouring contributor rights as the primary concern (as suggested by the Debian project). When evaluating the DCO, key features they required were:
The DCO would seem to cover [warranty of provenance], but doesn’t necessarily provide GitLab with standing to bring suit in the event of a breach... [but] the likelihood of GitLab bringing suit, or an individual contributor being able to defend a suit, is low. As for corporate contributors GitLab preserves its ability to enjoin the potential corporate defendant in a lawsuit if GitLab were ever to face litigation. (Quoted under fair use.)
Thus warranty of provenance to mitigate inter-corporation lawsuits is a distinguishing feature of the DCO.
References:
