|
|
| 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
|
|
|
|
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| Authored by: seeks2know on Monday, December 22 2003 @ 07:17 PM EST |
A lot of action for one day:
- 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.
- 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.
- SCO holds a conference
call to announce their Q4 and FY2003
financial results (a loss of
$1.,6M)
- 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".
- 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
| |
| 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 | # ]
|
|
|
|
|
