Slashdot Mirror
Usenix President - Linux Needs Better Paper Trail
Anonymous Coward writes "Usenix Association president Marshall Kirk McKusick is a veteran of BSD's intellectual property scuffle with AT&T in the 1990s, and he's got some thoughts and advice for the keepers of the Linux kernel going forward, commenting: 'There isn't a well-documented ownership trail with Linux. So, they have opened themselves up to a swamp of 'he said-she said' about where code came from'."
Dating back to when linux (the kernel) didn't even have a version number, code was always attributed to where it came from. I'm sure everyone is familiar with at least the changelog and its attributions. And of course actual comments with names and email addresses are all over the sourcecode itself.
/. in The Mysterious Future!) In the unlikely event of SCO ever saying which lines are thiers, we may end up with the interesting situation where a Caldera/SCO employee put them there - and get to slap SCO for abusing the legal system.
Now, Mr. McKusick might have a partial point. Its entirely possible that some gremlin over at Caldera took a bunch of SCO's 'Intelectual' Property and threw it into the main kernel under the GPL. In which case once the lines of code are actually identified, I suspect we will know who contributed them in under 20 minutes (10 minutes of which will be the article sitting on
In any event, I'd be willing to put money on Linux's source code source documentation beating SCO's out any day of the week.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
I wrote it, the whole thing. Linus was my roomate at the time, he took credit for all of it. I was the one that worked with Santa Claus and the tooth fairy to develop it, not Linus! Problem solved.
I boycott signatures
About a thousand geeks just simutaneously
wondered what the hell paper is.
Oddly enough, all of those thousand geeks could tell you what a scroll is.
There's nothing Intelligent about Intelligent Design.
Uh, this must be a typo. Linux developers arguing over the source for changes would always be; "he said-he said - then they got into a hissy fit hair-pulling fight"
Glad I could clear that up.
I guess, in the spirit of the GNU GPL, they'll have to come up with something, call it the FDA - a "Full Disclosure Agreement" that you *must* sign before contributing code, stating that you WILL tell everybody about the project and publish your code contribution, sort of a bizarro-world NDA.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Ok, so if I hypothetically had this idea to include a few lines into the kernel...I managed to slip a couple of lines of code into a "thank you" postcard to Linus eons ago. After reading it, he thought it was utter rubbish and tossed it away.
Actually, he was so pissed off about the whole stupidity that it motivated him to stay up an extra two hours hacking away. So technically, some of his code should be attributed to me, right?
Much like how some of that code should be credited to Pizza Hut, Starbucks, and a few different candy bars. So where's the documentation on that?
All the changelogs, the comments, and any other bits of documentation aren't enough. Where's the credit to the pizza delivery guy? He helped develop some of that code! Ingrates, I tell ya.
Slashdot: Process Improvements Wasn't Linus just talking about authors signing kernel submissions?
And maybe *you* should read RTFA (the McKusick interview)? He says explicitly that the paper trail was lacking "until recently" (by which he means the switch to BitKeeper). Maybe you should also learn some respect for people like McKusick who've been hacking free Unix since back when Linus was a kid. Among other things, this guy pretty much invented the modern Unix "fast file system", from which ext2 takes a lot of ideas. More recently, he's been responsible for softupdates in UFS (gaining the speed benefits of async mounts without compromising filesystem integrity in case of crashes).
The changelog is insufficient documentation. It contains vague attributions that something changed somewhere in the code. It isn't specific as to what lines of code changed. Later, when you go back and try to find where a set of lines came from, a changelog doesn't help much.
With a source code control system, you know that so and so added on such and such a date. You can then go to that person and ask them where they got it from if there's ever any question.
In the BSD world (I do a lot with FreeBSD), this has come in very handy when code disputes come up. Being able to talk to the actual people that inserted the code into FreeBSD has helped to clear up what otherwise might have been viewed as something improper.
I've tried to do similar things with versions of linux in the past, only to discover that I could, at best, find what version they came into the tree at, and who collected the patch and sent it to Linus. I wasn't able to track it further without searching public mailing lists for the information (with mixed results).
while you might believe that it will take 20 minutes to identify the code in question, my guess is that's overly optimistic, unless the code in question was contributed since bk. It usually takes me at least 5 minutes to find out where code comes from in FreeBSD when there's a question, and cvs annotate makes the process *MUCH* faster.
I'm not sure I'd disagree with your comments about SCO being able to come up with where the code came from relative to Linux.