|
|
| 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.
|
|
|
|
| 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 | # ]
|
| |
| 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 | # ]
|
- Alarming. - Authored by: Anonymous on Wednesday, July 19 2006 @ 10:48 AM EDT
- Alarming. - Authored by: PJ on Wednesday, July 19 2006 @ 10:49 AM EDT
- Thank you both then - Authored by: Anonymous on Wednesday, July 19 2006 @ 11:02 AM EDT
- ha ha ha - Authored by: Anonymous on Wednesday, July 19 2006 @ 04:16 PM EDT
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| Authored by: ewe2 on Wednesday, July 19 2006 @ 11:19 AM EDT |
| plain as the nose, as they say. [ Reply to This | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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
| |
| Authored by: Anonymous on Wednesday, July 19 2006 @ 03:57 PM EDT |
| It was once implemented! [ Reply to This | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
|
|
|
|
