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](
https://www.clahub.com/), but it wasn't quite ready yet).
---
[Visit Topic](
https://discourse.ros.org/t/starting-to-enforce-developer-certificate-of-origin-dco-for-some-ros-2-repos/7420/3) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)