Why Does SCO Focus On A Minix-to-Linux Link? 227
ansak writes "In the latest scoop from Groklaw, Groklaw user talks_to_birds pointed out an error in SCO's version of the famous Levenez Unix Timeline. The important error is the green dotted line which shows Minix to be a derivative of Unix. If this were accepted, and if Linux was shown to be a derivative of Minix, then SCO's lawsuits would be more likely to have merit. As it turned out, even MS called Samizdat unhelpful, but at least now there may be a plausible reason why someone would try to make the link between Minix and Linux in the first place."
Linux a derivitive of Minix? (Score:5, Interesting)
Not plausible (Score:5, Interesting)
No, because the guy who made this link, Ken Brown, intentionally ignored multiple sources of information that Linux was *not* derived from Linux. It was totally untrue, and he knew it because:
-
Tanenbaum, who wrote Minix, told him so.
-
The guy Ken Brown hired to find where Linux took from Minix told him that it had not in fact happened, after analysing the code.
There never was *any* plausible support for Brown's case and he knew it *befire* making PR announcements, but he went ahead anyhow.Even though they called it "unhelpful"... (Score:5, Interesting)
I said "Yes", of course, since I'd use Linux on principle if I hadn't been already when extortionists like TSG (The Sco Group) sued them. If they turn and sue someone like the NetBSD project, I'd find a place in my organisation for a NetBSD box as well.
For the curious, IDC called from Malaysia into Australia, and "Brian" (no idea if that's his real name) said that IDC were planning on setting up their main Asia-Pacific offices there.
Levenez's Chart (Score:5, Interesting)
Of course, Eric states very clearly on his site that "an arrow indicates an inheritance like a compatibility, it is not only a matter of source code"
And anyway, Minix doesn't contain any AT&T source code by Tanenbaum's own admission. Linux doesn't contain Minix code. These are both original works, influenced by the Unix flavor of their time. That is what the Levenez chart shows, nothing more.
The chart is only useful to SCO in their campaign of dishonesty to suggest something that is clearly untrue, and that has been proved repeatedly to be untrue.
Comment removed (Score:3, Interesting)
Re:The Diagram Is Not Measuring Source Dependancy (Score:5, Interesting)
The Wayback Machine [archive.org] indicates [archive.org] that "Note 1" was added in the period 2nd August 2002 [archive.org] to 14th October 2002 [archive.org].
This is well before the start of the SCO affair (7th March 2003), so the note is not a belated attempt to bolster Linux's case. The diagram genuinely does not measure source code dependence.
We need the source (Score:3, Interesting)
(*) or we could just ask him.
maybe not so simple... (Score:2, Interesting)
If anything, this shows that SCO is not going away merely because they don't have a case. The will keep grinding away as long as they have funding.
"cleanroom" (Score:2, Interesting)
Why? The problem is that Linux might be considered to be derived from a reverse-engineering of Minix, and that the reverse-engineering wasn't done "cleanroom" style.
Just as an example: When companies like NEC and AMD started producing x86-compatible processors, they went through a procedure designed to isolate them from being accused of copying Intel's work. Two teams were formed: One team's job was to analyze the processor and write a detailed specification of the Intel processor's operation; they passed this data to the second team, which designed a new processor to meet those specifications. The second team could ask the first team to clarify information, but in any case, all communications between the teams were kept minimal and were logged, in order to prove Intel's IP wasn't stolen. Intel sued anyway, but the audit trails kept Intel from proving its cases.
Now the question becomes, did Linus have access to Minix's source code while he was writing Linux? Did he ever look at Minix's source code to determine how it behaved? There was no separate team writing the specification. Linus can't prove a negative, unless he can rightly claim he'd never had access to Minix's source. But a civil court doesn't base its decision on absolutes, and a good lawyer might convince the court that Linus did incorporate intellectual property from Minix.
Perhaps. (Score:3, Interesting)
A modern web browser
- is OS-like in complexity, but less silly hardware tying is necessary
- poses interesting crossplatform targetting compatibility issues, such as those Carmack faces when writing his game engines
- like a game, requires rendering of very large, complex, and dynamic graphic objects, and this must be done in an efficient and quick manner-- something current web browsers tend to be bad at, DHTML animations rarely look smooth
- poses interesting optimization questions for these dynamic graphics, much like an Id game
- like an Id game, must perform complex network operations efficiently
- requires the efficient parsing and execution of text files, much like the maps and interpreted-c mods for Quake 3
- like Id game engines, must expose an external development interface for plugins and embedding
Gecko, KHTML and MSIE are great browsers in many ways, but they pretty much all suffer from the fact that DHTML/flash/SVG or (God forbid) VRML all behave in rather inefficient, obnoxious, and (well) gimmicky manners. They don't feel like they're integrated with the web pages. They CERTAINLY don't feel like something you could do serious application development with (remember back when DHTML was first being proposed and people seemed to be under the impression complex and high-level applications would target web browsers?) I would like to see someone with a background in game development take a crack at these issues, as these issues seem very similar to the problem game engine designers must solve.For the moment however it appears Mr. Carmack's spare time project is trying to build a spaceship, so maybe we'll have to wait.
Re:"cleanroom" (Score:1, Interesting)
However, you cannot say that AMD produce a clean room implementation of x86. They had the IP and they used it.
Re:maybe not so simple... (Score:3, Interesting)
Re:"cleanroom" (Score:3, Interesting)
Re:anything prior to 1991 (Score:3, Interesting)
Before SCO, I (and my company) used open source because of a warm fuzzy 'freedom' feeling. Today that support has hardened (and is still hardening) into a business *requirement*.
The GPL is a known quantity to me. All I have to do is agree to its straightforward terms and all my licensing worries are over.
Contrast that with SCO's EULA shenanigans. If I was with SCO, I would have to be watching my back against the EULA being changed on me, being hauled into court and having to meticulously track every license I own (or should that be rent?).
Technically, I can't see what's stopping any other software company that uses an EULA from pulling the same stunts as SCO.
The end result is my company has made a decision, for *business* reasons, that all software must be open source and to avoid EULAs if at all possible. Proprietary will be tolerated only if there is no alternative, and even then I will always be on the lookout for an open source replacement.
How many other companies must also be arriving at this view of the world?
Further more, companies such as mine are operating in stealth mode on this issue (hence the AC). I'm not going to sick my head up and asked to be shot at by a desperate software company. I don't care if I don't show up on any user surveys. What I'm really saying is that lots of companies going down the same path as my company will not be advertising the fact.
Perhaps proprietory software is a bit like a fence post being eaten by termites? No damage shows until all that is left is a paper thin outer shell, at which point the post collapses.
to the best of my knowledge- (Score:1, Interesting)
I know there's another more normaly used law that could be used as well, but darn if I can recall the name of it right now. Someone here will know it though most likely.
not necessary to win the legal case(s) (Score:3, Interesting)
The whole thing is being "reverse-engineered". The "desired outcome" is a lawsuit, so whatever it takes to produce one is what takes place. Normally, the lawsuit is the means by which another desired outcome is produced. In this case, the "desired outcome" is/are the lawsuit(s), because this is about individuals within organizations obtaining promotions or "finding valuables in attics", or something like that.
This is what happens sometimes within large (or perhaps, sometimes, not so large) organizations - a few individuals wielding great power, looking to improve their status in the world, stab and fumble and grope in the dark, searching for their own private monetary nirvana, unable to settle for a salary and job security that "ain't broke".
This is not good for Microsoft the company; it's not good for Microsoft the company's reputation; perhaps sometime soon someone representing Microsoft the company will step forward and proclaim this whole thing an unhelpful distraction, which is exactly what it is.
I think every one of us has worked with an individual or two who had their own selfish interests placed ahead of their coworkers and the company itself. How much more tempting might it be, working amongst (or for) one of the wealthiest individuals in the US, if not the world? Let's face it... Microsoft is a legend, and Microsoft will always be a legend. Microsoft can have a bright future, Microsoft should have a bright future. It's as plain and simple as that. What is really needed here is another Lee Iacocca, another Jack Welch, etc... people like this are out there, and they do exist. But money talks, and being around it changes you - it takes a very, very strong individual to be able to turn down the prospect of an early retirement to do the right thing. What, with the patents and all, who wouldn't want to just go to some tropical island and never have to worry about this nonsense again? Perhaps one day when someone who truly has a passion for quality products, whether they be hardware or software, when someone who has true leadership abilities, and can inspire people to produce tip-top products - I believe there will be such a day, and I believe there will be such a person, but a little patience will be required - but when this day comes, I think that we should all try to get out there and welcome Microsoft back into the real world. It would be a good thing, sort of like a long-lost friend or something. The changes that will be necessary will happen, and the negativity and FUD will stop, it's just going to take the right person to bring this about.
Re:"cleanroom" (Score:4, Interesting)
The workings of MINIX are discussed in the book in detail, and the complete source code and binaries are on a CD which comes with the book. The book was the standard cheap way to get MINIX, so it's pretty damn likely that Linus had a copy.
I was running Minix on my Atari and hacking the kernel source to support Cyrillic at around the time Linus started writing Linux, which was originally a replacement kernel for Minix. Linus did it because Andy Tanenbaum wouldn't add 386-only functionality to Minix, because he wanted it to be portable to whatever machines students had available to them--e.g. my Atari. Linus wanted protected virtual memory, so he started hacking on 386 assembler using his Minix system to do so.
All of this is pretty common knowledge, I thought, so I'm perplexed that so many people posting to this discussion seem unaware of it.
Re:"cleanroom" (Score:2, Interesting)
Re:Arrow into Unixware (Score:2, Interesting)
Re:It doen't matter. (Score:5, Interesting)
So they can choose between A) losing because they GPL'd everything in dispute regardless of whether it was proprietary or not before they distributed it, or B) losing because their entire linux business was based on willful, for-profit piracy.
In 1991 Linus said no minix code (Score:2, Interesting)
Source: Google [google.com]
Re:Long live FreeBSD (Score:3, Interesting)
I would also speculate the Microsoft wouldn't have too much of a problem with the LGPL as well, since that only involves contributing back changes to the LGPLed code.