Slashdot Mirror
Settling SCOres
Israel Pattison writes "The Inquirer is reporting that someone in Germany is claiming to have viewed the SCO-alleged infringing Linux source code without having to sign a NDA. The person gives details about the code that was presented, but the translation-by-software is difficult to follow." The story also includes a link to a human translation; maybe some Slashdot reader can do better. Also in the news is a story about a kernel developer getting uppity with SCO, as well he might.
Now, I haven't seen the code, but the way it's described sounds to me like SCO may have grafted comments from the Linux source onto the SysV code. Comments being as unique and "fingerprinty" as they can be, this might have seemed like a good plan for making the code look like it came from SysV. The litmus test may be the origin of the comments, especially the jokes. I know if someone ripped off my joke, I'd for SURE let people know. . .
You are not the customer.
Could someone who knows the fellow ask him to select a version of Linux and indicate the actual filenames/line numbers where the code is alleged to be "the same?" The question here is "where did the code actually come from." To answer that, its first necessary to know precisely the code at issue.
From there, I would imagine that Linus has extensive records on where particular kernel submissions came from. That leads to affidavits to the effect that the code was an original work, or its replacement with code which in fact is an original work. Either of which solves the problem.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I am not a lawyer (get this out the way first), but my opinion of some highly relevant issues:
According to McBride's public statements, SCO view all the *nix variants as derivatives of their stuff. If anybody is interested enough to discuss this, but doesn't remember, I'll locate the news links and post them.
However as far as IBM is concerned: IBM are fully authorized in their contract to create derivatives of *nix - use any methods in the source - sublicense it as they choose - and what's more the contract says IBM own any derivative products that they create. The only proviso appears to be IBM should not copy code or whatever associated paperwork came with it (copying ideas and methods is explicitly allowed).
Furthermore, it actually explicitly says this on SCO's own web site, and as part of SCO's evidence. Go, for example, to top of page 2: http://www.sco.com/scosource/ExhibitC.qxd.pdf
So now, I think, we have yet another problem with SCO's case (aside from GPL issue, ATT v BSD issue, whether code was copied from or to SCO, whether SCO have the copyrights, whether anything in *nix is a trade secret given it's history, BSD contamination in *nix history undermining any copyright claim to entire *nix source, etc): Namely IBM are allowed to do more or less whatever they like in and with derivative UNIX products, explicitly stated in the contracts with ATT (which SCO inherited).
What's interesting is that the scheduler seems one of the least likely places for such code-pollution to occur -- as one of the most central parts of the kernel, it's also one of the most scrutinized and well understood by many people.
I'm also under the impression that the `traditional' linux scheduler (before the rewrite by Ingo Molnar in 2.5) is one of the oldest parts of linux, predating any involvement by IBM or any other large company with access to SCO source. [but this is just my impression from reading the LKML, not based on any research!]
Because the mechanisms involved are fairly implementation-specific, it's also very unlikely that anyone could just copy a few random functions from SCO, unless they were very generic. Since SCO is by all accounts very old and crufty, it's unlikely you'd even want to.
By far the most likely place for copied code is in obscure device drivers that no one really looks at or understands very well besides the original author.
Of course what we really want to hear is the name of these functions! C'mon non-NDA guy, cough 'em up!
We live, as we dream -- alone....
I found the second link (re: kernel developer getting uppity with SCO) to be much more interesting. He claims to be the author (or significant modifier) of code which SCO purports to be in violation. His remark in short is "The violation is yours, 'cause I wrote the code". In a challenge to SCO, he's threatening to sue SCO unless they remove the paticular code sections from their list of copyright violations.
This may be one of the ways to put chinks in SCOs armor. Get other Linux kernel developers to compare what they've written against corresponding sections of OpenLinux. Then note SCO's violations.
As the author of the article stated himself:
:)
As long as there are no original sources available where nothing is altered or deleted - especially the dates - and as long as SCO does not give any evidence that the sources under scrutiny are unaltered, all there allegations are simply said bullshit.
I think at least in Germany they can be sued for misuse of the court and up to now they can be sued for damaging IBM and everybody who sells and supports LINUX.
Well - let us sue them into oblivion
CU
1) We have no function names, no file names, not even a precise description of what code or comments. Now, true, this guy says he was shown PAGES of code - NOT files, but Xerox copies - and that most of the Linux code was from Linux mailing list posts. Still, he can't write down (or remember, if he was not allowed to write notes) function names or specific comments? Something fishy, there.
2) He says some of the comments are identical but the code next to them ISN'T. This makes no sense unless SCO manipulated the comments. But why would SCO place identical comments next to non-identical code? Isn't that an OBVIOUS fake? Why would SCO do an OBVIOUS fake? Are they that stupid? Or was it an attempt to show fake code to analysts that will NOT be shown to the court - in other words, a publicity stunt?
3) This story doesn't resolve anything or even contribute to anything given its omissions and ambiguity.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Since a process scheduler is such a well studied piece of Computer Science theory, it might be that the code in both Linux and SCO's Unix is derived from the same published, academic source.
Something like an example from an Operating Systems 101 textbook... The natural starting place to write something like that. Both author's could've tossed in explanation from the same original source matter.
Also, the scheduler is part of what makes Unix what it is- a multitasking, process-switched operating system. If several people want to implement that feature, they'll all have a very similar thought pattern, and converge towards a similar solution.
I just use the old traditional car analogy when I try to explain it to people.
Here 'tis:
I make alternators, you make engines, leroy over there makes wheels, bubba makes frames and bodies and etc. Now we could all sit around and try to sell this stuff to each other with all sorts of schemes and deals and middlemen and whatnot, or we could all just cooperate completely and share a part with each other and all of us wind up with a pretty cool and snazzy complete car at very little cost to anyone. Then we *all* have our own good car to go drive to "real work" in. And whenever I build a newer better alternator I chip it in, and so does the engine guy, and so on. We do this forever, we are always driving a new car for real reasonable and not much hassle. And once in awhile someone totally new joins our car co-op group, like the new guy this week we added has a really nice car sound system we all get to add to our cars. Cool beans. Fat city.
...that some of SCO's allegations are certainly wrong in detail, and that certain specific code sections (like the scheduler) are under fire.
Now if someone can recall some of the strings that they saw and grep the kernel for them we can probably have a little chapter-and-verse from which to answer some of SCO's whining directly.
We have made progress against this stupidity, even if it's not as rapid or dramatic as you'd hoped. It'll be interesting to see how the threat of a countersuit impacts SCO's shares when the less technical sites pick it up.
Got time? Spend some of it coding or testing
Many of the comments in the Linux kernel are from the posix specification which is available on the internet. http://www.opengroup.org/onlinepubs/007904975/
It makes a lot of sense for a developer to copy the specification as comments and fill it up with implementation details. That's the way I would do it! That would explain why comments are the same and code is different.
"Fighting terrorists with millitary might is like killing a mosquitor on your Dad's forehead with a rifle."