7

"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 ...


6

The signed-off line does not indicate the author but who authorized the commit to enter the project's repository. It has primarily nothing to do with who committed or pushed the commit. Commonly it's used to indicate who did the review (that doesn't mean being the author, just the person who allows the commit to enter the repo or endorse the pull request.) ...


5

Some projects such as Linux ask for the DCO to be signed in order to do due diligence, and ultimately to protect downstream users. The DCO does not forbid projects from establishing individual processes, such as requiring that it's clearly the committer who has signed off on the commit and to have a clear means of contact later. This has nothing to do with ...


4

First, consider why you want to mandate signed commits. They are not a best practice for most open-source projects because they represent a significant barrier to entry – you need to set up GPG, manage a key-ring, and exchange public keys so that they can be verified. Signed commits have most value when the software is security-sensitive, so you want to be ...


3

Case study: GitLab 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: Patent protection (already covered by Apache 2.0) Inbound=outbound (...


2

There is no complete legal protection. DCOs make it easy to prove that all contributors have agreed to the licensing conditions. But if the contributors do not actually follow the conditions in the DCO, you might still get code without a proper license. With respect to these risks, it is mostly irrelevant how often you sign your commits. Regarding your ...


Only top voted, non community-wiki answers of a minimum length are eligible