[linux-elitists] [firstname.lastname@example.org: SCO Suspends Distribution of Linux Pending Intellectual Property...]
Wed May 14 23:25:52 PDT 2003
On Thu, 15 May 2003, Karsten M. Self wrote:
> Sixth, the point that Don raises about possible infringement, plagiarism
> in the kernel source is a significant one. There's a strong question as
> to where culpability lies. In scenario evaluation when I was helping
> manage a corporate free software development project, one stipulation
> was that the contributor who knowingly and willfully submitted work
> under false pretenses was committing a fraud. In that scenario,
> contributor agreements specifically stated this. Linus's code
> management practices are significantly more lax, and might put him at
> personal risk. If IBM has facilitated transfer of code or secrets
> gained in confidence from SCO, there is a significant issue. Frankly,
> the (d)evolution of this case, the shifting and vague claims by SCO, and
> decades of cross-contamination between all flavors of Unix, makes this
> a tenuous assertion.
I've worked on the kernel since 1991, and I can tell you that this issue
was addressed on the linux kernel mailing list as early as 1992, I
believe. The only sources of kernel code that I am aware of was the BSD
unencumbered sources, the Bach book, and Minix itself. The posts were
very explicit as to the risks to Linux itself if encumbered or proprietary
code were to find its way into the Linux kernel. Seeing as to how SCO is
keeping their cards close to their vest on this deal, I would think they
have a very poor case, considering your other points. The comment by SCO
that they didn't want to jeopardize their case, suggesting that offending
code would be removed from the kernel source base if SCO were to show
their hand is asinine.
> Too, in copyright, independent creation is a defense (unlike, say,
> patent law). Copyright forbids direct copying, it doesn't proscribe
> independent arrival at a similar engineering conclusion. For SCO to
> prove its case, verbatim similarities are not sufficient, a plausible
> chain of derivation is necessary.
And there are lots of small functions in the kernel that could be written
in only one or two ways, so a casual inspection of 10 lines of code to do
X in two different code bases may look very similar in code structure,
because they are basically doing the same thing.
> I'll point out as others have that the risk of transfer in the other
> direction -- from GNU/Linux to a proprietary product -- seems rather
That's happened numerous times. Microsoft's even been caught with their
hand in that cookie jar a time or two.
More information about the linux-elitists