decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal

User Functions



Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

UnitedLinux White Paper Shows SCO Thought JFS Came From AIX, Knew JFS was in UL - Updated
Tuesday, June 27 2006 @ 08:17 PM EDT

I am getting a lot of email, telling me that a certain UnitedLinux white paper that was on SCO's website has been removed, as of this afternoon. The paper reveals that SCO knew perfectly well back in 2002 that JFS had been put into the Linux kernel by IBM -- it says it was taken from AIX -- and that UnitedLinux participants, including SCO, not only knew it, they advertised it as a plus. Actually, it didn't come from AIX. It came from OS/2, according to this article from the time period. (There was a JFS in AIX also, apparently first, JFS1. No doubt SCO will claim methods and concepts leached into the OS/2 version, but according to that IBM page, the new JFS OS/2 version was the one put into Linux and then into AIX.) But the point is that SCO has claimed it didn't discover the high-end things like JFS were in the kernel until later. The paper shows they had to know, and further, they not only didn't care, they thought it was worth telling the world about.

Groklaw reported that SCO knew JFS was in UnitedLinux, quoting the whitepaper and providing a link, back in November of 2003 in an article we did debunking SCO's claims about the four main high-end things SCO was squawking about at the time, here, and I linked to that article twice in the last week or so in other articles. Today, it was also in part posted to the Yahoo! SCOX Message Board at 12:30 PM. By 2:32 PM, the whitepaper had disappeared from SCO's website.

So I happen to have the whitepaper, and since it is now among the "Disappearing Evidence," as I like to call it, I have taken a screenshot of that section, as well as the sections on I/O and hyperthreading, and the introduction, which tells us that all the participants in UnitedLinux used the same base software. As you will no doubt recall, SCO has maintained, in its Second Amended Complaint, beginning with paragraph 99, that IBM breached its contract by putting JFS from AIX into Linux.

Here's what we published in November of 2003, from the whitepaper, which is titled simply "UnitedLinux" and is dated November 7, 2002: (p. 13-15) [update: now here instead]: "The Journaled File System (JFS) is a full 64-bit file system. All of the appropriate file system structure fields are 64-bits in size. This allows JFS to support both large files and partitions. JFS was developed by IBM under the GPL license and is ported from its AIX systems. JFS provides a log-based, byte-level file system that was developed for transaction-oriented, high performance systems. Scalable and robust, its advantage over non-journaled file systems is its quick restart capability. JFS can restore a file system to a consistent state in a matter of seconds or minutes.”)

There isn't much use in making the link clickable now. I understand you get a Document Not Found page. I also notice that the Groklaw page from November 2003 is hard to read, because I didn't know how to do HTML back then. Groklaw members taught me bit by bit. So, I'll put the information after the graphics.

UPDATE: Thanks to Groklaw's readers, here's an even earlier version [PDF] of the paper, dated May of 2002, which as you can see is still on the Internet. And here's a paper all about SCO's version of UnitedLinux, still on IBM's site, written by John Terpstra in November of 2002. Terpstra was also a Caldera employee until around the time Darl McBride came aboard in July of 2002. Here's what he wrote about JFS and NUMA and all the rest of the features in the kernel SCO used in its version of UnitedLinux:

Linux kernel

The kernel is based on linux-2.4.19 with enterprise features enabled. The facilities and capabilities of the kernel include:

* File systems: Ext2, Ext3, JFS, Reiserfs, Logical Volume Manager (LVM); note that the kernel had support for POSIX ACLs as well as Extended Attributes
* I/O: raw I/O and asynchronous I/O
* Execution: Next Generation POSIX Threading (NGPT is a derivative of pThreads), HyperThreading
* Memory: NUMA, Memory Extension Technology (MXT), Large Memory Support (64GB physical RAM)
* SAN support: iSCSI
* Modern hardware support: ACPI
* SNMP/CIM support
* Protocols: IPv6

The UnitedLinux base system includes support for High Availability (HA).

As you can see, efficiency probably requires SCO to sue itself for all the high-end features it either put into Linux or distributed all over the world in its UL distro. Under the GPL. And now, for the proof of this November 2002 disappeared paper that used to be on SCO's website:



Republishing the November 2003 Groklaw article, "Cross Your Heart and Hope to Die, SCO?" in a more readable form -- how Groklaw got so popular, considering my flaws is a true mystery:

In its Supplemental Responses to IBM's Second Interrogatories and Second Requests for Documents, SCO gave this answer:

Insofar as this interrogatory seeks information as to whether plaintiff has ever distributed the code in question or otherwise made it available to the public, SCO has never authorized, approved or knowingly released any part of the subject code that contains or may contain its confidential and proprietary information and/or trade secrets for inclusion in any Linux kernel or as part of any Linux distribution.

Cross your heart and hope to die, SCO? Or cross your fingers behind your back? Let's see what the evidence shows.

SCO has specifically mentioned the following four as being code at issue in this case: JFS, NUMA, RCU, and SMP, and while it is conceivable that the "subject code" they are talking about in this response to IBM's interrogatory is referring to some other code, it seems reasonable to look at the code they have mentioned publicly. Actually, it's more than reasonable. It's our only choice, until they tell us exactly what code they are complaining about with specificity. Is it true that they never "authorized, approved or knowingly released" any of this code for inclusion in any Linux kernel or as part of any Linux distribution?

Let's start with JFS. In the case of JFS, they not only distributed Linux with JFS, one of Caldera's employees, Christoph Hellwig, contributed code to JFS, as Groklaw reported on July 18. Here is a snip from that article:

Here is an email in which he tells an inquirer how to contribute to JFS, including this tidbit: "I've run native sysvfs tools under linux, but as now that I'm Linux sysvfs maintainer I'm looking into implementing free versions of it. . . . The JFS/Linux core team has setup a CVS commitinfo, but currently I'm the only one who receives it."

And here he encourages someone to donate to the main JFS repository at IBM and talks about his role:

I'm one of the main commiters to JFS outside IBM and I'm really happy to see more people involved :)

First I'd like to encourage you to contribute your userspace changes to the main JFS repository at IBM. For the 1.0.11 release I have added autoconf/automake support to easify portability and a bunch of portablity patches (mostly getting rid of linuxisms) is under way to the Core team.

He also posts to the freebsd list as freebsd-fs at Here is the press release when SCO in 2002 released "SCO Linux Server 4.0 for the Itanium (R) Processor Family" and which mentions that the product is based on United Linux. This SCO page lists JFS as one of its features. . . .

They are complaining that IBM contributed JFS to Linux, but their own employee, from this evidence, was involved in helping out. On the day IBM announced JFS was being given to Linux, Hellwig is listed as making five contributions to the kernel.

And he is listed on this page of JFS contributors. Here is IBM's page on Who Is Using JFS? and it lists United Linux. So they not only released a distro with JFS in it under the GPL, their employee helped make it happen. Here is a page listing the Skunkworks team, and you will note that the first entry is Ronald Joe Record, a SCO employee (, and JFS is listed for him. But in case you aren't yet convinced, here is a handy list for you of some other pages that mention JFS, collected by Rand McNatt and nw: (mentions NUMA also) (JFS chapter on page 15-16.) (P. 8: "SCO Linux gives you a choice of four journaling filesystems, EXT3, Reiser, XFS and JFS.") (p. 13-15: "“The Journaled File System (JFS) is a full 64-bit file system. All of the appropriate file system structure fields are 64-bits in size. This allows JFS to support both large files and partitions. JFS was developed by IBM under the GPL license and is ported from its AIX systems. JFS provides a log-based, byte-level file system that was developed for transaction-oriented, high performance systems. Scalable and robust, its advantage over non-journaled file systems is its quick restart capability. JFS can restore a file system to a consistent state in a matter of seconds or minutes.”) ("Journaling file systems add a higher level of reliability and faster recovery time. JFS, ReiserFS, XFS and Ext3 journaling file systems are included with SCO Linux Server. Each of these file systems has been tested and optimised for the best performance and stability.")

Here is another one, which mentions both JFS and XFS:

SCO Linux Server 4.0 (Powered by UnitedLinux 1.0) . . . . The SCO Linux Server 4.0 has many advanced enterprise filesystems, including ext2, ext3, reiserfs, jfs, and xfs, which of these have support for ACLs on SCO Linux 4.0?

What about SMP? Hellwig worked on SMP also. Alex Roston has researched Hellwig and SMP and contributes this:

Christoph Hellwig is also a contributor to Linux's SMP systems. Here he proposes a patch that fixes the booting of an "SMP-compiled i386 kernel on a SMP-capable motherboard with" a CPU which is not SMP.

Linus replies to him with this note.

So Hellwig patches his patch.

Later, a SCO employee, Senior Programmer Torsten Duwe, ( acknowledges Hellwig's code. He also discusses the issues around binding a process to a CPU. (Process affinity) This is obviously only an issue on machines with more than one CPU, otherwise the process is already bound to the single CPU on the system. Here he posts a piece of code by Nick Pollit from SGI which allows the 2.4 kernel to perform something called "process pinning." Later on in the same discussion he discusses a Red Hat patch for the SMP code.

On another occasion he discusses SMP support for Pentium-3 chips and suggests that given the number of different architectures Linux supports that SMP should be either per-architecture or a configuration option. I've found several other references to SMP and Christoph Hellwig, but only one other seems significant. In this exchange he proposes a change to Linux's gendisk handling.

Red Hat's Arjan van de Ven notes that the patch is SMP unsafe and Hellwig agrees that he will fix the SMP problem if the patch is accepted, and if you follow the thread, it goes on a little longer with a discussion of whether Hellwig's code was inspired by someone else, and Hellwig acknowleges that he's rewriting another programmer's contribution.

In addition to his email address hch at, Christoph Hellwig also has another email address which he frequently uses for his Linux work. This address is hch at Here we see him making a reply to this post which discusses an SMP machine with problems, with a suggestion for either clearing up or diagnosing the problem.

"In a thread called "Re: Longstanding networking / SMP issue?" Hellwig acknowledges some buggy code. In this post he makes a suggestion for someone having trouble with XFS on an SMP machine.

Looking at all this, we see that Hellwig didn't just post a patch because he was having a problem with SMP. He's performing a large number of programming tasks involving this issue. He's creating SMP code, forwarding SMP code written by others, rewriting code belonging to others that impinges on SMP, and acknowledging buggy SMP code. In addition, he's interacting with other people at SCO. Hellwig's own SMP patch is acknowleged by another SCO programmer and a former SCO employee, Tigran A. Aivazian, who is acknowleged as a contributor to the Linux SMP HOWTO, although whether Mr. Aivazian was involved in the HOWTO while employed by SCO is unknown.

Further, we also see Hellwig involving himself in technical discussions revolving around SMP, and he also makes diagnoses and suggests workarounds for SMP code. Lastly, he also shows an awareness that his code needs to take SMP issues into account. He's also listed as the active maintainer of two other file systems under Linux, the FREEVXFS and SYSV filesystems.

So it should come as no surprise that he's made many contributions to another important Linux filesystem, the XFS filesystem contributed to the Linux kernel by those nice folks at SGI. While he's not listed as the filesystem's maintainer, he's so important to this effort that SGI has given him two more email addresses, 'hch at sgi dot com,' and 'hch at lab343.munich.sgi dot com.' He also has the authority to merge code into this subsystem, as you can see here. The document at this URL is full of emails that read like this example:

Date: Tue Jan 14 07:19:17 PST 2003
Author: cattelan
Merged by: hch
Merged mods: 2.4.x-xfs:slinx:136126a
The following file(s) were checked into:"

In other words, on January 14th of 2003, Christoph Hellwig merged an XFS patch by Russell Cattelan into the '' work area. You'll also note that he's merging kernel 2.4 code into the 2.5 kernel.

Here's another document where he's working with the XFS code. Here he writes about checking files into '' .

He also acts like a teacher/boss. Note his comments in the following documents. Here he replies to Andrew Morton with a suggestion for making his XFS patch better and Mr. Morton replies.

Here are more URLs listing XFS commits. In the first URL he commits filesystem code from three different email addresses:

His work rates frequent mention in the 2.5.* kernel release notes. Once again, it happens under three different email addresses. Note how much of this work involves the XFS filesystem, here and here.

Here Hellwig deals with an XFS bug. And here he's listed in connection with several XFS bugs. See number 452, 835, 840, 861, and 870. In other words, he was deeply involved with porting the XFS file system from SGI into Linux, and he performed all of a chief programmer's usual functions - coding, debugging, merging patches and codebases, supervising, and instructing.

"Worse for SCO, in addition to Hellwig's work on XFS and SMP, we also see from this post that Hellwig's supervisors, in this case Ralf Flaxa, ( are aware that he is online and making changes to the Linux kernel:

Reading this thread and previous requests I see a need by ISVs and applications to determine at runtime certain processor related features. They can roughly be grouped into:
1. number-crunching power in general

o number of CPUs
o CPU family and type
o BogoMips (per CPU and/or overall)
o SMP capabilities (here kernel scalability could be an item)

2. features specific to a processor

o for x86 e.g. the "flags" and *_bug fields
o info about FPU, MMU and the like

I have asked Christoph to work on a proposal and present it to this list. I think we agree that there is a need and demand for a standard way to gather this info and that /proc/cpuinfo was just a bad start - so I would like to give it another chance. This is Ralf speaking as director of Linux development at Caldera and as technical lead for the LSB sample implementation.

You might also notice the kernel version numbers. Where SMP is concerned, he's not just talking about code in 2.2. He (or his code) discusses 2.4 (though I'm not sure which release he's discussing) and 2.4.10. Lastly, most of the posts are dated after the January 5th, 2001 release of the 2.4 kernel, so Hellwig not only contributed to SMP, his contributions involved 2.4. One of them is even dated July 13, 2003, long after SCO filed suit against IBM. The XFS code is much the same, though most of it deals with the 2.5 codebase.

Mr. Hellwig has been at the heart of three important initiatives aimed at making Linux "enterprise ready," JFS, SMP, and XFS.

What about NUMA? As it happens, SCO Linux 4 lists it as one of its features, along with JFS and SMP:

Features of SCO Linux 4 include:

Linux 2.4.19 Kernel – The core of SCO Linux Server 4.0 is the 2.4.19 Linux kernel. New features include broadened USB support, Logical Volume Manager, improved journaling file system support, POSIX-ACLS, new O(1) scheduler (improves SMP support), Asynchronous I/O, Enterprise Volume Management System (EVMS), PCI Hot Plug Support on supported hardware, NUMA support, and many other performance enhancing capabilities.

And this white paper lists NUMA on page 10. Caldera should have known about NUMA in Linux: here is a description of ccNUMA in Caldera's OpenLinux Documentation.

Well, that's three down and only one to go, RCU. I had more trouble finding proof that SCO distributed a kernel with RCU. But, thanks to the Groklaw community, and especially nw, we got that one done eventually. Here's a guy who reports on downloading the 2.4.19 kernel from SCO's ftp site and finding RCU patches:

The SCO RPMs for the 2.4.19 kernels do not contain the generic 2.4.19 GPL kernel source code (linux-2.4.19.tar.bz2). These RPMs contain the SCO GPL patches (some are which RCU patches to the kernel) and "specfiles" to create the SCO 2.4.19 GPL kernels from the generic 2.4.19 kernel source code. The reason the SCO RPMs do not contain the generic 2.4.19 GPL kernel source code (linux-2.4.19.tar.bz2) can be found in an email from a UnitedLinux developer at:

The generic 2.4.19 GPL kernel source code (linux-2.4.19.tar.bz2) can be found at: - Copy this file to the RPM source directory before building the SCO 2.4.19 GPL kernels.

Then, I couldn't seem to find any more on RCU, so I put out the call for folks to try to find a bit more, knowing there could be some skeptics in the crowd. Dr. Stupid, as always, came through with skill and charm. Here is his email:

Here's an article about SCO Linux 4, showing it's based on UL and thus SuSE.

Here's a SCO page talking about how to update SCO Linux 4, note that it gives the explicit kernel version - 'k_deflt-2.4.19-246.i586.rpm' Date is Feb 2003.

Google cache of above just in case.

Note that SCO did distribute the kernel updates themselves. Allegedly it's rather harder to get the kernel from them these days. But they talk of the "United Linux SP1 CD" which SuSE could send you if you ask them nicely. Here is a page which verifies that SCO was using the SuSE kernel (though he's referring to the pre-service pack 1 version)

And while this may have been posted before on Groklaw, it bears repeating in this context: Christoph Hellwig, nodding approvingly about RCU and helping out.

Also check here. That 'k_deflt-2.4.19-246.i586.rpm' was made available on many sites, such as here. Search on google for 'k_deflt-2.4.19-246.i586.rpm' for more)

Note that this mirror site has the kernel built for various processors (athlon, SMP etc) but they are all built from the same source RPM which is at the bottom... kernel-source-2.4.19.SuSE-152.i586.rpm . Yes folks, remember that all the United Linux chaps were shipping the exact same kernel: SuSE's kernel. But that kernel isn't the plain 2.4.19 kernel, it's patched (with 152 patches to be exact!)

So, I downloaded the source RPM and unpacked it, to see just what SCO was shipping, under the GPL, in its SCO Linux 4 product.

Well, well... in the 'kernel' folder of the source package there is a file which isn't in the vanilla 2.4.19 kernel. That file is called rcupdate.c and I'll give you a short excerpt:

* Read-Copy Update mechanism for mutual exclusion
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
* Copyright (c) International Business Machines Corp., 2001
* Copyright (C) Andrea Arcangeli SuSE, 2001
* Author: Dipankar Sarma ,
* Andrea Arcangeli B^!

* Based on the original work by Paul McKenney
* and inputs from Andrea Arcangeli, Rusty Russell, Andi Kleen etc.
* Papers:
* For detailed explanation of Read-Copy Update mechanism see -

Leans back, lights cigar.... B^!

Oh, and btw, SCO could hardly have been ignorant about the enterprise level features going into UnitedLinux, as they crowed about them.

P.S. Moreover, the changelog for the kernel mentions rcu patches back in 2001, so the original kernel that SCO Linux 4 shipped with would have had RCU too.

So, there we have it. All four. And just in time for December 5, too. I do hope Judge Wells enjoys detail. While no one can yet know for sure what SCO meant in its response to the interrogatory, I think we can safely say that they cannot claim that they were unaware that they had released, and even were contributing toward, these enterprise-enabling features of Linux.


UnitedLinux White Paper Shows SCO Thought JFS Came From AIX, Knew JFS was in UL - Updated | 205 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Authored by: Just_Bri_Thanks on Tuesday, June 27 2006 @ 09:07 PM EDT
clicky, if possible

Bri. Just Bri. Thank you.
(With a long i sound.)
Without qualification, certification,
exception, or (hopefully) bias.

[ Reply to This | # ]

Off topic here, if you please?
Authored by: Just_Bri_Thanks on Tuesday, June 27 2006 @ 09:08 PM EDT

Bri. Just Bri. Thank you.
(With a long i sound.)
Without qualification, certification,
exception, or (hopefully) bias.

[ Reply to This | # ]

That's kind of weird...
Authored by: EverGeek on Tuesday, June 27 2006 @ 09:12 PM EDT
IBM didn't use the AIX version of JFS for Linux, it ported the OS/2 version. So
only is this disappearing, but it seems factually incorrect.

[ Reply to This | # ]

Why would SCO delete files?
Authored by: Anonymous on Tuesday, June 27 2006 @ 09:13 PM EDT
PJ, what do SCO hope to achieve by deleting files such as this?
Surely they don't think every other copy will be magically destroyed.

[ Reply to This | # ]

I hope IBM's Lawyers can make use of this
Authored by: Anonymous on Tuesday, June 27 2006 @ 09:13 PM EDT
I hope IBM's lawyers can make use of this information to debunk what SCO has
said. Also to use it as proof that SCO (like ENRON) is actively destroying

[ Reply to This | # ]

UnitedLinux White Paper Shows SCO Knew About JFS Being From AIX
Authored by: Anonymous on Tuesday, June 27 2006 @ 09:15 PM EDT
i guess the question now is does big blue have copies of these disapearing
documents in a form that is admissable(sp?) in court.

[ Reply to This | # ]

Authored by: mobrien_12 on Tuesday, June 27 2006 @ 09:22 PM EDT
Has anyone done a WGET on SCOG's website?

Screenshots are good, but what about a wget? And what about google cache?

[ Reply to This | # ]

UnitedLinux White Paper Shows SCO Knew About JFS Being From AIX
Authored by: Anonymous on Tuesday, June 27 2006 @ 09:22 PM EDT
Also available at: http: //

Get your copies while you can!

[ Reply to This | # ]

UnitedLinux White Paper Shows SCO Knew About JFS Being From AIX
Authored by: Nonad on Tuesday, June 27 2006 @ 09:33 PM EDT
Google search for whitepaper.

[ Reply to This | # ]

SCO monitoring message boards
Authored by: Anonymous on Tuesday, June 27 2006 @ 09:53 PM EDT has an interesting, but stale page about SCO monitoring Yahoo SCOX.

Other more recent incidents of note are: 1. The beta SCO Me had directory browsing enabled, one could access log pages-- this feature was turned off just after a posting regards this on Y SCOX.

2. A domain created to needle the resident troll, had obsessive hits from a content-watching Salt Lake City proxy. The hits shut down simultaneously with a post mentioning the curious pattern on Y SCOX. (Utah interest in Biff is peculiar, since all indications place the original troll in Belgium).

[ Reply to This | # ]

Authored by: Anonymous on Tuesday, June 27 2006 @ 10:28 PM EDT
This all sound like 1984!

[ Reply to This | # ]

UnitedLinux White Paper Still Available
Authored by: Anonymous on Tuesday, June 27 2006 @ 10:50 PM EDT
The white paper is still available for download from It also clearly links to "The SCO Group".

[ Reply to This | # ]

Is this all just FUD? ("Experts")
Authored by: jdg on Tuesday, June 27 2006 @ 11:27 PM EDT
In a normal case, having experts making claims about when they knew things that
is are easily refuted would be an absolute disaster. The expert losses
credibility and it is worse than not having an expert.

Given how trasparent this seems to be [IANAL], why would experts and why would
SCO do this. Did the expert not check things out, depending on what SCO told
them. Is the expert incompetent?

Does SCO not care; well, they must care because they are deleting the easily
found embarrasing stuff, which implies that they are just pushing the FUD angle
and the "throw everything every which way and maybe IBM will miss something
SCO slip in somewhere".

SCO is trying to appropriate the "commons"; don't let them [IANAL]

[ Reply to This | # ]

UnitedLinux White Paper Shows SCO Thought JFS Came From AIX, Knew JFS was in UL - Updated
Authored by: Anonymous on Wednesday, June 28 2006 @ 12:43 AM EDT

I love this site and wish all litigation was subject to fact findings like

[ Reply to This | # ]

UnitedLinux White Paper Shows SCO Thought JFS Came From AIX, Knew JFS was in UL - Updated
Authored by: Anonymous on Wednesday, June 28 2006 @ 12:58 AM EDT
AFAIK, IBM 'freed' the OS/2 JFS so that OS/2 clients could continue to get at
their on-disk data after OS/2 was withdrawn; i.e. for a good commercial reason.
Any side effects (like having a journalling file system in Linux) are purely
coincidental. There are now about 4 journallling file systems for Linux; not
many people use the ex-OS/2-one, but it is there as an option for anyone who
wants it.

[ Reply to This | # ]

The point please?
Authored by: Anonymous on Wednesday, June 28 2006 @ 02:07 AM EDT
What's the harm of SCO working on JFS in the assumption it was contributed by
IBM coming from OS/2?

[ Reply to This | # ]

Concept shared with UNIX - directories
Authored by: IMANAL on Wednesday, June 28 2006 @ 03:24 AM EDT
The following remark from the same UL document about ext2 file system shows thtat the UL group did not find it strange that Linux shared properties or concepts with traditional UNIX, like the concept of directories:

"The ext2 file system is the Linux native file system and shares many properties with traditional UNIX file systems. It has the concept of blocks, inodes, and directories."

IM Absolutely Not A Lawyer

[ Reply to This | # ]

Admission of guilt (yet again)?
Authored by: Anonymous on Wednesday, June 28 2006 @ 04:20 AM EDT
The clear contradiction of their statements in court and this document, AND the
fact that it has suddenly become inaccessible after discovery strikes me as a
very clear sign that SCO knows jolly well that it's been, um, 'creative' with

Can this be used against them?

[ Reply to This | # ]

Where did JFS come from?
Authored by: Anonymous on Wednesday, June 28 2006 @ 07:42 AM EDT
The ironic thing about the Linux JFS code was that it was worked on by one of
the BSD grandfathers Greg Lehey. As a lot of people know already, Greg keeps an
online diary of his life. Here is is explanation of why the 0S/2 code was used.

"Off to IBM after breakfast, and was able to locate both Mark Peloquin and
Steve Best, the latter of whom had time for me. They're all located in the same
area. The most interesting thing about Steve's JFS project is the reason they
chose the OS/2 version as the starting point. We had all assumed that it was a
bit of a copout because they didn't want to release the really high performance
AIX version, but the real reason was that the old AIX JFS was being phased out,
and the new one, also based on the OS/2 version, wasn't ready yet."

[ Reply to This | # ]

Links going 404
Authored by: ThatBobGuy on Wednesday, June 28 2006 @ 09:00 AM EDT
It will be fun to watch through out the day, all the links to sco/caldera that
will no longer work.. Found two so far :)

[ Reply to This | # ]

  • Links going 404 - Authored by: Anonymous on Wednesday, June 28 2006 @ 03:25 PM EDT
I have a copy of the free UnixWare license!
Authored by: The Simulator on Wednesday, June 28 2006 @ 09:17 AM EDT
I still have a copy of the license for using UnixWare for free. As it happens,
I never actually made us of it because I discovered Linux at around the same
time. But it would be of help, I could scan it and send it in...

Simulation engineers do it with models virtually every day!

[ Reply to This | # ]

UnitedLinux White Paper Shows SCO Thought JFS Came From AIX, Knew JFS was in UL - Updated
Authored by: Anonymous on Wednesday, June 28 2006 @ 03:28 PM EDT
Here are two links, SCO knew !.,14179,2807197,00.html

[ Reply to This | # ]

UnitedLinux White Paper Shows SCO Thought JFS Came From AIX, Knew JFS was in UL - Updated
Authored by: Anonymous on Wednesday, June 28 2006 @ 03:44 PM EDT
INAL, but extolling virtues of the UnitedLinux and SCO's wonderful contributions
would be in the opening remarks at trial -- then tell the jury forget all that
-- SCO has forgotten all that and wants to go back and blame everyone else for
their previous acts.

SCO was probably driving a white Bronco at that time.

[ Reply to This | # ]

how Groklaw got so popular is no mystery
Authored by: Anonymous on Wednesday, June 28 2006 @ 04:27 PM EDT
PJ, we don't come here for your wonderful HTML coding skills. We come here for
the same reason we've always come here -- because we can get good info and
insightful commentary about the SCO vs. IBM case.

Non-lawyers like myself would likely never have been aware of the goings-on in
this case, or understood any of it, without Groklaw making the sources easily
available to us and explaining what the legalese means.

By the way, thanks for all your efforts since day 1 of Groklaw, and keep up the
good work.

[ Reply to This | # ]

Sco removes more evidence files from its site
Authored by: Anonymous on Wednesday, June 28 2006 @ 04:49 PM EDT
I clicked on the links to the sco site about linux that PJ posted. now they are
gone. And the google cache link didn't work either. Darn!

[ Reply to This | # ]

Authored by: Anonymous on Wednesday, June 28 2006 @ 05:33 PM EDT
Better make sure it's not copyrighted material first!

[ Reply to This | # ]

UnitedLinux White Paper Shows SCO Thought JFS Came From AIX, Knew JFS was in UL - Updated
Authored by: Anonymous on Thursday, June 29 2006 @ 09:08 PM EDT
As nearly as I can tell, this drives a stake through the heart of a big chunk of
what's left of SCO's case.

[ Reply to This | # ]

Caldera knew nothing about JFS, just assumptions
Authored by: Anonymous on Wednesday, July 05 2006 @ 07:14 PM EDT
At the time when UL came out, I read the Linux JFS project development teams
docs quite often, and there was mentioned that their starting point was indeed
OS/2 version, NOT the AIX one.

I welcomed the UL idea, and examined the whitepaper and was astonished about the
JFS error. I thought it has to be a typo and sent an email for correction, and
their responded with political correct aswer "They'll check that from

They never did!

I'll check whether I have that email should be!

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )