Labels

Embracing the Developer Certificate of Origin

APPROVED Rubber Stamp 

 Streamlining and embracing the Developer Certificate of Origin (DCO) in the Free and Open Source (FOSS) community has huge value and in order to help foster embracing the DCO more easily by any FOSS project, regardless of its license, the Linux Foundation has placed the DCO on a standalone project page which you can use as reference or take it to embrace it on your own project. If you are a maintainer of a FOSS project I highly encourage your to consider evaluating the use of the DCO in your own project. Embracing it should consist on simply referring to it through your documentation on how people should contribute, or simply copy and pasting it into your own project and using. I provide a simple example through the CRDA project. Through the rest of this post I will review why this document is important and how we ended up making the DCO a standalone project that the rest of the community can benefit from.

Good FOSS software projects receive tons of contributions from developers all over the world. As FOSS evolves at times we face to stand tricky questions, speculation and at times silly claims over how we evolve software. For very large projects this can get even more complex. The Free Software Foundation (FSF) thought of this long ago and their preferred practice was to request developers provide copyright assignment to the FSF. Linux ended up creating a document and light weight process which has also proven to be highly appreciated by the industry for use when evaluating inbound contributions to a FOSS project. The document is called the Developer Certificate of Origin (DCO), it was written and evolved to enable to give developers and maintainers explicit guidelines of the requirements to contribute and consumers of Linux some form of legal assurance of the provenance and integrity of contributions. The DCO is now a document cherished and appreciated by many attorneys, and it has slowly been being embraced by more large FOSS projects. If a project has seen issues with getting their developers to jump on board with a Contribution License Agreements (CLA) it should consider this more lightweight process.

Lets review some of the tough questions a FOSS project may face. How do we get some form of assurance that folks contributing were the ones doing the development ? Are we getting any written consent that folks contributing are legally entitled to do ? In a distributed development environment what is a subsystem maintainer assuring me when they send me all the contributions they've collected ? FOSS contributions create public records with names attached, as laws over privacy evolve are we sure contributors are aware that they are waiving any privacy concerns over such contributions and that a public record will be made ? We may not necessarily have to prove all the above but if we could embrace a light weight procedure in order to provide some assurances would we be willing to embrace it ? How valuable would it be, what would it look like ?

Linux has had to face some of these questions, mainly because the claims SCO was making in 2003 now known as the SCO-Linux controversies and on May 23, 2004 Linus Torvalds decided to send out to the Linux community a Request For Discussion for considering embracing a Developer Certificate or Origin. The gist of it can be summarized in the following two paragraphs:
Some of you may have heard of this crazy company called SCO (aka "Smoking Crack Organization") who seem to have a hard time believing that open source works better than their five engineers do. They've apparently made a couple of outlandish claims about where our source code comes from, including claiming to own code that was clearly written by me over a decade ago."
So, to avoid these kinds of issues ten years from now, I'm suggesting that we put in more of a process to explicitly document not only where a patch comes from (which we do actually already document pretty well in the changelogs), but the path it came through.

The DCO started to be embraced by large projects, examples of that are any project embracing Gerrit, Android, OpenStack, LibreOffice, QT, but they all typically just referred to the Documentation in Linux. The reason the DCO became a standalone project was that referring to the Documentation in Linux is not exactly ideal, and some non GPLv2 projects wanted to embrace it and they expressed copyright concerns over it. On November 2012 I sent a request out to lkml to review if we could make the DCO a standalone document. That discussion lead to W. Trevor King to create a github tree with the original contributions to it alone through a signed-off-by git tree and a talk about the DCO at the April 2013 Linux Collaboration Summit in San Francisco (slides here), thanks to Bradley M. Kuhn for help with coordination. After followup advice from volunteered attorneys, in particular Richard Fontana, and a few folks from the Linux Foundation Technology Advisory Board (TAB) at the 2013 Linux Plumbers conference, it was decided that the community would surely stand to gain from this and we'd follow up with a release. The new standalone DCO project page closes these discussions and serves as a single point of reference that any FOSS project can use now. Thanks to the Linux Foundation for listening, and Greg KH for the last push.

If you've embraced the DCO or know of projects that have embraced it please send me a note at mcgrof@do-not-panic.com, I'll extend the list below for now. If you can send me a link to a reference to the project's documentation that refers to it that'd be great too.

Projects which embrace the DCO:
Labels:

Comments

Post a Comment

Popular Posts