How strictly should I enforce DCO-signing for complete legal protection?

Question

The Developer Certificate of Origin protects the codebase from legal threat by requiring that each commit is signed, indicating that the contributor is authorised to make and license the commit (for example, if submitted while working for an employer).

To offer this protection, how strictly must this be adhered to? For example:

• an automated tool squashes a series of commits into one before merging it into the codebase
• a contributor makes a series of commits, but only signs the last one

Answer 1

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 concrete questions:

• If you rewrite history (e.g. squash or rebase commits), then you get a new commit. Any signatures that are part of the original commits will be lost. So if you want to be able to trace signatures exactly, you should prefer history-preserving operations such as merging.

• A git commit is immutable and references its parent commits, so the commit represents the complete history that led up to this state. So a git repository is a bit like a blockchain. Therefore, signing only the most recent commit on a branch implicitly signs the whole history up to and including that commit.

Answer 2

Seeing as the DCO is intended to mitigate legal threat, a per-commit policy technically maximises the mitigation. (But as pointed out by Amon, is practically irrelevant, as long as signatures are preserved.)

References:

• What additional benefits does the DCO provide?
• Case study: GitLab (points out that mitigating inter-corporation lawsuits is the goal)