² Even as to the categories of material identified in the Final Disclosures, SCO uses Dr. Cargill to expand considerably the scope of its allegations. For example, the Cargill report alleges that IBM has misused the “totality of the Streams framework”, drawing in every line in over 150 new files, never before mentioned by SCO.

SCO fleshed out the accusation in its Memorandum in Opposition to IBM's Motion to Confine SCO's Claims to, and Strike Allegations in Excess of, The Final Disclosures :

Dr. Thomas Cargill, a software consultant and former computer science professor and UNIX developer, concludes in his report that Linux 2.4 and 2.6 and LiS Streams (collectively "Linux") are substantially similar to the Unix System V Release 4 operating system ("SVr4"), and therefore, that Linux infringes copyrights of SVr4. (Ex. 3 at 3.) In reaching this conclusion, and by applying the applicable legal test, he further opines that Linux is a substantial copy of UNIX System V Release 4 ("SVr4") because it appropriated the essential structure of UNIX by incorporating (1) many of the "system calls" in SVr4; (2) the SVr4 file system; (3) the ELF format; and (4) the Streams communication module. (Id. at 3-4.)...

Dr. Kernighan concedes originality and alternative designs, arguing only that Streams has been made available as a module to Linux "for legacy compatibility" and that Streams was developed by SCO's predecessor in interest, AT&T.

As usual, SCO seems to have failed to research its own history. I also think it has misunderstood what LiS is. So I'll help SCO out. As you will see, it was Caldera that wanted STREAMS put into the Linux kernel, failed, but included it in its own distro, Caldera Open Linux, so it could offer what it called Caldera Netware for Linux.

Once again, SCO would now like to sue folks for something it itself put into Linux, or in this case tried to put there but failed. It's not in the kernel, which is what this litigation is supposedly about.

First, what is STREAMS? Of course, I had no idea, not being a programmer. But I am a researcher, so I'll share with you what I found, providing the urls, so if you wish to correct anything, or add anything, you can.

This Linux Gazette page from 1998, explains, in answer to a question from someone who had downloaded it from ftp://ftp.caldera.com/pub/netware/INSTALL.redhat -- Caldera's site, notice, offering STREAMS for other distros -- and tried to install it in Red Hat but couldn't and wanted to know how to fix the problem:

When I type in rpm -i kernel-2_0_35-1nw_i386.rpm, I get the following error: ln: boot/vmlinuz-2.0.35-1nw-streams: No such file or directory Can you tell me why? More importantly, can you tell me how to fix it?

(!) Well, the Netware for Linux requires a kernel with STREAMS and IPX patches built into it.

STREAMS is an alternative to BSD sockets. It's a programming model for communications within a Unix or other kernel --- between the applications interfaces and the devices. The Linux kernel core team has soundly reject suggestions that Linux adopt a STREAMS networking model for its native internal interfaces and we won't go into their reasoning here. (I'm inclined to agree with them on this issue in any event.)

So, this error suggests that the 'ln' command (creates hard and symbolic links) can't find the '/boot/vmlinuz...' files to which it refers.

One trick to try is to view the contents of the rpm file using 'mc' (Midnight Commander). Just bring up 'mc', select the RPM file with your cursor keys and highlight bar, and hit [Enter]. That will treat the RPM file as a "virtual directory" and allow you to view and manually extract the contents. Look in RPM:/boot for the kernel file --- also look for the README files....

Note that this kernel may not support you hardware configuration (that's one reason why many Linux users build custom kernels). So you may have to find and install the kernel source patches and build your own --- or at least build a set of modules that match that version.

Probably your best bet would be to subscribe to the caldera-netware mailing list. Look to Liszt to help find specific mailing lists and newsgroups:

Liszt: caldera-netware
http://www.liszt.com/cgi-bin /start.lcgi?list=caldera-netware&server=majordomo@rim.caldera.com ...

Probably your best bet would be to subscribe to the caldera-netware mailing list.

I'm subscribed, but impatient. Thank you for your help....

Naturally you'll want to leave an entry for your existing (working) kernel so that you can reboot into that if this Caldera supplied kernel is inappropriate for your system.

As you can see, Caldera was evangelizing STREAMS and encouraging its use. It tried hard, but failed, to get Streams put into the Linux kernel. Back in 1998, Alan Cox commented on STREAMS and Linux on LKML, stating why he thought there was no way Linux, the kernel, should ever include it. You can see he is talking to chrisc@caldera.com if you open the headers. Caldera was upset that Linux developers were opposed to including STREAMS in Linux, and complained that if they wouldn't allow it, "Caldera is stuck."

What does that mean? Stuck how? Caldera had just put Netware stuff into Caldera Open Linux, including STREAMS, in connection with Netware for Linux, as you'll see in the LKML interchange. (See also this 1998 c't review.) Why didn't Linux developers want it in the kernel? There were important technical reasons, as you'll see. It would slow Linux down, Cox said. And who, Cox asked, will maintain it if Caldera someday switched from being a Linux vendor? Ah, how prophetic.

Here's the Cox reply to "chrisc@caldera.com", with the caldera guy's prior message interspersed, and slightly edited for language, but otherwise intact so you can see how hard Caldera pushed for Streams and how firmly it was rejected, beginning and ending with a row of stars so you can quickly see where it begins and ends:

**************************

From (Alan Cox)
Subject Streams and Linux
Date Mon, 29 Jun 1998 02:03:30 +0100 (BST)
[Red Hat firmly off, Linux hacker hat firmly on]

> pennies worth. All of the following is my personal opinion, worth
> every penny you have paid for it. :-)

I can't be bothered to even discuss the more stupid poltical aspects
of all this. I'm just going to explain technical issues - nothing more
or less.

> "convert" Streams code to "Linux-specific" alternatives necessarily
> preclude this kind of "conversion" as an option. Given this
> premise, we have two alternatives:

The are several things people muddle up

1. Streams

This is an API design for layered networking. Even the inventor
of the streams concept said of the way it was used
"The idea loses something when it is shouted"

Streams are technical very flawed and not a good thing to put in
a kernel. Indeed our Solaris, SunOS, SCO etc emulation layers
turn streams into sockets as fast as possible. (note btw ibcs2
does this -without- kernel patches), as could Caldera. Although
for the syscall registering issue there may be a sane reason for a
registering those. Ask Linus.

2. TLI/XTLI

These are the interfaces _most_ people actually use. TLI and XTLI
isolate the user from the innards of streams. TLI is actually
very flexible, it tends to be unpopular with non commercial people
because TLI programming is painful.

Alexey Kuznetsov wrote a complete TLI emulation over sockets layer
for Linux. Entirely in user space. Its free, it exists it addresses
most of the issues people often think are "streams". This TLI
implementation is free software.

So most TLI/XTLI applications are sorted. Finally almost all
applications in the commercial world are written to the socket API
(maybe emulated onto TLI). Thats another reason vendors are running
from streams as fast as they can.

> Besides, despite the strongly-held opinions of many persons, the
> jury is still out on whether or not "Streams performance" is all
> that bad. And even if the performance of Streams _is_ that bad,

The jury returned the final verdict about four years ago. There is no
argument about the technical flaws in streams: SGI do not use streams
internally for networking, Sun moved away from streams for the performance
parts of their networking (their papers imply what actually occurs is
"Hi Im a streams module but I do Sun funky network too" "Hi Im the other
module on this stack right now, I also do sun funky networking - lets
stuff this streams [redacted] and talk sanely"). Sun moved socket() and friends
back into the kernel. Sequent moved sockets and socket API stuff back into
the kernel. Unixware Im reliably informed is currently doing the same.

So from a technical point of view streams is dead. There are people who
worked on streams for years at companies like Spider, who specialised
in making streams go as fast as is possible who will tell you it doesnt
go fast enough and equally importantly you cannot make it scale if you
want to be top of the pile.

Thats the technical status.

> isn't the most important issue. If I had a choice between _no
> application_ and a _slow application_ which met my critical needs,
> I'd choose the latter 100% of the time. Would you?

The Linux kernel is a technical project. Streams are "not interesting"
technically. Productization is a vendor issue.

> a mistake to tie "NetWare on Streams" with "NetWare performance".
> The two are entirely unrelated.

Indeed - netware is fast "despite streams" and "despite the netware
protocol weaknesses" - its a victory of sheer human stubbonness and hacking
skill over technically poor tools. You may care to benchmark netware 3
versus netware for unix on pure packet turn around time for a null NCP
operation. Now compare it with 2.1.x knfsd (socket based kernel code)
turning around an NFS no-op.

You will find it interesting.

> A: Because certain extensions to the kernel must be made in order to
> support the Streams loadable module. For example, Streams
> introduces some new system calls which are NOT present in the base
> kernel (e.g. putpmsg, getpmsg). The kernel system-call table must
> be modified to support these Streams entry points.

Syscall numbers you didnt register with Linus as far as I can tell, which
means since 2.2 uses more numbers you are likely to see breakages. Irrespective
of any streams issues those two calls as NULL hooks you could get dropped
into 2.1.x. Ask Linus - he did it for AFS. I cannot put anything like that
into 2.0 until it has official 2.1.x syscall numbers from the man himself
or I cause a back compatibility monster with a syscall numbering collision.

> that the kernel changes required to support a loadable Streams
> module are strikingly tiny. But there is such a "religious"
> opposition to Streams among _kernel developers_ that they refuse to
> allow even these tiny patches into the "base kernel". They seem to

It is entirely a technical opposition.

> fear the introduction of support for a Streams module as such a
> terrible "pollution" of their kernel that they have not and
> apparently will not allow it to happen. So Caldera is stuck--the

Putting support for something in the kernel implies a maintenance commitment
that in this case is not there. Ask Caldera or any vendor about the effect
of shipping a package you cant maintain. They can write in big letters
"this package is an add on its not supported", it makes no odds. So there
are real issues adding anything to a kernel - especially as its damned
hard to remove something from the kernel, even when its way more dumb than
say streams

That said I see no reason why Caldera shouldnt ask and get a pair of syscall
numbers from Linus they can hook.

> cases (e.g. NetWare for Linux), the software under consideration is
> proprietary and hence is not a candiate for a "freeware"
> reimplementation.

Actually there is MARS_NWE which is effectively exactly that. Caldera are
really selling a "branded" genuine netware. That I suspect makes the case
even more awkward for a rewrite. Again your cite is a political and
productization issue.

> A: I've been truly amazed at the "group opinion" on this subject.

If you were technically aware of whats going on in networking you wouldnt
be. Streams is being dropped globally. Streams was originally a victory
of standards people over sanity, its now being blasted into oblivion because
1. Networks have sped up by a factor of 100 in 3 years - Memory hasnt
2. Network performance is the hottest checklist item and its going to grow
faster and faster.

> Most people say that opposition to Streams is on technical grounds,
> but I believe the real opposition is a political one. Many people

I've never seen Linus with a political agenda. And even the people who get
political about streams (eg Larry McVoy) do so from a technical base point.

> be going out of their way to make Streams painful for everyone, as
> if to fulfill their own prophecies on the "badness" of Streams.

They don't need fulfilling.

> The fascinating thing going on here is the fear of the "success" of
> Linux: If someone wrote a "major application which depended on

It wouldnt be a success - it would be an app that screws the future of
the Linux networking stack. Right now we are the most [redacted] hot piece of
PC networking software on the planet. The only people who can touch us
are FreeBSD (who also dont do streams).

Having an application that is streams dependant that makes it hard to break
the streams stuff isnt acceptable from a purely technical standpoint. Nor is
it good for the long term future of Linux.

What it means 3 years down the line is Linux would be bottom of the webstone
benchmark and all the nice "linux is fast" graphs that sell Linux webservers
will be gone, dead and history.

Linux is _technically superior_ - that is its fundamental superiority. The
core Linux product must continue to be so and the Linux core team agenda
is purely technical superiority

> the masses. (Not to mention David's unsupported assertion that the
> mere presence of Streams in the kernel cause the kernel itself to
> slow down--this just ain't so.)

It does. We cannot do zero copy page flipping in a streams environment. When
we do that the GCOM code _will_ probably break. I suspect it'll break in a
fixable way where it'll be even slower again but with 1Gigabit networking
once the cards support it , non zero copy networking is _not_ an option if
we want to stay top of the pile. So we will end up breaking the GCOM stuff
possibly pretty badly although I hope not, there is no malice in breaking
of things.

Another very worrying issue is field of interest in the support. Caldera
ship only x86 Linux. Has anyone ever even verified the GCOM streams code
is 64bit clean big and little endian, alignment clean, copes with ARM
packing rules and all the other little portability wonders the mainstream
code has to meet.

> I disagree with David's assertion that Streams will "creap" [sic]
> like a "fungus" into the rest of the kernel. Streams has a
> well-defined kernel interface that is not likely to change much

No streams does NOT have a well defined kernel interface. It has a poorly
defined set of interactions with core Linux data structures. You may not
be a good enough programmer to see that - I don't know your background. I've
worked on Linux since it appeared, I've worked for people like 3Com who
had this problem badly. Anything that has data structure interfaces with
other code leaks through the structures over the boundary, or ties down
those structures.

Streams depends on the sk_buffs in the kernel. In a zero copy world those
buffers may well just not exist any more

> it's maintained by some nice guys at Gcom, NOT the _kernel
> developers_. Linux Streams (LiS) has a lifetime of its own

For how long. Who maintains it if Caldera pull out of Linux to concentrate
on DOS only. Who maintains it if Caldera decide GCOM are charging too much.
Are Caldera committed to 2.2 support of it, have they discussed getting
the syscall numbers (which is all the actually need) from Linus ?

> A: This remains to be seen, but a couple come to mind. Firstly,
> Caldera's NetWare for Linux (NW4L) would definitely NOT be on Linux
> were it not for Streams. You can decide for yourself whether or

These are entirely non-technical issues, and you seem to be a bit short
of actual examples except the netware client, which has a free version
shipped in the standard kernels.

The decisions people like Linus and Davem make on what goes into the
kernel are purely technical ones. If Caldera think there is a market in
shipping a modified "streams aware" kernel good for them. Streams is a
marketing and productization issue not a technical issue. Streams ran out
of technical arguments a very long time ago. Right now every vendor is
trying to figure out how to get streams OUT of their box while keeping
legacy API compatibility code from bloating the kernel another 200 K.

We don't want to put that 200K in. Maybe to Caldera its a worthwhile
commercial product. As I've said - reserve your syscall numbers I cannot
see an opposition to that. Thats the advice I gave in 1996 or so when
this first came up.

Alan

**********************************

chrisc at Caldera mentions LiS, and here is that project's page. I gather LiS is what Caldera used. This GCom page informs us that Linux STREAMS [LiS] was released under the LGPL. GCom's David Grothe claims to be the LiS copyright holder, by the way, not SCO or IBM, and as you may have noticed on that page, there was a decided difference of opinion between him and Cox and clearly no cooperation. It's so ironic, then, that SCO is trying to claim Linux is infringing STREAMS, when the kernel guys absolutely hated the idea and chose an alternative. Anyway, LiS isn't STREAMS, Dr. Cargill notwithstanding, but rather it provides for an interface between STREAMS and the kernel, or at least that is what I get from this information:

Linux STREAMS (LiS) provides for an interface between STREAMS drivers and the surrounding kernel environment. This interface has grown over time and is likely to expand in the future.

Another page explains a bit more:

LiS is a software package that comprises an implementation of SVR4 compatible STREAMS for Linux. It takes the form of a loadable module for the Linux kernel. LiS installs in any directory on your system, not in the kernel source tree. When it is built it is possible to link pre-compiled STREAMS drivers with it so that when LiS loads into the kernel it brings "application" drivers with it. Alternatively, STREAMS drivers can be coded as loadable Linux drivers which depend upon LiS. In this way, individual STREAMS drivers can be loaded and unloaded dynamically.

Caldera was all about blending proprietary and open, and Linux is not on that same page. It's why, in my opinion, Caldera could never make it as a GNU/Linux vendor. A lot of folks despised what they were doing. Now Caldera -- morphed into the SCO Group -- wishes to sue over stuff they fought hard to include into Linux, the kernel, and when that didn't work put into their own distribution. Let that be a lesson to all who think that proprietary anything is safe to include in FOSS. Somehow, it always comes back to bite you.

Anyway, Linux STREAMS or LiS was a separate project, not part of the kernel, as you'll see in the whining of the Caldera person trying to get STREAMS included in the kernel, because he mentions the LiS project. Cox says the conversation first started in 1996.

If you are interested in STREAMS, you can learn all about its methods and concepts from the following:

• "UNIX (R) System Software Readings", which says it "presents the proceedings of AT&T Unix Pacific Co., Ltd.'s UNIX System Software Technology Seminar for the Asia/Pacific region held in July, 1986," and which begins: "This compilation explains new software technologies used in UNIX System V Release 3.0, newly announced by AT&T. The small book contains an Introduction by Larry Crume (then President of AT&T Unix Pacific); the Keynote "Beyond UNIX" by Brian W. Kernighan; "Streams Technology," by Gilbert J. McGrath
• "Networking Architecture and Protocol," by Laurence M. Brown
• "Distributed UNIX System--Remote File Sharing," by Arthur L. Sabsewitz
• "Directions in Internationalization" by Gary L. Lindgren
• "The Shell--Past, Present, and Future" by David G. Korn
• AT&T Bell Labratories Technical Journal "A Stream Input-Output System" Dennis Ritchie, 1984 Vol. 63, pp. 1577-1593 Oct. 1984
• Proceedings of the 1989 Summer USENIX Conference, Baltimore MD "Out-of-Band Communications in STREAMS" S. Ragos, 1989
• AT&T "UNIX System V Release 3.2 - STREAMS Primer" Prentice Hall, 1989
• AT&T "UNIX Streams Release 3.2 - STREAMS Programmer's Guide" Prentice Hall, 1989
• Proceedings of the 1986 Summer USENIX Conference, Alanta, GA "A Framework for Networking in System V" D. Olander, G. McGrath, R. Israel, 1986 (the orginal paper describing the implementation of STREAMS and TLI in System V)
• "Unix System V Release 4: Programmer's Guide: Streams"

If AT&T meant to keep STREAMS to itself, a big old secretive method or concept, it had a funny way of showing it. SCO is claiming copyright infringement, however. So let's think that through. That last book is one of the ones that SCO registered the copyright for, TX 2 833-114, listed on SCO's 2nd Amended Complaint in SCO v. Novell but not on the list in the Second Amended Complaint in SCO v. IBM. What that means is that, as usual, its copyright claims depend greatly on whether it even has any copyright rights. Novell has dueling claims. And it also means it probably should have listed the copyright it purports to have in this litigation, if it wished to argue STREAMS. It's not a fatal mistake, but it's certainly typical.

I happen to have a copy of the book "Special Edition: Using Caldera Open Linux," by Allan Smart, Erik Ratcliffe, Tim Bird, and David Bandel. The first three were Caldera employees at the time of publication in 1999. There is an entire section on NetWare and OpenLinux. On page 690, the book directed readers to Caldera Systems' FTP site at ftp://ftp.calderasystems.com/pub/netware/ to obtain "the latest NetWare client updates and patches for OpenLinux." I never recommend visiting SCO sites, or their supporters' sites, but you don't need to in this case. If you go to Planet Mirror, you'll find it's available for download. They say a picture is worth a thousand words, so here's a screenshot of what you'll find there:

I'd say this information puts SCO in rather an awkward position. First, why is it mentioning STREAMS in connection with IBM? Second, why is it suing anybody but the LiS guys over LiS? Even if it did, is there any basis? It provides an interface. An optional interface at that. The Linux kernel guys apparently did nothing but prevent STREAMS from getting into the kernel as best they could, so why say Linux is infringing? And finally, how can SCO sue anybody for something Caldera so actively and publicly promoted and distributed itself, and under the LGPL to boot? I note that the Caldera representative arguing with Cox mentions the LiS project with approval. So it knew about the project since at least 1998, and apparently before, maybe since 1996. If it represented "copyright infringement," SCO likely waited too long to assert that claim, even if it had copyright rights, which is a very big question mark. If you read the article I wrote about Judge Kimball back in 2003, you'll find a case where he ruled that waiting too long to assert a copyright claim is fatal to the case. For those who hate to click on links, I will reproduce that one section:

10. And here is a copyright case he handled, in which he said the plaintiff waited too long to raise his objection. "Had Jacobsen [plaintiff] voiced his disapproval in 1996, Hughes would have had the opportunity to take the offending material out of the books," he wrote in his decision. Because he waited too long, the material had lost its copyright. A news story in the Deseret News explains:

In his ruling, Kimball said Jacobsen did not "express any disapproval" of the series until 1999, after the third volume had been published. "Had Jacobsen voiced his disapproval in 1996, Hughes would have had the opportunity to take the offending material out of the books," Kimball wrote. "For Jacobsen to wait until three volumes of the series had been published before voicing his disapproval, when it is clear he had ample opportunity to let Hughes know of his disapproval as early as 1996, results in extreme prejudice to Hughes."

Obviously, Caldera knew about LiS at least back in 1998. We saw that in the Cox-chrisc@caldera.com exchange. Caldera not only raised no objection in 1998, it was a participant and evangelizer. How, then, can SCO sue anybody now?

UPDATE: First, you don't want to skip the comments on this article, as readers have posted some very valuable information. And I want to thank Groklaw member dmomara for reminding me of the following detail. Contrast the information in this article with the letter [PDF] sent by Brent Hatch to Todd Shaughnessy back in discovery phase, dated Aprill 19, 2004 and Exhibit G[PDF], attached, where SCO listed LiS ("Linux files from LiS-2.1.5, downloaded from ftp://ftp.gcom.com/pub/linux/src/LiS/LiS-2.15.tgz") and claimed the following:

1. SCO, as the copyright owner of source code and/or documentation upon which the following files and lines of code were copied or derived, has never contributed or authorized these lines of code, or the documentation related thereto, for use in Linux as specified under Section 0, or any other provision, of the GPL.

2. SCO, as the copyright owner of source code and/or documentation upon which the following files and lines of code were copied or derived, has never granted a license to any party that knowingly authorized use of these files or lines of code outside a UNIX-based distribution.

3. None of the following files or lines of code have ever appeared in any Linux-related product distributed by SCO.

Guess again.

Yes, this is the stupidest lawsuit in the history of the world.

Well.

OK. Top ten.