Slashdot Mirror
Linus Blasts SCO's Header Claims
jonbryce writes "Linus has responded to the latest claims made by SCO in their letter to the Fortune 1000 companies. Basically, he wrote the code himself, and it has been there since Linux 0.0.1. No copying from BSD or any other source." You can also read his comment to the Linux kernel mailing list, which reads in part "I think we can totally _demolish_ the SCO claim that these
65 files were somehow 'copied.' They clearly are not."
56 days till it's all over
#
#\ @ ? Colonize Mars
#
ftp://ftp.kernel.org/pub/linux/kernel/Historic/lin ux-0.01.tar.gz
Next!
Linus' analysis spawned a masterful trolling Subject header on the Yahoo message board for scox: Linus caught - confessing to be ashamed. Nevermind that Linus' shameful confession wasn't copying code, but rather that his Linux 0.01 implementation of ctype wasn't threadsafe. Such beautiful spin. Darl would be proud. :)
According to his LKML post, it was more like half an hour.
I want my Cowboyneal
And what if the user of the original macro invokes it like this:
char * cp;
if (isdigit(cp++))
do_something();
What then, O wise one?
It results in undefined behaviour. I admit it. I'm a tool.
#define isdigit(x) ((x) >= '0' && (x) <= '9')
I'm not going to dig through C standard, but this code is unsafe, so there is a perfectly good reason to disallow this (even though it will compile).
This macro is expanded in-line, so the code
isdigit('5')
is translated by C preprocessor to
(('5') >= '0' && ('5') = '9')
Now imagine what happens with isdigit(i++). If i == 9, i will be incremented twice and you will get the wrong answer.
Also consider what happens if x is a return value of a function, e.g. isdigit( foo(...) ). First, the function is called twice (which can be slow and certainly unneccessary). Second, the function may have side-effects (i.e. it may modify an external variable, write to a file, etc.), so doing it twice is equally bad.
___
If you think big enough, you'll never have to do it.
I thought you were just kidding with this, so I took out the CD-ROM that came with the "LINUX Core Kernel Commentary" book, since it has a 0.01 version for comparison with 2.2.x. The original is definitely not copied and the one from 2.2.10 looks like an incremental change (comments added, new error numbers, but the file itself doesn't look any diffferent).
See section 7.1.3. Other identifiers beginning with underscore are reserved only for some purposes. For example, users can have structure fields beginning with underscore and a lower case letter.
The definition of isdigit() prohibits it from being implemented that way.
Linus commented that he himself remembers writing those files. Well, thanks to Kernel.org and a little too much time on my hands, I did a little exploring. Kernel 2.6.0 has errno.h in two files. To make my life a little easier, I combined the two files, errno.h and errno-base.h. In Kernel 2.3.50 it is one file.
/*Argument list too long*/ -- 2.6.0 /*Arg list too long*/ -- 2.3.50
Well, as we know, SCO is claiming that 2.4.21 is the kernel that started with the problems. If that is the case, assuming that SCO actually has a case then we have a problem.
But the thing is that the errno.h and errno-base.h in 2.6.0 and the errno.h in 2.3.50 have only one difference other than being split up and the appropriate location indicators. The only difference is:
#define E2BIG 7
#define E2BIG 7
I obtained this by using diff. So a simple utility disproves SCO's claim on that ground. Also, you will notice that the Kernel v. 0.01 has only 39 error numbers. They are also included, with the same error numbers in the current 2.3.50 and the 2.6.0 files. A cursory look revealed that 2.4.23 has the same errno.h err codes.
So when Linus says that he wrote them there is proof. Further, since 2.4.21 is the infected one, what is the difference between 2.3.50 and 2.4.23 and the comments. Surely SCO can not be so stupid as to say that comments are a cause for action -- the end user does not even see nor are they accessable to the end user unless they have the source.
The views expressed are mine own and do not express the views of my employer.
I'm not a stock guru. But I think it's not the price, but the number of Bids and Asks.
In another word...
400 People wants to buy the stock.
89200 wants to sell it.
In a few more words...
They're in deep sh*t.
In US, you can easily buy enough major firearms to wipe out your neighbourhood but a few little fireworks are banned.
Well, I just posted a comment about this here, but I've been digging a little more. (Oh, and BTW, he said he used the same numbers, not that he took a copy of the file from Minix. Not that it would make any difference whatsoever, as every line is like '#define EBADF 9')
/. posts change more from 'Preview' to 'Submit'. (Yes, even this one, but I changed it back, and added this sentence.)
From Linux 0.01 to Linux 1.0, errno.h got from 60 lines to 132, and the comment at the top of the file was removed. Also, each error number got a comment. Apart from that, they are mostly the same, listed from 1 to 39 (the last one in 0.0.1, 1.0 goes to 122, and has numbers 512-514 as well). In 2.6.0, the file has split into errno-base.h and errno.h, in include/asm-generic/, and errno-base.h is virtually identical to errno.h in 1.0 from 1 to 34 (the word 'arg' has been expanded to 'argument', and errno.h takes over from errno-generic.h in 2.6.0). In errno.h in 2.6.0, EDEADLOCK has been redefined from the number 58 to the letters EDEADLK, there are two new numbers, and 512-514 have been removed. That's from 1.0 to 2.6.0, virtually unchanged after almost 10 years in developement, and with a very clear resemblance to a file last modified 1991-09-17, that openly states that most of this is taken from Minix. Even my
SCO's claims are getting extremely strange lately. Yes, removing these files, if they were infringing on SCO's copyright, would be quite difficult. You can't live without error messages, can you? But proving the genealogy of these files is just so trivially easy, that SCO hardly can have checked at all. Other files they've mentioned, like include/linux/a.out.h, are also very much the same from 1.0 to 2.4.20 and 2.6.0 (there are some more changes in that file, so I'm not listing them. There are more similarities than differences, however.) I've looked a bit at include/linux/stat.h as well, and 2.6.0 still has plenty of stuff that was there already in Linux 1.0. Most of the files SCO has listed are old, and they are very much Linux.
Actually, since the macro evaluates *p++ twice between sequence points, it *IS* against the standard. The program is not required to compile or behave in any particular fashion.
IOW, the program
int main(int a, char *b[]) { int i = 0; i = i++ + i++; return i; }
has no defined meaning according to the C standard. A conforming compiler may refuse to compile it, and if compiled main may return any value, or even crash with a runtime error.
In real life, two and one will be common return values.
Is it possible that two people working independently of one another could write what amounted to the same header file?
Let's examine what is in a header file. It is a list of the names of the variables, constants and functions used in the main programme source code. The names of these entities are chosen at the whim of the programmer, but good practice teaches that names should be short and meaningful; this is done for the benefit of future developers. Two programmers who learned from similar texts might develop a particular style. Of course, some names might be influenced by specific extant personality traits. If psychometric testing of the two programmers revealed significant differences that might influence choice of variable names, then we might be surer that the two sets of header files are derived from a common ancestor.
Then there is the question of ordering. Convention dictates that the declarations be split into groups by type, and ordered either alphabetically or as they appear in the programme proper. If both programmers have used alphabetical ordering then this is not an issue, but given some automatic latitude by virtue of mathematical equivalency in the order of statements, it would be a greater coincidence for two programmers to code their functions, make use of constants and initialise their variables in the same order.
Of course, if the code in question is trivial, the circumstances are such that names are effectively prescribed {for instance, "port_addr" might well be a popular choice for a variable specifying a port address; and "init_printer()" is a logical choice of a name for a function to initialise a printer}, and/or it acts in certain very specific ways that depend on an exact sequence of instructions {thereby negating the "automatic latitude" proposed above} then there is more likelihood that two programmers would produce identical code when working independently to perform the same function.
The greatest degree of freedom comes in the addition of comments to code. An individual will inevitably develop a particular style in writing comments. Even this might be influenced by mood. Anything beyond the mere explanatory {for instance, "Jeff was here 9T6!"} is as individual as a fingerprint. However, coding convention in certain environments {a corporation keen to project a "professional" image, for instance; or a fluid international collaborative effort} might demand that comments are confined to the minimum necessary to explain the functionality of the code, with correspondingly less scope for personal expression.
In the light of the fact that we are talking about short programmes to accomplish specific simple tasks, in an environment which necessarily minimises an individual's latitude to leave a personal stamp on their code, it becomes more likely that two independent developers could indeed produce identical code. Alternatively, the existence of ancestral code on which Linux could legally have been based would cast reasonable doubt on SCO's assertions that portions of Linux were copied from SCO Unix.
Je fume. Tu fumes. Nous fûmes!
BTW, Web technologies started with webservers and web browsers. Not with CGI scripting.
The term "Web Technologies" usually refers to interactive web sites. The term didn't exist when I started programming HTML back in '96 or even when I was coding servlets in '98. Perhaps they meant web browsers and HTTPD servers, but that's not what they said.
I don't see anything funny, insighful or even relevant in the parent post. Just a newbie that probably thinks that the web was created when he discovered it.
Sounds to me like you're too insecure in your own skills to find the humor in the "10+ years in Java" type job ads. Sure, you could probably find some sort of rationalization, but the truth is that these things are written by HR departments that don't know any better.
In other words, don't be such a stick in the mud. It's funny! Laugh!
Javascript + Nintendo DSi = DSiCade
Does SCO have an accounting department? Or did the lawyers shoot them first? Somehow this is the only thing that makes any sense. The claims are becoming frivolous to the point of rediculum. The financial implications should become clear around the Ides of March. When there is no more money to pay the lawyers. Then, like a wild stampede of rats we will see an end to this fiaSCO. You can bet that some company will step up to the bat to buy out the shell that is left. Anyone taking bets on Microsoft?
OH THE SHAME I fell off the wagon and use sigs again!
Why is the judge letting SCO get away with this coy "they infringed, but we're not going to show you how yet" stuff? Why hasn't he said, "Put the infringing source code in a brief and hand it over tomorrow, or I'm tossing this"?
...and that's kind of what IBM, the judge, and 99.99% of Slashdot, Groklaw, and Yahoo! SCOX forum posters have been getting at. Heck, maybe Kevin McBride will pull a rabbit out of his hat.
Well, a pretrial judge pretty much did. SCO has to cough up their evidence, "with specificity", by January fifth. It's not exactly the next morning, but from what I gather, thirty days might as well be the next morning in the legal world. After this month of bullshit, I don't think they will get off easy come the fifth of January.
If, as SCO claims, they're being horrifically damaged, shouldn't they in fact be eager to get the offending code removed, which IBM could do, once it knows what the problem is?
And maybe I'll pull the next version of Windows out of my ass.
Either way, in two weeks, this case is finally going somewhere, either to trial, or into the dustbin of history. Of course, this does nothing to stop IBM's countersuit, or Red Hat's lawsuit, and if Novell weighs in, well, Darl might want to actually use those lawyers he just spent $9 million on last quarter.
Someday, you're going to die. Get over it.
No.
The "bid price" is the highest amount that any buyer is willing to pay for a stock at a particular time. Likewise, the "ask price" is the lowest amount that any seller is willing to sell the stock for.
So, one particular buyer is asking to buy 100 shares at 4 cents, while one seller is offering to sell 100 shares at $892 each.
Since you're looking at the closing quote, the bid and ask prices are not particularly meaningful. One way to read those numbers is that "all reasonable orders were filled by the end of the day, and the remaining unfilled orders were ridculous (4 cents and $892)."
New York Times-26 minutes ago
The Utah company, the SCO Group, has begun sending out a round of warning
letters to large corporate users of Linux, which is distributed free.
Novell Registers Unix Copyrights
... has quietly registered for the copyrights on many versions of the Unix computer operating ...
New York Times-26 minutes ago
system that the SCO Group already says it owns, further muddying the
Note: This is a repost of a comment that I sent to groklaw.
I do have a copy of the Unix source, 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.
They seem to read LKML, at least.
check it out
2 174158852#c41366)
Subj: AT&T donated rights
By: radicimo Date: 12/22/03 10:21 pm
from Groklaw thread on Linus' code
(h++p://www.groklaw.net/article.php?story=2003122
--
Standards
Authored by: meissner on Monday, December 22 2003 @ 09:10 PM EST
I was a member of the ANSI X3J11 C standards committee from its founding in 1983 until after the first ANSI and later ISO standards were released in 1989 and 1990 respecitively. As part of the process, AT&T through its official representive (Lawrence Rosler) specificially gave the rights to the C language and its library (including the ctype.h, signal.h, and errno.h header files) to the committe. I believe they did the same thing officially to the POSIX committee at the same time (which would cover ioctl.h and more of the errnos in errno.h, and more of the signals in signal.h). Unfortunately, I no longer retain paper documents from that period, but if it becomes important to establish a clear paper trail, I suspect Jim Brody (chair), Tom Plum (Vice char), and P. J. Plauger (secretary) probably do retain their copies.
Of course, as has been shown in the past, SCO really has no institutional memory of the past.
SCO said it was in linux 2.4. Comparing the original kernel sources is nice, but kind of useless. Linus himself admits that most of the files have been changed a lot.
I know as well as most /.ers that the code was definitely not copied into Linux. But, Linus usually doesn't make casual slips like this. Then again, Darl has probably made some stupid statement at some point about it being in every version of Linux. Go figure.
Like SCO's malloc fiasco, it's another case of, "Linux has it, but we're older than Linux, so we had it first!"
To be accurate, SGI admitted that the lineage of atealloc/atefree was questionable. Besides that, SCO didn't notice those functions...they were pointed out on Slashdot before SCO ever mentioned them. It seems that the best SCO's pattern recognition experts can find is that different UNIX like operating systems have similar define statements (the current header files) and switch statements (Berkeley Packet Filter).
When I was comparing the ancient Unix source against Linux I ignored those types of matches as being too stupid to bother examining.
Interestingly enough, the URL google uses is the same! Hmmm. So if you have a browser that allows you to customize the Referer header, you'll probably be able to access the article by just setting it to google, without actually going to Google News before...
Yes, indeed, it works!:
> telnet www.nytimes.com 80 /2003/12/23/technology/23linux.html HTTP/1.0
...
...
Trying 199.239.136.200...
Connected to www.nytimes.com.
Escape character is '^]'.
GET
Host: www.nytimes.com
Referer: http://news.google.com
Linus Torvalds, creator of the popular Linux computer operating system, defended his work yesterday as not always lovely but original - and certainly not copied, as a Utah company has contended.
ANSI Patent policy
1.2.11 ANSI patent policy - Inclusion of Patents in American National Standards
There is no objection in principle to drafting a proposed American National Standard in terms that include the use of a patented item, if it is considered that technical reasons justify this approach.
If the Institute receives a notice that a proposed American National Standard may require the use of a patented invention, the procedures in 1.2.11.1 through 1.2.11.4 shall be followed.
1.2.11.1 Statement from patent holder
Prior to approval of such a proposed American National Standard, the Institute shall receive from the identified party or patent holder (in a form approved by the Institute) either: assurance in the form of a general disclaimer to the effect that such party does not hold and does not currently intend holding any invention the use of which would be required for compliance with the proposed American National Standard or assurance that:
1.
a license will be made available without compensation to the applicants desiring to utilize the license for the purpose of implementing the standard; or
2.
a license will be made available to applicants under reasonable terms and conditions that are demonstrably free of any unfair discrimination.
1.2.11.2 Record of statement
A record of the patent holder's statement shall be placed and retained in the files of the Institute.
1.2.11.3 Notice
When the Institute receives from a patent holder the assurance set forth in 1.2.11.1 a) or b), the standard shall include a note as follows:
NOTE - The user's attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights.
By publication of this standard, no position is taken with respect to the validity of this claim or of any patent rights in connection therewith. The patent holder has, however, filed a statement of willingness to grant a license under these rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. Details may be obtained from the standards developer.
1.2.11.4 Responsibility for identifying patents
The Institute shall not be responsible for identifying all patents for which a license may be required by an American National Standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention.
ISO and IEC Patent Policy
...subclause...). ISO [and/or] IEC take[s] no position concerning the evidence, validity and scope of this patent right. The holder of this patent right has assured the ISO [and/or] IEC that he/she is willing to negotiate licences under reasonable and non-discriminatory terms and c
2.14.1 If, in exceptional situations, technical reasons justify such a step, there is no objection in principle to preparing an International Standard in terms which include the use of items covered by patent rights - defined as patents, utility models and other statutory rights based on inventions, including any published applications for any of the foregoing - even if the terms of the standard are such that there are no alternative means of compliance. The rules given below and in the ISO/IEC Directives, Part 2, 2001, Annex H shall be applied.
2.14.2 If technical reasons justify the preparation of a document in terms which include the use of items covered by patent rights, the following procedures shall be complied with.
19.
The originator of a proposal for a document shall draw the attention of the committee to any patent rights of which the originator is aware and considers to cover any item of the proposal. Any party involved in the preparation of a document shall draw the attention of the committee to any patent rights of which it becomes aware during any stage in the development of the document.
20.
If the proposal is accepted on technical grounds, the originator shall ask any holder of such identified patent rights for a statement that the holder would be willing to negotiate worldwide licences under his rights with applicants throughout the world on reasonable and non-discriminatory terms and conditions. Such negotiations are left to the parties concerned and are performed outside ISO and/or IEC. A record of the right holder's statement shall be placed in the registry of the ISO Central Secretariat or IEC Central Office as appropriate, and shall be referred to in the introduction to the relevant document [see ISO/IEC Directives, Part 2, 2001, H.3]. If the right holder does not provide such a statement, the committee concerned shall not proceed with inclusion of an item covered by a patent right in the document without authorization from ISO Council or IEC Council as appropriate.
21.
A document shall not be published until the statements of the holders of all identified patent rights have been received, unless the Council concerned gives authorization.
2.14.3 Should it be revealed after publication of a document that licences under patent rights, which appear to cover items included in the document, cannot be obtained under reasonable and non-discriminatory terms and conditions, the document shall be referred back to the relevant committee for further consideration
Annex H
(normative)
Patent rights
H.1 All drafts submitted for comment shall include on the cover page the following text: "Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation."
H.2 A published document for which no patent rights are identified during the preparation thereof, shall contain the following notice in the foreword:
"Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO [and/or] IEC shall not be held responsible for identifying any or all such patent rights."
H.3 A published document for which patent rights have been identified during the preparation thereof, shall include the following notice in the introduction: "The International Organization for Standardization (ISO) [and/or] International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance with this document may involve the use of a patent concerning (...subject matter...) given in
From the Linux Kernel Archive:
;)
> The original errno.h, from linux-0.01, says it was taken from minix, and goes
> up to 40.
Good eyes - I only analysed the ctype.h thing, and didn't look up errno.h in the original sources. errno.h has a _big_ comment saying where the numbers came from (and some swearwords about POSIX
Looking at signal.h, those numbers also seem to largely match minix. Which makes sense - I actually had access to them.
In both cases it's only the numbers that got copied, though. And not all of them either - for some reason I tried to make the signal numbers match (probably lazyness - not so much that I cared about the numbers themselves, but about the list of signal names), but for example the SA_xxxx macros - in the very same file - bear no relation to the minix ones.
Linus
So, do you admit that Linus copied the entire substance of include/errno.h from somewhere else?
...
I dug out Unix 5th Edition because it's the closest to the original that I could find. Linus says that he copied his errno.h from Minix. Tanenbaum probably copied his from somewhere else. The chain of copying goes back to the original AT&T Unix code.
Compare with the paranoid attitude of gcc: gcc doesn't include copies of other people's system header files from, say, solaris or hp-ux; gcc includes scripts that manipulate the files on the end user's system, if the end user has legal copies of these files.
See this bit from the GNU coding standard:
Referring to Proprietary Programs
RMS has a stick up his a** about a lot of things, but better RMS's stick than Boies' dick.
I haven't read the Posix standard
Here is the 2003 version of the standard for errno.h.
The names are standardized in 2003 (and were probably standardized before 1991). But the values are not standardized. If you or I were to write an errno.h from that specifcation, the odds are incredible that we would happen to choose the same 31 values in the same order as the original Unix implementation. Personally, I would follow the order in the specification, which is alphabetical.
Again, from a legal point of view, it's a molehill. The actual value of those identical error numbers numbers is not $3,000,000,000. More like $300 or $3000. Ditto with the ioctl numbers. As you point out, the values of certain signal numbers (like SIGKILL) are well known. And all of these files are completely unrelated to SCO's claims that IBM copied SMP, NUMA, JFS, RCU code into Linux.
But from a PR point of view, it's damaging to us.
This activity looks uncomfortably like SCO's allegations about how Linux is developed. Here's Unix code; here's Linux code; the Linux code is a verbatim copy of the Unix code.
A nasty twist: because this is part of the ABI, it would be difficult and painful to replace include/asm-*/errno.h with a clean room implementation from the Single Unix Specification.
A note here: I'm not pro-SCO, and I'm not trolling. I'm looking to find the strongest SCO points because we're at war with SCO, so it's important to understand the strong points of the enemy's position.