SCO: Code Proof Analyzed, Linus Interviewed

Arker writes "Bruce Perens has now obtained a copy of the entire slide show from which the recently scrutinized SCO-related Linux code excerpts came, and has analyzed the remainder of the 'evidence' they presented there. Their other code exhibit turns out to have been the venerable Berkeley Packet Filter(!), and their revised line-counts are consistent with simply adding together all the lines of code that have been contributed by Unix licensees." Also, Iphtashu Fitz writes "A new interview with Linus Torvalds has been posted on eWeek.com. In it he slams SCO over the recently leaked source code. Among other things, he points out in the interview that some of the code in question has been removed from the 2.6 kernel ['because developers complained about how "ugly" it was'] before SCO even started complaining."

Comments

Mirror

[inertia187]

Man, the site's already slow even though it's "slashdot effect ready" (har). Here's a couple mirrors:

• Link 2
  
• Link 3
  

Re:Mirror

[Saint Aardvark]

And another:

http://saintaardvarkthecarpeted.com/perens/SCOSlid eShow.html

I hate to say it, but the rebuttal article has

[thammoud]

misinformation. For example,

"SCO's legal theory fails, because they ignore the fact that if a work doesn't contain some portion of SCO's copyrighted code, it is not a derived work. This is especially glaring on slide 20, in which SCO claims ownership of JFS, IBM's Journaling File System. The version of JFS used in Linux was originally developed for the OS/2 operating system"

JFS actually came from AIX to OS/2 and not the other way around. Do a google search on "JFS OS/2 AIX" and you can confirm this. e.g

http://freshmeat.net/projects/jfs/?topic_id=142

Tarek

Re:I hate to say it, but the rebuttal article has

[Arker]

IIRC, it was originally developed for AIX, yes, but the OS/2 version was not a port, it was a clean room implementation from the spec sheet instead. And it was the OS/2 code that was the basis for the Linux port. So, in fact, the article is correct.

Re:I hate to say it, but the rebuttal article has

[sjbcfh]

JFS actually came from AIX to OS/2 and not the other way around. Do a google search on "JFS OS/2 AIX" and you can confirm this.

Or you can go straight to the source (no pun intended).

The relevant portion:

Historically, the JFS1 file system is very closely tied to the memory
manager of AIX. This design is typical of a closed-source operating
system, or a file system supporting only one operating system.

The new Journaled File System, on which the Linux port was based, was
first shipped in OS/2 Warp Server for eBusiness in April, 1999, after
several years of designing, coding, and testing. It also shipped with
OS/2 Warp Client in October, 2000. In parallel to this effort, some
of the JFS development team returned to the AIX Operating System
Development Group in 1997 and started to move this new JFS source base
to the AIX operating system. In May, 2001, a second journaled file
system, Enhanced Journaled File System (JFS2), was made available for
AIX 5L. In December of 1999, a snapshot of the original OS/2 JFS
source was taken and work was begun to port JFS to Linux.

Re:I hate to say it, but the rebuttal article has

[Arker]

Subject: Re: XFS vs. JFS
Subject: Re[2]: XFS vs. JFS
See also Q1 on the JFS FAQ from IBM.

Basically the original implementation was too tightly tied to specific AIX features. So a spec was written and given to the OS/2 team, who were completely separate from the AIX team, and they wrote a clean implementation avoiding such problems. This OS/2 implementation, then, was ported to both AIX and Linux. The original AIX implementation is dead, and has been for some time. All implementations in current use are based on the clean room work by the OS/2 team.

Call the FTC!

[Anonymous Coward]

Repeating this from the last SCO story, needs more exposure...

I just got off the phone with the FTC. If everyone calls and complains then the chances they will investigate SCO goes up. They look for patterns. In other words, if the majority of their calls are about SCO then they will investigate. It is time to take the Slashdot effect to the phones.

These are the key points to make:

-You did not purchase software from SCO
-The company that "produced" your software did not purchase it from SCO
-It was not marketed or packaged by SCO
-Despite this SCO is asking for $199 from home users (You) and $699 from business for 1 CPU

They will ask for your name, phone number, address etc. That is mostly to verify your identity and citizenship I think.

Here is the number:

1-877-382-4357 option 4

They are nice and listen well. The lady I talked to even took the time to get a better understanding of what Linux is. The best quote from her "You didn't purchase it from them and they want you to pay them? That sounds crazy."
--
Call FTC 1-877-382-4357 opt 4
-You didn't buy from SCO
-Vendor didn't either
-They want $199 ...

Here's some information that may help. They actually asked for this info:

The SCO Group
355 South 520 West
Suite 100
Lindon, Utah 84042

801-765-4999 phone

The guy I spoke with was actually somewhat familiar with what Linux is. One of his first questions was how this company got involved with me, which my answer was "Well, that's the problem. They didn't."

He eventually asked if SCO has contacted me personally with regard to this situation, which they have not. Don't lie to them. Be completely truthful. At the end of the call I got a reference number, and he said that if SCO does contact me personally, I should call back and let them know.

It was very easy to do, and took about 5 minutes of my time. The recording while I wated for the counselor to pick up the phone did say that the FTC does track trends in complaints. If we get enough people to complain, something will happen. Please, take a few minutes and call!

Re:Call the FTC!

[Anonymous Coward]

Or you can file a complaint online.

Re:Call the FTC!

[demachina]

> It might be a good idea to write to the Utah attorney general office as well.

I did this last week as well as the AG in NY, Eliot Spitzer and my home state AG. I received a reply from Utah yesterday. The gist of the response was they viewed it as a Federal copyright law issue and not in their domain, it was up to the courts to decide or congress to change the copyright laws. They suggested I contact a congressman.

I haven't given up yet since they overlooked the main issue in my inquiry, that SCO is demanding money from consumers under threat of legal action, which borders on extortion, and that they today have shown their infringement claims are, at least so far, false. I also pointed out the possibility Microsoft is using SCO as a proxy in an effort to exterminate one of the few remaining threats to their monopoly.

You missed one link, there....

[Anthony Boyd]

In Bruce's commentary, there was a link to an Infoworld article/interview with Bruce. It's pretty good. Bruce disputes SCO's claims, and the reporter didn't minimize/trivialize it. Coupled with the eWeek interview, I think we might stand a fighting chance in the court of public opinion.

"treated .. as"

[whoever57]

Such right to use includes the right to modify such SOFTWARE PRODUCT and to prepare derivative works based on such SOFTWARE PRODUCT, provided the resulting materials are treated hereunder as part of the original SOFTWARE PRODUCT.

Personally, I find this very subject to multiple interpretations. Nothing in the contract explicitly grants ownership of derivatives to ATT, so IBM could argue that even without the amendment that grants ownership of derivatives to IBM, nothing gives ownership of the derivatives to SCO. This might be important for code developed at Sequent.

Re:"treated .. as"

[rking]

I don't think there's any way that you could interpret that paragraph as granting ownership of derivatives to AT&T (or to SCO) and I don't think that even SCO are trying to claim that it does, at least not in their court claims (their PR contains all manner of gibberish).

What that paragraph does say is that the derivative works are covered by the same terms of that contract as the original software is. The contract requires that the original code is not disclosed to others. Thus, the derivatives also cannot be disclosed to others.

Remember, this case is about trade secrets and breach of contracts not about copyright violations. SCO are not claiming to own the copyright to the derivatives, they are claiming that IBM is contractually prohibited from publishing the code.

Their argument is still wrong because code that is linked to theirs is not derivative of theirs when separated out and containing none of theirs.

Re:Removed from the code

[Doomdark]

Even if the code wasn't in there at all, but they examined the original SCO code in order to create their own, that would still be in violation of their IP rights.

This is a common misunderstanding; thinking that there is something fundamentally wrong or illegal with reverse-engineering (be that examining source code or binaries). Like another poster pointed out, the only mechanism that could protect against "monkey see monkey do" would be trade secret registration.

For patents, it does not matter if you saw something and reimplemented it, or even created it yourself from the scratch. Copyright only protects against unauthorized copying, not against reimplementations.

The whole clean-room reimplementation idea was an overkill created by Compaq lawyers, when they were cloning IBM PC. They wanted to be 150% sure everything was legal, since they were dealing with a high-tech behemoth, with ample resources to use on lawyering. Doing clean-room development is plenty good for avoiding potential trouble, but it is not a requirement of any sort (more like a sterilized man using a condom).

See The Tanenbaum-Torvalds Debate

[polished look 2]

The Tanenbaum-Torvalds Debate

Re:I think we speak for all of us:

[Daniel Phillips]

They're saying that the jump from 2.2 to 2.6 an "Improbable Linux Development Path". For me, a non-kernel hacker, can someone explain why this particular point isn't true? Or do you have to pull from many examples in order to prove otherwise?

I agree it's improbable, but that doesn't change the fact that it happened, and we did it ourselves. The big lie is that it happened by incorporating SCO's code or ideas. I know that's ridiculous, because I was there for almost the whole period in question, working on my little parts of the kernel, but also watching others work on theirs, talking with them, seeing the ideas develop and patches take shape. In fact, this stuff is all in the public record, it's in the linux kernel mailing list archives, particularly the work on SMP and NUMA.

Re:Linus Pulls no Punches

[Error27]

IBM has four patent claims to cover SCO's four most important products. IBM chose the four patents out of hundreds of possible patents that SCO infringes on. The patents they chose are meant to serve as a warning.

• IBM has patent on a compression technique that SCI uses everywhere and so it will take months and months to remove.
• IBM patented a tiny feature in an email program from an operating system that is distributed with hundreds of programs. All the programs probably infringe on IBM patents.
• IBM has the patent for the start menu... And everything else as well.
• IBM owns the patent for the whole idea behind SCO's clusterring software, and legally they can shut SCO down.

The idea is it only takes four patent to shut SCO down and IBM can find more if it has to.