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

Username:

Password:

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

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
A Word to SCO from the Open Group's Website
Wednesday, July 19 2006 @ 10:20 AM EDT

Now that we have read SCO's incredible Objections to Judge Brooke Wells' Order (which I call their "How are we supposed to know what IBM did?" appeal), I'd like to say a brief word about some of the items SCO would like to sue about, and most specifically about methods and concepts. SCO can't seem to find them in their code, if it even is their code, despite having every AIX and Dynix and Linux release since the founding of the world. So let's show them where they can find some methods and concepts and some code too. Groklaw member Beowulfe sent me some very helpful links and started me on a riff.

Might I ask them to visit this page on the Open Group's web site, and start to look around?
This standard has been jointly developed by the IEEE and The Open Group. It is both an IEEE Standard and an Open Group Technical Standard.

Abstract: The 2004 edition incorporates Technical Corrigendum Number 1 and Technical Corrigendum 2 addressing problems discovered since the approval of the 2001 edition. These are mainly due to resolving integration issues raised by the merger of the Base documents.

This standard defines a standard operating system interface and environment, including a command interpreter (or "shell"), and common utility programs to support applications portability at the source code level. This standard is the single common revision to IEEE Std 1003.1-1996, IEEE Std 1003.2-1992, and the Base Specifications of The Open Group Single UNIX Specification, Version 2. This standard is intended to be used by both applications developers and system implementors.

So that sets the stage. The Open Group is about standards, specifically standards regarding Unix. It describes itself like this on the homepage: "The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of Boundaryless Information Flow™ will enable access to integrated information, within and among enterprises, based on open standards and global interoperability."

Not if SCO can stop it. SCO isn't about boundaryless information flow. They have a different dream.

I think they will find if they visit the Open Group's website that SCO has a problem with items on the list of things it would like to sue about. For example, take STREAMS and the various system interfaces SCO fusses about. Here's the Open Group's page on System Interfaces: General Information. And that takes you to a most complete explanation of how STREAMS work and which IEEE document provides access to STREAMS modules. Here's the Standard I/O Streams page. I think those methods and concepts are out there, guys.

Or perhaps you'd like to read all about errno.h. Here you go, the Error Numbers page. And here's a helpful page called "Internationalized System Calls and Libraries":

This Product Standard defines the basic operating system interface (and header files) normally invoked directly from C Language programs. It includes full conformance to ISO/IEC 9945-1:1990 (POSIX-1). The ISO standard defines only a subset of the operating systems interfaces required by application developers and additional interfaces and features have been added to meet their needs. To satisfy internationalization requirements the Product Standard provides for full data transparency allowing flexibility in the choice of coded character set(s) employed.

Notice header files? Here's Caldera's register of certification to the standard for internationalized system calls and libraries. If you read their Brand Certificate [pdf], you'll find they first registered in 1995 and to do so they had to get certification from the Open Group, not the other way around. And *now* they want to sue people?

So, does that mean SCO is trying to sue people for using standards? Why, yes. I believe it does.

Here are some more standards, the Open Group's Standard Unix Utilities page -- whatever you want to know about how Unix does its thing; and here's the General Concepts page (or as I like to think of it the Unix Methods and Concepts page). Why, bless my stars. It seems the entire world is allowed to know about and talk about and share a mountain of Unix methods and concepts.

Then, just so SCO doesn't get any bright ideas that their troubles will be over if they just sue the Open Group too, here's a link to a UC Davis paper, The Executable and Linking Format (ELF), dated 1998 that goes into exquisite detail about ELF, beginning like this:

The executable and linking format (ELF) was originally developed by Unix System Laboratories and is rapidly becoming the standard in file formats. The ELF standard is growing in popularity because it has greater power and flexibility than the a.out and COFF binary formats. ELF now appears as the default binary format on operating systems such as Linux, Solaris 2.x, and SVR4. Some of the capabilities of ELF are dynamic linking, dynamic loading, imposing runtime control on a program, and an improved method for creating shared libraries.

1998 guys. The "standard binary format". If SCO wanted to sue over ELF, the time was back in the '90s, and not IBM.

And then, the cherry on top, an article all about ELF in Linux Journal from 1995, which explains it, shows code, and ends like this:

For more information about the ELF file format, you can obtain the ELF specifications from a number of sources--you can try ftp.intel.com in pub/tis/elf11g.zip. The specifications are also available in a printed format. See SYSTEM V Application Binary Interface (ISBN 0-13-100439-5) and SYSTEM V Application Binary Interface, Intel386 Architecture Processor Supplement (ISBN 0-13-104670-5).

Nowadays, SCO follows a different standard, the FUD Works Best If It Isn't Too Specific protocol.

But, you may say, SCO may not know. Perhaps they are not tech-oriented.

Folks. They sell Unix software for a living. They write it. At least they used to. These days, they seem to be more about grabbing FOSS code and calling it good. Here's Caldera's 2003 Conformance Statement for UnixWare 7.1.3 on the Open Group's website. And here's a presentation by the Open Group at SCOForum 1998. They know. Maybe they hope the judge doesn't? And if their lawyers didn't know, I hope they will find this article very helpful.


  


A Word to SCO from the Open Group's Website | 114 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here...
Authored by: emperor on Wednesday, July 19 2006 @ 10:40 AM EDT
If any.

-roman

---
He who fights with monsters might take care lest he thereby become a monster.
And if you gaze for long into an abyss, the abyss gazes also into you. -
Nietzsche

[ Reply to This | # ]

Alarming.
Authored by: gfolkert on Wednesday, July 19 2006 @ 10:41 AM EDT
Exactly what I was thinking. I happened over to the Open Group's site a while
back and was tracking things down.

PJ, you just have a nose that knows.

[ Reply to This | # ]

Off Topic
Authored by: emperor on Wednesday, July 19 2006 @ 10:45 AM EDT
Make links clickable, please.

-roman

---
He who fights with monsters might take care lest he thereby become a monster.
And if you gaze for long into an abyss, the abyss gazes also into you. -
Nietzsche

[ Reply to This | # ]

A Word to SCO from the Open Group's Website
Authored by: Peter H. Salus on Wednesday, July 19 2006 @ 10:50 AM EDT

There's little to say, Pamela. SCOG keeps getting itself
deeper and deeper into a self-constructed morass. Just
think, several of the system calls in your previous piece
were in v1 (mount and umount), v6 or v7. And these all
preceeded the incorporation of original SCO.

If someone at BSF had been assigned to reading some history
of UNIX, Minix and Linux in 2003, we might not have been
spared the suit, but we might have been spared some of the
arrant stupidity.

---
Peter H. Salus

[ Reply to This | # ]

Q.E.D.
Authored by: ewe2 on Wednesday, July 19 2006 @ 11:19 AM EDT
plain as the nose, as they say.

[ Reply to This | # ]

SCO once documented ELF
Authored by: Chris Lingard on Wednesday, July 19 2006 @ 11:56 AM EDT

Just doing a Google search for ELF I found this GDB: The GNU Project Debugger

In the page SCO is listed, they once supported open source. Do not bother looking, it does not give ELF inforation now. It points to the offer to become a SCO developer:

GDB interfaces and standards

Object files and debugging formats

* SCO's page contains specifications for the ELF executable format, x86 calling conventions, and more.

So SCO once posted details of the ELF standard themselves, another page has disappeared. And it is not in the archives, SCO have changed the robot.txt to delete old copies.

[ Reply to This | # ]

Formula
Authored by: Anonymous on Wednesday, July 19 2006 @ 12:04 PM EDT
Speculation:

1. Some M.I.T. kid "invents" something that compares compiled code to
compiled code, looking for similarities in the generated code.

2. SCO catches wind of this breakthrough, uses it, convinced there is copied
code between Linux and their code, because of some matches. (Perhaps many
matches).

3. SCO is aware (or made aware) that compiled code compared to compiled code
may show matches on the same architecture simply due to the similarity in
compiler optimizations for very generic programming methods. However, SCO
perhaps thinks "yay money!" and launches a suit designed to shakedown
IBM.

4. SCO uses discovery to try to put together the exact same build scenarios as
IBMs code, hoping that they can trace from the compared compiled code back to
the (pre-compilation/pre-optimization) source, hoping to find literal copying,
or "hail mary!" methods and concepts. Initially, they find some
header files that look remarkably similar, which any UNIX guru would realize
were due to ABIs, standard error codes, etc. -- compatability things not subject
to protection.) However this gives SCO the chance to make rediculous
statements, put on a dog and pony, and otherwise attempt to "scare"
the world about Linux and pressure IBM.

5. SCO, needing money to continue the fight, arranges with Microsoft to prop up
SCOs stock price with "gifted" cash (below the IRS inducing $12k a
year) payed to thousands of puppets who try to keep SCOs stock from scaring off
legal help.

6. Rest is history (in the making?)

All speculation, of course, but reading between the lines isn't hard with these
guys. Where's the SEC? Where's the FBI? Where's justice?

Hmmm...

[ Reply to This | # ]

They knew and they know
Authored by: Anonymous on Wednesday, July 19 2006 @ 12:12 PM EDT
They are after all the UNIX company!

As Caldera they had to know. OldSCO knew. TSCOG knew and knows. Darl knew and so
do his lawyers. They are not just some software company, they are an OS company.
They do not have a special force field that prevents them from knows the
standards that every single company working on UNIX or other OSes knows. They
knew plain and simple.

Since we know they knew, and still do, we need to work extra hard to prove them
wrong in court. Not just vs IBM, but all future legal actions they might take.
We need to provide a layer of legal immunity to FOSS.

To this end we have to push to make it known that Darl and company appear to be
running a scam, and that the people running TSCOG need to exposed and brought
before a court of law for their actions.

It is clear to me that they are suing on whatever charges they can try and make
up, so they can shake down IBM and scare people from Linux. They must be
stopped. The scam must be exposed. The executives of TSCOG must be brought to
justice.

That is why we are all here. That is why PJ is here. Groklaw should be mirrored
1,000 times, to protect it as an asset in the effort of freedom.

[ Reply to This | # ]

Standard I/O streams vs. STREAMS
Authored by: TimMann on Wednesday, July 19 2006 @ 03:08 PM EDT
Confusingly, standard I/O streams and STREAMS are two entirely different
things.

Standard I/O streams are something that every Unix-like system has had from the
dawn of time. MS-DOS has them too. The standard I/O streams are simply a
process's default source of input (stdin), default place to write output
(stdout), and default place to write error messages (stderr). They got called
"streams" as a generic term for something that could be an open file,
a device (e.g., terminal), a pipe, or whatever, and that should not be assumed
to be seekable.

"STREAMS" with their concept of pushing modules, etc., were invented
much later. A standard I/O stream isn't generally a STREAM. Whoever invented
the term STREAMS, reusing a Unix term that already existed with a different
meaning, ought to be shot.

[ Reply to This | # ]

A Word to SCO from the Open Group's Website
Authored by: Anonymous on Wednesday, July 19 2006 @ 03:19 PM EDT

When SCO claims rights to "methods and concepts" are they actually claiming rights to specific implementations of those methods and concepts (and derivative works)?

I know this has noting to do with patents, but let me just make an analogy to get my point across:

    I don't think you can patent the idea of an airplane, but you can patent a specific implementation, or specific parts of an implementation.

In this sense, perhaps they are not claiming ownership of (for example) Streams, but that the specific implementation of Streams as used in "their" (sic) UNIX is what has been improperly incorporated into Linux. So, perhaps saying that Linux had "X" before SCO or that there is a standard API and sementics for "X" does not address the real issue -- did SCO's (again, sic) implementation get hijacked?

[ Reply to This | # ]

ELF
Authored by: HighlandSun on Wednesday, July 19 2006 @ 03:27 PM EDT
I still have my System V ABI books on my book shelf, published by Prentice Hall,
Copyright 1990 AT&T. Specifically, the Processor Supplements for Intel i860,
Motorola 68000 Family, and SPARC. These contain the processor-specific features
relevant to ELF and a number of other Unix system features. ELF was already
publically documented and quite well known back in 1990. All of the data
structures, methods and concepts etc. were published so that anybody could
implement them compatibly, on all of the major microprocessor architectures of
the day.

If anyone needs specific titles or ISBN numbers I can provide them, though I'm
sure they're easy enough to find online...

[ Reply to This | # ]

  • SVID publication - Authored by: Anonymous on Wednesday, July 19 2006 @ 06:19 PM EDT
A Word to SCO from the Open Group's Website
Authored by: Anonymous on Wednesday, July 19 2006 @ 03:57 PM EDT
It was once implemented!

[ Reply to This | # ]

A Word to SCO from the Open Group's Website
Authored by: Anonymous on Wednesday, July 19 2006 @ 04:02 PM EDT
IANAL as well.

If all that is done was removing the copy from the web site,
all is good.

However, if IBM requests this information from SCO, and SCO responds that the
document no longer exist, SCO would be slapped with very severe sanctions.

When you are in litigation, you have to take extra care about archiving and
preserving documents that you think might be relevant. The web page in question
would fall squarely in this category.

I would think their web site is backed up, and copies kept for a certain amount
of time, so I believe all IBM has to do is ask. Either IBM get what they want,
or SCO is in some hot water.

[ Reply to This | # ]

Look at all this standards compliance Caldera/tSCOg still tout on a public webserver
Authored by: karl on Wednesday, July 19 2006 @ 05:59 PM EDT
Hey folks, here's some more. It's really quite impressive how much original SCO and Caldera participated in the standards processes and worked to make their products conform with published standards.

From a Caldera webserver...

Why conform to a standard?

There are many benefits to using a development system that conforms to industry standards; more benefits are realized when the target environment for your application is a system that also conforms to industry standards.

The standards to which UnixWare 7 conforms can be classed as binary and source:

Binary standards

Aim to permit compiled code to be run on any implementation of a particular family of processor (such as the Intel486 family). If the system on which you develop your source code complies with the binary standards for that system's processor, then you will need to compile your source code only once and it will run on any implementation of the processor family that also conforms to the standard, regardless of manufacturer.

Source standards

Enhance compatibility of source code across all implementations of the UNIX system, the aim being that any program written to these standards need only be recompiled (with no source code changes) using a compliant development system on the target system to run on that system.

Binary standards can be seen as a super-set of the source standards for a particular processor architecture.

For example, the X/Open Portability Guide has both a binary and source standard. If you conform to the binary standard, then you automatically comply with the XPG source standard. Your code will not only run without compilation on any binary-compliant implementation of the processor family on which it was developed, it will also run with only a recompile on any system that complies with the source standard.

Binary standards conformance

UnixWare's powerful application run-time environment is designed to conform to the following industry binary standards; any binary executable that conforms to these standards is intended to run without modification on UnixWare:

UNIX®95
X/Open UNIX 95 Brand (Single UNIX Specification)

XPG4
X/Open Portability Guide, Issue 4 Version 2 Base Profile Brand

ABI
System V Application Binary Interface Specification, 3rd. Ed.

iABI
System V ABI Intel Processor Supplement, 3rd. Ed.

iABI+
ABI+ for Intel Architectures Specification 3.0

iBCS2
Intel Binary Compatibility Specification, Version 2

COFF
Common Object File Format

ELF
Executable and Linking Format

SCO DDI
Device Driver Interface Version 5 or greater

ICCCM
The X Consortium's Inter-Client Communication Conventions Manual

sendmail
Industry-standard mail and messaging protocol See the section ``UNIX95 conformance'' for a complete description of how UnixWare 7 conforms to the UNIX95 standard.

Source standards conformance

The UnixWare 7 UnixWare and OpenServer Development Kit (UDK) -- the compilers, system headers, libraries, and development environment -- is designed to comply with the following source standards:

POSIX
Portable Operating System for UNIX (POSIX.1, POSIX.2 and POSIX.4); ISO 9945-1:1990; IEEE Std 1003.1-1990

UNIX®95
X/Open UNIX 95 Brand (Single UNIX Specification)

XPG4
X/Open Portability Guide, Issue 4 Version 2 Base Profile Brand

SVID3
System V Interface Definition, Issue 3

FIPS
Federal Information Processing Standard 151-2 (IEEE Std 1003.1-1990 with all extensions)

ISO/IEC 9899:1990
C Language Standard (plus ISO MSE amendment -- EN 29899)

[ Reply to This | # ]

What's the big deal?
Authored by: Anonymous on Wednesday, July 19 2006 @ 06:58 PM EDT
I don't understand why the Single Unix Spec should be news, or why it's
particularly relevant, given that the System V Interface Definition is (still)
available online from SCO. Also notice that SUS explicitly doesn't define system
calls or, for instance, details of the file system implementation.
Compiler/utility hackers know all this stuff since we need(ed) to consult it for
source code portability and binary generation, obviously without any contractual
liability.

Possibly more interestingly, the PowerPC ABI supplement describing that version
of ELF was a joint SunSoft/IBM production, Sun Part No:802-3334-10
Revision A, September 1995. It's All rights reserved, but also online from
SCO.

By the way, the FSF has copyright assignments/disclaimers from The Santa Cruz
Operation, Inc.and Caldera International, Inc.for their contributions to the GNU
tool chain (which is advertised as supported by SCO on OpenServer).

Dave Love

[ Reply to This | # ]

Devil's Advocate
Authored by: Anonymous on Wednesday, July 19 2006 @ 09:14 PM EDT
Not that I want to give them a clue, but within the Methods and Concepts strategy most of these standards surely only represent the "Concepts". They tell the developer of a Un*x-like OS what to write, but not how to write it. That would be the "Methods", the specific algorithms, control flow, module design, etc., needed to implement the specification. At least, that's what I suspect they will argue.

Of course, that gives them quite a heavyweight intellectual task of characterising the Methods that were purloined by IBM (or Linus) and cunningly re-coded so as to look totally different from the SysV implementation. And establishing that the Method is not a scene à faire, given the specification in the standard (like the errno's, for instance). And that such a Method was not documented in exquisite detail by Knuth or the Design Patterns crew many years ago. Seems unlikely that either SCO or BSF are equal to the task.

Still, they're probably dumb enough to try it.

[ Reply to This | # ]

A Word to SCO from the Open Group's Website
Authored by: allin on Wednesday, July 19 2006 @ 11:47 PM EDT
Go PJ! I sense blood on the boil here, and quite right too.

The Groklaw strategy of "critical but non-abusive" makes good sense
but is hard to maitain when the objects of criticism are such opportunistic,
grasping trolls (is that mild enough not to get deleted?)

[ Reply to This | # ]

The Question is not if and how SCO can find that code
Authored by: Anonymous on Thursday, July 20 2006 @ 06:21 AM EDT
The Question is: How did SCO find the stuff IBM supposedly "stole"
from them in Linux *and* in their code without being able to tell anyone where
they found it.

Aparently SCO is saying: Linux has Feature X, which our Unix has too, so it must
be stolen from us. Well, on that ground Xerox could sue Microsoft into
bankruptcy.

[ Reply to This | # ]

Someone please educate me...
Authored by: Reven on Thursday, July 20 2006 @ 09:33 PM EDT
Ok, I really need someone to educate me on this. If tSCOg cannot find in their own code where a certain method and/or concept is implemented, what makes that particular method/concept protectable? To be able to say they own it, they have to say where and when it was copyright. So forget about what code IBM is supposed to have infringed with, how can tSCOg claim they own the code that is being infringed against without identifying where their methods/concepts are implemented?

So far as I can tell, tSCOg has picked a series of method names and said to IBM "you used/divulged these methods". They then said didn't need to identify where in their code the methods are implemented because methods aren't necesarily implemented in code. But this is copyright law we're talking about, not patent. So fine, let's take it as a given that IBM used/divulged the methods that SCO names. Mark that as "admitted". tSCOg (by their own admission) can't say where those methods are implemented in their own code. If they can't show where they are implemented, how can they show they have any copyright? There can be no contractual obligations either, as there is no contract that mentions the methods by name.

To me the arguments seem wrong. IBM and tSCOg seem to be arguing about whether or not it is possible to identify the code behind methods and whether or not tSCOg should be required to based on court orders. It seems to me that as a matter of law tSCOg must identify at (least in their own code) where the methods are implemented, or the whole thing is moot - no identification, no copyright. Case closed.

---
Ex Turbo Modestum

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