Claimed Proof That UNIX Code Was Copied Into Linux 578
walterbyrd writes "SCO's ex-CEO's brother, a lawyer named Kevin McBride, has finally revealed some of the UNIX code that SCO claimed was copied into Linux. Scroll down to the comments where it reads: 'SCO submitted a very material amount of literal copying from UNIX to Linux in the SCO v. IBM case. For example, see the following excerpts from SCO's evidence submission in Dec. 2005 in the SCO v. IBM case:' There are a number of links to PDF files containing UNIX code that SCO claimed was copied into Linux (until they lost the battle by losing ownership of UNIX)." Many of the snippets I looked at are pretty generic. Others, like this one (PDF), would require an extremely liberal view of the term "copy and paste."
Re:First post (Score:3, Insightful)
Re:What's so liberal about it? (Score:5, Insightful)
clutching at red straws on pdfs (Score:2, Insightful)
Re:What's so liberal about it? (Score:0, Insightful)
(same AC) Actually, I've been programming for just over twenty years. I think a better analogy is why two recipes for omelets call for eastern Australian ostriche eggs. Please explain to me why the enum LABELS are exactly the same. The replies that this source is something from a POSIX/ANSI/ISO specification, rather than just merely personally attacking me, were a bit more helpful.
Oh Good (Score:4, Insightful)
Re:SCO! (Score:4, Insightful)
Re:variable names and data structures. (Score:1, Insightful)
IIRC, ELF was a SCO standard for x86 *nix interoperability so quite possibly
Re:SCO! (Score:3, Insightful)
I think it's about time for someone to bring up the Dead Parrot Sketch. It seems to suit this situation perfectly.
Why the fuck are we wasting more time on this (Score:5, Insightful)
this fiaSCO has been running on for nearly 8 years - what the hell is up with the courts that they keep this bullshit alive. /dev/null
Kill -9 all | sort >
Re:More details and downloadable archive (Score:4, Insightful)
Ho-hum.
I'm not a coder. I couldn't create a kernel if my life depended on it. I couldn't code a hungry cat to catch a mouse. 1/2 or more of what I read in code is gibberish to me.
But, one thing is pretty sure. Linus Torvalds wrote Linux, and his programming background came directly from Unix. OF COURSE he is going to write the same commands he has used a thousand times in the same way. OF COURSE there are going to be lines that look very much the same, sometimes even identical.
Now, open any dozen books that are 50,000 words in length. Search for strings that are duplicated between the books. Entire sentences, or phrases, it hardly matters. Just do the search. Anyone who is used to playing with databases can probably search those dozen books, and find numerous instances of phrases that were copy/pasted from one author's book to another. In fact, I'll bet that technical and factual books will have a higher incidence of matching phrases and sentences than works of fiction - but fiction will have it's share as well.
And, before we do this data base mining, we need to set up some method of assigning a variable string for proper names. In the wife's romance novels, we would be looking for " $ kissed $ ". It will be repeated so often that you can't help seeing the plegiarism. One author after another rips it from his predecessors.
50 instances are claimed for "copying". Out of how many lines of code? Good grief. I guess it should have been mandatory that Linus write any code not only in a different programming language, but in a different language than English. Then, he MIGHT have been safe. Maybe. Not likely though, because SCO can probably read Chinese, or hire some scumbag lawyer who can.
Re:Who needs proof? (Score:2, Insightful)
It is true that anyone who slams Microsoft for not innovating, while simultaneously claiming that Linux is innovative, is an idiot. Neither is particularly innovative. (Nor is OS X for that matter.)
The difference is that Linux openly admits it's just a solid, free implementation of the tried-and-tested UNIX design, while Microsoft spouts so much bullshit about "innovation" that the word has become practically meaningless.
That's talking about the Linux kernel, of course. Some projects commonly used with Linux, such as Gnome and KDE, are actually very innovative. The only problem is that every time they try something new, half the community slams them for being too different from Windows and the other half slams them for being too similar to Windows. It's tough to innovate when everyone actually wants everything to stay exactly the same forever.
Re:Oh Good (Score:3, Insightful)
Of course that didn't stop the SCO trolls from trying and wasting everyone's time.
Delayed justice is no justice at all.
Re:It's only a header file (Score:3, Insightful)
To drive that point home, take a look at BSD kernel source code, libs, headers, etc etc.
There was this litigation, long ago, University of California Regents, if I recall.... and it caused this schism.... and more free code than had probably ever been produced with C before Torvalds and RMS came along.
The day SCO wins their case... (Score:1, Insightful)
Re:What's so liberal about it? (Score:5, Insightful)
No one cares whether it's a public spec or not (it may be, I do not know). It's a OS header file. The functions have to be named the same way in order for end-user programs to be source-compatible. If you've been programming for 20 years, this shouldn't be too hard to grasp.
If SCO were allowed to claim copyright over this, then it would be simply impossible for Linux to provide a compatible libelf. This means you'd essentially prevent anyone from ever making compatible OS libraries, as they'd be infringing on the original author's copyright. That would be ridiculous. Public function names and prototypes (documented or not, standardized or not) are not considered copyrightable.
Another example: is Wine, according to you, a humongous violation of Microsoft's copyrights? After all, it implements the Windows API with identical function names and prototypes, undocumented features and all (which is nowhere near a published standard of any sort).
Re:comments added... (Score:3, Insightful)
Re:What's so liberal about it? (Score:3, Insightful)
Interface names needed for interoperability are fair game. Interfaces once published are public domain. The specific document is not.
Software is copyrightable but it is not a work of fiction where more protection is given. Writing a book on physics protects the specific wording in that book but it doesn't keep others from using the word "relativity" with the same meaning or your specific name for the speed of light -c- to explain the same exact phenomenon your original book described.
Guess what? Wine contains a function named MessageBoxW and I can't remember the parameter types, but I assure you they are the same as in Windows source. That Microsoft hasn't done anything about it, should tell you how much legal standing a suit on struct member names or function behavior would have.
Re:FUD (Score:2, Insightful)
They mostly consists of straight forward code, #defines or function definitions which looks similar.
Of course they are similar becuase this are POSIX functions and defines!
Their claims are just ridiculus.
10 words that tell it all. (Score:3, Insightful)
Re:Oh Good (Score:5, Insightful)
You're seriously assigning all the problems with the Soviet economy to their lack of copyright? You, sir, take the cake. That's the most absurd statement in support of copyright I have ever heard.
"The idea being that those who ignore (or don't know) their history, will be doomed to repeat it. And you obviously don't know your history, or I am about as certain as the sun will come up tomorrow that you would change your mind on that issue. "
Given your interpretation of the history of economics is rather... I'll be nice and say 'intriguing', I guess I have to agree that I don't know it. I don't see how the lack of copyright led to Stalin screwing the country over, but I guess I am just dense.
"The fact that some laws have been corrupted, like the duration of copyrights for example, is not justification for elimination of all such laws. Sure, it needs to put back the way it was, but not eliminated."
But the fact they are built on the concept of preventing free flow of information - and the fact they can no longer be enforced even by companies with more power than some countries - DOES make copyright and patents outdated. That ship has sailed.
"Copyrights and patents were established for the public good, and believe me, in the places where there are none, there is also damned little public good."
The entire world prior to about the 18th century begs to differ with you. On the other hand, I don't know history, so don't listen to me; nothing of merit was produced before copyright! The Greek epics, countless thousands of books, paintings, songs, architecture, machine designs, all came to exist about 300 years ago, right around the time copyright was invented. Not one before it was established. Thank you for setting the record straight!
Re:variable names and data structures. (Score:5, Insightful)
Umm, no. This is only logical. If he had the documentation to data types, or even if he reverse engineered them, they would be identical. I have done some trampolining of functions to/from code which i only have binary access. If I am handling a struct, I would examine the structure in memory and make my struct identical so I could copy it with simple memcpy(to, fro, sizeof(struct)), or replace references by just changing the pointer to different place.
Re:Oh Good (Score:5, Insightful)
Sorry, Jane. You are wrong. Not your fault, really, since you are just repeating what you've been told many times over the years. But it is wrong.
Your appeal to socialist Russia as an example of why copyrights are needed is laughable. The Soviet system failed mainly for many reasons, but lack of copyright recognition wasn't one of them.
The fact is that the idea that copyrights and patents are a benefit to society is based on no evidence at all. It is one of those ideas that were accepted for a long time without being examined in any detail. There are many examples of places and times where copyrights and patents did not exist and innovation there certainly was not harmed, and careful studies have found pretty good evidence that innovation was helped by their absence. The site techdirt.com discusses these issues regularly, frequently pointing to academic research in peer reviewed journals so you can check out the research yourself if you don't trust the reporting. But you don't have to depend only on research. There are examples today where industries thrive in the absence of copyrights or patents. One easy to understand example is the fashion business. No copyrights or patents. Lots of copying, yet good money is being made by many players. And there's certainly no lack innovation there.
It certainly is true that eliminating copyrights and patents would be kind of disruptive, since some large businesses have come to depend on the artifical monopoly authorized by copyright and patents. But there is reason to believe that we would be better off now had they never been invented. Whether the disruption that would come from eliminating them is reason enough to keep them is questionable. I am pretty sure we would quickly adjust to their absence if they were abolished tomorrow, and be better off, on the whole. Of course, that is unlikely to happen because our government is bought and paid for by the businesses that depend on copyrights and patents, so we will have to suffer the burden of these government-granted monopolies for some considerable time to come.
Re:More details and downloadable archive (Score:4, Insightful)
Re:First post (Score:5, Insightful)
Since we have to rely on this PDF , and there is no way to prove that that code was actually in UNIX at the moment ( as it's closed , there's no way to check ) .
I am left to conclude that it's much easier to copy from Linux (which is open ) , than from UNIX ( which is closed ).
In other words , using this PDF , i could also claim to SCO stole from Linux , and then implemented it in their commercial product , thus violating the GPL .
Re:First post (Score:5, Insightful)
Header files are public - but they seldom contains any advanced functionality. They are just a definition of the calls available, defined data types and constants.
If the header files didn't contain the same (or very similar) definitions then the API wouldn't work. I expect the same header definitions to reappear in many other operating systems with minor differences - many even in Windows (Which do have a Posix API)
But of course - a lawyer wouldn't understand that, it's just a question of money.
Re:More details and downloadable archive (Score:1, Insightful)
I'm not a coder. I couldn't create a kernel if my life depended on it. I couldn't code a hungry cat to catch a mouse. 1/2 or more of what I read in code is gibberish to me.
But, one thing is pretty sure. Linus Torvalds wrote Linux, and his programming background came directly from Unix. OF COURSE he is going to write the same commands he has used a thousand times in the same way. OF COURSE there are going to be lines that look very much the same, sometimes even identical.
Linus Torvalds started linux; out of the current code he authored a few percent. Linux is now massive, and this is a pretty large amount of it for one guy to have written, but his main job these days is on managing code submissions from others. This case is really unrelated to Torvalds; if submitted code was plagiarized he wouldn't have been responsible or known about it, and it's really fairly unrelated to Linux; if SCO were to have succeeded Linux wouldn't disappear, but certain companies like IBM, SGI, etc, would have needed to pay some cash and redo some code.
Torvalds is not on trial here.
Also, as a guy who had his own code plagiarized, I am very wary of special pleading to try and excuse such behavior. We need to look at the facts of the case; we can still use Linux (I do) and at the same time be completely, absolutely opposed to it being tainted with plagiarized code.
The truth is that code was reused (if not copied, exactly, in the same way you don't submit a copied essay which you've taken from a classmate) from a UNIX derivative, which is now (somewhat disputably) owned by SCO.
That is understandable (even if illegal and arguably inethical); there's a dying version of UNIX which no-one seems to be the definite owner of, why not reuse useful snippets from it for the sake of compatibility and efficiency? Well this whole mess is exactly why; when in doubt write your own goddamn code, always.
We should be just as mad at SGI and IBM for being lazy and careless as we are annoyed that a company like SCO exists only to litigate and not do anything useful.
But please do not try and excuse or downplay this behavior. Linux is not going away, and we want justice to always be done because next time it'll be some other company using code from Linux (or one of your projects).
These are not small words like "kissing" that are under dispute, this is not about reusing some very common routines that everyone uses, that's just silly. Rather it's about companies wanting to maintain compatibility with legacy versions of UNIX and doing so by referring directly to the legacy UNIX at best, and plagiarizing their code at worst.
Trying to imply that this is some nonsense that should be dismissed just because you like Linux is like playing down and ridiculing the evidence of the murder of Hans Reiser's wife because you like ReiserFS. It's even sillier in some ways because Linux isn't at stake in the case like ReiserFS was. (An extreme analogy I know, but valid).
Always support justice, always maintain strict ethics when using your code as you would expect others to for your own code. If everyone did that companies like SCO couldn't exist, and more money would go to coders and less to lawyers.
Re:Oh Good (Score:3, Insightful)
Re:First post (Score:2, Insightful)
Though, I do agree that it looks like copying. I do not think (having read the ELF spec and implemented it), that code would look that similar in general (some of the duplicated enums are not in the ELF spec (which funny enough is published by SCO)), however, I was under the impression that header files where not copyrightable since they only describe an interface.
If there were any reason to implement source level compatibility with SCO, i think this would be allowed (though IANAL). Ridiculous is to bring in the dlopen header, this is implemented on every UNIX-like system, and headers are needed for compatibility, which is explicitly allowed by most copyright laws around the world (the same headers are also in OS X, BSD, Solaris), the important part, if you want to determine whether code was copied is the code, not the headers.
From the looks of it, the ELF code was actually copied, and I do not think that you need any liberal notion of copying for seeing that, I have seen this kind of copying by students earlier, and they usually rightfully get into troubles for it.
Re:Shocking (Score:5, Insightful)
Especially given that "original" files appear to have been altered to contain comments to the effect that a USL copyright statement somehow proves that the information is "UNPUBLISHED PROPRIETARY SOURCE CODE" together with a meaningless statement about the existance of a copyright statement not implying publication.
It looks as though they have "mailmerged" part of their claims into their supposed evidence. Shouldn't this have resulted in the judge throwing this out as null and void?
Re:More details and downloadable archive (Score:5, Insightful)
I'm all for strict ethical standards, and I won't claim to have gone through more than a half dozen of these PDF's checking them.
That said - the six or so files I looked at were exclusively issues about some fairly well established naming conventions, the repetition of which is about as unlikely as finding an elm street and sycamore street 'coincidentally' close to each other in both our home towns and calling it 'evidence' the city planner of one stole the plans of the city planner of the other.
I've heard people claim in several posts that "Well, if you looked at the PDF's that weren't cherry picked for ridiculousness ..." there are 'obvious' copying of code. That may be, but I'd like someone to actually link to a pdf with this obvious copying of code - burying the evidence in bullshit data is what you do when the evidence is against you and you *don't* want the other side to find it, not when it's in your favor and you're trying to make your case.
At a minimum, the fact that he has buried his 'evidence' in with other bs data doesn't make it very clear he knows what actual evidence of copying would look like.
Pug
Re:First post (Score:4, Insightful)
I did see the code - and the filenames, but the majority of that was header files that are containing definitions that have to be identical for portability reasons.
And the few code snippets that did contain actual functions didn't contain any real and obvious surprises. The working code was hardly something that you can call "advanced" by itself.
And then there is the issue of which way some code actually did go. From Unix to Linux or the opposite way.
Re:First post (Score:5, Insightful)
They both had a common parent which was public with those structures. Remember these were public APIs, no one is disputing that the structures were similar. The question is whether the implementations were copyright violations.
Re:First post (Score:5, Insightful)
"it was certainly a matter of one window with unix source to read from, the other window with linux source to write"
Hell no. That's a bullshit accusation.
Here we likely have a programmer who has never seen the SCO code (was it even released publicly back then?) but knows that applications can call functionY from libraryX from the interface documentation. If he creates a new libraryX containing a compatible functionY he isn't violating copyright. It is established that creating code with a compatible API interface isn't a copyright violation unless you actually do copy the code.
Indeed it appears this is exactly what is happening in the linked elflib files. The filenames are the same because they have to be (note both the redhat_libelf.h and SCO_libelf.h are actually referred to by just libelf.h in code and elflib.h is what applications need to link to) and the functions are the same because they have to be or else applications will be calling functions that don't exist.
This also happens with the WINE project. People there are creating the same header filenames and inside those headers the exact same function names. They aren't working off a split screen setup and blatantly copying Microsofts closed source code. They are merely recreating the functions that applications can call in Windows.
A similar thing happened years ago with Compaqs IBM compatible BIOS. Compaq re-created the IBM BIOS to get around having to buy the IBM BIOS. Both BIOSes responded to the same application calls in the same way with the same return values and messages. Despite this Compaq didn't break copyright because they still re-wrote the code. In fact Compaq hired engineers specifically for the fact they had never seen IBM BIOS code. This way it could be easily established that they didn't copy the code but instead just wrote the same code that performed the same task.
Re:First post (Score:3, Insightful)
One function per file, and the same name for the file as the function, is actually damn good C coding practice. Nothing else.
Re:First post (Score:3, Insightful)
The PDFs provided seem pretty damning.
Let me guess, you're neither a programmer nor a lawyer. Am I right?
Re:First post (Score:5, Insightful)
Re:More details and downloadable archive (Score:4, Insightful)
Because in FORTRAN, variable names beginning with letters I through N meant integers, and all other meant floating-point. For those with some FORTRAN experience, naming the first 6 loop counters "i,j,k,l,m,n" is automatic.
Re:Oh Good (Score:4, Insightful)
"It's not an "outdated idea". If you really think that copyrights and patents are a bad idea, you need only look at countries where they did not exist -- like Russia during its peak of Socialist power -- to see how that works out economically. Hint: it doesn't. "
A wild thought. It is *JUST* possible that some other aspect of communism, besides the lack of copyright, was responsible for the slow rate of development in the Soviet Union.
Your reasoning would lead us to conclude that the high rate of alcoholism and consumption of vodka was caused by the lack of copyrights ... and that Mr Gorbachev need only turn back the clock, implement a proper copyright system, and become a Hero of the Soviet Union by saving them all from economic perdition.
Re:More details and downloadable archive (Score:3, Insightful)
I hope they took the other person's then.
Never mix tabs and spaces.
Re:comments added... (Score:3, Insightful)
Keep in mind further a huge chunk of that code is GLIBC code - that is code that isn't part of Linux, it's from GNU and was written by the FSF (interestingly SCO never tried to sue the FSF, but non profit orgs tend to lack much money so I guess their not great targets for an extortionist).
IBM may have contributed some code to glibc but under FSF rules it could not be accepted unless they signed over copyright anyway. Still if it was infringing from there then I can see the point of sueing IBM.
All this are more like an intro though to my actual response to your comment: which is yes, and so did GNU. In fact RMS details in the history of the gnu project the (rather radically) different design decisions that he and his team made early on in their writing of unix-like components for gnu where their implementations completely deviated from the original UNIX versions:
1) Whenever a file was small enough (I believe their limit CA 1988) was 2mb) it would be read entirely into memory and not buffered in chunks from disk for any program, and then written back as a whole again. This uses more memory but is a much faster way to work. Today Linux (and other OS's) actually does this on the filesystem level with massive amounts of file changes kept in memory and only written out in idle-times or at dismount time because memory is so much faster than disk.
2) They made no attempt to support any architectures below 32-bit, so no you couldn't compile gnu on a 16-bit system. Downside - even if you could port the linux kernel to a 286 the rest of the base system wouldn't be able to compile on it. Upside - it could actually take advantage of the capabilities of 32-bit systems, especially with regard to memory addressing and use optimizations in how variables were defined based on this.
These are just some pieces of a much longer list, but they were the main reason why the gnu tools developed a major reputation for being faster and more reliable than their unix counterparts and the popularity of the gnu toolchain prior to the appearance of any kernel. When Linux appeared on the scene and was married to the two, it's own approach of maximising it's target platforrm's abilities (the same thing that made Tanenbaum angry) created probably the most performance efficient operating system of the time. Much faster than any other unix then available and able to run on commodity hardware. The legendary portability would only come later (you can largely thank Jon Maddog Hall for that as he got that ball rolling).
But the core point is - for very good reasons both the FSF and the Linux developers used some radically different fundamental design goals in how they wrote their tools compared to unix, these differences led to things be implemented in radically different ways on some levels. Your suggestion is verifiable and documented fact. This doesn't change that there really is only one way to write a proper quicksort - the core algorythms may well have had significant similarity, but the surrounding code was designed differently (how the data got INTO the algorythm in the first place was one of the things that GNU deliberately didn't do the same way unix did - as per example one above).
Re:More details and downloadable archive (Score:3, Insightful)
The truth is that code was reused (if not copied, exactly, in the same way you don't submit a copied essay which you've taken from a classmate) from a UNIX derivative, which is now (somewhat disputably) owned by SCO.
Um, citation needed? Nothing in TFA suggests to me any code reuse.
Don't mistake writing for the same API as "code reuse". You seem to have no clue that APIs are not a subject of copyright protection [eetimes.com] -- either you're badly underinformed, or you're a troll.
If you write for given API, where variable/parameter/function/field names are either part of the API or are a de-facto standard, there is no helping creating structures that look the same, creating same function declarations that look the same, etc.
Again, let there be no mistake: in my opinion, there is no code "reuse" or "plagiarism" in any of the samples TFA refers to. So most of your rant is a waste of steam. The fact that Linux-is-a-UNIX makes certain things look similar, but that's simply because to be a UNIX, you must implement a bunch of APIs, and by necessity functions and structs will have same signatures, and there will be a bunch of C macros that are same as well, perhaps to the letter. When it comes to C macros, sometimes there is only one way to write them correctly, save for whitespace, and function dictates form, to the letter. This does not imply any reuse of code, merely implementing same thing.
What code of yours was plagiarized, again?
Re:Oh Good (Score:3, Insightful)
>It's not an "outdated idea". If you really think that copyrights and patents are a bad idea, you need only look at countries where they did not exist -- like Russia during its peak of Socialist power -- to see how that works out economically. Hint: it doesn't.
Oh that's right, Russia's economy failed because they didn't have IP laws. Odd they wrote some of the 20th century's best literature (Dostoyevski for example) without copyright. They made some of the 20th century's most important scientific advances without patents (they got to space BEFORE America remember).
Seem the facts don't match your claims but you must be right because you studied history. Obviously an excessive amount of government power and high levels of (creativity diminishing) censorship had nothing to do with it. The fact that every xerox machine in Russia had an armed guard next to it to prevent samizdat in fact made for a much more complete control of copying (with the technology of the time) than the copyright in the west did - and modern copyright regimes have far more in COMMON with Russia's control over copying during communism than it does with capitalism.
The fact that their economy was tied up by a massive an inefficient beaurocracy didn't contribute to their failure at all and of course all those factory workers who didn't bother to be productive because in that kind of communist system there is no way to advance anyway and even if you did you'd still be earning just as little (unless of course you were military or in politics and could get special favors) didn't do anything to harm their productivity (and thus their economy). All those economics theorists and philosophers who say so are obviously just trying to trick us all. Good thing the trick worked because it was the cornerstone of the US's approach to beating Russia during the last decade of the cold war.
The dictatorial system with it's endemic corruption also did no harm to Russia's economy. It all failed because they didn't have strong enough patent and copyright laws and we can prove this by indicating that after 20 years the only countries where these laws are not getting pretty damn draconian are the ones which have no government to speak off, or at least, none that the rest of the world gives a damn about and so their people tend to suffer.
Yeah that makes sense. The good countries are good because they have draconian IP laws. It isn't that the people who lobby for draconian IP laws tend not to bother with the poorest countries on earth because there's no point trying play extortionist with people who don't have any money you can fleece them for. That has nothing to do with it.
Thanks you're intelligently researched arguments with their undeniable factual basis, so complete and devoid of any selective reporting have changed my minds. IP laws for the win...
PS. If you haven't figured it out by now. This post is a textbook example of sarcasm.
Re:More details and downloadable archive (Score:3, Insightful)
Thank you for the clarification - I'd thought that Gcom shipped an actual STREAMS implementation, not just an API translator.
Still, just makes my point even further - Kevin claiming that Linux infringes SCOX's copyrights because it "included" STREAMS is just batshit insane.
Re:First post (Score:3, Insightful)
Back in the day, my University had the source code for VAX/VMS 4.2 or so on microfiche. Endless lines of Macro-32 and BLISS. We had some of the the AT&T Unix materials as well. It wasn't that difficult to arrange, if you were a higher ed institution or a customer of a certain size.
Re:More details and downloadable archive (Score:4, Insightful)
So use a REAL tab character in your code like $DIETY intended, and set your editor to "show tab character". We have wide screens now - there's NO excuse for using anything except a real tab any more.
Actually, there are several huge reasons for not using real tab.
1) Tab means different things to different people. Even when you spell it out, people interpret it differently. In the original sense (i.e. old Underwood typewriters, and the like), tab meant to release the carriage and let it move thanks to the spring, until it was stopped by a tab stop. This means that if you set your tab stop at position 5, and 60, and you pressed tab when positioned anywhere from position 1 to 4, it skipped to 5. Pressing tab when positioned at 5 through 59 (in this example) skipped you to position 60. So, in it's original sense, tab relied on tab stops (literally tiny "tabs" on the top of the typewriter). However, there are few standard document formats (especially for source code) that define the tab stops. You don't see a line in an ASCII or Unicode source code file that says "the tabs for this document are at position 5 and 60". There's no common convention for this.
So people invented arbitrary tab stop conventions. Like "tab stops are every 4 characters" or "tab stops are every 8 characters". But a small difference like this can change the meaning of your document! If you line up code and comments with "real tab characters" every 4 characters, and then someone opens your document with tab stops every eight characters, then the issue is NOT just that things are moved right. The issue is that things do not line up! If I create a nice comment section with a table explaining something, and use tab characters counting on a tab stop every 4 characters, and you open it with tab stops every 8 characters, the MEANING of the comments may change.
Example:
/* Here is a table of all the fields and whether they are changed by this function:
[tab][tab]Passed to function[tab]Returned from function[tab]Changed by function
[tab][tab]------------------[tab]----------------------[tab]-------------------
A[tab][tab][space][space][space]Yes[tab][tab][tab][space][space][space]Yes
longer[tab][tab][space][space][space]Yes
*/
These comments will mean different things depending on the tab stop assumptions!
2) The designers of some editors mis-understood how tab-stops worked, and instead, some made tabs equivalent to a fixed number of spaces. For instance, for some editors a tab is instantly interpreted as 4 spaces. But in the original definition of tabs, it was a "variable" amount of spacing, which took you to a predictable column. These are two vastly different concepts.
3) Those who are smart enough to realize that there is confusion are really annoyed by those who are clueless and inserting real tab characters without knowing that there's an issue.
Re:clutching at red straws on pdfs (Score:2, Insightful)
Re:First post (Score:3, Insightful)
It doesn't matter how often people say this, it won't make it true. Case history even in the early '80s already confirmed that it was fairly difficult to prove that derived firmware work had been created (for reasons I explained in the '99 case). IBM, unlike you, had smart enough lawyers to know that they weren't going to be able to protect their whole PC over a few kilobytes of ROM BIOS.
It doesn't matter how often you say IBM didn't want to stop Compaq, it only demonstrates your ignorance. You're nearly right about the rest, though, in that IBM's lawyers understood copyright law well enough that once the facts of the case were in the open, they knew that they didn't have a chance and endless appeals would be pointless.
You seem to think every company is like SCO, and will pursue a case indefinitely if they want to win regardless of facts, so if they accept a defeat, it means they didn't want to win. Which is cute and funny and stupid.
That's ridiculous and you know it. If you look at what X's work does and how it works, and use that information to copy what it does, then you are using X's creative input in order to make a creative work of your own. Thus a derivative work has been created.
And here you demonstrate your ignorance regarding what constitutes a derivative work, and then in your analogies ignorance of the specific situation. Maybe read up on the legal code and acquire a clue.
Today, a "clean-room reinterpretation" is used fairly honestly: you can only read what you're not restricted by or from reading. IOW, you implement from published licence-unencumbered specs. 30 years ago it meant, "Pretend that a derived work hadn't been created by handwaving an imaginary wall. This wall ignores the nature of creative expression in software and takes advantage of a technically illiterate court."
The wall was real, no handwaving, otherwise Compaq would have lost the case. And the same technique is used today which you'd know if you had any relevant experience and weren't using your imagination in place of knowledge -- the court exceeding you both in technical experience and knowledge of the law despite your hilarious claims otherwise. The main difference today is in that word "license-unencumbered" since back then software patents were much more rare. Had IBM held patents on pieces of the BIOS, not even a clean-room implementation would have been legally safe. But I'm sure that's not the point you were trying to make, since it's far too intelligent.
You're angry because you know that so much of the geek dream lore surrounding the development of PC clones is sophomoric bullshit.
I'm laughing my ass off. You're mad because your attempt to re-imagine reality, the public record, and established case history is failing so spectacularly.
BIOS. Clones were born, IBM moved on, and the victory for straight "piracy" was rechronicled lest the nascent commercial PC software market be scared away. Perhaps had people such as yourself not been so dishonest at the time, we'd see a very different software landscape where copying is considered far more acceptable.
Bwa ha ha! Oh yeah! If IBM and others hadn't realized there was a legally valid way to implement "secret" functionality, they totally would have been happy to have people outright copy later! Please. The connection to "straight piracy" is in your imagination only. The rest of the engineering profession knows that reverse-engineering is important to the point where they were even able to get exceptions in the DMCA for it. The "pro-piracy" crowd you are so hilariously trying to paint the accurate historical view as coming from has not such power. IEEE and ACM? That's a different story.
IBM hadn't moved on even in the 90s, btw, when I was there. They were still bitter over losing control of the PC market, though their impression of the case was the same as everyone else, at least those who know what happened. I.e. not you. But keep it up! You're cracking me up here with your "truth".