login
Header Space

 
 

Developer's Certificate of Origin

Wireless Project Suggests 'Changes-licensed-under' Tag

September 28, 2007 - 2:44am
Submitted by Jeremy on September 28, 2007 - 2:44am.
Linux news

"Based on the new guidelines posted by the SFLC on 'Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers', specifically section 5, we are introducing a new tag for use with patches which deal with files licensed under permissive licenses (BSD, ISC) on Linux wireless in our larger GPL project, the Linux kernel," explained Luis Rodriguez in an email titled, "new 'Changes-licensed-under' tag introduced for Linux-wireless". The web pages linked in the email appear to be an official response by the SFLC regarding the recent BSD vs. GPL licensing controversy surrounding the Atheros wireless device driver. Luis continued:

"Although some developers have a practice of implying their patches for a permissive licensed file abides by the respective permissive license of the file being patched, and although some changes are obviously not copyrightable, we would like to 'err on the side of caution', take the advice from SFLC, and introduce Changes-licensed-under in order to help the BSD family reap benefits of our contributions to permissive licensed files."

There were only a few brief replies to Luis' email. Stephen Hemminger suggested a simpler solution, "no, please don't [go] down this legal rat hole. It would cause bullshit like people submitting dual licensed patches to the scheduler or GPL only patches to the ath5k or ACPI code. Instead, add a section to Documentation/SubmittingPatches that clearly states that all changes to a file are licensed under the same license as the original file." Krzysztof Halasa pointed out that this was already the case, quoting a line from the Developer's Certificate of Origin contained in the SubmittingPatches file which says, "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".

Linux: 2.6.12 Available, The First Git Release

June 18, 2005 - 1:07pm
Submitted by Jeremy on June 18, 2005 - 1:07pm.
Linux

Nearly three and a half months since the last stable release, Linus Torvalds announced the availability of version 2.6.12 of the Linux Kernel. He notes that the changes since -rc6 are minimal, "as you can see from the appended diffstat, most of the things are pretty small (ie it looks like a long list, and then you look at the diffstat and realize that most of the changes end up being just a line or two)." He adds, "one of the least important changes is still worth pointing out," talking about the recent update to the Developer's Certificate of Origin [story]. "The sign-off procedure was clarified to make it clear that the person signing off understands that the project - and thus the patch and the sign-off itself, of course - is public and will be archived."

This is the first stable release of the Linux kernel since the source code was moved out of BitKeeper in early April of 2005 [story]. 2.6.12-rc3, released in late April, was the first release candidate kernel managed by Git [story], thus Linus' git repository only holds changes since 2.6.12-rc2. Due to this fact, Linus did not release a complete changelog between 2.6.11 [story] and 2.6.12. He explains, "the full ChangeLog ended up missing, because I only have the history from 2.6.12-rc2 in my git archives, but if you want to, you can puzzle it together by taking the 2.6.12 changelog and merging it with the -rc1 and -rc2 logs in the testing directory." The latest version of the Linux kernel can be obtained directly from the kernel.org archive [story], or your nearest kernel archives mirror.

Linux: Clarifying the Developer's Certificate of Origin

June 14, 2005 - 8:00am
Submitted by Jeremy on June 14, 2005 - 8:00am.
Linux news

Following SCO's allegations regarding the origination of some source code files comprising the Linux Kernel, in May of 2004 Linux creator Linus Torvalds implemented a simple method for tracking how patches reach the source tree [story]. The simple system was further refined in the following months [story], and has become second nature to most kernel developers. However, a recent debate on the lkml illustrated the fact that nothing is simple, in this case with concerns that archiving someone else's email address in the "Signed-off-by:" line could violate the UK's Data Protection Act.

Alan Cox [interview] suggested that to solve for this concern, the DCO, or Developer's Certificate of Origin, be updated to explicitly give permission to include an email address when archiving patch information. Linus agreed, "yes, I'll update the SubmittingPatches [documentation file] to state explicitly that the sign-off is a public record." Alan pointed out that adding a comment to the file alone is not enough, but that the new wording needs to be part of the DCO, "you have to -actively- agree to the DCO to submit a change, and that is what makes it work (whether you put something in submitting patches or not that is more explanatory)." Again, Linus agreed, "I'll also run it past the OSDL lawyer, and if others were to run it past their lawyers, that would be good." Once approved, the update will become version 1.1 of the DCO.

Linux: Documenting How Patches Reach The Kernel

May 23, 2004 - 9:34am
Submitted by Jeremy on May 23, 2004 - 9:34am.
Linux news

Linux creator Linus Torvalds began a recent email, "this is a request for discussion.." describing a method of tracking how patches find their way into the Linux kernel. The incentive for this change in process was made clear:

"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."

He notes that though people have proven to be quite good at debunking these claims, the effort has been tedious. "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." Read on for Linus' complete description of how this process would work.

speck-geostationary