SCO v. IBM
I am no fan of SCO. But the IT community is making themselves fools if they blindly support IBM simply because SCO is viewed as anti Linux.
INQ's comment that SCO was only able to show 300 lines of code is kinda stupid. If SCO can find one (1) line of code that IBM infringed, that's copyright infringement. In this case, one guy copied four (4) words, and had to give up a lot.
The arguments that header files are not copyrightable are plainly stupid. Every programmer knows that header files are no different from other program source files.
The real issue is whether IBM infringed or had a license to the code.
30 Comments:
sharikou
"Every programmer knows that header files are no different from other program source files"
Header files only contain descriptions of the stuff implemented in other places and it is the implementation that you can copyright. How can a #define, struct definition or function prototype be copyrighted?
Of cource software patents are incredibly stupid, that kind of stuff we see with them does only one thing: slows down progress and inovation.
Also, MS also sais that Linux infringes their patents but has never shown a single line. They are simply spreading FUD.
SCO's entire case is frivolous since SCO does not own the patent rights to UnixWare. SCO is only a licensee to Novell.
SCO's lawsuit is motivated by the fact that it fancied itself the low to mid range version of unix but has been getting clobbered by linux and freebsd. Before linux, Xenix did fill the low end range but SCO has been unable to move up to the midrange as it wished.
SCO obtained money from MicroSoft to launch the lawsuit since MS has also been concerned about linux versus windows on servers and had plenty of cash to spare. SCO's suit is an act of pure desperation but is without merit.
The issue wasn't so much about header files as it was about numonics.
SCO claimed that they could copyright the association of the number "40" with the string "ELOOP", which, any programmer (such as I) would call silly.
There are a set of standard error codes (numbers) which have some standard(ish) strings that are used because strings are typically easier than numbers. For example:
#define ELOOP 40 /* Too many symbolic links encountered */
That line of code may be copyrightable because of the comment, but "#define ELOOP 40" is not, and will never be, because such a line is needed to define a macro named ELOOP with the value 40, and the courts are not stupid enough to make programming as we know it illegal with a single court decision.
If ruled in SCO's favor, even variable names will be copyrighted, any all the short ones will be taken first... I can see it now, programs using names like "asjdhgasd" for variables, because all the good names like "ELOOP" are taken. Totally silly.
just imagine what happens when someone copyrights variable named i or construct like this:
for (int i=0;i!=10;i++){
// blah
}
The standard is the same as it is for a book or article. I'm sure that many books and articles contain the same lines of text. That isn't infringement. Having the same paragraph would be perhaps suspicious while having the same word for word article or chapter would be proof of infringement.
It wouldn't be enough to have the exact same lines of source code scattered in various places. You would need an entire block of code that matched.
I doubt the copyrightability of #defining constants too. But, there are 300+ lines, it doesn't matter some of them are #define, as long as there is one line of good code, that could be basis of infringement action.
sharikou
"But, there are 300+ lines, it doesn't matter some of them are #define, as long as there is one line of good code"
You know for common tasks it is quite possible that two (or more) programmers come up with identical code. I've seen it happen several times.
Also now as those lines are known it is trivial to change them making the whole thing pointless. There is just so little code.
I'd say that SCO is in a lot deeper hole with the claimed 700k lines of code.
No, it is impossible that one line of C code could be the basis of infringement. I can assure you of this fact as a professional programmer. This would be like finding the same line in two books and claiming infringement.
326 lines:
121 lines are #define headers
164 lines are structure declarations
41 lines are function prototypes
None of these concern executable code. It would be very easy to use the same defines, function prototypes, and small structures. Arguing that these are infringement would be like arguing that a similar table of contents is infringment.
SCO's original notion was that linux would cover the low end and customers could move up to a middle range SCO Unix. The lawsuit is because that didn't happen. Essentially, SCO wants to now ban linux so that its Unix won't have any competition.
The vast majority of SCO's claims of infringement involve: "thousands and thousands of lines" of "non-literal copying " of "non-literal protectable elements. The structure, the algorithms of UNIX".
However, in general the structure of code is not at all protected since similar tasks would tend to lead to similar structure. The functional algorithms would apply the same standard as written material in that plagarism doesn't have to be a word for word copying but can also be a paraphrased copy as well. It would take a lot more than 1 or 10 or even 100 lines to show deliberate functional copying. This type of copying would tend to be self limiting because the effort involved with studying code to find out what could be safely altered would be similar to amount of effort to write it from scratch. Therefore, if the coding doesn't obviously match it shouldn't logically be considered infringement.
121 lines are #define headers
164 lines are structure declarations
41 lines are function prototypes
Are you saying SCO defined these macros and prototypes, but they weren't used anywhere in the code?
First, I'd like to reference Scientia from AMDZone's first two points (posts), they are quite right!
But I'd like to add that copyrighting material is not boolean (true or false, white or black, etc).
You can't just look at a single line of code and proclaim infringement. It's the combination of code, in part or in whole which is copyrighted.
But I would strongly argue that an include file IS copyrightable. A lot of macros, references (other includes) and definitions may exist which uniquely define a work.
That's like saying because a web page 'includes' a JavaScript file, that file (being code) is not copyrightable. Complete non sense!
Also, I would like to note that the author of the article probably has no knowledge of IP law.
This is because they don't do anything other than describe how information is shared amongst the operating system.
Are they trying to say that if code does describes how to do something it is then copyrightable? This is bull, because when you have code which 'does' something and your the first to do it, then it is PATENTABLE. If it has already been done (or close enough), then it belongs to the open domain and falls under 'fair use'.
jeach: you're flat wrong.
http://www.copyright.gov/circs/circ1.html#wwp
What Is Not Protected By Copyright?
...
Works consisting entirely of information that is common property and containing no original authorship (for example: standard calendars, height and weight charts, tape measures and rulers, and lists or tables taken from public documents or other common sources)
The errno definitions in errno.h are nothing but a list of definitions taken from public documents.
The issue isn't whether a file is an include file or not. It's whether a document contains a creative expression or not.
If I wrote an <errno.h> file and filled it with additional comments and artistically chosen whitespace, that would be a creative work. E.g., this simple program
marshall.c
sharikou
"Are you saying SCO defined these macros and prototypes, but they weren't used anywhere in the code?"
Of cource they used those definitions. The question is if the functions that used those things were 1:1 copy of their copyrighted code or not.
E.g there really isn't many ways to create a struct describing TCP/IP header but you can write quite different code that does stuff with those structs. One such task might be filtering.
Sharikou, Ph. D said...
... it doesn't matter some of them are #define, as long as there is one line of good code, that could be basis of infringement action.
oh no, i'm agreeing with your statement :). Well, what 'spam' and 'hex' said are correct too. While it is possible to have one line identified as copyright infringed, the line must be unique in a sense that it is not easy for 2 person to write the same line of code. eg.
int i; //this is weird, don't copy me
I once ran a IP checker through some of the source code that I maintain, there are quite some #define's flagged with concerns. After a closer look, they are actually matching word by word and even the sequence. However, I can easily ignore these concerns because the same wording appear in a standard. They are actually some bits fields and the corresponding bit offset.
Anyway, I'm not in the position of saying SCO claim is valid or not, as I never read what are those lines that they claim.
No, ho ho got it right:
E.g there really isn't many ways to create a struct describing TCP/IP header but you can write quite different code that does stuff with those structs. One such task might be filtering.
Function protoypes and defines are a single line. And, small structs would also be commonly duplicated. The notion that someone would duplicate a function prototype but not duplicate the function code itself is beyond ridiculous. That would be like claiming forgery because another painting used a matching frame when the painting itself was completely different.
As I've said before, if you were really going to steal code then it wouldn't have many changes. If you are capable of reading the code and understanding its function enough to make substantial changes then you understand enough to write it from scratch. That isn't the issue.
The issue is that Bell Labs wrote the first Unix which ran on a PDP 7 minicomputer. Since Bell Labs was part of AT&T it was forbidden to sell computer hardware. Consequently, Bell Labs distributed Unix to universities for a very low fee. These universities trained the programmers who then wrote other versions of Unix. What SCO is claiming is that ALL versions of unix including ALL versions of Linux are derived from the original unix and therefore should pay royalties to SCO. Is Microsoft paying royalties for Excel to VisiCorp who wrote the first spreadsheet? No.
Here it goes again... more exploding Core Duos in the news.
http://www.engadget.com/2007/03/21/swollen-batteries-affecting-17-inch-macbook-pros-too/
Try posting in a topic that is "slightly" more relevant, and last time i checked a Core duo wasn't a battery
Isn't that nice. AMD is trying to get rid of the pile of its old s939 CPU's and has to give them away for very small prices.
Can anyone find some good numbers how big CPU stockpiles does AMD and Intel currently have? I remember a few months ago Intel had quite a lot of those CPU's but from what I've heard currently AMD is in trouble since even with lowered price it is difficult to sell the CPUs.
"I remember a few months ago Intel had quite a lot of those CPU's but from what I've heard currently AMD is in trouble since even with lowered price it is difficult to sell the CPUs."
Actually, I've heard just the opposite. People are complaining about the lack of 939 CPU's. I doubt that AMD is having any trouble getting rid of their 939 CPU's, and by many indications, most of them are already sold. Just look on pricewatch: the 939 CPU's all cost significantly more than the AM2 ones. That means demand is high while supply is low. On the other hand, old netburst CPU's are being offered at really low prices, yet it seems that no one is buying. Everyone knows that they're bad CPU's, power hungry and slow compared to the AMD 64's.
This comment has been removed by the author.
I wasn't talking about s939, I was talking about AM2. AMD killed s939 dualcores way too fast.
I've seen lots of people who are uprading their s939 based PC's and often they go with C2D since they have to replace most of their components anyway. Some of them might stay with s939 a bit longer but s939 dualcores are almost impossible to get, even s939 Opterons are hard to get but still often better than X2's. Also the price premium you were talking about doesn't help AMD.
At $89 for a motherboard and CPU, it doesn't really matter what socket it is. Why worry about buying the correct chip for your motherboard when you can just get a whole new platform at that price? This is a wise move by AMD.
"At $89 for a motherboard and CPU, it doesn't really matter what socket it is."
Yep, those AMD chips must be real pieces od crap to be sold that cheap.
bubba said...
Yep, those AMD chips must be real pieces od crap to be sold that cheap.
You misunderstand the situation. The chips are quite excellent, but are being sold at these prices to continue to steal market share from Intel.
AMD is currently assaulting Intel on all fronts, and Intel is taking a major beating. Intel's attempts to take AMD out of the market have failed and left them wide open to attack. BK is inevitable.
You misunderstand the situation. The chips are quite excellent, but are being sold at these prices to continue to steal market share from Intel
No you misunderstand, It's from AMD's own mouth:
""Regardless of what the competition may do, we price our products according to the value they represent to our customers," spokeswoman Suzy Pruitt said in an e-mail. "
So you see, even in AMD's own words their chips are worthless crap.
Here's the quote.
http://www.marketwatch.com/News/Story/Story.aspx?dist=newsfinder&siteid=google&guid=%7B73A866D1-3741-44E0-9116-A22E851D98F8%7D&keyword=
***AMD is currently assaulting Intel on all fronts, and Intel is taking a major beating. Intel's attempts to take AMD out of the market have failed and left them wide open to attack. BK is inevitable.***
I'll agree that AMD is agressively pricing their chips, but Intel taking a beating, where was Intel's revenue warning, Neither company is going to BK, but currently Intel is looking slightly brighter
There is no overstock of socket 939 at AMD. Socket 939 dual cores however are indeed in short supply. I've only seen 3800+ and 4200+ listed.
As for the $89 price for the motherboard and 3400+ cpu, this is not unusual. Contrary to the lame assertion that this indicates "crap", a little common sense indicates otherwise.
This processor is a single core 3400+ which has today been replaced by the socket AM2 Sempron 3400+. This makes this processor worth about $40. The price on NewEgg for the same motherboard is $60 so this would be $100 on NewEgg and therefore not much of a discount. You can buy a dozen motherboards for socket 775 on NewEgg between $40 and $50 and you can buy several Intel Celerons from $40 to $50. You can in fact find an equivalent 3.2 - 3.46Ghz Intel Cedar Mill Celeron and motherboard for the same $100 on NewEgg.
AMD blows intel out of the water with a 97% increase in sales for 2006.
Intel looses 4 billion dollars worth of sales to AMD in 2006.
Even while Intel has there core 2 super chips to compete they still loose another 4 billion dollars in sales to AMD.
Intel drops another 13% in sales in 2006.
Another bad year for Intel marked by declining, falling sales.
AMD had a 97% sales increase for 2006.
Check again realgenius. The only reason AMD gained is because they bought Ati. Now they're posting losses and have no hope of returning to profitability. AMD is losing marketshare in all segments; both CPUs and graphics.
Clovertown is so advanced that it has pre-fragged all of AMD's upcoming CPUs.
AMD BK 2Q08.
scientia: "This processor is a single core 3400+ which has today been replaced by the socket AM2 Sempron 3400+. This makes this processor worth about $40."
IMO it doesn't look good to AMD. IIRC AXP 3400+ was supposed to be equivalents of P-4 3.4GHz, or maybe 3.2GHz. But these P-4 processors are sold at least $70. The fact that AXP+MB sold at only $15 higher means AXP is valued even lower than P-4. AMD simply doesn't do well on the low-end market-wise.
Post a Comment
<< Home