|
|
| Linus' First Analysis of the Files |
 |
|
Monday, December 22 2003 @ 05:41 PM EST
|
Linus has taken a quick look at the files and has given permission for us to publish his first analysis. There will be more to say later, but the bottom line is that SCO appears to have made a copyright claim to some files that Linus wrote himself. I'll let him tell you about it, by reproducing his initial email to me from earlier today.
***************************************************************
I have a very strong memory of having written the original "errno.h"
myself too, and I really think that at least the i386 version of errno.h
actually has different numbers from "real UNIX". Some of the first ones
match, but not the rest. That one I explain by just having a list of error
codes, and just giving numbers in order, but maybe I'm wrong.
I have this distinct memory of figuring out only later that I _should_
have made the numbers be the same, so that I could have been binary
compatible. After all, I do actually have the book "Intel386 Family Binary
Compatibility Specification 2" (copyright Intel corporation, btw, not
SCO), and it lists the error numbers right there. They are different from
what Linux uses on x86.
Other architectures fixed that mistake, but the point is that the history
of "errno.h" is definitely _not_ from UNIX sources.
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.
|
|
|
|
| Authored by: eamacnaghten on Monday, December 22 2003 @ 06:33 PM EST |
Does this give Linux an opportunity to sue SCO for defamation? And would he
want to?
PS - A typo above...
#define tolower(c) (_ctmp=c,isupper(_ctmp)?_ctmp+('a'+'A'):_ctmp)
should read
#define tolower(c) (_ctmp=c,isupper(_ctmp)?_ctmp+('a'-'A'):_ctmp)
[ Reply to This | # ]
|
| |
| Authored by: BsAtHome on Monday, December 22 2003 @ 06:35 PM EST |
Linus is right, as we all suspected and knew.
I don't know how USA law
works, but this kind of "trade-practice" produced by SCO is not appreciated by
the Europen courts.
How about it, can someone put a sock in SCO's
mouth.
BS
---
SCOop of the day, Groklaw Rulez [ Reply to This | # ]
|
| |
| Authored by: _Arthur on Monday, December 22 2003 @ 06:36 PM EST |
Do SCO say which Copyright Notice is supposedly stripped ?
AT&T ? Microsoft? SCO ? BSD ?
All of the above? None of the above ?
_Arthur[ Reply to This | # ]
|
| |
| Authored by: brenda banks on Monday, December 22 2003 @ 06:39 PM EST |
doesnt this mean that sco is really infringing on linus's code?
hmmmmmmm
---
br3n[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 06:50 PM EST |
Please tell me that this is the stuff SCO will use to amend its complaint
with Copyright claims. That would make my day.[ Reply to This | # ]
|
| |
| Authored by: mac586 on Monday, December 22 2003 @ 06:54 PM EST |
Does SCO's behavior with this new letter, and the press conference, throw
gasoline on RedHat's filings in Delaware?
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 06:54 PM EST |
I can understand that SCO is incompetent, but are they really that
incompetent???? I guess so....
Go get Linux. SCO is treading on your turf and using your name in vain.[ Reply to This | # ]
|
| |
| Authored by: jmc on Monday, December 22 2003 @ 06:58 PM EST |
But SCO are still saying, on their web site here that their claims
only apply to 2.4 kernels upwards.
Yet these files are found in 2.2 etc
kernels completely the same (apart from architectures not then
implemented).
On my machine with 2.4.22 on it, ctype.h, for example,
has a 1998 date on it.
So SCO absolutely have to be contradicting
themselves (like just for a change).
[ Reply to This | # ]
|
| |
| Authored by: Halmonster on Monday, December 22 2003 @ 07:11 PM EST |
Is it possible that someone fixed these files by borrowing correct code from a
burdened source?
Don't we need to inspect all the patches to make sure they are as clean as the
original files?[ Reply to This | # ]
|
| |
| Authored by: Blakdelvi on Monday, December 22 2003 @ 07:11 PM EST |
I can see the SCO press release now: "Linus Torvalds admits he is 'a bit
ashamed' regarding our copyrighted code".[ Reply to This | # ]
|
| |
| Authored by: pyrite on Monday, December 22 2003 @ 07:16 PM EST |
C is an international standard. You can get it from ISO in Switzerland, you can
get it from ANSI in the states, I bet you can get it from DIN in Germany, etc...
ASCII is also an ANSI standard.
It's like the tower of Babylon or something...if everyone just arbitrarily
makes up their own character codes then no one will be able to work together
with each other - each hardware manufacturer will need different keyboards,
etc...
Basically, standardization is a good thing... it makes life simpler, safer, and
more efficient. But I guess some people don't care about that, only money. Oh
well....[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:17 PM EST |
Two points:
1) If, as Linus claims, he wrote these headers himself, without reference to any
other Unix source, then there is no copyright infringement.
2) From what I have read, I am convinced now that SCO's intention is not to win
in court, but simply to spread as much FUD as possible about Linux. Winning any
court cases would just be a nice side effect.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:17 PM EST |
SCO has pursued from day one a policy of NOT telling
which files and which code they are talking about.
This is simply a continuation of that policy.
It should be recognized that SCO DOES NOT have to tell
all the files that SCO is claiming violate SCO's [alleged]
copyright in SCO's letter. SCO only has to demonstrate
enough in the letter to make the letter creditable; SCO has
done that.
Now the question is: What the hell is SCO up to this time?
What are they claiming copyright to? Is this code all of it? [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:18 PM EST |
It's amazing that SCO are still putting these things out there without
any
input from any technically competent employees. OK, I know they're
more of a
publically traded lawsuit these days than a proper software
company, but
they've still got software engineers, right?
Either SCO's software
developers are just plain stupid, or their
bosses aren't listening to them (or
maybe aren't asking them). I think the
former, whilst a possibility, is
somewhat unlikely (there are limits to just
how stupid one can be and still
manage to write computer software, and
SCO's claiming copyrights on errno,
ioctl, signal and ctype sources are
beyond those, IMO...).
Of course,
they might just be trying to distract the analysts in order
to bolster their
share price; if that's what they're up to, then hopefully
the analysts will
figure it out this time.
SCO's latest claims, like all those before
them, appear to be
baseless. [ Reply to This | # ]
|
| |
| Authored by: Flower on Monday, December 22 2003 @ 07:20 PM EST |
SCO "shows the code" and within a few hours of research their claims
get blown away with a proverbial 10-gauge. And worse yet, it is so bleeding
obvious you have to wonder how SCO came up with their claims. Almost too
embarrassing to watch.
But what's really neat is how clear Linus explains things. This analysis
requires very little tweaking before it becomes "Grandma ready."
"I did this because..." "You can tell it's my code because I
made this stupid mistake and caused these problems." "The numbers
SCO use are the same numbers I got out of book published by Intel." All of
it adds up to a compelling argument that, in my lay opinion, is exceedingly
difficult to refute.
I'm looking foward to what gets said about the other files SCO is pointing to.
---
Teach it phenomenology.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:20 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:24 PM EST |
| After reading this, now I know why Tannenbaum gave Linus that 'F' grade ;-) [ Reply to This | # ]
|
- Following Linus' code review: - Authored by: eamacnaghten on Monday, December 22 2003 @ 08:04 PM EST
- Following Linus' code review: - Authored by: Maserati on Monday, December 22 2003 @ 08:07 PM EST
- Actually... - Authored by: kerrle on Monday, December 22 2003 @ 09:07 PM EST
- Actually... - Authored by: Anonymous on Monday, December 22 2003 @ 09:13 PM EST
- Actually... - Authored by: bruzie on Monday, December 22 2003 @ 09:58 PM EST
- Actually... - Authored by: Nathan Hand on Monday, December 22 2003 @ 10:29 PM EST
- Actually... - Authored by: Anonymous on Tuesday, December 23 2003 @ 12:18 AM EST
- Actually... - Authored by: Anonymous on Tuesday, December 23 2003 @ 09:53 AM EST
- Actually... - Authored by: Rodrin on Tuesday, December 23 2003 @ 05:06 PM EST
- Actually... - Authored by: Anonymous on Tuesday, December 23 2003 @ 05:18 PM EST
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:27 PM EST |
Up until now Linux has wide acceptance as a FREE (as in beer) OS.
For anyone to come along and claim ownership and hence payments, requires a
degree of proof and there is no getting away from this.
Companies have duties to their shareholders not to meet bills for unproven goods
and services.
------------------------------------------------------------
Free air is normally free. SCO now claim to have the God-Given right to collect
royalties on every breath we take. Would you accept this just on their say
so???? Neither Do I.
------------------------------------------------------------[ Reply to This | # ]
|
| |
| Authored by: rsmith on Monday, December 22 2003 @ 07:28 PM EST |
A lot of the things found in these files are part of the POSIX standard, like
signals, errno's etc.
The C Manual gives enough information in appendix B2 to implement ctype.[ch].
SCO might be able to copyright their _implementation_ of some of these things,
but not if it's trivial.
And there are only so many ways of saying #define....
---
Never ascribe to malice that which is adequately explained by incompetence.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:31 PM EST |
| EBADSCO - analysis is orthogonal to reality. As someone who's been programming
in C for twenty years, SCO's "evidence" is a joke. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:32 PM EST |
#1: SCO doesn't own the copyright to the UNIX code in question.
#2: Even if SCO owned the copyright, Linus never used UNIX code to write his
version.
#3: Even if SCO owned the copyright and Linus had used UNIX code to write his
version, simple lists of identifiers and numbers are not protected by copyright
law.
#4: Even if SCO owned the copyright, Linus had used UNIX code to write his
version, and simple lists of identifiers and numbers are protected by copyright
law, this particular list of identifiers and numbers is an internationally
published standard owned by noone.
What were they thinking?[ Reply to This | # ]
|
- The Story so Far - Authored by: Anonymous on Monday, December 22 2003 @ 07:40 PM EST
- The Story so Far - Authored by: Anonymous on Monday, December 22 2003 @ 07:54 PM EST
- The Story so Far - Authored by: Anonymous on Tuesday, December 23 2003 @ 08:49 AM EST
- The Story so Far - Authored by: Anonymous on Monday, December 22 2003 @ 07:55 PM EST
- The Story so Far - Authored by: Anonymous on Monday, December 22 2003 @ 08:39 PM EST
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:39 PM EST |
Another interesting SCO contradiction... If these headers are the problem, where
does their whole "IBM put enterprise code in linux to destroy us"
line of reasoning go. Clearly, even if these were unix files stripped of their
copyright notice, most of them pre-date IBMs contributions.
In other words, linus's original analysis stands... they are smoking crack...
It is the only theory which fully explains the facts.[ Reply to This | # ]
|
| |
| Authored by: the_flatlander on Monday, December 22 2003 @ 07:44 PM EST |
I love Groklaw.
Have any of the "big guns," (Mr. Moglen, RMS, ESR, for example),
made statements yet?
I've looked around at various tech-news sources and found nothing.
Which is why I love Groklaw. All you need to know, first.
TFL
Yes, that's my understanding, SCO claims copyright on variables named
"i."[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:46 PM EST |
More and more assertions that "SCO are stupid", or words to that
effect, are making their way to the SCO related comments. I'm sure that SCO are
not stupid.
Under what set of rational assumptions and plans going forward do SCO's actions
make sense?
With a small amount of reseach Linus trivially refuted some claims they made.
Therefore its unlikely an intelligent person would have had proving these claims
true as an end goal. We need to understand what the end goal is. [ Reply to This | # ]
|
- SCO's reasons - Authored by: Anonymous on Monday, December 22 2003 @ 07:59 PM EST
- Linus' First Analysis of the Files - Authored by: Anonymous on Monday, December 22 2003 @ 08:08 PM EST
- SCO's motives. - Authored by: the_flatlander on Monday, December 22 2003 @ 08:11 PM EST
- Linus' First Analysis of the Files - Authored by: Anonymous on Monday, December 22 2003 @ 08:21 PM EST
- Linus' First Analysis of the Files - Authored by: rgmoore on Monday, December 22 2003 @ 08:21 PM EST
- Linus' First Analysis of the Files - Authored by: Anonymous on Monday, December 22 2003 @ 10:33 PM EST
- SCO thinking... - Authored by: Anonymous on Monday, December 22 2003 @ 10:48 PM EST
- SCO thinking... - Authored by: Anonymous on Tuesday, December 23 2003 @ 01:27 AM EST
- Understanding SCOX's Goal - Authored by: WhiteFang on Monday, December 22 2003 @ 10:48 PM EST
- A scam pure and simple. - Authored by: Anonymous on Tuesday, December 23 2003 @ 01:11 AM EST
- My thoughts - Authored by: Anonymous on Tuesday, December 23 2003 @ 03:33 AM EST
- Re: My thoughts - Authored by: Anonymous on Tuesday, December 23 2003 @ 05:21 AM EST
- A Noble Question - Authored by: Anonymous on Tuesday, December 23 2003 @ 11:23 AM EST
- Blame game - Authored by: Anonymous on Tuesday, December 23 2003 @ 11:41 AM EST
| |
| Authored by: mrsam on Monday, December 22 2003 @ 07:46 PM EST |
The following thought just occured to me.
Up until a year ago, Alan
Cox was a Red Hat employee (he's now on an extended sabbatical). If it turns
out that at some point in the past Alan Cox worked on some of the files in
question (which seems VERY likely, and it doesn't matter how small his changes
were), then SCO has just made a major blunder, because this stunt goes directly
to the heart of Red Hat's lawsuit against SCO: SCO's intellectual property
claims are bunk, and Red Hat has the smoking gun to prove that.
Ditto for
IBM. If any IBM employee worked on any of these files (and, of course,
contributed the changes under the GPL), then it's going to be more sauce for the
goose.
SCO is doing an amazing job of shooting themselves in their feet,
time and time again. I'm wondering how many intact feet they have left,
now.
When Chief Blabbermouth himself yapped in the media how it's to
SCO's advantage to keep the alleged infringements to themselves as long as
possible, in order to accrue more damages, I knew that this will end up biting
them in arse, eventually (as it did, in IBM's motion to compell). Judges don't
like seeing anyone purposefully inflating damages that they are seeking to
redress by bringing the legal action. Similarly when they went on and on in the
press how they have all these mountains of evidence of alleged infringements, I
knew that their bluff is going to be called (as it did, in IBM's motion to
compell).
Expect to see the flaming wreckage of this latest stunt in some
future court filing too. It was clear from the get-go that SCO are amatures at
this sort of a thing: using lawsuits as a business model. Every freshman Matlock
wanna-be in their first year of law-school learns one thing: when you're
litigating, you keep your yap SHUT. Flapping your gums, like what's SCO's been
doing (for the laughably obvious aim of pumping their stock) never leads to
anything good.
[ Reply to This | # ]
|
- Linus' First Analysis of the Files - Authored by: Anonymous on Monday, December 22 2003 @ 08:03 PM EST
- Linus' First Analysis of the Files - Authored by: Anonymous on Monday, December 22 2003 @ 08:49 PM EST
- Linus' First Analysis of the Files - Authored by: Anonymous on Monday, December 22 2003 @ 08:57 PM EST
- Linus' First Analysis of the Files - Authored by: Anonymous on Monday, December 22 2003 @ 09:47 PM EST
- Linus' First Analysis of the Files - Authored by: dentonj on Monday, December 22 2003 @ 11:49 PM EST
- It doesn't matter. "truth" is irrelevant. - Authored by: Anonymous on Tuesday, December 23 2003 @ 04:36 AM EST
- Experts at it? - Authored by: Anonymous on Tuesday, December 23 2003 @ 10:47 AM EST
- Experts at it? - Authored by: Anonymous on Tuesday, December 23 2003 @ 09:38 PM EST
- Experts at it? - Authored by: Anonymous on Tuesday, December 23 2003 @ 09:42 PM EST
- Experts at it? - Authored by: Anonymous on Wednesday, December 24 2003 @ 03:26 AM EST
- "...shooting self in foot..." - Authored by: Anonymous on Tuesday, December 23 2003 @ 09:38 AM EST
- Linus' First Analysis of the Files - Authored by: Anonymous on Tuesday, December 23 2003 @ 11:13 AM EST
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 07:49 PM EST |
I must say this isn't surprising comming from SCO. They've proven their
inability to track the origin of their code. I cite the code they showed at
their Las Vegas conferance as an example.[ Reply to This | # ]
|
| |
| Authored by: dentonj on Monday, December 22 2003 @ 07:51 PM EST |
| ht
tp://stage.caldera.com/cgi-bin/ssl_getmanpage?malloc+S+OSES30+malloc
Eve
n SCO's own man pages reference the "Intel386 Binary Compatibility
Specification, Edition 2" book. I wonder why the code looks similar.... Is
this another case of SCO claiming ownership and Copyright on something they
don't own and have no idea where the original code came from?
[ Reply to This | # ]
|
| |
| Authored by: Israel Pattison on Monday, December 22 2003 @ 07:54 PM EST |
I was very pleased to find the following letter from my
Congressman, David Price (D-NC, 4th) in my mailbox this
evening (all transcription errors mine):
Dear Mr. Pattison:
Thank you for contacting me regarding legal action that
SCO Group, Inc. is threatening to bring against some users
of the Linux operating system.
I understand your concerns about the legal tactics of SCO.
As you know, the company initiated a lawsuit against IBM,
Inc. earlier this year, alleging that IBM had incorporated
UNIX code into Linux software distributed by IBM in
violation of an agreement between the two companies. SCO
has also stated its intention to charge a licensing fee to
some Linux users and to bring lawsuits against some large
Linux users if they refuse to pay the fee.
With Red Hat and IBM both in my congressional district,
you can be sure that I fully support the development and
deployment of open source software. I also understand
that SCO may be targeting Linux users in order to buttress
its lawsuit against IBM and to have a chilling effect on
the distribution and use of Linux. Because of the
separation of powers of the federal government, however,
Congress cannot become directly involved in an ongoing
legal battle that is still under the jurisdiction of a
court or to intervene in specific lawsuits that SCO may
eventually bring against Linux users.
Earlier this month, a federal judge ordered SCO to provide
information within 30 days that specifies what UNIX code
it believes IBM incorporated in Linux and to detail why it
believes IBM has violated SCO's rights. Unless SCO is
able to satisfactorily provide this information, which it
has refused or been unable to do so far, I think it
unlikely that the company will prevail in its lawsuit.
Thank you again for contacting me. Please continue to
stay in touch on issues of concern.
Sincerely,
DAVID PRICE
Member of Congress
4th District, North Carolina [ Reply to This | # ]
|
| |
| Authored by: davep on Monday, December 22 2003 @ 07:57 PM EST |
OK, so SCO's General Counsel supposedly sent a letter to a bunch of companies
threatening legal action. The basis for this is so ridiculously false that SCO
must have known they were bluffing when they sent the letter.
What recourse do the companies who received this letter have? What about
companies like Red Hat who didn't receive the letter but whose businesses were
affected by the press coverage surrounding it? What about investors who
purchased shares of SCOX after hearing about this supposed "proof"?
What about Linus, whose reputation has clearly been tarnished?
Could someone complain to the local bar association about Mr. Tibbitts'
barratry? Would they need to be personally wronged to do so? (a recipient of
the letter? an investor? a concerned citizen?) Do they need to be a resident
of the state of Utah?
I'm just curious if there are any sorts of remedies available for this sort of
thing.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 08:23 PM EST |
| SCO recently opened a office in
Dublin,
Ireland.
Quite near to Microsoft, as it happens (about 20-30minutes on
the bus from Merrion Square to Sandyford, hop on the 46A.). Is
this the covert
information channel they are using to coordinate with their
masters, outside
of american national jurisdiction but inside
the american imperial sphere?
(Irish government is puppet to
american megacorps, particularly microsoft).
Could be no more
difficult than SCO folk meeting for a pint with some MS folk
down
the pub.
[ Reply to This | # ]
|
- SCO Ireland - Authored by: Anonymous on Monday, December 22 2003 @ 08:26 PM EST
- SCO Ireland - Authored by: Anonymous on Monday, December 22 2003 @ 08:37 PM EST
- Tinfoil hat? - Authored by: Anonymous on Monday, December 22 2003 @ 08:55 PM EST
- Tinfoil hat? - Authored by: Anonymous on Monday, December 22 2003 @ 08:58 PM EST
- Tinfoil hat? - Authored by: Anonymous on Tuesday, December 23 2003 @ 03:43 AM EST
- Merrion House - Authored by: Anonymous on Monday, December 22 2003 @ 09:10 PM EST
- SCO Ireland - So what? - Authored by: Anonymous on Friday, December 26 2003 @ 01:29 PM EST
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 08:55 PM EST |
You know, I can't help but wonder just what would happen if something like this
could be pulled off the next time newSCO releases more code as
"proof": Don't say a WORD.
That's right: stay quiet. Keep mum. Sure, do the homework. Get the facts.
Just don't say anything where newSCO would see it. Instead, feed it to the IBM
lawyers for their perusal and enjoyment. Let newSCO think they finally have one
over on the F/OSS community.
When the Day of Recconning (sp?) comes (and you know it will!), we can get a
play-by-play of how their collective jaws crash through the floor of the court,
much like one would see in cartoons... Hehehe...
The only down-side I see to this is that the FUD would take root and the SCOX
stock would rise. However, most of us have heard "The bigger they are,
the harder they fall"... ;)[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 08:57 PM EST |
I have access to System V code, and while I have no doubt that what I am posting
is completely legal, I decided to post anonymously.
I have done a fair bit of comparisons between SVR4.0.1 and Linux, and I've also
compared with BSD and 32V. A couple of weeks ago, I commented (privately) that
errno.h (in some architectures) looks the same (i.e. possibly copied).
Obviously the variable names and numbers match - but the comments match exactly
too. If you look at 32V, or BSD, the comments do *not* match. In particular,
it seems clear that the errno.h in the BSD that I looked at has a separate
heritage - whereas some of the Linux errno.h's don't.
The biggest overlaps are in asm-mips/errno.h and asm-alpha/errno.h. (Actually,
looking at the output from ESR's tool now, but without the source code in front
of me, these matches might appear in other architectures too.)
For example, look at the definition of ESPIPE in 2.4.23 asm-alpha/errno.h:
#define ESPIPE 29 /* Illegal seek */
This is 1 of at least 50 lines (in errno.h) that matches exactly, including
comment.
While you can argue that comments etc. can't be protected by copyright - I
would also feel better if someone could point out a public unprotected place
that these comments might have come from.
[ Reply to This | # ]
|
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: Anonymous on Monday, December 22 2003 @ 09:07 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: babazaroni on Monday, December 22 2003 @ 09:09 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: davep on Monday, December 22 2003 @ 09:18 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: mac586 on Monday, December 22 2003 @ 09:30 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: Anonymous on Monday, December 22 2003 @ 09:32 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: gvc on Monday, December 22 2003 @ 09:37 PM EST
- The comments match because they are POSIX standard, and NOT SCO IP - Authored by: Anonymous on Monday, December 22 2003 @ 09:42 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: Anonymous on Monday, December 22 2003 @ 09:43 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: stend on Monday, December 22 2003 @ 09:54 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: Anonymous on Monday, December 22 2003 @ 09:59 PM EST
- FOLLOW UP: Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: Anonymous on Monday, December 22 2003 @ 10:19 PM EST
- How about a *REAL* comment? - Authored by: Anonymous on Monday, December 22 2003 @ 10:41 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: Philip Stephens on Monday, December 22 2003 @ 11:15 PM EST
- This is where the comments come from - Authored by: Anonymous on Tuesday, December 23 2003 @ 12:34 AM EST
- you're grasping for straws... - Authored by: Anonymous on Tuesday, December 23 2003 @ 01:18 AM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: DrStupid on Tuesday, December 23 2003 @ 07:05 AM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: hstudt on Wednesday, December 24 2003 @ 06:02 AM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: vonbrand on Thursday, December 25 2003 @ 09:44 PM EST
- Where do the comments in errno.h come from? Because they match in SysV 4.0.1 - Authored by: Anonymous on Friday, December 26 2003 @ 02:16 PM EST
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 09:10 PM EST |
| I had to dig out a back issue of Linux Magazine - the June 2001 issue - after
reading Linus' post, because I wanted to share this with those who didn't play
around with Linux until recently.
Linux Magazine published an interview with
Dennis Ritchie, the inventor of C and co-creator of Unix, which I think sheds a
little more light on Linus' own inabilities as a programmer in the earlier years
of Linux. Linus admits as much in his post, that he didn't fully understand C or
writing an operating system from scratch, and Ken Thompson - the other
co-creator of Unix - apparently agreed that Linus' programming abilities left
something to be desired.
LM: Have you ever looked at the Linux
source code?
DR: I haven't looked in a lot of detail. A year and a half ago
or so, we ported Inferno [a Bell Labs OS for appliances] to it, and it was
somewhat of a pain. Somebody discovered a driver - I guess - some place in the
kernel that had some extremely stupid thing going on. It was about then that Ken
gave some interview, and he remarked that he didn't think very much of the
quality of the code.
LM: Did you agree with him?
DR: Well, I haven't
really looked at the code, so I really have nothing to say except that [Ken] got
enormous amounts of hate mail for being quoted. Of course the quote was really
out of context in any event. [...]
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 09:12 PM EST |
#6 (or whatever we're up to): Even if SCO owned the copyright and yada yada
yada, they've still made this code available under GPL themselves.
I know this is an old line, but it still holds. And claiming owership of
something as ubiquitous as ctype.h doesn't help their theory that they
distributed Linux unknowingly. Think about it - if they're claiming that
there's a correlation between UNIX ctype and Linux ctype, then they have to be
saying that having the same identifier names (e.g. "tolower") is
enough for a copyright violation, since we've already seen that there are
differences in implementation and history.
So if copyright violation was that easy, all it would have taken was one SCO
programmer to say "hey, how come I can use 'tolower' on this UnixWare
box and this Linux box and they both compile? They must have some macros in
common! Hey Darl, have a look at this!"
Unless, of course, SCO's programmers weren't dopey enough to think that such a
tenuous link was a copyright issue.[ Reply to This | # ]
|
| |
| Authored by: John Goodwin on Monday, December 22 2003 @ 09:17 PM EST |
http://www.caldera.com/developers/gabi/
There are plenty of specification docs in there (PDFs) for different platforms.
Happy digging.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 09:46 PM EST |
"To our knowledge, 2.6 builds upon the intellectual property
violations that continue to be in 2.4. JFS, NUMA, XFS, RCU, and a host of other
code violations have not been removed." -- Blake Stowell,
2003-12-18
It doesn't take a C guru to know that header files are
not where you'll find filesystems or advanced scheduling and locking techniques.
Linux 2.4.20 JFS, for example, is 42 source files totalling 795k. None of those
files are mentioned in this letter.
If Linux stole these technologies, then
why is SCO wasting everyone's time with toupper() and "#define EBFONT 59"?
That's what I would have asked during the conference call.
[ Reply to This | # ]
|
- These files have nothing to do with RCU, SMP, NUMA, JFS, or XFS - Authored by: Flower on Monday, December 22 2003 @ 10:15 PM EST
- These files have nothing to do with RCU, SMP, NUMA, JFS, or XFS - Authored by: Phong on Tuesday, December 23 2003 @ 04:45 AM EST
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 10:03 PM EST |
| Ok so..there orignal...what now? [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 10:05 PM EST |
I don't think Linus's argument is valid. Sco says, "File X infringes our
copyright." Linus says, "I wrote the original Linux version of File X and it
didn't contain your material back then."
Well, that argument gets Linus off
the hook, but not Linux's File X. It's had contributions since then, which have
moved it closer to the Unix version. The question is whether the recent
versions infringe, not whether the oldest version infringes.
I think it is
all a tempest in a teapot, however, since SCO's claims relative to these files
sound weak. These header files are largely listings of facts, rather than
program code.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 10:26 PM EST |
Nobody expected the carefully hidden source files to be such foundation segments
of the whole building.
SCO is claiming that errno.h, errno.c, ctype.h, ctype.c were copied from
Unixware, without showing to anybody what the source code of Unixware is.
Here is a chance for IBM to raise the question whether SCO copied Linux code and
is claiming the opposite. If this is the truth, then SCO should pay damages to
the Linux community and to IBM for difamation.
What a bunch of crooks the SCO heads are.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 10:31 PM EST |
sooner or later SCO's gonna have to claim copyright violations on Intel
Corporation's attempts to "reverse engineer" trade secrets in SCO
in order to embed "secret error codes" into the Intel x86 series of
chips.[ Reply to This | # ]
|
| |
| Authored by: John Goodwin on Monday, December 22 2003 @ 10:35 PM EST |
| For those who like to read Groklaw, rather than multi
megabyte specs, a summary
of the Generic ABI docs
posted at caldera.com--
I
thought I would take a look at what SCO considers part of "an ABI". Quite a lot
actually. The ABI is a family of specifications (one for each processor),
which
at the generic level subsumes what we think of as libc, X, and pretty much all
of "Advanced UNIX Programming". Of course, as a standard, it is aware that it
is building on other standards, often included by reference
or subsumed
wholesale in order to make the specification useful.
This raises the
interesting question, if "ABI" include all of X/Open, SVID, X Windows, Motif,
ISO Standard C, and so forth by title, then what, exactly,
is the proper subset
of the ABI claimed belonging to SCO as theirs? Are they really claiming all of
Motif and C? Last time I checked, those ran on OSs other than Unix.
A 1/2
dozen header generic files, together with their "processor specific" reflexes,
are pretty thin, given the broad sweep of the full ABI!
Here are some
interesting notes on "Generic ABI 4.1 (ca. 1997)":
1. The SCO ABI
specification *predates* their "purchase" of UNIX:
"UNIX is a registered
trademark in
the USA and other countries, licensed exclusively through X/Open
Company Limited."
By the way, these web docs publish text for the following
files (for i386 etc.), are listed verbatim in the processor specific
pdfs:
assert.h, ctype.h, dirent.h, dlfcn.h, elf.h, errno.h, fcntl.h,
float.h,
float.h, fmtmsg.h, fnmatch.h, ftw.h, glob.h, grp.h, iconv.h
sys/ipc.h,
langinfo.h, limits.h, locale.h, lwpsynch.h, machlock.h,
math.h, sys/mman.h,
sys/mod.h, sys/mag.h, netconfig.h, netdir.h,
nl_types.h, sys/param.h, poll.h,
pwd.h, regex.h, sys/resource.h
rpc.h, rtpriocntl.h, search.h, setjmp.h,
sys/shm.h, signal.h,
sys/signinfo.h, stat.h, statvfs.h, stdarg.h, stddef.h,
stdio.h,
stdlib.h, stropts.h, synch.h, termios.h, thread.h,
sys/ticlts.h,
ticots.h, ticotsord.h, time.h, sys/time.h, sys/times.h,
tiuser.h,
tspriocntl.h, sys/types.h, ucontext.h, sys/uio.h, unistd.h,
sys/utsname.h
wait.h, wchar.h, wctype.h, X11/Atom.h ... Xutil.h, Xm/ArrowB.h
...
Xm/XmStrDefs.h, netinet/in.h, netinet/ip.h, netinet/tcp.h
Any of these
look familiar? The reason you publish interfaces in standards is to help
programmers write code that is portable to your system, because if you have a
nifty OS, you would like software to run on it, and programmers to support it.
At least you do if you are not
SCO but Caldera, ca. 1997. Very helpful of them
to put all this text into their standard.
Oddly enough, they published all
this before they "owned" Unix.
2. Mostly, its the lower, underpinning layer
for SVID. Specifically, draws on architecture of processor, SVID, POSIX,
X/Open, ISO definition of C programming
language, and X11R5.
3. Scope of the
Generic ABI is --
"All interfaces in the X/Open CAE Specification, Issue
4.2 (excluding those marked Withdrawn) and certain interfaces in the System V
Application Binary Interface, Fourth Edition are contained in this document, the
System V Applica-
tion Binary Interface, Edition 4.1 (System V ABI 4.1)."
4.
SV ABI is intended to be conformant to XPG4.2. System V was modified to make it
so, and what parts were changed is highlighted.
5. X/Open CAE Specification
takes precedence over SVID, where they conflict.
6. Here's how comprehensive
the ABI is:
"The complete System V ABI is composed of this generic ABI
specification and the supplemental processor-specific specification for a
particular processor architecture.
These two documents constitute a
specification that should be used in conjunction with the publicly-available
standards documents it references (some of
these are listed above). The ABI
enumerates the system components it includes, but descriptions of those
components may be included entirely in the ABI, partly
in the ABI and partly in
other documents, or entirely in other reference documents."
Let's savor
that: The ABI is a list of system components, some of which are
described by
various other standards. "Property", presumably, can be listed,
and it is the
ABI that is claimed owned--how extensive is that?
We will be alert for the list
of components, then.
You know, the ABI serves a purpose besides getting SCO
crapware to run on Linux.
It is really designed so System V (including SCO's),
not Linux, can run other
Unix software! In theory, they *want* portability to
System V, so they tell you
how to do it. Programmers, follow these rules and
you'll be compliant.
There's Level 1 conformance and Level 2 conformance.
Mostly, the strategy
is to *restrict* the functions you call. Get that? 90% of
what's in the
ABI is what you *don't* do, because what you avoid is what makes
you portable
(to System V). So, the ABI list had better be *pretty extensive*
or you
won't be allowed to do anything. It has to be a big, big list of all
of
"what Unix traditionally does".
Ergo, the ABI *has* to claim to be the
whole Unix world, or it wouldn't be a
very useful ABI would it? But a list of
restricted functions is a far cry from
a list of everything I own. That's like
saying "you can avoid my tresspassing
on my property as long as you stay out of
my city's limits." Well, true enough
but listing all the neighborhoods in my
city (listing all components of the
ABI) is not the same as defining my property
boundaries.
This remind of a persistent tendency to say "here's a list of
stuff, it's in
there"? This is what it is about. Start with a maximal list of
components
required to function, including everybody elses stuff. Now claim it
all,
since with less than this you are not compliant with my
standard.
Guess what happens if SCO claims to own the GABI *and* any
implementation of it--
No one, I mean *no* one, can write Unix code portable to
System V. There's a
business strategy. If you harm Linux, you harm System V.
Standards are like
fair trade--trade wars hurt both sides. Probably, they hurt
System V more
than Linux, though in the narrow markets SCO cares about the
effect might be
the opposite--or just hasten migration.
7. What does the ABI
control?
-- the system memory map (must be compliant)
--
compilers
-- certain files or utilities like "sh" and "true" which can be
assumed
present, in light of the ABI.
In fact heres a list of some stuff
that's in the Generic ABI:
-- character representation
-- machine
interface (processor specific)
-- function calling sequence
-- OS
interface
-- ELF headers
-- object file binary format
-- program
loading and dynamic linking
-- C library (libc)
-- threads
-- DL
library (libdl)
-- network, sockets
-- libnls
-- libcurses
-- X
Windows (libX, also incl. XT intrinsics libXt, Motif libXm)
-- archive file
formats ("tar files")
-- terminfo database
-- networking
protocols
-- system commands
-- execution environment ("THE
ENVIRONMENT")
-- file system structure
-- windowing and terminal
interface
-- a certain dev environment required to compile all of
this
a.k.a. "The Unix Programming Environment"
-- streams, TLS, System V
IPC
What did we learn? When SCO says "ABI", they mostly mean the entire
set
of Unix standards that allow a binary executable to run portably
on System V,
even if written for another environment. This is far
more extensive than just
iBCS and its heirs and assigns.
We have just seen the tip of the iceberg, I
think, of what is going
to be claimed. But what, exactly, is going to be
claimed? [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 10:39 PM EST |
As someone else pointed out, SCO's letters are dated the 19th, but when were
they sent? Dates can be changed easily enough with mail merge.
So, SCO floats this balloon to see if they're on the right track, and we do
their research for them, since it seems they have no one in-house who is
qualified to do it?
They find out this won't fly, so they simply don't put the letters in the
mail? Does anyone know if they were actually sent?
[ Reply to This | # ]
|
| |
| Authored by: atul on Monday, December 22 2003 @ 10:41 PM EST |
|
Here's the beginning of include/asm-mips/errno.h in the 2.4 kernel. Note the
comment about being compatible with the MIPS ABI. This was/is a public standard
for binary compatibility across different Unixes running on the MIPS CPU family
(IRIX being the most common example). There's a book (out of print) and
supposedly it's available as a PDF too. In any case, it's clear that the file
could easily have been created from the public documentation, without any
reference to the "proprietary" SCO headers. This applies equally to
include/asm-mips64/errno.h, which is basically identical.
(Forgive the ugly
layout, I can't seem to get the hang of posting preformatted text on Groklaw.
Sigh...)
/*
* This file is subject to the terms and conditions of the
GNU General Public
* License. See the file "COPYING" in the main directory of
this archive
* for more details.
*
* Copyright (C) 1995, 1999, 2001 by Ralf
Baechle
*/
#ifndef _ASM_ERRNO_H
#define _ASM_ERRNO_H
/*
* These
error numbers are intended to be MIPS ABI compatible
*/
...
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 10:55 PM EST |
With respect to ctype.h / ctype.c and how one might do
this "efficiently" ... in 1984 I was working on some CP/M
code that needed to classify characters. One of the original
Multicians send me some code that used a 256 byte array of
flags to accomplish the task quite simply. He commented that
he had written the code long long ago for Multics, sent me a
copy of his code, and said that I was free to modify and use
it as I wished. I did so, and placed the resultant ischar(),isdigit(), and
various other functions and macros
into the public domain.
In a previous life ... in the mainframe world ... perhaps
1967 or 1968 I did something quite similar, and also published the code.
But the issue is copyright, and thus the exact details
of the code are important, not the algorithmic techniques
involved in solving the problem :-)
Would one choose variables named _U and _L to mean
upper and lower case? I did so in 1984, purely by chance.
Also chose _C to mean "Can be used in a legal Amateur
Radio Callsign", and _D to mean "Can be used in a date
string". Programmers all think alike.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 10:56 PM EST |
...circa 1988, and I can't see how anyone who knew any C could possibly think
that the ctype implementation is copied.
The array has a similar name (_ctype in Linux, a variation on that in Unix).
Some of the C macros used to perform each test (see the definition of _U, _L etc
in include/linux/ctype.h) have the same names as they do in Unix. Some do not.
For example, isdigit() uses _D (for digit) in Linux and but Unix uses a
different capital letter. Similarly, _SP in the Linux version has a
single-capital-letter name in Unix.
Notably, the order that the macros are defined (and hence their specific bit
values) are different.
The implementations are also interestingly different. The specific isxxx()
macros, for example, are written in a different way in Linux and in Unix. Unix
doesn't use an __ismask()-like macro, preferring to access the array directly.
As Linus pointed out, there are only so many ways to write an ISO-compliant
ctype implementation in C. I can see how anyone who didn't know this might
think that the Linux code could be copied, but nobody who knew any C could
possibly make this mistake.
The most telling difference for me is that the Unix ctype handles EOF, like the
ANSI/ISO standard says it should, but the Linux version does not. Why someone
would copy the Unix code AND go to the trouble of introducing an incompatibility
with the ANSI/ISO standard is one for the lawyers to sort out.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 11:07 PM EST |
And even if these files did come from Unix, these are all really old (legacy
Unix) files. Caldera open-sourced legacy Unix in 2001.[ Reply to This | # ]
|
| |
| Authored by: eamacnaghten on Monday, December 22 2003 @ 11:10 PM EST |
All in all I think we have enough to start composing an open letter to SCO.
Points to be raised are...
Even if SCO (and not NOVEL) owns copyrights to UNIX....
SCO cannot claim copyrights over the POSIX standard...
There is sufficient evidence to show that the files were not copied...
We know of a Linux expert that can challenge SCO's Linux expert over
infringment allegations...
The letters that were sent out were impropper...
Any thoughts anyuone?[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 11:17 PM EST |
``Looking at the other flags, Linux uses "_D" for "Digit",
while traditional UNIX instead uses "_N" for
"Number".''
Perhaps that is what SCO was calling an example
of obfuscation that those evil Linux kernel programmers were carrying out.
:-)
What really cracks me up is that SCO originally claimed that the
so-called infringing code was not in the kernel but in the periphery of Linux;
not in the core code. Well, I don't see how you can get much more ``core'' than
claiming that these header files are infringing. Makes you wonder what SCO will
claim the next time the stock price begins to fall. Maybe they'll sue
Andy Tanenbaum.
[ Reply to This | # ]
|
| |
| Authored by: belzecue on Monday, December 22 2003 @ 11:42 PM EST |
When this case is inevitably thrown out and SCO have to pay IBM's legal fees
and costs, what would that amount be, you think? One million? Five? Less,
more?[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 11:49 PM EST |
Reporting of Linus and McBride's further comments
Note: McBride claims to have an expert witness. Let's see if they identify him
in response to IBM's interrogatories
http://www.nytimes.com/2003/12/23/technology/23linux.html?ex=1072760400&en=3
58156925bce490c&ei=5062&partner=GOOGLE
Darl C. McBride, the chief executive of SCO, said he stood by the company's
assertions. He said that a Linux expert who will testify in the SCO suit against
I.B.M., which was filed last March, went over the code closely. "As a
social revolutionary, Linus Torvalds is a genius," Mr. McBride said.
"But at the speed the Linux project has gone forward something gets lost
along the way in terms of care with intellectual property."[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, December 22 2003 @ 11:57 PM EST |
If SCO states on there website the following:
"16. Why does SCO require an NDA to be signed to view evidence of UNIX
System IP in Linux?
Showing proof of UNIX System V IP in Linux requires SCO to disclose UNIX System
source code. SCO is obligated to protect this source code, both to preserve its
value to SCO and its shareholders, as well as to prevent devaluation of the
source code that it has licensed (at considerable expense) to many customers.
Thus SCO will not exhibit UNIX System source code to anyone except under
protection of an NDA or a UNIX System source code license. The NDA only applies
to the UNIX System source code; it doesn’t restrict the disclosure of other
materials and information presented in the IP discussion."
Why don't they just tell the linux community what files in the linux kernel are
suspected of being copied and not show them any of there UNIX source code to
prove it. At least it would allow them to know what SCO says is copied and they
could research it on there own as to the source of those code files. And
wouldn't require an NDA to be signed as they wouldn't be showing there prized
UNIX source code. I believe this is what Linus and others have been requesting
when SCO started all of this and SCO has failed to provide it..
[ Reply to This | # ]
|
| |
| Authored by: John Goodwin on Tuesday, December 23 2003 @ 12:32 AM EST |
So what does SCO think an ABI is? ... continuing the line
of questioning. We've looked at what Caldera *used* to think an ABI was. What
does SCO think it is now? From the FUD letter:
[[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.]]
So there is this stuff called "ABI Code" which is subject to
copyright restriction, as opposed to "API Code", which is the stuff
of "open standards".
So are the ABI standards closed, and API ones open? But the Caldera-authored
ABI standards *contain* the API ones (SVID, POSIX, X/Open, XPG4). Or does SCO
mean SVID is an ABI, and POSIX not? Maybe all standards ever written by Caldera
and SCO are "closed" and ABI, and all standards ever written by
anyone else are "open" and API. That would be convenient--I use
your stuff, but by retroactive definition you don't use mine. Maybe one day
we'll know what they mean.
[[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.]]
A clear statement of the purpose of portability standards, both ABI and API, but
too restrictive. Clearly they value portability from and to System V Unix, but
not Unix-cross-Linux in any direction? So let me get this straight: SCO
doesn't want *any GNU* code, including Linux, to run on UnixWare (GNU/Linux
developers sure aren't UNIX licensees. GNU is not Unix). We only support
developers if they buy tools from us and develop on our platform. UnixWare, to
put it bluntly, is as closed as MS Windows, and developers as locked into our
dev tools and platform. Or that's what we wish.
Where does that leave BSD? Are they "licensed"? Are their OSs
"Unix"?
[[The UNIX ABIs were never intended or authorized for unrestricted use or
distribution under the GPL in Linux.]]
The text file heritage theory is clearly not true. It can't possibily be what
SCO thinks--unless they are planning to try and pull a fast one on the jury. It
is hard to believe they can be convincing.
They seem to think the ABI is "code" that lives in "header
files"--a.k.a. the interface. But that notion of interface is
i386-centric. Because if you look at the non-i386 docs, they are *way* lower
level than ctype.h quoted in the i386 ABI. But Caldera wrote the ABI for i386,
which is so generic sounding that it talks about everything in the Unix
Programming Environment--libc, X Windows, Motif even. So maybe they really
think "ABI" is the same as "C library" and "system
calls" (hey, I thought that was POSIX and API!)--only the i386 doc speaks
as if that were truely part of the ABI. The other processor specific standards
confine themselves to byte order and word boundaries, details like that.
[[Nevertheless, many of the ABIs contained in Linux, and improperly distributed
under the GPL, are direct copies of our UNIX copyrighted software
code."]]
I suppose it depends on what they mean by "direct copy". Is that
copying the algorithm or the text? The textual similaries, which are not that
great to the expert eye, will be explained by common standards, programmatic
generation of error messages, shared educational culture, or plausible
similarity of independent implementations.
I take it, in conclusion, that operationally in the SCO-verse "ABI"
means more or less any header (or .c file but we have only one silly example of
that), that facilitates cross-platform portability at a low level, where low
level is "C library or lower".
As near I can make out, they mean:
All your Unix portability are belong to us.[ Reply to This | # ]
|
| |
| Authored by: redwulf19 on Tuesday, December 23 2003 @ 01:04 AM EST |
Mr. Linus Torvalds
The source code to the original unix, both bsd and non bsd can be obtained
here.
http://www.tuhs.org/
best regards[ Reply to This | # ]
|
| |
| Authored by: miniver on Tuesday, December 23 2003 @ 02:21 AM EST |
| You can read IEEE Standard 1003.1 (ie: POSIX) online for yourself
at http://www.opengroup.org/onlinepubs/007904975/toc.htm. Of particular
note would be the following pages:
As you can see from the standard, the file names are
mandatory, as are the symbol names. The symbol values are system-dependent. Of
particular note is the Change History section, which indicates where a
particular file derived. Most are from SVID (the Unix System V Interface
Definition), or the ISO C standard, but some are from BSD or other sources. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 03:06 AM EST |
I recently spent some time at the nasdaq web site where you can view the sale of
stock by insiders. Insiders by law are required to file forms when they intend
to sell and after the actual sale takes place. This has been called a pump and
dump scheme but the other side is dump and pump. There is no restriction on
insiders buying stock in the company, only on the sale. What has occured today,
although it appears to be bone-headed by sco is an effort to drive down the
price of sco stock over the next few weeks as the discovery trial date
approaches. I have watched several insiders filing for stock sale at regular
intervals. With the recent claim of copyright infringement, that Linus so
effortlessly slammed the door on, the stock price will be fluttering down like
an autumn leaf. I suspect that these insiders know this and will be buying up
shares by the bucketful. They will immediately file to sell, which takes some
time for the actual sale to occur. Not sure how long maybe someone can help with
timing. Here is the tricky part. They need to convice the judge that they have a
case so they will hand over a pile of documents to satisfy a continuation, claim
victory, spread more fud and insist that ibm disclose all of its linux
contributions. This will cause the share price to rise just in time to sell.
Again, I'm not sure of the timing between filing for intent to sell and the
allowed date of sale. These blood suckers may be greedy but they are not stupid.
linux is composed of 1's and 0's but sco appears to be full of #2.[ Reply to This | # ]
|
- Dump and pump - Authored by: Anonymous on Tuesday, December 23 2003 @ 05:36 AM EST
- Dump and pump - Authored by: Anonymous on Tuesday, December 23 2003 @ 12:47 PM EST
- Dump and pump - Authored by: Anonymous on Tuesday, December 23 2003 @ 01:43 PM EST
- Dump and pump - Authored by: Anonymous on Tuesday, December 23 2003 @ 10:50 PM EST
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 03:53 AM EST |
Some interesting information here. However, I have to ask why we geeks who can
be so rigourous in other part of our lives (codeing syntax, mathematical proofs
etc) completely fail to be so when it comes to issues of the law. Let us assume
for the sake of argument that there are only so many ways to express the desired
functionality. Does that mean the copyrights are invalid? I have yet to see
anyone comment on that. I know that when it comes to pattents that independent
invention does not invalidate the pattent. (I know I know, pattents aren't
copyrights, but it gives one good reason NOT to assume that independent creation
makes something non-infringing) Why should we assume that because there are
only so many ways to express the desired functionality that the copyright must
not have been violated? In fact, it seems to me that the oposite conclusion is
more likely. While Linux may not have used UNIX code he none the less came up
with something that was copyrighted. The fact that this may be the only way to
express something and be C standards compliant doesn't invalidate the
copyright, it just means SCO has a legal monopoly on standards compliant
implementations for the next 75 years or so. Linus didn't have to use short
names, he didn't have to follow the standards, and I don't know why one would
think one would find a court which will say "Oh, you wanted to be
standards compliant? Well ok fine feel free to break the law."
Is there controlling legal authority on this issue?[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 04:12 AM EST |
Linus needs to get in his giant robot already, then go after McBride hiding in
its clownish looking robot.
More negotiations, less tomatoes.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 07:35 AM EST |
SCO (finally) produced some tangible accusations. Now let’s untangle them
together.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 08:53 AM EST |
Even if the headers would have been completely the same - I consider it a
real idiocy to claim ownership of header files - which actually implement
something completely open (i.e. the ANSI C standard as well as the POSIX
standard).
You can't make something private which is already open
!
So even if the files would be equal - where is the intellectual
property ? Error code values are simply part of the official system interface,
which is therefore part of ANY program running on your system. SCO can't claim
anything from programs run on their machines, so they can't claim anything from
other systems attempting to emulate their own, just like the WINE project
doesn't pay Microsoft.
In short, SCO is talking b***s*** again.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 09:02 AM EST |
Shouldn't items like this be kept for the court? I mean, SCO can float any
stinker they want, wait for some Open Source guru to refute it and say
"Oh, well, let's not bring that one up in court. What else do we
have?"
[ Reply to This | # ]
|
| |
| Authored by: Observer on Tuesday, December 23 2003 @ 10:00 AM EST |
| If you look at the analysis, I think it's pretty obvious that Linus originally
authored these macros in the ctype header files, bugs and all.
However, many
of these files have been changed (fixed) since the time they were originally
released. My question then is, have the files been modified in such a way that
SCO can make claims that the NEW implementations of these macros were copied out
of SCO's code?
Of course, SCO can claim all kinds of things,
regardless of whether they make sense or not, but I'm thinking that the
Copyright infringement claim cannot be immediately written off by simply proving
that the files, in their original form, were written independent of any help
from SCO source code. You also need to show that changes inserted later on were
also original and non-infringing.
(One major complication here is that, as
Linus says, there are only so many ways to efficiently implement these macros,
so there is a high probability that two completely independent parties are
likely to come up with very similar solutions to the problem.)
--
The
Observer [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 10:22 AM EST |
linus shouldn't waste his time to respond. every accusation that sco has come
up with up to this point has been misconceived or false.
sco is a leech and the only time you should give them is to flick them off of
your arm and crush them with your boot.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 10:45 AM EST |
Raise stock price, SELL!, SELL!, SELL!, get $ich!
I highly recommend the book "Sold Short: Uncovering Deception in the
Markets" by Manuel P. Asensio, and Jack Barth. It contains some case
histories of market deception. This SCO thing reaks so much of old securities
market scams I am about to puke out my own stomach.
SCO lost money recently paying its lawyers. IMHO... this whole thing has
nothing to do with software.
----------------------------------------
LAWYERS on BOTH sides ALWAYS get paid!!![ Reply to This | # ]
|
| |
| Authored by: gbl on Tuesday, December 23 2003 @ 10:46 AM EST |
IANAL, but I have a book on Media Law :-)
A useful definition of UK
copyright is available here
I would guess
someone can find a similar page in the US government web pages?
Note point 1
original literary works, e.g. novels, instruction manuals, computer
programs, lyrics for songs, articles in newspapers, some types of databases, but
not names or titles
The last clause is important, it prevents people
copyrighting names such as "John Smith"
In this context "databases" means
organised information, but not necessarily the information itself. This
particular clause allows the phone company to copyright the phone book even
though it contains mostly public domain information.
So where does a short
list of names and numbers come in this (informal) definition? It's not a
database, it's not a program. The information is in the public domain. You
might just be able to convince a jury that the list should be treated as a poem
(poems get special treatment because they are often quite short.) But I doubt
it.
It's a weak argument that SCO is attempting even if the files were
copied verbatim (which they were not) and not available from any other source
(which they are.)
The copyright we see on /bin/true in some unix-like
operating systems are probably meaningless and unenforceable in law. I suspect
the copyright notices on most common unix header files are not much more
enforcable.
---
If you love some code, set it free. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 12:04 PM EST |
Now we know why they wanted Linus to sign an NDA before looking at the files.
If he had done so, this article would have never been written, and they could
have continued with their FUD without Linus being able to refute it. So, it has
become evident that the NDA is so that the truth does not get out.[ Reply to This | # ]
|
| |
| Authored by: elrond_2003 on Tuesday, December 23 2003 @ 12:16 PM EST |
On the bright side, at least one news service is quoting Linus
first rather than DM. Perhaps the tide really is turning. Better check fast
since it is on an MSN link.
---
free as in speech. [ Reply to This | # ]
|
| |
| Authored by: IdleTime on Tuesday, December 23 2003 @ 02:05 PM EST |
I just did a quick compare between errno.h on Solaris and errno.h under Linux
and they are quite different. I have access to various HP, IBM, Sun, SGI, SCO
boxes so I can diff the various files very easily.
Here is the result from doing diff -Naur errno.h_solaris errno.h_linux (Sorry
for the HUGE post, but I feel it is necessary:
--- errno.h_linux 2003-12-23 14:00:18.069751216 -0500
+++ errno.h_solaris 2003-12-23 13:58:52.505758920 -0500
@@ -1,132 +1,186 @@
-#ifndef _I386_ERRNO_H
-#define _I386_ERRNO_H
+/* Copyright (c) 1984, 1986, 1987, 1988, 1989 AT&T */
+/* All Rights Reserved */
-#define EPERM 1 /* Operation not permitted */
-#define ENOENT 2 /* No such file or directory */
-#define ESRCH 3 /* No such process */
-#define EINTR 4 /* Interrupted system call */
-#define EIO 5 /* I/O error */
-#define ENXIO 6 /* No such device or address */
-#define E2BIG 7 /* Argument list too long */
-#define ENOEXEC 8 /* Exec format error */
-#define EBADF 9 /* Bad file number */
-#define ECHILD 10 /* No child processes */
-#define EAGAIN 11 /* Try again */
-#define ENOMEM 12 /* Out of memory */
-#define EACCES 13 /* Permission denied */
-#define EFAULT 14 /* Bad address */
-#define ENOTBLK 15 /* Block device required */
-#define EBUSY 16 /* Device or resource busy */
-#define EEXIST 17 /* File exists */
-#define EXDEV 18 /* Cross-device link */
-#define ENODEV 19 /* No such device */
-#define ENOTDIR 20 /* Not a directory */
-#define EISDIR 21 /* Is a directory */
-#define EINVAL 22 /* Invalid argument */
-#define ENFILE 23 /* File table overflow */
-#define EMFILE 24 /* Too many open files */
-#define ENOTTY 25 /* Not a typewriter */
-#define ETXTBSY 26 /* Text file busy */
-#define EFBIG 27 /* File too large */
-#define ENOSPC 28 /* No space left on device */
-#define ESPIPE 29 /* Illegal seek */
-#define EROFS 30 /* Read-only file system */
-#define EMLINK 31 /* Too many links */
-#define EPIPE 32 /* Broken pipe */
-#define EDOM 33 /* Math argument out of domain of func
*/
-#define ERANGE 34 /* Math result not representable */
-#define EDEADLK 35 /* Resource deadlock would occur */
-#define ENAMETOOLONG 36 /* File name too long */
-#define ENOLCK 37 /* No record locks available */
-#define ENOSYS 38 /* Function not implemented */
-#define ENOTEMPTY 39 /* Directory not empty */
-#define ELOOP 40 /* Too many symbolic links encountered
*/
-#define EWOULDBLOCK EAGAIN /* Operation would block */
-#define ENOMSG 42 /* No message of desired type */
-#define EIDRM 43 /* Identifier removed */
-#define ECHRNG 44 /* Channel number out of range */
-#define EL2NSYNC 45 /* Level 2 not synchronized */
-#define EL3HLT 46 /* Level 3 halted */
-#define EL3RST 47 /* Level 3 reset */
-#define ELNRNG 48 /* Link number out of range */
-#define EUNATCH 49 /* Protocol driver not attached */
-#define ENOCSI 50 /* No CSI structure available */
-#define EL2HLT 51 /* Level 2 halted */
-#define EBADE 52 /* Invalid exchange */
-#define EBADR 53 /* Invalid request descriptor */
-#define EXFULL 54 /* Exchange full */
-#define ENOANO 55 /* No anode */
-#define EBADRQC 56 /* Invalid request code */
-#define EBADSLT 57 /* Invalid slot */
-
-#define EDEADLOCK EDEADLK
-
-#define EBFONT 59 /* Bad font file format */
-#define ENOSTR 60 /* Device not a stream */
-#define ENODATA 61 /* No data available */
-#define ETIME 62 /* Timer expired */
-#define ENOSR 63 /* Out of streams resources */
-#define ENONET 64 /* Machine is not on the network */
-#define ENOPKG 65 /* Package not installed */
-#define EREMOTE 66 /* Object is remote */
-#define ENOLINK 67 /* Link has been severed */
-#define EADV 68 /* Advertise error */
-#define ESRMNT 69 /* Srmount error */
-#define ECOMM 70 /* Communication error on send */
-#define EPROTO 71 /* Protocol error */
-#define EMULTIHOP 72 /* Multihop attempted */
-#define EDOTDOT 73 /* RFS specific error */
-#define EBADMSG 74 /* Not a data message */
-#define EOVERFLOW 75 /* Value too large for defined data type
*/
-#define ENOTUNIQ 76 /* Name not unique on network */
-#define EBADFD 77 /* File descriptor in bad state */
-#define EREMCHG 78 /* Remote address changed */
-#define ELIBACC 79 /* Can not access a needed shared
library */
-#define ELIBBAD 80 /* Accessing a corrupted shared library
*/
-#define ELIBSCN 81 /* .lib section in a.out corrupted */
-#define ELIBMAX 82 /* Attempting to link in too many shared
libraries */
-#define ELIBEXEC 83 /* Cannot exec a shared library directly
*/
-#define EILSEQ 84 /* Illegal byte sequence */
-#define ERESTART 85 /* Interrupted system call should be
restarted */
-#define ESTRPIPE 86 /* Streams pipe error */
-#define EUSERS 87 /* Too many users */
-#define ENOTSOCK 88 /* Socket operation on non-socket */
-#define EDESTADDRREQ 89 /* Destination address required */
-#define EMSGSIZE 90 /* Message too long */
-#define EPROTOTYPE 91 /* Protocol wrong type for socket */
-#define ENOPROTOOPT 92 /* Protocol not available */
-#define EPROTONOSUPPORT 93 /* Protocol not supported */
-#define ESOCKTNOSUPPORT 94 /* Socket type not supported */
-#define EOPNOTSUPP 95 /* Operation not supported on transport
endpoint */
-#define EPFNOSUPPORT 96 /* Protocol family not supported */
-#define EAFNOSUPPORT 97 /* Address family not supported by
protocol */
-#define EADDRINUSE 98 /* Address already in use */
-#define EADDRNOTAVAIL 99 /* Cannot assign requested address */
-#define ENETDOWN 100 /* Network is down */
-#define ENETUNREACH 101 /* Network is unreachable */
-#define ENETRESET 102 /* Network dropped connection because of
reset */
-#define ECONNABORTED 103 /* Software caused connection abort */
-#define ECONNRESET 104 /* Connection reset by peer */
-#define ENOBUFS 105 /* No buffer space available */
-#define EISCONN 106 /* Transport endpoint is already
connected */
-#define ENOTCONN 107 /* Transport endpoint is not connected
*/
-#define ESHUTDOWN 108 /* Cannot send after transport endpoint
shutdown */
-#define ETOOMANYREFS 109 /* Too many references: cannot splice
*/
-#define ETIMEDOUT 110 /* Connection timed out */
-#define ECONNREFUSED 111 /* Connection refused */
-#define EHOSTDOWN 112 /* Host is down */
-#define EHOSTUNREACH 113 /* No route to host */
-#define EALREADY 114 /* Operation already in progress */
-#define EINPROGRESS 115 /* Operation now in progress */
-#define ESTALE 116 /* Stale NFS file handle */
-#define EUCLEAN 117 /* Structure needs cleaning */
-#define ENOTNAM 118 /* Not a XENIX named type file */
-#define ENAVAIL 119 /* No XENIX semaphores available */
-#define EISNAM 120 /* Is a named type file */
-#define EREMOTEIO 121 /* Remote I/O error */
-#define EDQUOT 122 /* Quota exceeded */
+/* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T */
+/* The copyright notice above does not evidence any */
+/* actual or intended publication of such source code. */
-#define ENOMEDIUM 123 /* No medium found */
-#define EMEDIUMTYPE 124 /* Wrong medium type */
+#ifndef _SYS_ERRNO_H
+#define _SYS_ERRNO_H
+#pragma ident "@(#)errno.h 1.16 95/07/04 SMI" /* SVr4.0
11.18 */
+
+/*
+ * PROPRIETARY NOTICE (Combined)
+ *
+ * This source code is unpublished proprietary information
+ * constituting, or derived under license from AT&T's Unix(r) System V.
+ * In addition, portions of such source code were derived from Berkeley
+ * 4.3 BSD under license from the Regents of the University of
+ * California.
+ *
+ *
+ *
+ * Copyright Notice
+ *
+ * Notice of copyright on this source code product does not indicate
+ * publication.
+ *
+ * (c) 1986,1987,1988,1989 Sun Microsystems, Inc.
+ * (c) 1983,1984,1985,1986,1987,1988,1989 AT&T.
+ * All rights reserved.
+ */
+
+#ifdef __cplusplus
+extern "C" {
#endif
+
+/*
+ * Error codes
+ */
+
+#define EPERM 1 /* Not super-user */
+#define ENOENT 2 /* No such file or directory */
+#define ESRCH 3 /* No such process */
+#define EINTR 4 /* interrupted system call */
+#define EIO 5 /* I/O error */
+#define ENXIO 6 /* No such device or address */
+#define E2BIG 7 /* Arg list too long */
+#define ENOEXEC 8 /* Exec format error */
+#define EBADF 9 /* Bad file number */
+#define ECHILD 10 /* No children */
+#define EAGAIN 11 /* Resource temporarily unavailable */
+#define ENOMEM 12 /* Not enough core */
+#define EACCES 13 /* Permission denied */
+#define EFAULT 14 /* Bad address */
+#define ENOTBLK 15 /* Block device required */
+#define EBUSY 16 /* Mount device busy */
+#define EEXIST 17 /* File exists */
+#define EXDEV 18 /* Cross-device link */
+#define ENODEV 19 /* No such device */
+#define ENOTDIR 20 /* Not a directory */
+#define EISDIR 21 /* Is a directory */
+#define EINVAL 22 /* Invalid argument */
+#define ENFILE 23 /* File table overflow */
+#define EMFILE 24 /* Too many open files */
+#define ENOTTY 25 /* Inappropriate ioctl for device */
+#define ETXTBSY 26 /* Text file busy */
+#define EFBIG 27 /* File too large */
+#define ENOSPC 28 /* No space left on device */
+#define ESPIPE 29 /* Illegal seek */
+#define EROFS 30 /* Read only file system */
+#define EMLINK 31 /* Too many links */
+#define EPIPE 32 /* Broken pipe */
+#define EDOM 33 /* Math arg out of domain of func */
+#define ERANGE 34 /* Math result not representable */
+#define ENOMSG 35 /* No message of desired type */
+#define EIDRM 36 /* Identifier removed */
+#define ECHRNG 37 /* Channel number out of range */
+#define EL2NSYNC 38 /* Level 2 not synchronized */
+#define EL3HLT 39 /* Level 3 halted */
+#define EL3RST 40 /* Level 3 reset */
+#define ELNRNG 41 /* Link number out of range */
+#define EUNATCH 42 /* Protocol driver not attached */
+#define ENOCSI 43 /* No CSI structure available */
+#define EL2HLT 44 /* Level 2 halted */
+#define EDEADLK 45 /* Deadlock condition. */
+#define ENOLCK 46 /* No record locks available. */
+#define ECANCELED 47 /* Operation canceled */
+#define ENOTSUP 48 /* Operation not supported */
+
+/* Filesystem Quotas */
+#define EDQUOT 49 /* Disc quota exceeded */
+
+/* Convergent Error Returns */
+#define EBADE 50 /* invalid exchange */
+#define EBADR 51 /* invalid request descriptor */
+#define EXFULL 52 /* exchange full */
+#define ENOANO 53 /* no anode */
+#define EBADRQC 54 /* invalid request code */
+#define EBADSLT 55 /* invalid slot */
+#define EDEADLOCK 56 /* file locking deadlock error */
+
+#define EBFONT 57 /* bad font file fmt */
+
+/* stream problems */
+#define ENOSTR 60 /* Device not a stream */
+#define ENODATA 61 /* no data (for no delay io) */
+#define ETIME 62 /* timer expired */
+#define ENOSR 63 /* out of streams resources */
+
+#define ENONET 64 /* Machine is not on the network */
+#define ENOPKG 65 /* Package not installed */
+#define EREMOTE 66 /* The object is remote */
+#define ENOLINK 67 /* the link has been severed */
+#define EADV 68 /* advertise error */
+#define ESRMNT 69 /* srmount error */
+
+#define ECOMM 70 /* Communication error on send */
+#define EPROTO 71 /* Protocol error */
+#define EMULTIHOP 74 /* multihop attempted */
+#define EBADMSG 77 /* trying to read unreadable message */
+#define ENAMETOOLONG 78 /* path name is too long */
+#define EOVERFLOW 79 /* value too large to be stored in data type */
+#define ENOTUNIQ 80 /* given log. name not unique */
+#define EBADFD 81 /* f.d. invalid for this operation */
+#define EREMCHG 82 /* Remote address changed */
+
+/* shared library problems */
+#define ELIBACC 83 /* Can't access a needed shared lib. */
+#define ELIBBAD 84 /* Accessing a corrupted shared lib. */
+#define ELIBSCN 85 /* .lib section in a.out corrupted. */
+#define ELIBMAX 86 /* Attempting to link in too many libs. */
+#define ELIBEXEC 87 /* Attempting to exec a shared library. */
+#define EILSEQ 88 /* Illegal byte sequence. */
+#define ENOSYS 89 /* Unsupported file system operation */
+#define ELOOP 90 /* Symbolic link loop */
+#define ERESTART 91 /* Restartable system call */
+#define ESTRPIPE 92 /* if pipe/FIFO, don't sleep in stream head */
+#define ENOTEMPTY 93 /* directory not empty */
+#define EUSERS 94 /* Too many users (for UFS) */
+
+/* BSD Networking Software */
+ /* argument errors */
+#define ENOTSOCK 95 /* Socket operation on non-socket */
+#define EDESTADDRREQ 96 /* Destination address required */
+#define EMSGSIZE 97 /* Message too long */
+#define EPROTOTYPE 98 /* Protocol wrong type for socket */
+#define ENOPROTOOPT 99 /* Protocol not available */
+#define EPROTONOSUPPORT 120 /* Protocol not supported */
+#define ESOCKTNOSUPPORT 121 /* Socket type not supported */
+#define EOPNOTSUPP 122 /* Operation not supported on socket */
+#define EPFNOSUPPORT 123 /* Protocol family not supported */
+#define EAFNOSUPPORT 124 /* Address family not supported by */
+ /* protocol family */
+#define EADDRINUSE 125 /* Address already in use */
+#define EADDRNOTAVAIL 126 /* Can't assign requested address */
+ /* operational errors */
+#define ENETDOWN 127 /* Network is down */
+#define ENETUNREACH 128 /* Network is unreachable */
+#define ENETRESET 129 /* Network dropped connection because
*/
+ /* of reset */
+#define ECONNABORTED 130 /* Software caused connection abort */
+#define ECONNRESET 131 /* Connection reset by peer */
+#define ENOBUFS 132 /* No buffer space available */
+#define EISCONN 133 /* Socket is already connected */
+#define ENOTCONN 134 /* Socket is not connected */
+/* XENIX has 135 - 142 */
+#define ESHUTDOWN 143 /* Can't send after socket shutdown */
+#define ETOOMANYREFS 144 /* Too many references: can't splice
*/
+#define ETIMEDOUT 145 /* Connection timed out */
+#define ECONNREFUSED 146 /* Connection refused */
+#define EHOSTDOWN 147 /* Host is down */
+#define EHOSTUNREACH 148 /* No route to host */
+#define EWOULDBLOCK EAGAIN
+#define EALREADY 149 /* operation already in progress */
+#define EINPROGRESS 150 /* operation now in progress */
+
+/* SUN Network File System */
+#define ESTALE 151 /* Stale NFS file handle */
+
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _SYS_ERRNO_H */
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, December 23 2003 @ 05:40 PM EST |
Is SCO really suing over stuff like ctype.h? Doesn't this
mean that they should also sue any other other
company who made an operating system or compiler,
and the ISO as well, since they all use their own version
of ctype.h? [ Reply to This | # ]
|
| |
| Authored by: gvc on Tuesday, December 23 2003 @ 09:16 PM EST |
| The Linux Kernel Mailing List has a
lengthy discussion that arrives
at the firm conclusion
that errno.h was generated automatically from the
messages
contained in an old version of the gnu C compiler, gcc, (an
effort of
Stallman's Free Software Foundation).
The particular library, libc, that
included the text, is
now obsolete, but an effort is ongoing to search
archives
to determine the original author. In any event, the
comments were not
copied from some other version of errno.h, but generated using a C
program.
As I mentioned in a previous post, the Python programming
language
documentation
embeds exactly the same comments. It was probably
derived from the same
source. [ Reply to This | # ]
|
| |
| Authored by: pgangwisch on Wednesday, December 24 2003 @ 08:38 AM EST |
Okay, this is sort of a devil's advocate point. It appears that SCO may not be
so worried that Linus or anybody else copied verbatim. The point may be that
Unix design and organization "inspired" or instructed the Linux
designers and crafters. This is really undeniable, given the public history and
promotion of Linux as a "unix clone" or unix-like system. In the
errno.h posted earlier many of the error code identifiers are identical between
Solaris and Linux. Even if some of the values are not the same the high level
concept and execution of the errno mechanism is. This may be the crux of their
case, that Linux indeed tried to be like Unix and emulated it wherever possible.
I don't know whether that can be counter-argued. If SCO claims that they own
every aspect of the Unix design and the court buys it, it seems they could
really cause some problems. This may be why Novell is now asserting its own
claims, to counter the SCO contention.[ Reply to This | # ]
|
| |
| Authored by: vonbrand on Thursday, December 25 2003 @ 08:00 PM EST |
| Further analysis of the header files and their copyright status is in the
comments to this article on LWN
(look for "An analysis of SCO's claims" by larryblunk).
AFAIKS, even
if the particular assignment of values to error conditions is
copyrightable; this stuff predates the USL vs BSDI suit, is unencumbered in BSD,
and so SCO can claim no "prohibition to use without fee" rights on it. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Friday, December 26 2003 @ 10:24 PM EST |
And If SCO pays some developer to set source from sco into Linux????
Stupid question I know....
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Thursday, January 01 2004 @ 06:01 AM EST |
Back on Slashdot I predicted if SCO started quoting code they'd end up
fingering code Linus himself wrote...
If SCO is to be believed we'd have to accept that Linus stold the Unix code
from AT&T in 1990 or 91 and at that time for some strange reason it
wouldn't compile was incomplete and flooded with stupid newbie mistakes.
Oh yeah and for a breaf moment in time the Unix dev team went insain and had
Unix behaving totally diffrent internally.
And Linus did a remarkable effort covering his tracks to the level no industreal
theaf could ever do before.
In other words Linus created a temporary paradox device that permitted a reltive
newbie to become a master corprate estenage expert overnight operating from
annother nation while studdenly at the same time 20 years of work by programming
experts produces nightmareishly bad code.
One wonders if the famalys of Ken Thompson, Dennis Ritchie and Brian Kernighan
should sue for slander along with Linus considering SCO is effectively clamming
the creators of Unix not only made stupid mistakes but could not fix them in 20
years yet Linus did (shortly after stealing the code).[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, January 27 2004 @ 05:52 PM EST |
I am not any kind of C/C++ guru but I remember at my first keystrokes on C/C++
in the old MS-DOS with borland turbo c/c++ IDE. I did wonder where all this come
from ? indeed, from the UNIX world when it was created and C language was also
born... Thus everythings software descent is from the old common ancestor: UNIX.
I want to point that even the evil Bill Gates taken some
"inspirations" from the unix world when he wrote MS-DOS :-). Thus,
Why not SCO sue Microsoft too ???? (regarding derivative/inspired UNIX way)
At the time of Caldera: I tried their distrib then I taken it away from my
computer because it was crappy... Can someone get to their source files in that
distrib and then search for ANY SCO/UNIX/CALDERA copyrighted original headers or
implementation files ???
....I need a cigarette before I explode!!!!!
[ Reply to This | # ]
|
|
|
|
|
