Slashdot Mirror
SCO Berates Linus' Approach To Kernel Contributions
Matthias_305 writes "The New York Times has an article about a new court document in which SCO critizes Linus Torvalds touting the 'inability and/or unwillingness of the Linux process manager, Linus Torvalds, to identify the intellectual property origins of contributed source code.' They claim to have got evidence from a conversation on the kernel mailing list in which Torvalds advocates programmers shouldn't care about patents. According to the article he stands by his view which is at least 'candid'." On a related note, BobDowling points to a proposal at The Inquirer ("Shutting down SCO's FUD machine") regarding SCO's claims. "SCO won't let people see the contested source code without signing an outrageous NDA but the article gives a mechanism for publishing appropriate MD5 checksums which allow code trees to be compared without anyone else seeing the code. This is offered as a means to locate the source of SCO's contested code. ... This mechanism gives a concrete procedure that SCO can be challenged to follow as part of the community's "put up or shut up" response. There would be no threat to SCO's claimed IPR."
'inability and/or unwillingness of the Linux process manager, Linus Torvalds, to identify the intellectual property origins of contributed source code.'
Seems they want to bully Linus to present the evidence for their cause they failed to present. This seems at least irrational to me.
SCO's approach seems to scare everyone that Linux is illegal dynamite, waiting to blow a hole through their purses. If they're really concerned and ethical, should they not go upfront and declare the violations in the code and be done with it?
Secondly, what if someone had poisoned the code over a period and SCO's blowing the whistle now? Something like the tcpdump files getting infected with a trojan?
If you keep throwing chairs, one day you'll break windows....
A point seems of major importance and I have not seen it addressed so far. In such a situation, how could SCO prove they did not steal a part of the linux kernel ? Is there an official organism in the US where companies can register source code for future legal problems ? If not, how is that supposed to work ? Experts would look around at SCO's and get convinced (or not) by the internal memos and CVS logs ? I know we are talking about the US legal system, but that's totally surrealistic to me ...
What I don't understand about the SCO/IBM case, is why IBM isn't taking action to immediately stop SCO from doing what they are doing. I am sure it must be affecting their AIX business, and I can't believe that there isn't a legal method they can use to take some kind of cease and desist out on SCO.
If such a law doesn't exist in the USA, does that mean Pepsi can say they have proof that Coke has dog poo in it, but they aren't going to show the proof? I doubt it somehow.
Furthermore, if SCO are doing these things just to manipulate their share price, and the allegations turn out to be baseless, surely that is fraud?
I have not seen any post from any SCO people standing up for or against anything lately. Can SCO management legally gag their employees during this litigation? Not trolling or stirring, just deafen by the silence.
The following describes the common sections found by the Inquirer reader (although I have only looked at the linux source files).
Of course, this assumes that the line numbers the Inquirer published are for the linux files and not the BSD files (why did they only publish one set?!?)
I think SCO is starting a patent war that may expose SW patents for what they are and the destructive capability they have - while not possessing many (any?) redeeming features.
And what's their winner argument in this case?
Linus is not checking all contributions against potential patents. Are you kidding me? So for every contribution he has to go search the patent database?
SCO and Software Patents, man if we could only hit 2 birds with one stone...
Computer Science is Applied Philosophy
Just to be clear, U.S. patents expire 20 years after filing. Patents, unlike copyrights, have been holding the line against term expansion pretty well over the years. Copyrights (though theoretically limited to life of the author + about 70 years) keep getting extended so as to be effectively perpetual. Trademarks are yours as long as you use and protect them.
Also, there is _always_ an economic incentive to invent something better. If I invent a better mouse trap, people will buy it over your old-but-still-patented mousetrap.
A corporation and bunch of lawyers won't ever invent anything and shouldn't be allowed to own a patent
Some fields of research require a $5M or a $50M laboratory and a team of twenty. There are some inventions that will not and cannot be made with a chemistry set in someone's basement. (Of course, software generally is not such a field.)
the patents should be non-transferable and with a relatively short patent period.
We already have a relatively short patent period: 20 years. Formerly patented material continues to pour into the public domain every single week, unlike copyright.
Patents already have periodic maintenance fees that must be paid every few years during the 20-year term.
These fees increase in size in the later years and they are higher for large companies than for small ones. (Both notions that might help with the copyright problem.)
Non-transferrability, now, there is an interesting idea. Let's talk about that.
"We reject as false the choice between our safety and our ideals." --The American President (20.1.2009)
It is based on something like this:
- Preprocess the code (replace all variables with the letter 'V', strip the comments, replace white space strings with a single character)
- Divide the result into fixed sized units of length k that overlap, each starting at a succeeding character. They call these k-grams
- Efficiently calculate a hash for each of these k-grams
- Divide the result into windows that contain a number of these k-grams
- Within each window, use a method of selecting a subset of these k-grams that does not depend on position, but rather on the k-gram itself, such as the minimum hash value within that window; if there are ties, select the right-most hash value within the window
- The result is the fingerprint of the code
- Any document with fingerprints in common has some code in common with the original source
Okay, that's a very rough idea of the process, but you might have some idea of it now. Check it out yourself if you're interested.The MD5 idea is a good idea, but I think it needs some refining.
//) [obviously additional rules for script files, maybe #]
- You want to get EVERY example, for potential manual review
- You want to avoid any problems with white space leading to different MD5s for "identical" code
- Doing a 5 line compare seems flawed as what if you compare lines 1-5 in A and B, but lines 1-5 in A match lines 2-6 in B
I therefore propose that:
1. before calculating any check sums, both files should be massaged into some common "base" format.
- Remove all white space inc. tabs and spaces
- Concatenate on one long line, but line break immediately after any semi-colon (;) or end-comment (*/) or immediately before begin comment (/* or
- With comments, line break at least every (say) 20 characters or if there was a line break in original file.
- Maintain some kind of map back from massaged file to Linux source (line 237 in massaged = line 40-42 in Linux source)
- In the massaged file, mark any line less than say 20 characters in a non-comment section as being potentially and probably too small to be copyrightable. This would eliminate stuff like i++; or #include . Matches for these should still show up in the overall results, but be considered as less important unless there are also lots of "more important" matches in the same source file as well.
2. Run both sets of sources thru this algorithm, and calculate two or more hashes for each line, say MD5 and some kind of CRC. If both sets of sources match for all the hashes, a match is found. This is to reduce number of false positives.
The NY Times article had a surprisingly insightful closing quote.
/. readers, but it's refreshing when a mainstream article makes this point explicit. Slowly, perhaps, the general (non-geek) public will understand open source software and the issues surrounding it.
Indeed, because Linux code is published publicly, it is easier to track what I.B.M. contributed to the operating system. But the issue, of course, is whether SCO's Unix license covered any of the code I.B.M. put into Linux.
Should the SCO suit turn up any offending code, the open nature of Linux â" and the many programmers working on it â" will ensure a quick solution, according to open- source software experts.
Now, that should be old news for
Phiwum's law: anyone that names an obvious law after himself and then puts it in his own sig is just pathetic.
I too have been explicitly told not to do patent searches when I come up with an idea, for exactly that reason.
I was also told explicitly that, partially because of the above, violating someone else's patents is essentially unavoidable. Therefore the purpose of patenting things is to have a bigger stick when you sit down to discuss any patent dispute.
So you have tons of engineers inventing things and deliberately remaining ignorant of whether anyone else has invented it, then trying to patent it for the sole purpose of ensuring that if it turns out to already be invented, that inventor will be violating some other patent that did get through.
Does that not sound completely fscked to anyone?
The enemies of Democracy are