Documenting kernel code provenance

He notes that the process of debunking these claims, while highly effective, has not been entirely fun. As a way of making life easier when the next SCO comes along, Linus is proposing a lightweight mechanism which would document how each patch finds its way into the kernel. In essence, this scheme would require each patch to contain at least one line like:

    Signed-off-by: Some kernel hacker <skh@some.host>

One such line would be added by each person who handles the patch on its way to the mainline kernel. Together, these lines would document the originator of the patch and the path it took before it was merged. Each developer, by "signing off" on the patch in this way, would indicate that he or she has the right to submit it to the kernel under a free license - either by virtue of having written the code, or by having obtained it from a source which allows this form of redistribution. Companies which require review of code contributed to external projects can designate a person who must sign off on patches before they go out.

This procedure is a far cry from, for example, the full-blown copyright assignment required from contributors to GNU projects. Contributions to the kernel will still require no physical, signed papers, no assignment of copyright, no indemnification, and no documented permission from the contributor's employer. The Free Software Foundation, with its assignment policy, is trying to set itself up as the owner and custodian of the GNU system, with clear title to the code, the ability to specify the license under which that code will be released and to enforce the terms of that license. The kernel hackers, instead, seem to feel that they can get by without such a custodian, wish to retain ownership of their code, and, as the netfilter team has demonstrated, they feel entirely capable of enforcing their own licenses.

The kernel system is, instead, aimed entirely at documentation. The next time somebody questions the legitimacy of code in the kernel, it would be nice to be able to point out, quickly, exactly where the code came from. In this way, perhaps, people can spend less time digging through ancient mail archives and more time developing. For this reason, suggestions varying from GPG-signing of patches to the (poorly received) idea of adopting an ISO-9000 process will probably not be implemented. Some tweaking will probably happen, but whatever system finally gets adopted will remain a simple, lightweight documentation mechanism.

While the new kernel contribution scheme is aimed at documenting future contributions, the just-launched Grokline project is trying to document the past. From the site:

The project has put together a basic Unix timeline, and is soliciting input from anybody who can help document where all this code came from.

Grokline will, without doubt, yield no end of interesting historical information. One can't help wondering, however, if the community isn't gearing up to fight last year's war. The SCO Group has done us a tremendous favor by showing that (1) finding copyright infringements in free software (and the Linux kernel in particular) really is hard, and (2) the community will unite with devastating effect against anybody who seeks to profit from baseless attacks on free software. It is hard to imagine another company wanting to be the next SCO. The next time a copyright claim is raised against free software, the claimants will be well advised to have their evidence in place from the beginning - and to be right.

If there is another SCO-scale war in our near future, it will probably not involve copyrights. It will be, instead, a patent fight. Unless it serves to establish prior art, documentation of the provenance of code will not be helpful in a patent case. It is also worth noting that the SCO case has forced a remarkable alignment of interests between many large, deep-pocketed companies and the broader free software community. That alignment of interests may well be absent in a patent battle. Next year's patent war may not be fought off as easily as this year's copyright and (formerly) trade secret suit. By all means, we should be documenting where our code comes from, and, in general, doing our best to ensure that it has been contributed legitimately. But it would be a mistake to believe that this documentation alone will be sufficient to defend us from all "intellectual property" charges.