decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

Donate Paypal


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

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
STREAMS, LiS, and Caldera's Netware for Linux - Updated
Monday, July 03 2006 @ 01:08 PM EDT

You may have noticed in IBM's Reply Memorandum in Support of Motion to Confine SCO's Claims to, and Strike Allegations in Excess of, the Final Disclosures, that footnote 2 mentioned something called STREAMS:
2 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. Here's the press release from 1998, announcing Streams in NetWare for Linux 1.0:

Features of NetWare for Linux include:...

* 2.0.35 Linux kernel updates (including streams)

A NetWare for Linux three-user version is now available for download at no cost from the Caldera Web site (http://www.caldera.com/products/netware). Bump packs can be purchased in user license increments of 1 ($95), 5 ($450), 25 ($1,875), or 50 ($2,750). A $59 two-CD jewel case version offering a complete NetWare solution including NetWare for Linux, NetWare utilities and OpenLinux Lite 1.2 will be available mid-August.

On-line documentation is available for download at no cost from Caldera's FTP site and Web site. For peer support subscribe to the Caldera NetWare mailing list at (http://www.caldera.com/support/forums.html). In addition, customers may purchase support from Caldera at $200 per incident. Additional documentation, training and support for this product are not available at this time. As part of the Small Business Server product, full support options will be available later this year.

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

Well.

OK. Top ten.


  


STREAMS, LiS, and Caldera's Netware for Linux - Updated | 351 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Linux Kernel 2.4 vrs. 2.6
Authored by: brian-from-fl on Monday, July 03 2006 @ 01:48 PM EDT
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.)

Didn't TSG's original claims exempt versions of the Linux kernel that were 2.4 and earlier?

[ Reply to This | # ]

Corrections Here
Authored by: tuxi on Monday, July 03 2006 @ 01:52 PM EDT
So PJ can find them.

---
tuxi

[ Reply to This | # ]

Off Topic Here
Authored by: tuxi on Monday, July 03 2006 @ 01:54 PM EDT

Please use clicky links, HTML Formatted, and check with the preview.

Thanks

---
tuxi

[ Reply to This | # ]

Streams are fullly described
Authored by: Anonymous on Monday, July 03 2006 @ 02:09 PM EDT
in The Magic Garden Explained, by Goodheart and Cox. Just like most everything else in SVR4.

[ Reply to This | # ]

Streams, LiS, and Caldera's Netware for Linux
Authored by: Jude on Monday, July 03 2006 @ 02:18 PM EDT
I'm inclined to conclude that either:

1) Dr. Thomas Cargill is a complete doofus who doesn't know what he's talking
about, or

2) SCO's lawyers have made Dr. Cargill an unwitting participant in a
lie-by-omission (tell only the parts of the truth that support the desired
conclusion).

[ Reply to This | # ]

Streams, LiS, and Caldera's Netware for Linux
Authored by: dyfet on Monday, July 03 2006 @ 02:25 PM EDT
I actually recall the referenced email from Alan Cox back in 1998. That was from a time that I followed activity on the kernel list, since I was doing some work on kernel telephony drivers back then. I have not followed the kernel list in a long time, though, having other areas of interest since then.

I also do recall the effort and noise Caldera made at the time about trying to get streams into the Linux kernel, as well as the marse_nwe package. Mars_nwe was I imagine popular for those who had dos and Microsoft Windows (3.x) clients with the old netware ipx client stack. Using a GNU/Linux machine as a ipx file and print server I guess made some sense for supporting those legacy environments. Mars_NWE is apparently still around. There was also once an appletalk server for GNU/Linux (netatalk).

[ Reply to This | # ]

At the trial
Authored by: eric76 on Monday, July 03 2006 @ 02:34 PM EDT
It seems almost a shame that the jury at the trial won't get to see the most
easily disposed of claims.

Without seeing everything leading up to the trial, it is difficult to think that
they are going to understand much about the case.

[ Reply to This | # ]

STREAMS methods and concepts
Authored by: alangmead on Monday, July 03 2006 @ 02:35 PM EDT
Apple's OpenTransport networking facility, the one used in pre-OSX (pre Unix) versions of their operating system were based on STREAMS and XTI. I'm not sure if The SCO Group would count this a exposing their methods and concepts, because frankly, their theory makes little sense to me so far.

[ Reply to This | # ]

Caldera's Netware for Linux in 1996
Authored by: Chris Lingard on Monday, July 03 2006 @ 03:07 PM EDT

I have a boxed set of Caldera Network Desktop from 1996. It predates the version mentioned in the article. The CD and books explain that the Linux kernal and the FSF stuff are licenced under the GPL. The CREDIT file on the CD is interesting.

Caldera is:

Bryan Sparks, Ron Holt, Jim Freeman, Greg Page, Ransom Love, Nick Wells, Sarah Lee, Stan Covington, Tim Bird, Allan Smart, Doug Cooper, Debi Thompson, Lyle Ball, Dean Taylor, Kevin Gee, Jon Meyer, Ming Jiang,

Additional thanks to:

Jeff Barr (Vertex), Ralf Flaxa (LST), Stefan Probst (LST), Raymund Will (LST), Ralph Yarro (ArtFX/NFT), Marc Ewing (Red Hat), Donnie Barnes (Red Hat), Erik Troan (Red Hat), All of our beta testers, Banjo the Sea-Monkey(R),

Members of the original Novell "Corsair" team:

Peter Bartok, Tim Bird, Ken Ebert, Jim Freeman, Rob Hicks, Ron Holt, Ransom Love, David Mortenson, Greg Page, Doug Smith, Bryan Sparks, Nick Wells, Steve Willis, Ralph Yarro

So in 1996 Ralph Yarro was working for Novell, the Corsair project was Linux based, and he was collaborating with Caldera to create a Linux distribution.

Though it is a Linux CD, using mostly GPL packages, the licence to use was for one computer only, They were selling optional, copyright binary packages then, "Caldera Internet Office Suite" for $329, and Caldera WordPerfect and Motif Bundle" for $250.

[ Reply to This | # ]

One nitpick
Authored by: Anonymous on Monday, July 03 2006 @ 03:29 PM EDT
Another excellent expoSCOure...

But one nitpick

From the article: "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."

Okay, where in SCO's complaint or in any public court document, does it say that
SCO's claims are confined to the kernel?

In fact, if you look back over the record, you will see that

1. SCO have been pretty fastidious about saying their claims are about the Linux
"Operating System" (and of course "Operating System"
includes more than kernel)

2. If you go back and check when SCO want to deep dive into AIX CMVC, and IBM
eventually produced the "base operating system" [IBM's words], SCO
then complained that they wanted additional stuff such as application layes on
top of AIX (I can't remember the exact words, but its in the record), as well
hardware related information, microprocessor code...

Quatermass
IANAL IMHO etc

[ Reply to This | # ]

Second nitpick
Authored by: Anonymous on Monday, July 03 2006 @ 03:42 PM EDT
"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's 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?"


I believe that:

1. SCO's claims about streams are in Cargill report.

2. The Cargill report is SCO's in support of claim that Linux infringes SCO's
copyrights. This isn't an offensive claim... but is a defense to IBM
Counterclaim 10 (and then the follow-up IBM Counterclaims such as IBM's Lanham
Act claims relating to its Linux activities and SCO's public statements about
those activities infringing SCO's copyrights etc.)

3. As SCO points out in their opposition to IBM's most recent motion, the Linux
copyright infringements that SCO alleges, weren't put into Linux by IBM [SCO
then uses that as a purported justification for not listing them in their
December disclosures, but that's another story]

4. As you will recall, IBM's Counterclaim 10 essentially says that IBM's Linux
activities do not infringe SCO's copyrights. IBM's Linux activities include
IBM's copying of the whole of Linux, including IBM contributions to Linux and
non-IBM contribution to Linux (so if IBM wins CC10, it more or less clears
everybody). We wanted it that way. IBM wanted it that way. Whereas SCO would
have preferred the case just to be about IBM contributions.

No matter what, in the case scope as eventually chosen by Judge Kimball, IBM
Counterclaim 10 is in the case, and does encompass IBM contributions and non-IBM
contributions to Linux.

5. Now SCO is defending against Counterclaim 10. Therefore they need to allege
that some parts of Linux infringe their copyrights, whether IBM contributed that
code or not, therefore they chose to allege that Linux infringes SCO's
copyrights because of non-IBM contributions...



So me, it's not looney that SCO is bringing up these issues in the IBM case.
These issues ARE part of the case. (To me, the looney part is that SCO's claims
are so weak and their earlier public statements so vociferous)


Quatermass
IANAL IMHO etc

[ Reply to This | # ]

Streams, LiS, and Caldera's Netware for Linux
Authored by: Anonymous on Monday, July 03 2006 @ 03:46 PM EDT
I am so glad that IBM did not settle - we can all see what frauds Daryl
SCO/Caldera (whoever or whatever company they are) are.

I think them going out of business is letting them off too easy - I would like
to see someone do jail time and be made an example out of.

this lawsuit was nothing more than stock manipulation - period.

[ Reply to This | # ]

Streams, LiS, and Caldera's Netware for Linux
Authored by: BsAtHome on Monday, July 03 2006 @ 05:19 PM EDT
Just for the record... There is a Sreams framework for FreeBSD. You can find it at FreeBSD SysVR4 Emulation.

The FreeBSD Streams emulation package has existed since a long time (at least 1998) and there are copyright notices in the files back to 1994. The whole lot includes a complete emulation layer for SVR4 (!) that is ancient compared to Linux' compatibility with POSIX and therefore SVR4.

Please also note that there is a complete description of errno.h, syscalls etc., etc.. Oh, and did anybody tell anyone that *BSD also implements ELF?

---
SCOop of the day

[ Reply to This | # ]

Did Caldera ever do any good?
Authored by: Anonymous on Monday, July 03 2006 @ 05:41 PM EDT
It's almost embarrassing to read here how Alan Cox eviscerated the whining
arguments of the employee from Caldera. Hopefully
"chrisc@caldera.com" was *not* actually a programmer, because he
sounded rather foolish (from Alan to ChrisC: "You may not
be a good enough programmer to see that...").

But my understanding was that Caldera at some point did some good, but I cannot
recall what that may have been. It seems like they had some good technical
people, but that the company was always despised because of it's chronically bad
management (led from the top by Ralph Yarro).

[ Reply to This | # ]

ChrisC is Chris Clark
Authored by: PeteS on Monday, July 03 2006 @ 05:56 PM EDT
On this changelog you can actually see this entry:

Thu Feb 19 15:53:06 1998 Chris Clark chrisc@caldera.com

* nls/genlib.c (getmsg): Fix the ddd sequence.

He appears to have worked on the Netware parts of the Caldera distribition.

PeteS

---
Artificial Intelligence is no match for Natural Stupidity

[ Reply to This | # ]

Streams, LiS, and Caldera's Netware for Linux
Authored by: Anonymous on Monday, July 03 2006 @ 06:01 PM EDT
"If AT&T meant to keep Streams to itself, a big old secretive method or
concept..."

"First, why is it mentioning Streams in connection with IBM?"

It appears from the recent IBM court filings that the Cargill report was filed
in defense of IBM's counterclaims (including the 10th), not in support of SCO's
own claims. All they need is a crazy interpretation of the copyright act (and
ignoring estoppal etc) together with evidence that IBM is (has been?) copying
LiS in some form as part of their Linux activities.

[ Reply to This | # ]

Two questions
Authored by: Anonymous on Monday, July 03 2006 @ 07:00 PM EDT
1) Maybe Caldera knew about LiS in '96 or '98 but wasn't this before they
purchased SCO? Wouldn't it have to be proven that they were aware of the
possible copyright infringement AFTER the SCO acquisition?

2) Is it possible that SCO is making this streams claim so IBM's motion (can't
recall the number) for a declaration of non-infringment with linux activites
will fail?

[ Reply to This | # ]

Caldera was not the first to add STREAMS--it's a standard!
Authored by: xtifr on Monday, July 03 2006 @ 07:33 PM EDT

IIRC, there was another company, possibly European, possibly named "Blue Moon" which did the first implementation of Streams for Linux. Their goal was to create a version of Linux that could be certified as a "real" UNIX by meeting the Open Group's UNIX spec. And their implementation of Streams was just as soundly rejected by the kernel dev team.

This is an important point that seems to be being overlooked: Streams, for all that the Linux devs rejected them, are part of a standard, not a proprietary method of Caldera's/SCO's! This is similar to SCO's claims about ELF, except that Streams are part of a much broader standard.

In addition to PJ's list of publications, I would suggest that you can learn more about Streams (if you care) by reading the UNIX standards published by the Open Group (at least, the UNIX95 and UNIX98 standards--I'm not sure about the more recent ones).

---
Do not meddle in the affairs of Wizards, for it makes them soggy and hard to light.

[ Reply to This | # ]

My IP Feels Violated
Authored by: Anonymous on Monday, July 03 2006 @ 08:01 PM EDT
I was fishing through the LKML for information on Dynix when I did something
wrong and somehow by chance ended up at a random message where Alan Cox was
talking about streams and how Caldera wanted them in Linux against much
opposition.

I immediately realised that this was an important find in the SCO story and went
to Groklaw to report this stupendous find -- to find out that this same message
was reported in a story published 6 hours earlier (its a nice summer day - what
are you doing on your computer at that hour?).

While I don't have copyright on this, I can say that I own the method and
concept - find good story (concept) - post to Groklaw (method). Everyone who has
read this story owes me $699. Please make out the cheques to
"Anonymous". Thank you.

[ Reply to This | # ]

An analysis and Translation of the above.
Authored by: BitOBear on Monday, July 03 2006 @ 09:15 PM EDT
Some computer words are like some legal words, that is you have to be an expert
to use them, and even if you are an expert you still might have problems using
the word with complete correctness.

I would strike the sentence where PJ talks about Streams being an interface to
the Linux kernel.

I am splitting a technical hair here, but it may be important for some people to
understand. In computer science an "interface" is (arguably) a point
where two otherwise distinct features, hardware devices, or data representations
(etc) agree to and use a common (e.g. well documented) means of exchange. To be
an "interface" a thing must represent a point of change; change of
format, or context, or something.

The word is also _hideously_ recursive (or self decomposing, or something).

Let's take the “Ethernet Interface” on your computer. It has a wire interface
where you plug in the Ethernet cable. It has a bus interface where you plug it
into the slot on the motherboard. It has an Ethernet interface chip that can
electrically drive the wire on one side and can electrically drive the memory on
the other. The computer needs drivers to copy the card-memory buffers (data
structures which are essentially pictures of Ethernet packets in dedicated
memory in the interface card) into kernel-memory (as data structures with
sort-of pre-digested pictures of Ethernet packets in a ready-for-kernel-use
format). Then the Linux kernel networking system has an API (Application
Program Interface) that the driver is written in, and it _offers_ an API that a
Linux program uses to talk network concepts to the rest of the world.

So “interface” is a really tricky context dependent word.

“The Interface to the Linux Kernel” is the syscall. There is an API for this
interface. The basics are, however, that each system call to the kernel gets a
number (hence Mr. Cox's harping on Caldera never asking for a pair of reserved
syscall numbers from Linux) and that number is then “known” and both the kernel
and the application (or actually the syscall application library) know that when
they see a particular number in the system call, that a particular request is
being made. Part of that “knowing” is the knowing where and how the data that
must flow between kernel and program can be found. A syscall number is
basically a promise to perform (or fail to perform) in a well-understood way.

Since adding a syscall to the Linux kernel is a promise, there mus be some code
to back up that promise, and so there must be someone to back up that code.
This is why there are “teams” associated with Linux kernel development. There
is the networking team, and the usb team, and the scheduler team, and so on.
Many of those teams are kind-of informal, or have a large or highly changeable
membership. But there is a certain resistance to issuing new numbers if there
isn't going to be enough value, or enough committed potential team membership,
to keep the promise.

Caldera's first mistake was trying to put stuff in the kernel without getting a
set of _official_ numbers. By the time of Mr. Cox's email, the pool of official
numbers had _already_ grown to the point where the LiS' arbitrary (unofficial)
numbers may have _already_ come into conflict with actual, issued, official
numbers. (This is a main danger of arbitrary, un-blessed additions.) The LiS
people had other choices; they could have made their system calls map over the
“ioctl” syscall (which is “I/O Control” and serves as a catch-all syscall for
this sort of thing). [Using ioctl is _very_ arguable, since streams itself has
an ioctl element, but for an unofficial extension, the extra indirection would
have been more stable as an add-on and could have been naturally dropped
directly when the syscall numbers were issued.]

So Caldera's second mistake was in demonstrating that they really didn't
understand how to work with Linux or the community. They wanted to add
something to the kernel, but having done so, they offered no warrant of support
(e.g. No team community) nor of understanding (they botched the first pass badly
by using very questionable technique for their unofficial approach).

Meanwhile...

“Streams” is a _style_ of data handling. The “socket interface” is another
style. I use the word style because there isn't really another good
common-English word for it. In both cases an application program lays out data
in a manner that matches the expected interface and then makes a syscall; its
just that the layouts and techniques are totally dissimilar. A good comparison
might be written English to written Chinese. You can represent all the data in
both, but in one you go left to right and in the other you go right to left; in
one you have letters that make up words, in the other you have icons
(pictographs?) that represent concepts. It's a fundamental stylistic difference
regardless of what content you are trying to deliver.

In the socket interface (the one that is in the Linux kernel today) the
application represents its data in a format that is _very_ like the format the
driver will present to the card. Consequently it is often possible to pass the
data from the application all the way down to the card without ever having to
change its layout. This directly infers the “No-Copy” improvements Mr. Cox
cites. This isn't an accident, by the way, the socket interface was modeled on
common network card interfaces of the time of its invention, and later cards had
their interfaces modeled on the then-existing socket interface. (Open [pseudo]
standards often evolve by consent and convenience 8-). The important thing here
is that for newer/faster networks it is possible to get the data from the wire
to the user without moving it about in intermediate places. (Hence memory not
getting faster the way interfaces have, etc, in the email).

Streams (e.g. “STREAMS”) is a style that was (more or less) at the leading edge
of the original “micro-kernel” movement. It is tied to some of the more archaic
(or at least literal) Object Oriented Design principles. In streams there are
only “messages”, and each part communicates with each other part by creating and
forwarding a message. Each part then has an incoming-message queue (e.g. thing,
list, whatever) for messages arriving from each direction (towards device and
towards user) and it has its own processing procedure for messages going in each
direction. It also had, up at the syscall level, two fairly natural interfaces,
one to send a message, and one to get a message [hence needing two syscall
numbers].

The inherent performance hit comes from the fact that streams messages must come
from streams message memory (streams buffers) and must have streams message
headers and streams message bindings etc. Also, since each step of the STREAM
has its own procedure (that must be invoked by the STREAMS scheduler) you get a
complex counting and processing burden for each an every step of each and every
message.

Now LiS is, on it's face, an implementation of the (well documented) STREAMS
interface. That is, it knew about “streams messages”; which are _not_
necessarily going out over a network, they are how all the parts of a STREAM
communicate with each other, and only some of which are going to turn into
network packets (messages). It provides the two syscall to get and send
messages, and its underside eventually just turns the messages into socket-based
data structures. So LiS is a translator. It is _pure_ overhead. But in the
same way that I don't speak/read/write Chinese, and so I would _need_ a
translator to deal with Chinese, Linux doesn't speak STREAMS, so any application
or kernel module that _only_ speaks STREAMS would need LiS.

[Aside: I have, quite recently, brought up STREAMS on the Linux kernel mailing
list. I believe that with the existing kernel systems like tasklets etc one
could do some very Streams-like processing which would allow the actual network
card buffers to be passed about inside the kernel. That is, for the cost of
some of the reference counting, we could skip even more of the copying. In
short, In My Humble Opinion (IMHO) some baby was thrown out with the bathwater.
But that is not anything that exists in any code, it's just an argument. 8-)]

So, here is the summary of all of the above:

1) the existing kernel handles its data in a style completely distinct, and
fundamentally incompatible with STREAMS, making the Streams allegations a
complete joke.

2) If someone were willing to do the work and own the project, they could _add_
Streams to the kernel with an official set of syscalls.

3) If they got the official syscalls issued to them that doesn't mean that there
would be any official streams code coming out of kernel.org (e.g. The official
kernel, in the absence of the add-on streams code, would just return “not
supported”) but it would be safe to then publicly add the possibility and let
the community vote.

4) Caldera didn't do any of that, but they were told they _could_.

5) Even if they did, it would probably be met with a “high immune response” by
the Linux kernel community at large because streams-isms (styles) would then
tend to start encroaching in on the rest of the kernel.

--

Again, as a “reasonably well informed expert in the field” I nearly _choked_ on
my sandwich when I first read the allegation that Linux had “Streams technology”
in it. That isn't even remotely true. And as far as LiS is concerned, you
probably couldn't even start to use it in 2.4 or later (e.g. In the kernels at
issue in SCO vs IBM) without a whole bunch of work. Even the “interface”
provided by Caldera is now left well behind. That is, it's dead.

[ Reply to This | # ]

If Cargill was SOOOO completely wrong about Streams...
Authored by: Anonymous on Monday, July 03 2006 @ 10:17 PM EDT
Dr. Thomas Cargill said that Linux infringes SCOG's copyrights to SVR4.

However, he used Streams as one leg for his conclusions. He obviously is non competent with Streams. So, is he just as non competent with UNIX and Linux across the board?

Did Dr. Thomas Cargill just demote himself through a very public display of non competence? Would you take a UNIX or Linux class from him now? Would you trust him when he says Linux infringes now?

[ Reply to This | # ]

    This was never a law suit.
    Authored by: kawabago on Monday, July 03 2006 @ 10:40 PM EDT
    This case was always an armed extortion attempt, the law was the weapon. Too
    bad SCO was looking down the barrel of thier own weapon when they pulled the
    trigger.

    [ Reply to This | # ]

    Streams in Novell case too
    Authored by: jmc on Tuesday, July 04 2006 @ 06:00 AM EDT
    It's down as item 17 in the list of alleged copyright infringements by SuSE in
    the 2nd amended complaint.

    Incidentally both of the links in the "Novell timeline" are wrong for
    that - the PDF link gives a 404 and the text link takes you to K Bracebill's
    declaration.

    [ Reply to This | # ]

    Does this matter now?
    Authored by: Anonymous on Tuesday, July 04 2006 @ 07:02 AM EDT
    Does this matter now after most of the claims have been rejected?

    [ Reply to This | # ]

    from streams-1.30.98.tar.gz/LICENSE/README
    Authored by: Anonymous on Tuesday, July 04 2006 @ 11:30 AM EDT
    "This is LiS (SVr4 conformant STREAMS for Linux), also known as 5LiS. LiS does not contain any code from SVr4 u*x and as of today is under GNU General Public License (GPL)"

    - Francisco J. Ballesteros

    [ Reply to This | # ]

    Importance of text on GL, and open courts
    Authored by: webster on Tuesday, July 04 2006 @ 01:33 PM EDT
    .
    0. Sorry if I repeat anyone. I haven't read anything since the update.

    1. quote from update: "....as readers have posted some very valuable
    information. And I want to thank Groklaw member dmomara for reminding me of the
    following detail."

    That detail wast the letter denying STREAMS, LiS distribution by a misled SCO
    lawyer,

    2. Groklaw member, dmomara, possibly remembered reading this item. Maybe the
    search and text helped this member to find the letter quickly for PJ. No wonder
    PJ and helpers, scanners and editors, spend all hours getting this stuff up in
    text. It is greatly appreciated.

    3. If SCO's own lawyers don't know the truth, how can they even begin to make
    good faith representations in court? IBM will find a way to make this episode
    apparent to the Court in pleadings, a footnote, no less.

    4. After this case some litigants will be able to forcefully argue to a judge
    that sealing and non-disclosure agreements may retard the search for truth and
    obscure malfeasance. Trade secrets will not weigh heavily against these
    considerations.



    ---
    webster

    [ Reply to This | # ]

    STREAMS, LiS, and Caldera's Netware for Linux - Updated
    Authored by: fredex on Tuesday, July 04 2006 @ 04:14 PM EDT
    I'm posting this with some fear and trepidation: fear that someone will point
    out to me how stupid I am becauase I can't see the obvious...

    Regarding the update (based on dmomara's information), and the three numbered
    items PJ posts in that update, I've looked at both the letter and the Exhibit G
    she links to. They both link to the same document, is this correct? I would
    think it isn't.

    in neither case do I find in the linked document the text of the 3 numbered
    items in the update.

    So what I guess I wish to know is am I misunderstanding something PJ said there,
    or is there an error in the links, or something else?

    Fredex

    [ Reply to This | # ]

    That Alan Cox email is great
    Authored by: Anonymous on Tuesday, July 04 2006 @ 06:39 PM EDT
    My favorite part of the Alan Cox bit, besides the [redacted]s, is where he
    says:

    >> 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 ?

    What excellent questions...

    [ 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 )