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
SCO's Letter and the Files
Monday, December 22 2003 @ 04:19 PM EST

Here is the letter from SCO warning recipients of alleged copyright violations. I must tell you that the list of files has everyone I am hearing from falling on the floor laughing. We will be issuing a statement explaining why as soon as they recover.



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

December 19, 2003

Re:  The SCO Group, Inc. (“SCO”)

Dear Unix Licensee,

In May 2003, SCO warned about enterprise use of the Linux operating system in violation of its intellectual property rights in UNIX technology. Without exhausting or explaining all potential claims, this letter addresses one specific area in which certain versions of Linux violate SCO's rights in UNIX.  

In this letter we are identifying a portion of our copyright protected code that has been incorporated into Linux without our authorization. Also, our copyright management information has been removed from these files.

These facts support our position that the use of the Linux operating system in a commercial setting violates our rights under the United States Copyright Act, including the Digital Millennium Copyright Act. We are notifying you of these facts so you can take steps to discontinue these violations.  We believe these violations are serious, and we will take appropriate actions to protect our rights.  No one may use our copyrighted code except as authorized by us.  The details of our position are set forth below.  Once you have reviewed our position, we will be happy to further discuss your options and work with you to remedy this problem.  

Certain copyrighted application binary interfaces (“ABI Code”) have been copied verbatim from our copyrighted UNIX code base and contributed to Linux for distribution under the General Public License (“GPL”) without proper authorization and without copyright attribution.  While some application programming interfaces (“API Code”) have been made available over the years through POSIX and other open standards, the UNIX ABI Code has only been made available under copyright restrictions.  AT&T made these binary interfaces available in order to support application development to UNIX operating systems and to assist UNIX licensees in the development process.  The UNIX ABIs were never intended or authorized for unrestricted use or distribution under the GPL in Linux.  As the copyright holder, SCO has never granted such permission.  Nevertheless, many of the ABIs contained in Linux, and improperly distributed under the GPL, are direct copies of our UNIX copyrighted software code.  

Any part of any Linux file that includes the copyrighted binary interface code must be removed.  Files in Linux version 2.4.21 and other versions that incorporate the copyrighted binary interfaces include:

include/asm-alpha/errno.h

include/asm-arm/errno.h

include/asm-cris/errno.h

include/asm-i386/errno.h

include/asm-ia64/errno.h

include/asm-m68k/errno.h

include/asm-mips/errno.h

include/asm-mips64/errno.h

include/asm-parisc/errno.h

include/asm-ppc/errno.h

include/asm-ppc64/errno.h

include/asm-s390/errno.h

include/asm-s390x/errno.h

include/asm-sh/errno.h

include/asm-sparc/errno.h

include/asm-sparc64/errno.h

include/asm-x86_64/errno.h

include/asm-alpha/signal.h

include/asm-arm/signal.h

include/asm-cris/signal.h

include/asm-i386/signal.h

include/asm-ia64/signal.h

include/asm-m68k/signal.h

include/asm-mips/signal.h

include/asm-mips64/signal.h

include/asm-parisc/signal.h

include/asm-ppc/signal.h

include/asm-ppc64/signal.h

include/asm-s390/signal.h

include/asm-s390x/signal.h

include/asm-sh/signal.h

include/asm-sparc/signal.h

include/asm-sparc64/signal.h

include/asm-x86_64/signal.h

include/linux/stat.h

include/linux/ctype.h

lib/ctype.c

include/asm-alpha/ioctl.h

include/asm-alpha/ioctls.h

include/asm-arm/ioctl.h

include/asm-cris/ioctl.h

include/asm-i386/ioctl.h

include/asm-ia64/ioctl.h

include/asm-m68k/ioctl.h

include/asm-mips/ioctl.h

include/asm-mips64/ioctl.h

include/asm-mips64/ioctls.h

include/asm-parisc/ioctl.h

include/asm-parisc/ioctls.h

include/asm-ppc/ioctl.h

include/asm-ppc/ioctls.h

include/asm-ppc64/ioctl.h

include/asm-ppc64/ioctls.h

include/asm-s390/ioctl.h

include/asm-s390x/ioctl.h

include/asm-sh/ioctl.h

include/asm-sh/ioctls.h

include/asm-sparc/ioctl.h

include/asm-sparc/ioctls.h

include/asm-sparc64/ioctl.h

include/asm-sparc64/ioctls.h

include/asm-x86_64/ioctl.h

include/linux/ipc.h

include/linux/acct.h

include/asm-sparc/a.out.h

include/linux/a.out.h

arch/mips/boot/ecoff.h

include/asm-sparc/bsderrno.h

include/asm-sparc/solerrno.h

include/asm-sparc64/bsderrno.h

include/asm-sparc64/solerrno.h

The code identified above was also part of a settlement agreement between the University of California at Berkeley and Berkeley Systems Development, Inc. (collectively “BSDI”) and UNIX Systems Laboratories, Inc. regarding alleged violations by BSDI of USL's rights in UNIX technology.  The settlement agreement between USL and BSDI addressed conditions upon which BSDI could continue to distribute its version of UNIX, BSD Lite 4.4, or any successor versions, including certain “UNIX Derived Files” which include the ABI Code. A complete listing of the UNIX Derived Files is attached.  The ABI Code identified above is part of the UNIX Derived Files and, as such, must carry USL / SCO copyright notices and may not be used in any GPL distribution, inasmuch as the affirmative consent of the copyright holder has not been obtained, and will not be obtained, for such a distribution under the GPL.

Use in Linux of any ABI Code or other UNIX Derived Files identified above constitutes a violation of the United States Copyright Act. Distribution of the copyrighted ABI Code, or binary code compiled using the ABI code, with copyright management information deleted or altered, violates the Digital Millennium Copyright Act (“DMCA”) codified by Congress at 17 U.S.C. §1202.  DMCA liability extends to those who have reasonable grounds to know that a distribution (or re-distribution as required by the GPL) of the altered code or copyright information will induce, enable, facilitate, or conceal an infringement of any right under the DMCA.  In addition, neither SCO nor any predecessor in interest has ever placed an affirmative notice in Linux that the copyrighted code in question could be used or distributed under the GPL.  As a result, any distribution of Linux by a software vendor or a re-distribution of Linux by an end user that contains any of the identified UNIX code violates SCO's rights under the DMCA, insofar as the distributor knows of these violations.

As stated above, SCO's review is ongoing and will involve additional disclosures of code misappropriation.  Certain UNIX code, methods and concepts, which we also claim are being used improperly in Linux, will be produced in the pending litigation between SCO and IBM under a confidentiality order.  

Thank you for your attention to these matters.

Sincerely,

THE SCO GROUP, INC.

By:______________________________

Ryan E. Tibbitts

General Counsel


  


SCO's Letter and the Files | 266 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 04:25 PM EST
No wonder theve didnt want to upfront about the code

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: dan_stephans on Monday, December 22 2003 @ 04:25 PM EST
One reason people are laughing is that these header files implement open
interface specifications (POSIX, opengroup). It would be ridiculous to copy
something so trivial.

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 04:28 PM EST
Here is one of the files SCO is referring to. This file and the others could
have been easily reverse-engineered by reading W. Richard Stevens or any other
quality text on UNIX programming.


/* $Id: ioctl.h,v 1.1 2001/10/23 17:48:14 arjanv Exp $
*
* linux/ioctl.h for Linux by H.H. Bergman.
*/

#ifndef _ASMI386_IOCTL_H
#define _ASMI386_IOCTL_H

/* ioctl command encoding: 32 bits total, command in lower 16 bits,
* size of the parameter structure in the lower 14 bits of the
* upper 16 bits.
* Encoding the size of the parameter structure in the ioctl request
* is useful for catching programs compiled with old versions
* and to avoid overwriting user space outside the user buffer area.
* The highest 2 bits are reserved for indicating the ``access mode''.
* NOTE: This limits the max parameter size to 16kB -1 !
*/

/*
* The following is for compatibility across the various Linux
* platforms. The i386 ioctl numbering scheme doesn't really enforce
* a type field. De facto, however, the top 8 bits of the lower 16
* bits are indeed used as a type field, so we might just as well make
* this explicit here. Please be sure to use the decoding macros
* below from now on.
*/
#define _IOC_NRBITS 8
#define _IOC_TYPEBITS 8
#define _IOC_SIZEBITS 14
#define _IOC_DIRBITS 2

#define _IOC_NRMASK ((1 << _IOC_NRBITS)-1)
#define _IOC_TYPEMASK ((1 << _IOC_TYPEBITS)-1)
#define _IOC_SIZEMASK ((1 << _IOC_SIZEBITS)-1)
#define _IOC_DIRMASK ((1 << _IOC_DIRBITS)-1)

#define _IOC_NRSHIFT 0
#define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS)

/*
* Direction bits.
*/
#define _IOC_NONE 0U
#define _IOC_WRITE 1U
#define _IOC_READ 2U

#define _IOC(dir,type,nr,size) \
(((dir) << _IOC_DIRSHIFT) | \
((type) << _IOC_TYPESHIFT) | \
((nr) << _IOC_NRSHIFT) | \
((size) << _IOC_SIZESHIFT))

/* used to create numbers */
#define _IO(type,nr) _IOC(_IOC_NONE,(type),(nr),0)
#define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),sizeof(size))
#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
#define _IOWR(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),sizeof(size))

/* used to decode ioctl numbers.. */
#define _IOC_DIR(nr) (((nr) >> _IOC_DIRSHIFT) & _IOC_DIRMASK)
#define _IOC_TYPE(nr) (((nr) >> _IOC_TYPESHIFT) & _IOC_TYPEMASK)
#define _IOC_NR(nr) (((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)
#define _IOC_SIZE(nr) (((nr) >> _IOC_SIZESHIFT) & _IOC_SIZEMASK)

/* ...and for the drivers/sound files... */

#define IOC_IN (_IOC_WRITE << _IOC_DIRSHIFT)
#define IOC_OUT (_IOC_READ << _IOC_DIRSHIFT)
#define IOC_INOUT ((_IOC_WRITE|_IOC_READ) << _IOC_DIRSHIFT)
#define IOCSIZE_MASK (_IOC_SIZEMASK << _IOC_SIZESHIFT)
#define IOCSIZE_SHIFT (_IOC_SIZESHIFT)

#endif /* _ASMI386_IOCTL_H */

[ Reply to This | # ]

BSD or not BSD ? Make up your mind !
Authored by: Anonymous on Monday, December 22 2003 @ 04:30 PM EST
[...] "We specifically excluded the BSD-derived code", Sontag said.
"There is post-BSD UnixWare source code origined [sic] with SCO, and that
is of issue."
-- Chris Sontag, 2003-05-15

This what Sontag said when SCO started to talk about huge copyright
infringements in the Linux kernel.

Except for the two files shown in Las Vegas, today is the first time SCO
identifies files that infringe on their copyrights. All of the files identified
today are BSD files. It's been known for eons that the Linux kernel contains
BSD files; most people seem to think it's OK, and Caldera has distributed these
files under the GPL since 1994.

So, Chris, please tell us: is it BSD or is it not?

[ Reply to This | # ]

I'm sorry, but I may to have to sue SCO
Authored by: OmniGeek on Monday, December 22 2003 @ 04:33 PM EST
... for the keyboard I shorted out with the coffee that came out my nose when I
read the list of files they claim as theirs. Also for the injuries suffered by
contact with office furniture while rolling on the floor in helpless gales of
laughter. (Just kidding on all that, folks.)

---
My strength is as the strength of ten men, for I am wired to the eyeballs on
espresso.

[ Reply to This | # ]

Linus comments on CRN
Authored by: Tim Ransom on Monday, December 22 2003 @ 04:35 PM EST
"As you can see, it's basically something like five files, it's just
that several of them are replicated for every single architecture out
there," Torvalds wrote, pointing to the files listed on the letter.
"And the thing is, those files don't even contain any code. They contain
things like the error number lists--and, yes, we made the error numbers match
with traditional Unix on purpose, since, for example, Linux/alpha wanted to be
binary-compatible with OSF/1. Ask any programmer what this is, and he'll tell
you it's just a C header file that gives symbolic names to static error
numbers."

[ Reply to This | # ]

I thought settlement was sealed
Authored by: Anonymous on Monday, December 22 2003 @ 04:35 PM EST
If this is part of the BSD settlement, I thought that was under court seal. Is
SCO violating the court order by disclosing this?

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 04:36 PM EST
look at 'lib/ctype.c'

the first couple of lines:
/*
* linux/lib/ctype.c
*
* Copyright (C) 1991, 1992 Linus Torvalds
*/

Seriously funny!

[ Reply to This | # ]

Thank You Quote DB!!
Authored by: p0ssum on Monday, December 22 2003 @ 04:36 PM EST
No, none of the code in the Linux ABI modules contains SCO IP. This code is
under the GPL and it re-implements publicly documented interfaces. We do not
have an issue with the Linux ABI modules. The IP that we are licensing is all in
the shared libraries - these libraries are needed by many OpenServer
applications *in addition* to the Linux ABI.-- Blake Stowell, 2003-02-05

---
There are 10 types of people in this world, those that understand binary and
those that do not.

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: fb on Monday, December 22 2003 @ 04:37 PM EST

This is so lame and spawned of such abysmal ignorance of Unix and Linux that it doesn't even seem to be meant to convince anybody, really.

What it looks like is a feeble gesture to keep insiders from abandoning ship, or maybe groping for a stay of inevitable execution by Yarro and Canopy.

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: MyPersonalOpinio on Monday, December 22 2003 @ 04:38 PM EST

Link to the OpenGroup/IEEE POSIX standar ds describing most of these files

[ Reply to This | # ]

SCO's argument
Authored by: eamacnaghten on Monday, December 22 2003 @ 04:38 PM EST
A repeat from another thread - so please excuse me...

I think I can see SCO's argument (just about).

They are saying that POSIX defines the implementation names, but it is their implementation that has been copied.

For instance, the POSIX standard specifies that ENOENT needs to be defined an integer in errno.h, but does not define what it is.

Both Unix and Linux define it as 2, and SCO is claiming that that is because the Linux guys copied it from SCO.

However, this does not hold water, because these numbers are documented, without copyright notices, in the man pages, including the OpenServer ones (enter "man S Intro" on OpenServer and page down, you will see ENOENT defined as 2....).

It would make sense for the early Linux developers to use publically available POSIX deffinitions to maintain a consistancy, in fact it could be argued it would be irresponsible if they did not.

All the other definitions of the .h files are documented in the man pages as well. The comments are as in the POSIX standard as on www.opengroup.com.

Also - when compiling a C program, arguably none of the .h files gets incorporated into the binary - with the possible exception of the macros. All the .h files do is to validate interface APIs (as per Posix standard) and to associate numbers with names (ENOENT is 2 and so on). Any macros in there would be trivial and obvious and difficult to proove that it were not copied, so SCO has no business going after the people who use binaries, just those who compile code.

The other thing is that this is the first time I know of someone going after copyright claims based on .h files, these are relatively trivial and can be replaced in probably a couple of days - though it would be a pain because all binaries would need to be recompiled with the new headers. However, I believe that is accademic as SCO has no proprietary claims on the header files in Linux as far as I can tell.

For those without access to OpenServer a company known as Caldera have kindly put the appropriate man pages on the web....

http://docsrv.ca ldera.com:507/en/man/html.S/Intro.S.html

[ Reply to This | # ]

Confused April fools and winter solstice?
Authored by: Anonymous on Monday, December 22 2003 @ 04:40 PM EST
Did anyone ask [getting up from chair-toppling guffaw] which lines in
particular?

In SCO's through the "Looking Glass" (Caldera once had this as a
desktop) the Queen of Hearts when not in a solitare game apparently says
"Off with their headers'.

I don't think any of these headers directly generate any binary code (some may
when the #defines are expanded by another routine).

You would think they would be able to find at least one ".c" file.
Also, does x86 linux binary infringe anything because the arm, alpha, sun, etc.
headers are there?

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Alan Bell on Monday, December 22 2003 @ 04:42 PM EST
the CRN article
quotes from Linus are fairly predictable and rational, but far more amusing is this from Darl.

We're stepping up our enforcement activities, " said McBride, noting the letter sent out last week will tie into the pending litigation. "There's a huge amount of copying of Linux going on ... copyrights are there to protect people from making copies, and at the end-user level is where the substantial amount of copying going on. That's the target area with litigation coming."

[ Reply to This | # ]

another round of financing, anyone?!
Authored by: chrism on Monday, December 22 2003 @ 04:43 PM EST
O.K., I'm starting to enjoy this now. SCO is doing the best job imaginable of
showing the folly of our current IP laws (DMCA et al). Perhaps we shouldn't be
so anxious to see them go away anytime soon.

Whoever thought they might get away with gaming the system must have completely
given up any hopes they had by now.

Anyone want to try to get SCO some more funding to keep them going? ;-) Let's
pool our money, do a PIPE investment and then insist on a veto that can override
RBC's ;-) ;-)

I would like the stink of this fiasco to not only reach congress, but to hang in
the air of the chambers for as long as possible till breathing becomes iffy.

Chris Marshall

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: prgrmr on Monday, December 22 2003 @ 04:45 PM EST
Someone on slashdot pointed out that the Microsoft copywrite notices are missing
in the SCO (i.e., Unixware) versions of some of these files. This makes me
wonder if the 1997 agreement between M$ and $CO was and/or is continued to be
administrated correctly by SCO?

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 04:46 PM EST

This list is so completely ridiculous, I cannot even fall on the floor laughing. Let's begin with some nontechnical things:

  • They call this 60 files, although they are in essence just ten or twelve. It is completely obvious that, for example, the 17 instances of errno.h, signal.h and so on are mainly the same files. Let's repeat it: They have in fact "identified" no more than 15 files. Calling these "60 files" is like taking one file, counting any version of Linux (let's suggest there are 20000 versions) and shouting "I found 20000 files!".
  • These files are (mainly unchanged) in use since ages. In Unix. In any C compiler (including, for example, Windows C compilers). They have been more or less part of any publicly available version: SysV 3.2 Unix, BSD Unix, the various standards (POSIX, Unix as a standard as opposed to Unix as an operating system, ANSI and ISO C, and so on. Even if SCO *had* any rights (I am sure that better researchers will be able to publish proof over proof of the contrary on these files, they'll need to prove these rights in so many cases that any user can argue "good faith" for the next 500 years.
  • These files are definitely no "trade secrets" (one term SCO likes to use in case) nor patented (being more than 30 years old, in essence). There may be copyrights on these files, I do not know. However, as they do not contain implementations, but only interfaces, (in other words, mainly enumerations of error codes, well known function names, and the like), I can see no reason, why noone should be allowed to simply retype them into a text file, saving the text file under a new name and calling it a "clean room implementation". So, what's the story?
Jochen Wiedmann

[ Reply to This | # ]

Laughing and gnashing my teeth
Authored by: the_flatlander on Monday, December 22 2003 @ 04:48 PM EST
Funny, yes, but oh so stupid. It is hardly worth trying to rebutt.

Can it be that without a Chief Technical Officer there was no one available to
tell Darl and his friends how software works? Do they honestly beieve that you
can coyright the name of a variable, for example, "errno"? Or then
enforce that? Oh wow.

Geez, look at that, *I* put "honestly" and a reference to SCO
Group's executives in the same sentence. See? This is making me crazy.

TFL

Maybe Darl should *try* singing Kumbya...

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: toolboxnz on Monday, December 22 2003 @ 04:52 PM EST
The most annoying thing about this whole case is that the investors and analysts
just don't seem to see the contradictions and clever wording that SCO keep
using. Are they blind that SCO made a loss and made less sales in licensing
their products in Q4 than Q3? The share price took a huge dip at the beginning
of day after the loss announcement and then flattened out and even rallied
slightly at the end of the day.

Given they are managing to destroy their own market with this litigation (and
the fact that several reviewers have basically said their latest offerings
suck), this is only a trend that can continue. They are going to need a serious
cash injection early next year to continue trying to sue all and sundry.

How can we let these analysts know what we know? This attempt to claim ownership
of these header files is a joke. Surely they have something better than this. If
not, they are going to be massacred by IBM et al.

[ Reply to This | # ]

DON'T POST HEADER FILES HERE!
Authored by: Anonymous on Monday, December 22 2003 @ 04:52 PM EST
Just a precaution:

SCO's counsel has just sent out DMCA warning letters.

Could we all please resist the temptation and _NOT_POST_ the text of these files
on Groklaw until this dispute get's settled? You and I know it's not
copyrightable material, but who knows about the authorities?

I can find a copy of the code to look at if I get curious. That's not the case
with Groklaw - which is subject to things like DMCA takedown notices.

Thanks
Harlan

[ Reply to This | # ]

What's an ABI for anyway?
Authored by: John Goodwin on Monday, December 22 2003 @ 04:54 PM EST

This is so persons more knowledgable than I can chime in. My recollection is
that the ABI is primarily so executables across all Unices can run. Primarily,
this is to allow Solaris, HP-UX, SCO, etc. executables to run under Linux. In
other words, it is about compatibility, not licensing.

If this is the attack (or a new attack) it means that building a
*unix-compatible* clone, as opposed to building a POSIX implementation, is what
is claimed to be illegal. The files in question are fairly minimal and tightly
constrained for mere interoperability. (This can't be a copyright thing,
really, it has to be a patent thing; thought the DCMA blurs this by giving
patent like qualities to copyright IP).

That is, if SCO's claim holds up, nothing but a "pureblood UNIX
system" can ever interoperate at a binary level with UNIX. For
comparison, even Microsoft pretends binary interoperability is possible in
theory (there could be and are binary implementations of COM, DCOM, etc.).
Likewise for CORBA.

"No binary interoperability" comes pretty close to claiming monopoly
rights, as in "no reverse engineering" and "no cloning".
This is a known danger with DCMA (presumably why they take this line of
attack).

So my scope for this subthread--

(1) what is the ABI?

(2) what is it good for?

(3) what (absurd) consequences follow if these claims are true, and
ABI-compatible systems must license not only the client software (API level),
but the underlying server platform (ABI level) it runs on?

(4) How extensive does this "no binary compatibility allowed" go?
E.g. can Microsoft COM talk to UNIX now, without a demanded license from SCO?
What about CORBA? ELF Executables?

[ Reply to This | # ]

condensed list (9 files)
Authored by: Anonymous on Monday, December 22 2003 @ 04:54 PM EST
errno.h and variants (bsderrno.h solerrno.h)
ioctl.h and ioctls.h
signal.h
a.out.h
ecoff.h
ipc.h
acct.h
ctype.h
stat.h

(do libel laws apply? or interference with trade?).

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 05:01 PM EST
As someone who has customers sign software contracts & licences on a regular
basis, I would suggest that there are issues here to do with SCO threatening to
withdraw licencing rights from existing customers;

What revocation clause is there in the licence? The licence normally terminates
without recompense if there is an infringing act by the customer. These are
fairly broad brush in nature, and it may be that SCO has this in mind. There may
also be a contract with SCO that the licence defers to that outlines the
conditions for revocation. Both need to be read together.

Licences are normally sold in perpetuity, although term licences are becoming
more common. If SCO doesn't have enough reason for termination under the
contract or specific licence, then the perpetual rights of the customer to the
product can't be withdrawn arbitrarily. And the opposite is true as well;
examples of infringement include reverse-engineering, copying, use by a third
party, etc.

There may be an argument that this is a variation to the contract; do SCO have
the right to this based on no evidence of wrongdoing?

Perhaps they will argue that this is an assurance that they're seeking from
their customers; but doing it in this shotgun fashion is very strange indeed. I
would expect to get a lawyer's letter based on sending this to my customers.
I'd certainly expect to have a difficult time selling them any more.

Whatever the legal basis, this is commercial suicide.

IANAL, IAJASP
"I am not a lawyer, I am just a sales puke"

Reposted from the previous thread; I _always_ seem to be last on these...

[ Reply to This | # ]

Linus responds (LKML)
Authored by: rjamestaylor on Monday, December 22 2003 @ 05:01 PM EST
List: linux-kernel
Subject: Re: hmm..
From: Linus Torvalds <torvalds () osdl ! org>
Date: 2003-12-22 21:31:51
[Download message RAW]



On Mon, 22 Dec 2003, John Dee wrote:
>
> I know you guys have already probably seen this.. figured I'd share with
> the class, so the big kids can tear it apart.
> http://lwn.net/Articles/64052/

I spent half an hour tearing part of it apart for some journalists. No
guarantees for the full accuracy of this write-up, and in particular I
don't actually have "original UNIX" code to compare against, but
the files
I checked (ctype.[ch]) definitely do not have any UNIX history to them.

The rest of the files are mostly errno.h/signal.h/ioctl.h (and they are
apparently the 2.4.x versions, before we moved some common constants into
"asm-generic/errno.h"), and while I haven't analyzed them, I know
for a
fact that

- the original errno.h used different error numbers than "original
UNIX"

I know this because I cursed it later when it meant that doing things
like binary emulation wasn't as trivial - you had to translate the
error numbers.

- same goes for "signal.h": while a lot of the standard signals are
well
documented (ie "SIGKILL is 9"), historically we had lots of
confusion
(ie I think "real UNIX" has SIGBUS at 10, while Linux didn't
originally
have any SIGBUS at all, and later put it at 7 which was originally
SIGUNUSED.

So to me it looks like

- yes, Linux obviously has the same signal names and error number names
that UNIX has (so the files certainly have a lot of the same
identifiers)

- but equally clearly they weren't copied from any "real UNIX".

(Later, non-x86 architectures have tried harder to be binary-compatible
with their "real UNIX" counter-parts, and as a result we have
different
errno header files for different architectures - and on non-x86
architectures the numbers will usually match traditional UNIX).

For example, doing a "grep" for SIGBUS on the kernel shows that
most
architectures still have SIGBUS at 7 (original Linux value), while alpha,
sparc, parisc and mips have it at 10 (to match "real UNIX").

What this tells me is that the original code never came from UNIX, but
some architectures later were made to use the same values as UNIX for
binary compatibility (I know this is true for alpha, for example: being
compatible with OSF/1 was one of my very early goals in that port).

In other words, I think we can totally _demolish_ the SCO claim that these
65 files were somehow "copied". They clearly are not.

Which should come as no surprise to people. But I think it's nice to see
just _how_ clearly we can show that SCO is - yet again - totally
incorrect.

Linus

----

For example, SCO lists the files "include/linux/ctype.h" and
"lib/ctype.h", and some trivial digging shows that those files are
actually there in the original 0.01 distribution of Linux (ie September of
1991). And I can state

- I wrote them (and looking at the original ones, I'm a bit ashamed:
the "toupper()" and "tolower()" macros are so
horribly ugly that I
wouldn't admit to writing them if it wasn't because somebody else
claimed to have done so ;)

- writing them is no more than five minutes of work (you can verify that
with any C programmer, so you don't have to take my word for it)

- the details in them aren't even the same as in the BSD/UNIX files (the
approach is the same, but if you look at actual implementation details
you will notice that it's not just that my original
"tolower/toupper"
were embarrassingly ugly, a number of other details differ too).

In short: for the files where I personally checked the history, I can
definitely say that those files are trivially written by me personally,
with no copying from any UNIX code _ever_.

So it's definitely not a question of "all derivative branches".
It's a
question of the fact that I can show (and SCO should have been able to
see) that the list they show clearly shows original work, not
"copied".


Analysis of "lib/ctype.c" and "include/linux/ctype.h".


First, some background: the "ctype" name comes "character
type", and the
whole point of "ctype.h" and "ctype.c" is to test what
kind of character
we're dealing with. In other words, those files implement tests for doing
things like asking "is this character a digit" or "is this
character an
uppercase letter" etc. So you can write thing like

if (isdigit(c)) {
.. we do something with the digit ..

and the ctype files implement that logic.

Those files exist (in very similar form) in the original Linux-0.01
release under the names "lib/ctype.c" and
"include/ctype.h". That kernel
was released in September of 1991, and contains no code except for mine
(and Lars Wirzenius, who co-wrote "kernel/vsprintf.c").

In fact, you can look at the files today and 12 years ago, and you can see
clearly that they are largely the same: the modern files have been cleaned
up and fix a number of really ugly things (tolower/toupper works
properly), but they are clearly incremental improvement on the original
one.

And the original one does NOT look like the unix source one. It has
several similarities, but they are clearly due to:

- the "ctype" interfaces are defined by the C standard library.

- the C standard also specifies what kinds of names a system library
interface can use internally. In particular, the C standard specifies
that names that start with an underscore and a capital letter are
"internal" to the library. This is important, because it explains
why
both the Linux implementation _and_ the UNIX implementation used a
particular naming scheme for the flags.

- algorithmically, there aren't that many ways to test whether a
character is a number or not. That's _especially_ true in
C, where a macro must not use it's argument more than once. So for
example, the "obvious" implementation of "isdigit()"
(which tests for
whether a character is a digit or not) would be

#define isdigit(x) ((x) >= '0' && (x) <= '9')

but this is not actually allowed by the C standard (because 'x' is used
twice).

This explains why both Linux and traditional UNIX use the "other"

obvious implementation: having an array that describes what each of the
possible 256 characters are, and testing the contents of that array
(indexed by the character) instead. That way the macro argument is only
used once.

The above things basically explain the similarities. There simply aren't
that many ways to do a standard C "ctype" implementation, in other
words.

Now, let's look at the _differences_ in Linux and traditional UNIX:

- both Linux and traditional unix use a naming scheme of "underscore and

a capital letter" for the flag names. There are flags for "is
upper
case" (_U) and "is lower case" (_L), and surprise surprise,
both UNIX
and Linux use the same name. But think about it - if you wanted to use
a short flag name, and you were limited by the C standard naming, what
names _would_ you use? Maybe you'd select "U" for "Upper
case" and "L"
for "Lower case"?

Looking at the other flags, Linux uses "_D" for
"Digit", while
traditional UNIX instead uses "_N" for "Number". Both
make sense, but
they are different. I personally think that the Linux naming makes more
sense (the function that tests for a digit is called "isdigit()",
not
"isnumber()"), but on the other hand I can certainly understand
why
UNIX uses "_N" - the function that checs for whether a character
is
"alphanumeric" is called "isalnum()", and that checks
whether the
character is a upper case letter, a lower-case letter _or_ a digit (aka
"number").

In short: there aren't that many ways you can choose the names, and
there is lots of overlap, but it's clearly not 100%.

- The original Linux ctype.h/ctype.c file has obvious deficiencies, which
pretty much point to somebody new to C making mistakes (me) rather than
any old and respected source. For example, the
"toupper()/tolower()"
macros are just totally broken, and nobody would write the
"isascii()"
and "toascii()" the way they were written in that original Linux.
And
you can see that they got fixed later on in Linux development, even
though you can also see that the files otherwise didn't change.

For example: remember how C macros must only use their argument once
(never mind why - you really don't care, so just take it on faith, for
now). So let's say that you wanted to change an upper case character
into a lower case one, which is what "tolower()" does. Normal use
is
just a fairly obvious

newchar = tolower(oldchar);

and the original Linux code does

extern char _ctmp;
#define tolower(c) (_ctmp=c,isupper(_ctmp)?_ctmp+('a'+'A'):_ctmp)

which is not very pretty, but notice how we have a "temporary
character" _ctmp (remember that internal header names should start
with
an underscore and an upper case character - this is already slightly
broken in itself). That's there so that we can use the argument
"c"
only once - to assign it to the new temporary - and then later on we
use that temporary several times.

Now, the reason this is broken is

- it's not thread-safe (if two different threads try to do this at
once, they will stomp on each others temporary variable)

- the argument (c) might be a complex expression, and as such it
should really be parenthesized. The above gets several valid
(but unusual) expressions wrong.

Basically, the above is _exactly_ the kinds of mistakes a young programmer
would make. It's classic.

And I bet it's _not_ what the UNIX code looked like, even in 1991. UNIX by
then was 20 years old, and I _think_ that it uses a simple table lookup
(which makes a lot more sense anyway and solves all problems). I'd be very
susprised if it had those kinds of "beginner mistakes" in it, but I
don't
actually have access to the code, so what do I know? (I can look up some
BSD code on the web, it definitely does _not_ do anythign like the above).

The lack of proper parenthesis exists in other places of the original
Linux ctype.h file too: isascii() and toascii() are similarly broken.

In other words: there are _lots_ of indications that the code was not
copied, but was written from scratch. Bugs and all.

Oh, another detail: try searching the web (google is your friend) for
"_ctmp". It's unique enough that you'll notice that all the
returned hits
are all Linux-related. No UNIX hits anywhere. Doing a google for

_ctmp -linux

shows more Linux pages (that just don't happen to have "linux" in
them),
except for one which is the L4 microkernel, and that one shows that they
used the Linux header file (it still says "_LINUX_CTYPE_H" in it).

So there is definitely a lot of proof that my ctype.h is original work.



---
source:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107212899108511&w=2

---
SCO delenda est! Salt their fields!

[ Reply to This | # ]

Someone call an ambulance...
Authored by: talamacus on Monday, December 22 2003 @ 05:02 PM EST
...please, I'm dying of laughter here.

So, let's look at what SCO are claiming IP rights to:

Headers contain definitions. They tell you what goes in and what comes out. Most
of these are defined in POSIX standards going back past the 90s. They have
*absolutely nothing* to do with implementation. It's like trying to claim
copyright over "an input/output system" just because the input and
out are the same as something else.

Of course, they claim that it's the binary libraries that are infringing, but
fail to point to the actual libraries, or to the source. It's entirely possible
to use the described header in just about any implementation you want without
infringing upon anything, let alone falling afoul of SCO's blatant disregard of
copyright law.

I'm willing to hazard a guess that if you're using libraries that implement
the POSIX standards, you're on fairly safe ground. Of course, have a lawyer
check it out for you, but if this is their "millions of lines of verbatim
copying" then they're going to be taken to the cleaners.

-t

[ Reply to This | # ]

Red Herring?
Authored by: Anonymous on Monday, December 22 2003 @ 05:06 PM EST

Seriously, they have stated they don't want anyone to see the code. So why now
tell? This and the release of the malloc code are both designed to throw us off
our guard. I suspect they have something much more sinister up their sleeves.
You have been warned.

[ Reply to This | # ]

Blake Stowell statement contradicts letter?
Authored by: firasha on Monday, December 22 2003 @ 05:07 PM EST
From SCO's letter:
The ABI Code identified above is part of the UNIX Derived Files and, as such, must carry USL / SCO copyright notices and may not be used in any GPL distribution, inasmuch as the affirmative consent of the copyright holder has not been obtained, and will not be obtained, for such a distribution under the GPL.
....
In addition, neither SCO nor any predecessor in interest has ever placed an affirmative notice in Linux that the copyrighted code in question could be used or distributed under the GPL.
There was a post on slashdot with an interesting quote by Blake Stowell, given in this MozillaQues t interview (5 February 2003):
Blake Stowell: No, none of the code in the Linux ABI modules contains SCO IP. This code is under the GPL and it re-implements publicly documented interfaces. We do not have an issue with the Linux ABI modules. The IP that we are licensing is all in the shared libraries - these libraries are needed by many OpenServer applications *in addition* to the Linux ABI.
Now, from reading the MQ article, it looks like the ABI referred to here might not be the one at issue, but I thought I'd call attention to it so more knowledgeable folks could comment. Also--and perhaps more importantly--didn't SCO say that 2.2 kernels were not at issue? Some of these header files predate the 2.2 kernel by many years (early 1990s), so how can they be a problem in 2.4 but not 2.2...?

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: TerryL on Monday, December 22 2003 @ 05:10 PM EST
How the can C header files be considered to incorporate the copyrighted binary interfaces?????? Header files are source files, that define the interface to a binary library or object file that someone else provides. They come with compilers and 3rd party libraries. They give them away so people can use the libraries and object modules. I suppose someone MAY have removed a copyright statement from a header files - I wouldn't have seen it as the end of the world though, even if that's the case - mothing to make this much fuss about, I mean it's hardly secret information anyway. Is there some sort of multi-dimensional rift and SCO is actually from an alternative reality somewhere...

[ Reply to This | # ]

Linus's response to SCO claims
Authored by: Anonymous on Monday, December 22 2003 @ 05:12 PM EST
Linus's response to SCO's claims posted moments ago on LKML:


From: Linus Torvalds <torvalds@osdl.org>
To: John Dee <antitux@antitux.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: hmm..
Message-ID: <Pine.LNX.4.58.0312221316090.6868@home.osdl.org>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 22 Dec 2003, John Dee wrote:
>
> I know you guys have already probably seen this.. figured I'd share with
> the class, so the big kids can tear it apart.
> http://lwn.net/Articles/64052/

I spent half an hour tearing part of it apart for some journalists. No
guarantees for the full accuracy of this write-up, and in particular I
don't actually have "original UNIX" code to compare against, but
the files
I checked (ctype.[ch]) definitely do not have any UNIX history to them.

The rest of the files are mostly errno.h/signal.h/ioctl.h (and they are
apparently the 2.4.x versions, before we moved some common constants into
"asm-generic/errno.h"), and while I haven't analyzed them, I know
for a
fact that

- the original errno.h used different error numbers than "original
UNIX"

I know this because I cursed it later when it meant that doing things
like binary emulation wasn't as trivial - you had to translate the
error numbers.

- same goes for "signal.h": while a lot of the standard signals are
well
documented (ie "SIGKILL is 9"), historically we had lots of
confusion
(ie I think "real UNIX" has SIGBUS at 10, while Linux didn't
originally
have any SIGBUS at all, and later put it at 7 which was originally
SIGUNUSED.

So to me it looks like

- yes, Linux obviously has the same signal names and error number names
that UNIX has (so the files certainly have a lot of the same
identifiers)

- but equally clearly they weren't copied from any "real UNIX".

(Later, non-x86 architectures have tried harder to be binary-compatible
with their "real UNIX" counter-parts, and as a result we have
different
errno header files for different architectures - and on non-x86
architectures the numbers will usually match traditional UNIX).

For example, doing a "grep" for SIGBUS on the kernel shows that
most
architectures still have SIGBUS at 7 (original Linux value), while alpha,
sparc, parisc and mips have it at 10 (to match "real UNIX").

What this tells me is that the original code never came from UNIX, but
some architectures later were made to use the same values as UNIX for
binary compatibility (I know this is true for alpha, for example: being
compatible with OSF/1 was one of my very early goals in that port).

In other words, I think we can totally _demolish_ the SCO claim that these
65 files were somehow "copied". They clearly are not.

Which should come as no surprise to people. But I think it's nice to see
just _how_ clearly we can show that SCO is - yet again - totally
incorrect.

Linus

----

For example, SCO lists the files "include/linux/ctype.h" and
"lib/ctype.h", and some trivial digging shows that those files are
actually there in the original 0.01 distribution of Linux (ie September of
1991). And I can state

- I wrote them (and looking at the original ones, I'm a bit ashamed:
the "toupper()" and "tolower()" macros are so
horribly ugly that I
wouldn't admit to writing them if it wasn't because somebody else
claimed to have done so ;)

- writing them is no more than five minutes of work (you can verify that
with any C programmer, so you don't have to take my word for it)

- the details in them aren't even the same as in the BSD/UNIX files (the
approach is the same, but if you look at actual implementation details
you will notice that it's not just that my original
"tolower/toupper"
were embarrassingly ugly, a number of other details differ too).

In short: for the files where I personally checked the history, I can
definitely say that those files are trivially written by me personally,
with no copying from any UNIX code _ever_.

So it's definitely not a question of "all derivative branches".
It's a
question of the fact that I can show (and SCO should have been able to
see) that the list they show clearly shows original work, not
"copied".


Analysis of "lib/ctype.c" and "include/linux/ctype.h".


First, some background: the "ctype" name comes "character
type", and the
whole point of "ctype.h" and "ctype.c" is to test what
kind of character
we're dealing with. In other words, those files implement tests for doing
things like asking "is this character a digit" or "is this
character an
uppercase letter" etc. So you can write thing like

if (isdigit(c)) {
.. we do something with the digit ..

and the ctype files implement that logic.

Those files exist (in very similar form) in the original Linux-0.01
release under the names "lib/ctype.c" and
"include/ctype.h". That kernel
was released in September of 1991, and contains no code except for mine
(and Lars Wirzenius, who co-wrote "kernel/vsprintf.c").

In fact, you can look at the files today and 12 years ago, and you can see
clearly that they are largely the same: the modern files have been cleaned
up and fix a number of really ugly things (tolower/toupper works
properly), but they are clearly incremental improvement on the original
one.

And the original one does NOT look like the unix source one. It has
several similarities, but they are clearly due to:

- the "ctype" interfaces are defined by the C standard library.

- the C standard also specifies what kinds of names a system library
interface can use internally. In particular, the C standard specifies
that names that start with an underscore and a capital letter are
"internal" to the library. This is important, because it explains
why
both the Linux implementation _and_ the UNIX implementation used a
particular naming scheme for the flags.

- algorithmically, there aren't that many ways to test whether a
character is a number or not. That's _especially_ true in
C, where a macro must not use it's argument more than once. So for
example, the "obvious" implementation of "isdigit()"
(which tests for
whether a character is a digit or not) would be

#define isdigit(x) ((x) >= '0' && (x) <= '9')

but this is not actually allowed by the C standard (because 'x' is used
twice).

This explains why both Linux and traditional UNIX use the "other"

obvious implementation: having an array that describes what each of the
possible 256 characters are, and testing the contents of that array
(indexed by the character) instead. That way the macro argument is only
used once.

The above things basically explain the similarities. There simply aren't
that many ways to do a standard C "ctype" implementation, in other
words.

Now, let's look at the _differences_ in Linux and traditional UNIX:

- both Linux and traditional unix use a naming scheme of "underscore and

a capital letter" for the flag names. There are flags for "is
upper
case" (_U) and "is lower case" (_L), and surprise surprise,
both UNIX
and Linux use the same name. But think about it - if you wanted to use
a short flag name, and you were limited by the C standard naming, what
names _would_ you use? Maybe you'd select "U" for "Upper
case" and "L"
for "Lower case"?

Looking at the other flags, Linux uses "_D" for
"Digit", while
traditional UNIX instead uses "_N" for "Number". Both
make sense, but
they are different. I personally think that the Linux naming makes more
sense (the function that tests for a digit is called "isdigit()",
not
"isnumber()"), but on the other hand I can certainly understand
why
UNIX uses "_N" - the function that checs for whether a character
is
"alphanumeric" is called "isalnum()", and that checks
whether the
character is a upper case letter, a lower-case letter _or_ a digit (aka
"number").

In short: there aren't that many ways you can choose the names, and
there is lots of overlap, but it's clearly not 100%.

- The original Linux ctype.h/ctype.c file has obvious deficiencies, which
pretty much point to somebody new to C making mistakes (me) rather than
any old and respected source. For example, the
"toupper()/tolower()"
macros are just totally broken, and nobody would write the
"isascii()"
and "toascii()" the way they were written in that original Linux.
And
you can see that they got fixed later on in Linux development, even
though you can also see that the files otherwise didn't change.

For example: remember how C macros must only use their argument once
(never mind why - you really don't care, so just take it on faith, for
now). So let's say that you wanted to change an upper case character
into a lower case one, which is what "tolower()" does. Normal use
is
just a fairly obvious

newchar = tolower(oldchar);

and the original Linux code does

extern char _ctmp;
#define tolower(c) (_ctmp=c,isupper(_ctmp)?_ctmp+('a'+'A'):_ctmp)

which is not very pretty, but notice how we have a "temporary
character" _ctmp (remember that internal header names should start
with
an underscore and an upper case character - this is already slightly
broken in itself). That's there so that we can use the argument
"c"
only once - to assign it to the new temporary - and then later on we
use that temporary several times.

Now, the reason this is broken is

- it's not thread-safe (if two different threads try to do this at
once, they will stomp on each others temporary variable)

- the argument (c) might be a complex expression, and as such it
should really be parenthesized. The above gets several valid
(but unusual) expressions wrong.

Basically, the above is _exactly_ the kinds of mistakes a young programmer
would make. It's classic.

And I bet it's _not_ what the UNIX code looked like, even in 1991. UNIX by
then was 20 years old, and I _think_ that it uses a simple table lookup
(which makes a lot more sense anyway and solves all problems). I'd be very
susprised if it had those kinds of "beginner mistakes" in it, but I
don't
actually have access to the code, so what do I know? (I can look up some
BSD code on the web, it definitely does _not_ do anythign like the above).

The lack of proper parenthesis exists in other places of the original
Linux ctype.h file too: isascii() and toascii() are similarly broken.

In other words: there are _lots_ of indications that the code was not
copied, but was written from scratch. Bugs and all.

Oh, another detail: try searching the web (google is your friend) for
"_ctmp". It's unique enough that you'll notice that all the
returned hits
are all Linux-related. No UNIX hits anywhere. Doing a google for

_ctmp -linux

shows more Linux pages (that just don't happen to have "linux" in
them),
except for one which is the L4 microkernel, and that one shows that they
used the Linux header file (it still says "_LINUX_CTYPE_H" in it).

So there is definitely a lot of proof that my ctype.h is original work.

-
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[ Reply to This | # ]

A few .h files?
Authored by: Anonymous on Monday, December 22 2003 @ 05:16 PM EST
Someone at /. suggested this be cross posted. Its overrated but a good point.
--
Gee, my company's error.h and types.h are similar. Oh wait, every company I've
ever worked for has similar .h files because this is basic, common interface
stuff.
Its like saying "we patented the play, pause, record and rewind buttons on
our model of VCR, everyone with tape, CD and DVD players on the market better
pay us for this inovative interface!"
I don't know whether to laugh or cry over this.
--
--Let's hack root on 127.0.0.1 --panZ

[ Reply to This | # ]

I'm gonna file on copyright...
Authored by: Anonymous on Monday, December 22 2003 @ 05:17 PM EST
On using zero to represent True and one to represent false, and vice versa.
Oh boy, you guys are gonna be in trouble now!!!

[ Reply to This | # ]

Change of BSD-license
Authored by: Stefan on Monday, December 22 2003 @ 05:19 PM EST
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change

[ Reply to This | # ]

Header file example
Authored by: JMonroy on Monday, December 22 2003 @ 05:20 PM EST
For those who aren't programmers, a header file has several functions, one of which is to give meaningless numbers or strings a meaningful name, or method of representation (forgive my syntax, it's been years since I coded C).

A trivial, yet common example of a header file (for example, called "definitons.h"):

#define FALSE 0
#define TRUE 1
#define TARGET_NUMBER 3000000000 // 3 billion, hehe.. #define COMPANY_NAME "MyWidgetCo"

Now incorporating the header file into some actual code:

#include <"definitions.h">
....
....
int function my_compare_routine(int result) {
(if (result!=TARGET_NUMBER)) {
return(FALSE);
} else { return(TRUE); }
....
....

As you can see, it's not an integral part of the coding. There is no trade secret, nor anything intellectual to protect. Without the header file, the FALSE and TRUE, etc. could easily be replaced and the code would compile and run just fine.

Intellectual property... yeah, right.

[ Reply to This | # ]

Posix - Windows NT?
Authored by: kberrien on Monday, December 22 2003 @ 05:21 PM EST
I'm getting the gist that these are files required for Posix. And its just
tables, error codes, etc.. only one way to do it.

Windows NT (and its children, the vaunted Windows 2000, 2003, XP run posix too?)
is POSIX complaint (to a certain level if I remember). Would all this have to
be in NT too?

Didn't MS just this year buy Unix licensing rights, etc from SCO? So would not
NT 3.51, 4, 2k, 2k3, XP?, Longhorn also violate SCO's IP?????

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 05:21 PM EST
The errno.h files from the UNIX archives:

http://minnie.tuhs.org/UnixTree/V7/usr/include/errno.h.html
ht tp://minnie.tuhs.org/VSTa/srctree/newsrc/include/errno.h.html

What's interesting is that those files don't have any Copyright notices. One of the things that came out of the AT&T and BSD settlement is that code that was published without a Copyright notice fell under the pre-1976 US Copyright law and was put the code in the public domain.

So SCO is claiming infringement on code that has been placed in the public domain.

Even worse, while SCO acknowledges that some of the files may be from BSD, SCO is claiming that every thing from that agreement is Copyrighted by them.

The code identified above was also part of a settlement agreement between the University of California at Berkeley and Berkeley Systems Development, Inc. (collectively “BSDI”) and UNIX Systems Laboratories, Inc. regarding alleged violations by BSDI of USL's rights in UNIX technology. The settlement agreement between USL and BSDI addressed conditions upon which BSDI could continue to distribute its version of UNIX, BSD Lite 4.4, or any successor versions, including certain “UNIX Derived Files” which include the ABI Code. A complete listing of the UNIX Derived Files is attached. The ABI Code identified above is part of the UNIX Derived Files and, as such, must carry USL / SCO copyright notices and may not be used in any GPL distribution, inasmuch as the affirmative consent of the copyright holder has not been obtained, and will not be obtained, for such a distribution under the GPL.
Since Caldera distributed Linux and contributed code under the GPL for years, they are going to have a hard time proving that consent was not obtained.

SCO is trying very hard to confuse the media and the court with the name change from Caldera to SCO.

[ Reply to This | # ]

Too stupid
Authored by: Anonymous on Monday, December 22 2003 @ 05:28 PM EST
I feel uncomfortable with this. SCO is either very stupid or very clever. If
they are stupid they'll go to court with evidence like this. If they are clever
they'll baffle us with bullshit like this and go to court with something we
didn't see coming. In this case stupid is the easy answer....

[ Reply to This | # ]

  • Too stupid - Authored by: PJP on Monday, December 22 2003 @ 05:32 PM EST
    • Too stupid - Authored by: Anonymous on Monday, December 22 2003 @ 05:38 PM EST
      • Too stupid - Authored by: CPD on Monday, December 22 2003 @ 05:54 PM EST
  • Too stupid - Authored by: Electric Dragon on Monday, December 22 2003 @ 07:52 PM EST
  • It's the audience, stupid - Authored by: Anonymous on Monday, December 22 2003 @ 09:28 PM EST
  • Too stupid - Authored by: Anonymous on Tuesday, December 23 2003 @ 01:11 AM EST
  • Too stupid - Authored by: Anonymous on Wednesday, December 24 2003 @ 05:33 AM EST
SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 05:28 PM EST

I am sorry about this, but I have to respond to SCO at the level they have been spewing their FUD, just to make it fair:

"SCO is run by a bunch of poo-poo heads."

There, I feel better now. :)

I realize this may be deleted, I just couldn't help myself. :)

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 05:28 PM EST
Forgive me for reposting this but I wanted it under the main reply header
because I think it might be important. I just want to help what little I can.

While surfing the web I found a reference to an article located at

http://www.mozillaquest.com/Linux03/ScoSource-1_Story01.html

It has this statemet from Blake Stowell:

"No, none of the code in the Linux ABI modules contains SCO IP. This code
is under the GPL and it re-implements publicly documented interfaces. We do not
have an issue with the Linux ABI modules. The IP that we are licensing is all in
the shared libraries - these libraries are needed by many OpenServer
applications *in addition* to the Linux ABI."

I admit to being confused by this but Isn't this a contradiction?

[ Reply to This | # ]

Is this worth $3B? $300 per cpu?
Authored by: BubbaCode on Monday, December 22 2003 @ 05:29 PM EST
Seriously. Even if it was true that Linus copied ioctl.h, errno.h and their
freinds, what's the damage? Is having a binary copy of ioctl.h the cause of
$3B of damage? Is it worth 100's per cpu in license?

This is like saying you own the letter A and anyone who uses it needs to pay
up.

One of the major problems I have with SCO is that even if their claims were true
(which they probably are not), it is no where worth the kind of money they are
claiming.

[ Reply to This | # ]

Can SCO be sues now based on it's letter?
Authored by: Anonymous on Monday, December 22 2003 @ 05:35 PM EST
Since the sent SCO letter basically is a thread, can they be held liable for
babertry?

I imagine if they sent a letter to a German company, they could file a complaint
to a German judge?

Patrick

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: pooky on Monday, December 22 2003 @ 05:36 PM EST
I think what you are seeing is something that Darl hinted at in the conference
call. He said the majority of Linux users want to wait for SCO v IBM pan out or
want to see some evidence. Apparently SCOG thinks this is evidence.

I still don't see how end-users are willfully infringing when the legal status
of the code in the Linux kernel is up-in-the-air with SCO v IBM. How is someone
willfully infringing when both SCO and others claim the same code is theirs? End
users have nio way to know until it pans out in court against someone SCO claims
commited the original infrigement (IBM).

-pooky

---
IANAL, etc...

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 05:41 PM EST
If, as some posts persuasively argue (I'm thinking about the quote from Linus
Torvalds above), some of these files do not belong in any way to either SCO or
derive from UNIX code, can SCO be sued for attempted theft, fraud, or
misappropriation? Or charged criminally?

[ Reply to This | # ]

Watch out for SCO
Authored by: Anonymous on Monday, December 22 2003 @ 05:43 PM EST
SCO is being very clever here (not that they will necessarily win by reason of
this cleverness). FSF has been known to take the position that linking to GPL
header files makes the linking program a derivative of the linked header files,
and thus subject to the GPL. The issue has not been litigated, although there
are strong arguments that copying the information in header files should be
considered "fair use" under copyright law.

Regards,

Mark Wilson

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 05:49 PM EST
Sigh, this is still entirely useless information until SCO states with
specificity exactly which line(s) in those header files is/are infringing. For
crying out loud, every single one of those header files is distibuted with the
free Borland 5.5 C/C++ compiler for DOS/Windows.

[ Reply to This | # ]

ROTFL
Authored by: Nathan Hand on Monday, December 22 2003 @ 05:50 PM EST
Here is the letter from SCO warning recipients of alleged copyright violations. I must tell you that the list of files has everyone I am hearing from falling on the floor laughing.

PJ, you're right as usual. I eagerly scrolled down to the list of files, keen to see what the big fuss was about... and I saw... errno.h! I couldn't stop laughing for 5 minutes. I had to leave the room.

This is it? This is the big IP infringement? errno.h? Did SCO fire all their programmers and hire an escaped mental patient, because nothing else can explain this lame claim of ownership over... errno.h!

Ha ha ha ha....

[ Reply to This | # ]

  • ROTFL - Authored by: Anonymous on Monday, December 22 2003 @ 06:28 PM EST
SCO's Letter and the Files
Authored by: Flower on Monday, December 22 2003 @ 05:59 PM EST
Ok, let me get this straight as I am not a programmer. The header files are
basically there to reference .c files which define fields and what values those
fields can or do contain. So am I accurate in stating that each of these files
is nothing more than a primative database record?

You can't copyright a database and if it cannot be copyrighted it can't fall
under the DMCA.

Anymore insight people can shed on this would be greatly appreciated.

---
Teach it phenomenology.

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: dkpatrick on Monday, December 22 2003 @ 05:59 PM EST
Step back. Is SCO trying to claim ownership of the code or force IBM into
settling the suit? I think one could made a strong case that SCO is trying to
raise as much customer anxiety as possible, thereby disrupting the acceptance of
Linux and thus putting economic pressure on IBM, et al, to settle the suit with
SCO.

We can't assume that SCO is filled with idiots. I am sure their development
staff is as competent as any company's staff. They know the truth or falsity of
the claims and have advised SCO managment accordingly.

SCO reveals nothing to the defendant (IBM) but instead reveals bits and pieces
to the customers along with threatening letters and demands. They are trying to
get IBM's attention by getting the customers' attention. The customers who
don't want to fight the fight, capitulate and drop Linux (I am surprised that
some stated they would do this according to SCO), pay SCO, or pressure the
vendor(s) to do something about it.

It's a flanking move and let's not mistake what they say for what they
believe.

[ Reply to This | # ]

when Letters are NOT letters
Authored by: SaveDrury on Monday, December 22 2003 @ 06:02 PM EST
this was slick and smart...maybe?

they have released these "letters" via their website..
http://sco.com/scosource/unix_licensee_letter_20031218.pdf
and
http://sco.com/scosource/abi_files_letter_20031219.pdf

but does anyone know of an account where these "letters" were sent
via US Postal Service? I don't.

This is smart and slick... for worms.

Assuming this is true - that they've not sent these letters via USPS - would
they be shielded from any mail fraud laws?

are there any other laws (fraud?) that they're breaking via their (obvious and
now proven - thanks Linus) lies?

rat bastards. I wanna buy a SCO license and then demand that they send me these
letters via registered mail just to ensnare them.

[ Reply to This | # ]

errno?!? Nah.
Authored by: dwheeler on Monday, December 22 2003 @ 06:04 PM EST
I've looked a little futher into SCO's claims against
"errno.h". Frankly, this SCO claim doesn't look plausible.
I'm not a lawyer, so don't take this as legal advice,
but I _DO_ know a lot about computer software, and this
is a truly bizarre claim.

The file errno.h is simply a list of errors the kernel
can return, with three pieces of information for each error:
a short symbolic name for the error, a numeric code for the
error, and a brief comment explaining the error.

SCO cannot claim copyright over
the symbolic names; these are published in various
standards, including the Single Unix Spec from the
Open Group and the old IEEE POSIX specification.
SCO cannot claim copyright over the comment text either,
because those are also from the published specifications.
Indeed, I suspect you can trace most of this back to
the old /usr/group days.
Since the PURPOSE of these specifications is to
encourage uniformity, it's hard to argue that these
were unintentional either.

The notion of assigning numeric values to error codes
isn't a patentable notion either. The first FORTRAN
compiler did that! And since you can't copyright
ideas (only their fixed expression), it's not
copyrightable either.

The format of these seems to be slightly different
in tabs and spacing, which suggests that these
are NOT a cut-and-paste from somewhere else.
They're both #define statements, but that's not
plausible; the #define statement exists SPECIFICALLY
to define constant values for symbols, and the #define
statement requires a specific format, so it'd be hard
to show any real creativity when listing a bunch of
error codes. So, the format seems to refute the
claim of a copyright violation.

So, are the numeric values themselves copyrightable?
This seems wildly improbable.
The values themselves are arbitrary,
and a particular assignment embodies no original
"work of authorship", because one assignment has
no advantage over another.
And originality is critically necessary for material
to be copyrightable at all.

I compared the Linux kernel with
a version of Sun Solaris.
(The details: Linux kernel 2.4.7 /usr/include/asm/errno.h
and Sun SunOS 5.6 /usr/include/sys/errno.h).
Error numbers 1 through 34 have identical symbolic
maps. But after 1 through 34 things diverge in a hurry.
This version of the Linux kernel has 124 error messages,
so these assignments diverge rapidly after the first few.

So, the first few errno values are the same.
However, this doesn't require the kind of copying
prohibited by the copyright laws. It could also
occur because someone created their own
errno.h file (NOT a copyright violation),
and then intentionally used the same
error numbers for these old error codes
to make it easier for binaries to run on the Linux kernel.

The often-hated DMCA seems to even specifically permit this.
Here's the U.S. code section 1201:
"(f) Reverse Engineering. (1) Notwithstanding the provisions of subsection
(a)(1)(A), a person who has lawfully obtained the right to use a copy of a
computer program may circumvent a technological measure that effectively
controls access to a particular portion of that program for the sole purpose of
identifying and analyzing those elements of the program that are necessary to
achieve interoperability of an independently created computer program with other
programs, and that have not previously been readily available to the person
engaging in the circumvention, to the extent any such acts of identification and
analysis do not constitute infringement under this title. (2) Notwithstanding
the provisions of subsections (a)(2) and (b), a person may develop and employ
technological means to circumvent a technological measure, or to circumvent
protection afforded by a technological measure, in order to enable the
identification and analysis under paragraph (1), or for the purpose of enabling
interoperability of an independently created computer program with other
programs, if such means are necessary to achieve such interoperability, to the
extent that doing so does not constitute infringement under this title."

So it's doubtful that the numeric codes could be
copyrighted at all, and even if they could be, the
DMCA specifically says that people can even undo
encryption to permit programs
to communicate to each other. Since the Linux kernel
is one program, and application programs are different
programs, and their interoperability is considered
important in US law, the DMCA seems to clearly
state that this is in fact a permitted situation.

So... regarding errno.h, SCO can't claim the text or
symbols, because they're specified by standards.
Copyright covers only copying a specific
"tangible medium of expression", and the difference
in format suggests that there was NOT copying of the
medium of expression. There are similarities in the way
it's done because there's really only one normal way to do
this task (#define statements). The first errors have
the same numeric values, but copyright can't copyright
numbers (just their expression in a program).
And there's a good reason to have the numbers the
same for the low-valued error codes: interoperability,
which appears to be specifically permitted by US Code.

This isn't good evidence to get $3B.

[ Reply to This | # ]

  • errno?!? Nah. - Authored by: Anonymous on Tuesday, December 23 2003 @ 01:24 AM EST
    • errno?!? Nah. - Authored by: Anonymous on Tuesday, December 23 2003 @ 07:21 PM EST
SCO's Letter and the Files
Authored by: CPD on Monday, December 22 2003 @ 06:06 PM EST
Very, very strange. SCO claims a violation of a copyright on an ABI (outlandish
in itself, to say the least) and then lists a set of HEADER FILES (!) in
support. Even worse, the header files in question have values which don't match
the ABI! On top of this, any coder worth his/her salt would know that the
numeric values, such as error codes (about the only part of an ABI typically
implemented in a header file) is only a tiny part of the ABI. What about calling
conventions? There are at least three in common useage (C-style, Pascal-style
and register) which are most certainly part of an ABI. And there are parameter
widths. Then there are executable formats if the system loader gets involved -
are we talking elf, a.out, something else???

This reeks of suits with no teck smarts trying to make technical judgements.

Colin

---
Just when I thought it couldn't get any wierder, SCO proved me wrong again.

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: prong on Monday, December 22 2003 @ 06:06 PM EST
A few points.
  • There's a hazard of going a little over the edge here. SCO's most recent pronouncement is part of its current business model, which appears to be "scare the suckers out of license fees". While it is related to the IBM suit, it's a different tentacle, and needs to be considered seperately, and on its own merits (or lack of them, in this case).
  • It is very difficult to evalute the effect this letter may actually have, barring somebody producing a complete, publicly disclosable SCO license, and that still doesn't cover the private agreements that may not be available under trade secret provisions. My own perspective is that I would be very cynical about SCO's ability to trigger audits without specific allegations of violations, but I've seen software buyers sign the damnedest things.
  • SCO just shot itself in the foot again, with this announcement. A very large percentage of OpenServer and UnixWare licensees are turn-key systems vendors who resell those OSes as parts of business solutions (Micros being a large example), and this announcement is going to have those companies moving to rapidly dump SCO products and ramp up their sales forces to get customers to move to less problematic platforms.
On another note, I'd personally really like it if people would refrain from posting complete articles from external sources, particularly well mirrored ones like the LKML. As groklaw grows, there are going to be more posts, and having to scroll past 2 pastes of the same post is a bit annoying. This isn't a flame, or a personal knock on anyone, just a request for a little restraint.

Prong

[ Reply to This | # ]

Just showed code...
Authored by: kberrien on Monday, December 22 2003 @ 06:15 PM EST
Protective order? Didn't SCO just publically declare some of its IP, that was
already public? What kind of IP deserves a confidentiality stamp, and what kind
doesn't? Kinda would be hard to argue (I'm talking like a rational person,
not legal) later before the judge?

Is it only for IP which isn't IP because its so basic at the heart of it?

For the first time, today, I'm finally starting to get sick of all this. It's
starting to get really silly, and really strange. Its like DOT.COM fever has
hit the western US again. Heh, let's believe things that are not real...

[ Reply to This | # ]

Predictable Response?
Authored by: moogy on Monday, December 22 2003 @ 06:18 PM EST
Upon receipt of your letter we had two of our department
heads prepare an analysis for an executive meeting.

Legal Dept: Cost of determining legitimacy of claims
and legal options.
IT Dept: Cost of implementing alternatives to SCO software.

It seems that, due to the time constraints SCO has placed
for responding, our Legal Dept. will require a team of
paralegals, and possibly the help of an outside law firm,
just to determine our legal options, much less a decission
on a 'best course of action', and there is no guarantee
that this would be the end of our legal needs.

The IT Dept. informs us that a transition to several
possible alternatives could be implemented with reasonable
costs.

While we understand that the business focus of SCO has
shifted from software vendor to litigation factory, we
do not wish to follow this lead. Software is just one
of the tools that we need to do business, and we have
no desire to change our business.

Therefore, we regret to inform SCO that we will not
be renewing our SCO licenses.

Sincerely,
Your Licensee

---
Mike Tuxford - irc.fdfnet.net #Groklaw
First they ignore you, then they laugh at you,
then they fight you, then you win. --Gandhi

[ Reply to This | # ]

DMCA, RedHat, and the "invisible hand"
Authored by: Anonymous on Monday, December 22 2003 @ 06:22 PM EST
First of all if my company received a letter like this I would very quickly
forward it to our legal department asking what I should do. While I know this is
likely BS, it also looks like it might qualify as some sort of offical notice
under the DMCA requiring immediate action on my company's part.

I could very much see this resulting in at least a few companies dropping their
linux plans, postponing sales, or even mandating a switch to another platform
ASAP. This may even result in a few license payments to SCO from the ill
informed.

This brings us to RedHat's lawsuit against SCO. I suspect RedHat could make a
convincing argument that DMCA notices are threats by SCO to sue RedHat's
customers. In addition if RedHat loses any sales or customers due to these
letters they can show actual damages to the court.

IANAL but if I was RedHat I would file a motion asking for an immediate
injunction against SCO to prevent them from further damaging RedHat's business
until this matter is settled before the court.

This action by SCO makes me suspect that someone else really is using them to
damage Linux. Long-term for SCO this just digs them a deeper hole. In the
short-term this benefits anyone who views Linux as a threat to their business.

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 06:24 PM EST
Reading all this SCO crap is making me tired.

How about an industry wide consortium to simultaneosly sue SCO for restrait of
trade in every country and state having restraint of trade laws. Just
responding in a timely fashion should put them out of business.

[ Reply to This | # ]

Class-action from recipients?
Authored by: BsAtHome on Monday, December 22 2003 @ 06:27 PM EST
I was just thinking,...

Is it feasible for the recipients of the letter to start a class-action suit for harrasment/extortion/...?

Looks like the 1000 firms that got the letter need to get together and look at their legal options


BS

---
SCOop of the day, Groklaw Rulez

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Jude on Monday, December 22 2003 @ 06:27 PM EST
Rats, I didn't notice my session had expired.
The parent of this post is mine.

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Jude on Monday, December 22 2003 @ 06:28 PM EST
Rats, I didn't notice my session had expired.
The parent of this post is mine.

[ Reply to This | # ]

But SCO said Linux 2.2 was clean
Authored by: n0ano on Monday, December 22 2003 @ 06:31 PM EST
Once again, SCO's public pronouncements shift depending upon the direction of the current wind. To quote Blake Stowell in PC Pro:

End users have a choice. They can go back to using Linux based on the 2.2 kernel which includes no infringing code, or they can continue using SCO's UNIX code as it is being found in Linux and properly compensate the company for using it.

Interesting. The 2.2 kernel includes no infringing code. I predict that if you compare the 2.2 vs. 2.4 versions of the 65 infringing files you will discover almost no differences.

Unfortunately, this will not stop SCO's current claims. All it shows is that, once again, you can't believe anything they say, they will just change their story in the future if it suits them.

---
"Censeo Toto nos in Kansa esse decisse." - D. Gale

[ Reply to This | # ]

Annoying pun
Authored by: superluser on Monday, December 22 2003 @ 06:49 PM EST
Darn you, SCO! Look what you made me change my signature to:

--
All our segfault are belong to SCO.

[ Reply to This | # ]

Don't forget BFD and ELF standard
Authored by: John Goodwin on Monday, December 22 2003 @ 06:58 PM EST

I'm surprised they didn't include BFD or the parts of the ELF standard.
Probably because you can't support a standard and screw people with that
standard at the same time (well Microsoft tries but everyone understands they
use "standard" in a different sense than the rest of us).

Wouldn't most of what SCO claimed as "ABI" be necessary to support
the ELF standard? Aren't they just trying to hijack ELF?

Random text from google (search term "BFD SCO"):

[[Define `ELF_MACHINE_CODE' to the magic number which should appear in the
`e_machine' field of the ELF header. As of this writing, these magic numbers
are assigned by SCO; if you want to get a magic number for a particular
processor, try sending a note to registry@sco.com. In the BFD sources, the magic
numbers are found in `include/elf/common.h'; they have names beginning with
`EM_'.]]

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: AdamBaker on Monday, December 22 2003 @ 07:00 PM EST
Well this seems to have done the required job - I've seen very little here
about how badly the conference call went. The few bits I've bicked up from
Yahoo are that they seem to have put the Sun license revenue in Q4 even though
their accounting policy seeems to require delaying it till Q1 and they declared
a loss for Q4 (although it is not clear if this is pro forma or GAAP) but a
profit for the whole year. If the loss is pro forma then I think that means Darl
has run out of time to get his options. The earlier statement about earnings
being around 19c per share could be the pro forma figure and the loss is GAAP in
which case we need a pro forma loss in Q1 to stop Darl getting his options. This
looks likely with no SCOsource revenue predicted, a decreasing existing products
revenue and increasing legal costs.

[ Reply to This | # ]

What is SCO thinking?
Authored by: seeks2know on Monday, December 22 2003 @ 07:17 PM EST
A lot of action for one day:
  1. SCO announces that they have sent letters to thousands of their customers (UNIX licensees) asking them to certify compliance with their license terms and conditions.
  2. SCO announces that they have sent DMCA notification letters to Fortune 1000 Linux end users outlining violations of SCO's copyrights contained in Linux. The letter lists 65 files that SCO claims as infringing.
  3. SCO holds a conference call to announce their Q4 and FY2003 financial results (a loss of $1.,6M)
  4. At the end of the conference call, Darl McBride closes with a statement recognizing that Novell has registered copyrights for the same Unix code that SCO has recently registered. He calls Novell's actions "desperate" and "fraudulent".
  5. Novell later announces that have indeed registered copyrights for muck of the Unix code in dispute and they publish past correspondence with SCO over this issue.
My brain keeps demanding "Why did SCO take these actions today?"

SCO obviously initiated Actions #1 and #2 to divert attention from #3. (With minimal effect, as their stock dropped over 5% today.)

But Action #1 threatens their own customers, the source of their ongoing revenue. This is the type of letter that a software licensor sends to a licensee that he believes is in violation. The underlying message is, we believe that you may be in violation, please bring your actions into compliance with the terms of the license. Imagine Microsoft sending a letter to a customer asking them to certify that they are in compliance and, oh by the way, how many CPUs are you running our software on?

So my question is: "Why would SCO risk upsetting their existing revenue stream?"

Action #2 waives the DMCA banner and threatens Linux users. SCO encourages them to call to "discuss your options and work with you to remedy this problem." SCO also notes that the files listed are related to the old BSD vs. USL litigation.

I have several quick observations. First, SCO's copyright ownership of the listed files is very questionable. The BSD vs. USL litigation was settled out of court but suggested that many of the UNIX files did not include copyright notices and therefore were public domain. Second, a quick look at the files listed by SCO suggests that these are simple header definition files implementing POSIX standards. After months of work by multiple teams including MIT mathematicians, this cannot be the best that SCO has to offer. Finally by invoking the DMCA, SCO is making some serious charges.

My questions:
  • "Why would SCO open themselves to possible (best case) tortuous interference or (worst case) criminal fraud charges?"
  • Given that SCO lost credibility with the last set of files that it publicly claimed were infringing on their IP, why would they not present files that were absolutely solid in their portrayal of stolen code? Wouldn't they be sure to release their best stuff (just one or two files)?
I keep looking for some hidden strategy behind SCO's actions. But try as I may, I cannot find any supporting thread except acts of desperation to prop up the price of their stock.

My final observation: Surely SCO executives must see that there will be a day of reckoning when all of their press releases and letters will either be substantiated or proven false. With many of SCO's statements and claims currently contradicting their own earlier statements, what is their end game?

Please, SCO cannot be this stupid. There must be something I am overlooking. Your insight, please.

---
The beginning of wisdom is found in doubting; by doubting we come to the question, and by seeking we may come upon the truth. - Pierre Abelard

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 07:19 PM EST
Let's assume for argument's sake that the Earth is flat, pigs can fly, and
that SCO's assertions are in fact true - that the files in question (errno.h,
signal.h, etc.) were copied from BSD without proper attribution. The appropriate
response would be to reattach the joint USL/UC copyright. Problem solved,
right?

Wrong, at least in the alternate reality that exists in SCO's offices. The
people in the Infinite Wisdom Department at SCO must have thought of this, and
as such, their lawyer includes a stern admonition that these files "may
not be used in any GPL distribution, inasmuch as the affirmative consent of the
copyright holder has not been obtained, and will not be obtained, for such a
distribution under the GPL."

Fancy verbal maneuvering, but this fails the bullshit test. Read closely - the
lawyer has forbidden redistribution under the GPL. But that's the hidden catch
- you wouldn't (and indeed couldn't) redistribute these files under terms of
the GPL, because they already have a license - the BSD license! A license which,
in fact, is far more liberal than the GPL in terms of obligations and free
distribution.

Linux already has a fair amount of BSD-licensed code in the kernel - search for
"Regents" (which is a fairly unambiguous term) and you will turn up
dozens of examples of BSD-attributed code, all there perfectly legally. Copying
a properly BSD-attributed errno.h would be no different (and no less legal).
Saying that you can't redistribute these files "under the GPL" is
an unnecessary and irrelevant ruse, nothing more.

My $0.02,

Fruity

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 07:35 PM EST
After a cursory google of microsoft.com, I found this page listing some of the error codes. Look familiar, don't they?

Also note this phrase:

All errno values, defined as manifest constants in ERRNO.H, are UNIX-compatible. The values valid for 32-bit Windows applications are a subset of these UNIX values.

[ Reply to This | # ]

  • Microsoft - Authored by: the_flatlander on Monday, December 22 2003 @ 08:39 PM EST
    • Microsoft - Authored by: Anonymous on Thursday, December 25 2003 @ 12:41 AM EST
Fed up with SCO WARNING: Rant Ahead
Authored by: Anonymous on Monday, December 22 2003 @ 09:00 PM EST
I am sick and tired of SCO.

This is total BS.

Not even funny. Not even semi-amusing.

They are so full of crap at every turn there has got to be a legal way to stop
them. NOW.

Darl was born 135 years too late. Reminded me of a snake oil salesman. He
sounded so confident while he was spouting what he new had to be crap.

There HAS to be several laws against CEO's telling lies to the shareholders.

Are they walking such a fine line leagally they cannot be touched?

Doesn't the Lanham Act provide for immediate remedy?

They have obviously threatened to sue RedHat's customers. If there was ANY
doubt the conference call cleared that up. Why is RedHat so quiet? I would be
firing motions faster than SCO is threatening lawsuits.
Why is every Linux distributer so quiet? Legally quiet, that is. Real
corporations don't wage a legal war in press releases.
SCO is threatening to rip the heart of thier bottom line, and not a peep.

Can someone here who knows the law explain to me how they continue to get away
with this? For ten months they have been spouting venom, and a bunch of .h files
is all they have to show for it? Is there no way for an immediate "put up
or SHUT UP" in the law?

And another thing, when AT&T settled wasn't it because they where afraid
the SYSV code would end up public domain if they lost? Something about missing
copyrights?

Is there a way to get a judge to review that agreement (without showing the
public) to see if SCO is abiding by it?

There is injustice after injustice being committed here.
SCO cannot even keep what kind of case(s) they have.

Methods and concepts? You mean the ones that have been in textbooks for 30
years?

Derivitive code? you mean the software SCO does not have the rights to?

Line for line copying? Of Berkeley code? Or Linus own code? Or Posix standards?


Copyright? Settle that issue with Novell first.

IP? Patent?

Did MS buy a license to use the .h files?

Where does Canopy fit into all this? If SCO loses do they get to grab theier
collateral?

Thank You for letting me vent, and have a nice day, unless you are an executive
from Lindon


[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Monday, December 22 2003 @ 09:17 PM EST
Isn't mail fraud a very serious federal offense in the United States of
Amnesia*?

========

* Those who cannot learn from history are doomed to repeat it --George Santayana
(who could have been speaking of the relationship between John Ashcroft and Joe
McCarthy)

p.s. this sig has nothing to do with anything.

[ Reply to This | # ]

Just when you thought SCO couldn't be any more insane...
Authored by: Beyonder on Monday, December 22 2003 @ 09:30 PM EST
well they go and prove us wrong again.
Sorry, I've been one of those people rolling on the floor laughing, I actually
fell out of my chair.

Every time SCO does a press release the community responds with "They
can't be serious" (DOH!) But they are, and they keep
"topping" their previous insanity, somehow.

This is actually classic "pump-and-dump" strategy in case anyone
wanted to know. This isn't at all unusual for such a company to attempt, I've
seen it before. Just when you think it can't get any stupider or any more
insane, it does, and they keep at it.

They'll re-release old press releases too, as soon as they think it's time, or
when they think people have forgotten. The problem here is SCO is too much in
the public, and we catch on very quickly, but they don't care.

It's classic standard "pump and dump", been there, done that. The
show is over, move on.

SCO never had any proof, never will either, because it isn't copied. Linus
admitted (after a bit of arm twisting) that he himself wrote
"toupper" and "tolower", and very ugly versions of them
too. No self-respecting coder would take credit for something so aweful unless
they really did write it.

I've had my moments of code like that, stuff I would never admit to writing,
unless under extreme duress (okay okay!) heh. I've still got code out on the
net since 94 and earlier, it's like "my god, did I actually write that
crap?".

We know Linus wrote it, we know the other code came from BSD, we know that
Novell has rights to tell SCO to do whatever they want SCO to do, we know SCO is
full of hot air, and has no claims to anything, we know it's a pump and dump,
yet we sit here analyzing it...

ah well, at least it keeps people out of trouble I guess... ;)

[ Reply to This | # ]

SCO _still_ distributing Linux 2.4
Authored by: reuben on Monday, December 22 2003 @ 10:38 PM EST

I find it very interesting that SCO itself is still, right now, today, distributing the full sources for a Linux-2.4 kernel, accompanied by no license or restrictions other than the GPL. Apparently they haven't complied with their own DMCA letters.

You can find this at ftp://ftp.sco.c om/pub/LTP/SRPMS/linux-2.4.0-0t3f2.src.rpm

I suggest that anyone who can conveniently do so download a copy of this soon. It may be useful to have it well documented that even after the appearance of a specific copyright infringement claim, SCO itself continues to distribute the code in question to anybody who wants it, under no conditions but the GPL.

[ Reply to This | # ]

WOW, do they understand anything about copyright?
Authored by: Anonymous on Monday, December 22 2003 @ 11:55 PM EST
"in a commercial setting"... are they trying to indicate
that private use of an illegal copy is valid whereas
commercial use of same copy is invalid?

As far as copyright is concerned (and I deffinitly know I
know almost nothing about it) wouldn't an illegal copy be
illegal period whether used in a personal or commercial
setting?

In a word: WOW!

RS

[ Reply to This | # ]

SCO's Conference Call
Authored by: jtsteward on Tuesday, December 23 2003 @ 12:53 AM EST
I have just listened to the conference call.
53 minutes of BS.
Darl spouts an incredible amount of BS.
Sounded like Bill Clinton scripted his answers ala "I did not have sexual
relations with that woman" type answers and statements.
Mentioned code from August that was removed before presentation. Indicated BSD
code that was removed from Linux from August was SCO code, and was removed from
Linux AFTER presentation.
Remember code was BSD, and removed BEFORE August dog and pony show.

Can't quote exactly because call cannot be used in whole or part without
permission, and I don't think SCOG will give permission to Groklaw.


---
-------------------------------------------------
Darl needs more bullets, he keeps hitting his foot but he won't go down

[ Reply to This | # ]

"Berkeley Systems Development, Inc." never existed
Authored by: Anonymous on Tuesday, December 23 2003 @ 06:49 AM EST
Tibbitts writes:



"The code identified above was also part of a settlement agreement between
the University of California at Berkeley and Berkeley Systems Development, Inc.
(collectively *BSDI*) and UNIX Systems Laboratories, Inc. regarding alleged
violations by BSDI of USL's rights in UNIX technology."



If SCO's counsel had actually looked at the USL v. BSDI case, he might have
noticed that the principal defendant's name was "Berkeley Software
Design, Inc.", and that the term "BSDI" was always used to
refer to that corporation (never to the corporation and the university
collectively).

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: PeteS on Tuesday, December 23 2003 @ 07:23 AM EST
Let's look at a key part of the SCO statement

"The code identified above was also part of a settlement agreement between the University of California at Berkeley and Berkeley Systems Development, Inc. (collectively “BSDI”) and UNIX Systems Laboratories, Inc. regarding alleged violations by BSDI of USL's rights in UNIX technology"

Eric Raymond and others have responded extensively on this issue, and in particular has a link to the actual court documents in the case.

I suggest the legal types here take a look and see just what the record in that case does to this latest round of FUD.

---
Artificial Intelligence is no match for natural stupidity

[ Reply to This | # ]

SCO's Letter and the Files--A Bright and Shiny Object
Authored by: Anonymous on Tuesday, December 23 2003 @ 12:26 PM EST
Enough attention has not been given to the second-to-last sentence in SCO's open letter, namely:

As stated above, SCO's review is ongoing and will involve additional disclosures of code misappropriation. Certain UNIX code, methods and concepts, which we also claim are being used improperly in Linux, will be produced in the pending litigation between SCO and IBM under a confidentiality order. [Emphasis added.]

SCO is very clear in stating that the revelations of this letter are a subset of their claims; clearly we should not be comfortable with the relative paucity and weak nature of the so-called evidence. The letter is weak in defining SCO's basis for its suit and the claims are easily refuted through public documentation. It's a "gimme"--a bright and shiny object for us to focus on.

And therein lies the most interesting, and perhaps sinister, purpose of the letter. The hundreds of voices heard in the public outcry over this litigation have, essentially, written IBM's defense for this batch of code. SCO merely has to sit back and watch IBM's counterarguments unfold before its very eyes thereby placing IBM at a serious disadvantage at trial. After all, IBM will probably not be able to invent new counterarguments against SCO's claims at trial--that IBM must stick to facts limits IBM's maneuvering, whereas SCO is under no such restrictions in the invention of claims. SCO's letter allows it to prepare for trial without revealing the real code in question. And it has even managed to draw out the likely testimony of the foremost expert on the subject, Mr. Torvalds himself. While SCO will probably not stoop to Law & Order-like tactics such as "If you forgot your lunch last week (and we have pictures), then how can you say you remember how you wrote that code, 13 years ago?" (or maybe they will), having his testimony, or at least his gameplan, is to SCO's advantage.

And if they don't get enough of IBM's plan, they'll just release a few more code snippets to the public. Remember, Judge Wells ordered that the code be revealed to IBM--not to the public at large. Be very, very suspicious.

The letter is, most certainly, produced to bolster SCO stock prices, extract lines of argument, distract the knowledgeable, and spread fear, uncertainty and doubt. And because public outcry does not--and should not--influence a judge and jury's decisions, we must be careful not to jump to early and unfounded conclusions of victory.

Bill Eccles

[ Reply to This | # ]

signal.h
Authored by: Anonymous on Tuesday, December 23 2003 @ 08:53 PM EST
One of the header files claimed by SCO, and mentioned briefly by Linus, is signal.h. This header concerns signal handling, an esoteric topic that only a geek could love. Here's a primer so that normal people can follow the discussion. C mavens will notice that I am glossing over a lot of details that don't affect the legal issues.

Signals are an emergency alarm system. They provide a way to tell a program that it needs to drop whatever it's doing and respond to a crisis immediately. Signals may arise for a variety of reasons: a memory access violation, an illegal machine instruction, a Control-C from the keyboard, and so forth. A program can send a signal to another program, or even to itself.

In short, signals do for programs what fire alarms and tornado sirens do for people.

When a program receives a signal, typically it aborts with a core dump, unless it has made prior arrangements to respond differently. Sometimes aborting is good enough, but many programs try to respond more gracefully. They may clean up after themselves before aborting: write a message to a log, flush their buffers, and close their files. They may even be able to avoid aborting at all.

A program may need to respond to different emergencies in different ways, just as people do. If there's a fire, you run out into the front yard, but if there's a tornado, you huddle in the basement.

When a program receives a signal, it also receives a number that tells it what kind of signal it is. Different numbers are assigned to different kinds of signals. These assignments are arbitrary, and vary from one system to another. The variations could lead to problems if a program gets confused about which numbers corresponds to which signals. You wouldn't want to run out into the front yard, thinking there's a fire, when there's really a tornado.

The signal.h header is largely a gimmick to avoid that kind of confusion. It gives a name to every possible signal value. On a Unix or Linux system there are several dozen possible signals, and their names are mostly standardized. If the program refers to the signals by name rather than by hard coded numeric values, the same code can be compiled without change on multiple systems, because each system provides its own version of signal.h to assign the appropriate meanings.

Besides a list of signal names and numbers, the signal.h header declares some functions for sending and receiving signals, along with a few other bits and scraps that needn't concern us here. Much of this machinery is mandated by standards such as ISO C and POSIX, though there is room for variation in the details.

So what kind of infringement is SCO claiming?

The mere use of a header file, with a standard name, cannot be an infringement in itself. Any claim of infringement would have to rest on the contents of the header file.

SCO's letter makes an explicit claim of copyright infringement, which implies literal copying. I'm not in a position to judge for myself whether such copying has occurred, but there are no secrets here. By its nature, the source code of a standard header file (unlike the source code of a kernel) must be readily available in order to be useful at all. No doubt someone has already made the necessary comparisons. For that matter, recipients of SCO's letters can perform the comparisons themselves.

If the file had been copied verbatim from SCO's copyrighted code, or if substantial portions of it had been, then SCO might have a case for infringement, but even this scenario would not be a sure thing. Copyright protection does not extend to code that is trivial, obvious, or driven by functional necessity or published standards.

What might SCO claim other than literal copying?

It's always risky to guess what SCO is thinking, but maybe they object to particular mapping of names to signal values. This mapping is a major part of their touted ABI, as is the mapping of names to error numbers in errno.h.

Copyright law applies to the expression of ideas, not to the ideas themselves. Linux's use of an interface similar to that of Unix, or even identical, would not constitute a copyright infringement in the absence of literal copying. If you want to protect ideas, you use patents, not copyrights.

However, even this argument is moot.

According to Linus' account, both of those mappings in Linux are different from the corresponding mappings in Unix. These differences may be an accident of history -- young Linus couldn't afford a copy of the POSIX standard any more than he could afford a copy of Unix, and wound up guessing wrong sometimes -- but they establish two things:

  • The files were not copied verbatim, at least not in their entirety.
  • The ABI of Linux is not the same as the ABI of Unix.

If there was no literal copying, and if the ABIs are different, what does SCO have to complain about?

Not a thing. But you knew that.

Scott McKellar
http://home.swbell.net/mck9/sco/

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Wednesday, December 24 2003 @ 11:40 PM EST
is SCO pulling our chain???? CTYPE DOT F***ING H????? WHO EXACTLY do they
think they are fooling with this hilarious crap???? Are financial people THIS
DUMB????

Gee, however shall we live without EBADF defined? X-D

I can't believe they finally showed us their hand... I knew it would be
bullsh*t but THIS is beyond my wildest expectations of absurdity.... THANK YOU
SCO for an hour and a half of laughter!!

[ Reply to This | # ]

Why they should teach writing in law school
Authored by: Anonymous on Sunday, December 28 2003 @ 12:04 AM EST
My father is an attorney, so I have some exposure to what passes as writing in
legal filings:

/* ... These facts support our position that the use of the Linux operating
system in a commercial setting violates our rights under the United States
Copyright Act, including the Digital Millennium Copyright Act.
*/

First, unlike Trademark law, I believe that Copyright law doesn't apply
differently in commercial and non-commercial settings. "Fair use"
can even apply in commercial settings (satire, reporting, etc. can be commercial
endeavors and fall under fair use).

My real problem here is the "United States Copyright Act." That
should be "law" or "laws." The DMCA is the act passed
by congress and signed into law by the President, but I am unaware of any
generic copyright act. If there is one it would be separate from the DMCA, so
"the US Copyright Act, INCLUDING the DMCA" doesn't make sense.
That's like saying "your car's paint, including your house
windows" IMO.

/* Certain copyrighted application binary interfaces (?ABI Code?) have been
copied verbatim from our copyrighted UNIX code base and contributed to Linux
...
*/

Easy enough to disprove. Mistake here was to use "verbatim" which
means word for word.

/* ... the UNIX ABI Code has only been made available under copyright
restrictions.
*/

Aside from being a lie, this is misleading. The ABI *code* may have been made
available under copyright restrictions, but the interface (the I in ABI) has
been available outside of copyright restrictions. But the code itself has been
available outside of copyright restrictions -- just look at the BSD settlement.

/* The settlement agreement between USL and BSDI addressed conditions upon which
BSDI could continue to distribute its version of UNIX. ... The ABI Code
identified above is part of the UNIX Derived Files and, as such, must carry USL
/ SCO copyright notices and may not be used in any GPL distribution,
*/

Amazing, SCO claims that the settlement allows completely unrestricted
redistribution and derivation as long as a copyright notice is included, but
prevents redistribution of a derivitive that includes a copyright notice AND new
terms for the changed parts (the old parts are under the old terms see
http://www.gnu.org/licenses/gpl-faq.html#CombinePublicDomainWithGPL noting that
the public domain is different from a BSD license, but the legal idea is the
same -- portions available under less-restrictive conditions are always
available under those conditions). This sounds made up.

But, as noted by legal experts
(http://www.gnu.org/philosophy/sco/questioning-sco.html), SCO/Caldera did
authorize this.

/* Distribution of the copyrighted ABI Code, or binary code compiled using the
ABI code, with copyright management information deleted or altered, violates the
Digital Millennium Copyright Act (?DMCA?)
*/

This is hard to follow, since compilation that information is included as
comments, and compilation strips out ALL comments, including copyright-related
comments. Even if true, does this mean that inclusion of those notices (on the
files not written by Linus) would make this go away?

/* As stated above, SCO's review is ongoing and will involve additional
disclosures of code misappropriation.
*/

Where was that stated?

/* Certain UNIX code, methods and concepts, which we also claim are being used
improperly in Linux, will be produced in the pending litigation between SCO and
IBM under a confidentiality order.
*/

Translation: you may be sued on grounds we won't detail yet.

[ Reply to This | # ]

SCO's Letter and the Files
Authored by: Anonymous on Tuesday, January 06 2004 @ 05:26 PM EST
Funny... I thought that the files to which SCO is claiming are part of their
ABI are actually part of a publicly-published specification owned and maintened
by somebody else - The Open Group.

UNIX isn't just an operating system - it's also a specification. The Open
Group (not seemingly related to SCO at all) owns and maintains the UNIX
specification, including core API's.

The files that SCO mentions are mentioned as being part of the specification -
for example, that error numbers are stored in errno.h, and the definitions that
are required.

Have a look at http://www.opengroup.org/products/publications/catalog/c606.htm
or even download the PDF and have a quick read.

Does this make SCO's claim of ownership of those files completely baseless?

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