News Stay informed about the latest enterprise technology news and product updates.

Torvalds: Code development process still 'fine'

The success and maturity of the Linux development process has led to the operating system becoming a mission-critical fixture inside enterprise server rooms and data centers worldwide. But the informal ways of contributing code to the kernel appear to be over. Developers can probably thank the SCO Group and its multi-billion dollar suits against IBM and commercial Linux users for that. SCO has spent the last 14 months raising the possibility of copyright infringement and intellectual property theft with regard to the millions of lines of code that make up the Linux kernel. To stem future allegations of impropriety, kernel author Linus Torvalds announced this week a new method of accurately tracking code contributions and making proper attribution. The Developer's Certificate of Origin (DCO) requires developers to sign off on their contributions before they are considered for inclusion in the kernel. In this e-mail exchange, Torvalds explains why this step is necessary.

Linus Torvalds
In the past, you've said the code development (and contribution) process is fine; that the openness of the process in fact shines a brighter light on suspicious code? Why the change of heart? What has changed to make something like the DCO a necessity?
I still think our code development is fine.

What the new process tries to do is to document the process, and in fact a large part of the idea is to just make it possible for us to say 'this is how we do things, and here is the path this patch took on its way to be integrated.'

I've jokingly called it the 'ISO9000' process -- it doesn't really change how you do things, but you have to document how you do things. And I say jokingly, because the DCO process is obviously meant to be anything but cumbersome (unlike the ISO9000 process), and is really designed to be as easy to integrate as possible.

Developer's Certificate of Origin 1.0

Below is the text of the Developer's Certificate of Origin from the Open Source Development Lab.

By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

Source: OSDL

Have you been hearing more concerns from code contributors regarding their work, and proper attribution?
No. The thing is, the actual developers see how things work, and in fact take all of this for granted. Our changelogs document who does things, so for example, a recent changelog has looked like this (this is just randomly selecting a pretty short one that shows what I try to explain):

ChangeSet@1.1737.1.87, 2004-05-22 22:09:49-07:00,
[PATCH] rmap 37 page_add_anon_rmap vma
From: Hugh Dickins
Silly final patch for anonmm rmap: change page_add_anon_rmap's mm arg to vma arg like anon_vma rmap, to smooth the transition between them.

Here there's two things you see: The changeset was sent to me by '' (who is [kernel maintainer] Andrew Morton), and the original author was Hugh Dickins. Additionally, what you don't see (but also gets logged) was that I was the person who 'committed' it to the source control system.

What we haven't had is a process -- a set of documented rules for how we do this. So sometimes it says 'From: Hugh Dickins,' and sometimes it would say 'Based on code by Hugh Dickins,' and usually when a patch went through multiple people we didn't record the people who just passed it on at all.

Which isn't a problem for developers, since the important part of the information is there, but it's a problem if we try to explain how we do things.

So the DCO is trying to formalize this documentation to the point where we can just say 'these are the rules we follow,' and that just ends up making a number of people more comfortable -- especially the kind of people who haven't actually been involved, so they've not seen the process in action. Is this going to make the process laborious? Will it dissuade some from contributing, or encourage more contributions?
I designed the system to be as minimally intrusive as possible, so no, I don't think it will cause any problems. Right now the discussion is all about making sure people know about the process, and have the option to comment on it and we can still change anything if people have issues with it. But I expect that once everybody is used to it, it's going to be just another line in the explanations that get passed around with the actual changes that has a specific format and that people update as they pass these changes around. Did you foresee this day coming?
In the sense that people have discussed having something like this for a while, yes. In the sense of 'did we foresee 12 years ago that we'd need to create such a documentation system,' obviously not. Obviously this applies only to code that is contributed going forward. Are you as confident about the integrity of the code in the kernel today as you were a year ago?
Yup. If there is one positive thing on the SCO lawsuit is that it has caused a lot of discussion -- most of it has obviously been just flamage and noise, but it sure as hell has made people more aware of the issue. How do you expect members of the community will react to the DCO?
So far it's been pretty positive, and a number of people have said 'that makes sense.' There's been worry about the exact details, and for example, sometimes the changes are just so trivial (i.e. one-liner obvious fixes, spelling errors etc), that there is a feeling that we should probably have a 'fast track' where we don't even worry about who does it, since it doesn't matter.

FEEDBACK: Do you think the DCO is necessary? Why or why not?
Send your feedback to the news team.

Dig Deeper on Linux servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.