ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Starting to enforce Developer Certificate of Origin (DCO) for (some) ROS 2 repos


With the Crystal release being out of the door we will follow up on the previously mentioned goal to enforcement a Developer Certificate of Origin (DCO) on contributions to core ROS 2 repositories [1]. We will use the following GitHub App to automate the check:

After having done some testing with dummy repositories we will enable this for actually used repositories. We will start with a few (from two different orgs, repos with frequent contributions) and will add more repositories over time if we are confident that the process works well:

In the beginning we won’t require passing the DCO check in order to give us the freedom to merge already existing and reviewed PRs. But in the near future it will be mandatory so please consider reading about how to sign your commits of future contributions: adding the Signed-off-by line to your commits now.

You can do either of the following:

  • invoke git commit with -s / --signoff to automatically add this line to your commit message
  • manually add a the line to each commit message, e.g. Signed-off-by: Your Name Developer <>
  • create an alias in .gitconfig to append -s to each git commit invocation
  • create a commit.template which contains the Signed-off-by line to pre-populate interactive commit messages



ROS TSC Meeting Notes 2019-01-17

In the linked post @gerkey doesn’t give a rationale, it contains merely a statement of intent:

We’re also working on updates to developer policies, such as enforcement of a Developer Certificate of Origin (DCO) on contributions to core ROS 2 repositories.

In ROS 2 TSC Meeting Minutes: July 24th, 2018 it’s also only stated that DCO will be required. ROS 2 TSC Meeting Minutes: September 6th, 2018 states “Explain rationale, say that we’ll take comments now and at ROSCon”.

It’s probably obvious, but could you perhaps provide some insight into the reasoning behind this decision?

I’ve probably missed it, so if there was any discussion at ROSCon about enforcing DCOs, my apologies.



In short: (i) we decided to enforce a contribution mechanism because of strong support for doing so among industry partners generally over several years and among the ROS 2 TSC membership more specifically and recently; and (ii) we chose the DCO because it’s become a commonly accepted practice for open source projects. As compared to other mechanisms (e.g., a CLA), the DCO is the lightest-weight tool that appears to convince a large fraction of the likely corporate stakeholders (and more importantly, their respective lawyers) that it’s OK to use the output from and contribute to a project.

The goal here is to do the right thing with respect to preventing inappropriate contributions while having a minimal impact on the development workflow. FWIW we almost enabled a CLA for ROS 2 a few years back, but the tools weren’t sufficient at the time to avoid having a bunch of manual steps; e.g., requiring people with commit rights to be checking github usernames against a spreadsheet before merging their PRs (we tried CLAHub, but it wasn’t quite ready yet).



Are there any plans to move to a CLA in the future? It would give the ROS TSC more freedom over the code than the DCO appears to, although I imagine that would be negatively perceived by some people.



No, not at the moment nothing in that direction is planned or envisioned.



I’m not disagreeing with that decision, but I’m interested in knowing the basis for that envision. Brian’s explanation seems mainly to pertain to the state of things a few years ago and starting simple.



In the mean time we have enabled the DCO check to a number of repositories (see for the complete list) and added a note about the DCO to the file to each of these repositories.

Happy signing off :heavy_check_mark:

1 Like

ROS 2 TSC Meeting Minutes: 2019-03-21