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."
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. :)
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).
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.
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.
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)."
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.
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.