IBM Subpoenas Intel Into SCO Fray 248
whovian writes "Since IBM was ordered by the courts to show more code, they are now reported by Groklaw to have subpoenaed Intel to show 'all communications between Intel and SCO or Canopy about IBM, Unix or Linux, all meetings with either concerning IBM, Unix or Linux, and all contracts or other business relations, past, present, or future, between Intel and SCO.' The text is available at the website."
Re:IBM running scared? (Score:3, Informative)
However, since then Intel has been a massive backer of Linux, including massive investment into RedHat and driver engineering for Linux.
Hog wash! (Score:5, Informative)
What they most likely want to establish is that SCO new Itanium was delayed and Intel notified them about the changing strategy of the processor.
SCO is claiming that the Monteray project was cancelled by IBM "out of the blue (Pun somewhat intended)" and due to the advent of Linux. IBM canceled the Monteray project as they were allowed to do since the business reason for continuing was no longer there. They need to have Intel confirm this, information which Intel obviously is reluctant to provide
Re:my professional, legal and technical opinion.. (Score:2, Informative)
You forgot to read the last paragraph of the study:
"Doing this on purpose in a setting out of context generally implies that the instigator needs to find a new hobby."
Re:*sigh* (Score:5, Informative)
Re:Food for thought (Score:5, Informative)
How did this get +4 Insightful? Obviously you've never dealt with a court case more complicated than a traffic ticket.
When two companies discuss business it is done under Non-disclosure Agreements. Now I'm sure SCO and Intel had meetings about ia64 (since SCO was working on an OS for it and all) If IBM just went to Intel and said "hey tell us what SCO said back then" and Intel complied then SCO could sue Intel for NDA breach. Unlike their current suits they'd actually win that one, too.
In a previous job we were in a similar position -- one of our customers was being (quite justifiably) sued and the other party needed information relevant to the case from us.
We compiled the information but we couldn't just give it directly to them because that would breach our agreements with our (now former) customer. Instead we made a list of everything we had and had OUR LAWYERS write up a subpoena based on that.
Then we handed it to them and said "please have this served on us". As soon as it had a judge's signature on it we faxed them the stuff they wanted within minutes.
Basically in civil litegation ABSOLUTELY EVERYTHING that you find out from third-party corporations goes through the subpoena process whether they're friend or foe. Don't assume just because Intel got one from IBM that they must be on SCO's side or anything.
The Monterey Project - cliffnotes (Score:1, Informative)
SCO and IBM entered into a strategic business agreement in October of `98 to aggressively accelerate growth of UNIX enterprise servers. They are delivering a single UNIX product line for IA-32 systems and future IA-64 systems; the result, due in early Q2, 2000, is a single product line on IA-32, IA-64 and IBM PowerPC, ranging from entry-level servers to very large enterprise environments.
monterey cliff notes stuff basically [viewtouch.com]
Re:Who should be following this is ... (Score:4, Informative)
Re:Hmm, interesting... (Score:4, Informative)
IBM knows that Intel knows all about Itanium, its roadmaps, schedules, and delays. IBM knows that Intel has a good idea of what they told SCO about Itanium schedules and delays. Given that SCO is now down to claiming that any funny business about purloining code went on during Project Monteray, on which IBM and SCO cooperated, and that that was largely about AIX on Itanium, details about Itanium and what SCO knew about it are important.
There are perfectly straightforward, perfectly innocent explanations for why IBM would want information from Intel, and oddly enough they fit the current major issues of the case far better than any wild and extravagant theories about Intel conspiring to bring IBM down.
So what does IBM know that you don't? IBM know what they're talking about.
Jedidiah.
Jun U Nakajima, SCO and Trillian project (Score:5, Informative)
So, how did Linux become so capable of scaling beyond the heights of the old UNIXs. More importantly, who helped put what where?
As with the marketing of cars and TVs, it is the vendor's high end leading edge models which sells the standard models, from which most of the sales and profit is made. For the enterprise server market today, that high end is multi-headed 64-bit SMP systems, never mind the fact that single 32-bit processors provide more than enough power to do most jobs. For all intents and purposes, it is the ability of the core OS to scale on 64-bit SMP systems that defines "enterprise scalability". Other enterprise feature are effectively just add-ons, which in the case of Linux, have been freely contributed from many vendors and developers.
Since version 2.0, Linux was more than just a 32-bit x86 operating system. With the insistence and assistance of Jon "Maddog" Hall, Linux was already ported to the 64-bit Alpha processor, which delivered great performance and stability. Just like the traditional AT&T UNIX source base, the ownership of the Alpha chipset passed though many hands, suffering the same fate of a thousand cutbacks. Even Alpha's "native" OS, VMS, has been ported to Itanium by HP/Compaq.
Since 1997, Intel has been promoting the Itanium line as the inevitable successor for every other server processor on the market. Despite the early vaporware status, Intel has been very successful, at least in terms of marketing. With the exception of its mainframe systems, even IBM ships Itanium systems that directly compete with their own Power processors.
For what The SCO Group has to offer with SCO Unixware 7,the Itanium line is the only 64-bit option. The problem for The SCO Group is that modern Linux can compete so well in that same market that the value of Unixware is rapid deteriorating to a historical curiosity. I suspect that The SCO Group (at that time called Caldera) executives were well aware of this before they acquired the server part of Old SCO in August 2000, or they would have known, if they spoken to the right executives and technical staff.
So how did Linux get scale on Itanium? The SCO Group would have you believe it was all IBM's doing, which isn't as interesting as the real story. The web of history weaves to encircle and entangle a much more diverse group of conspirators, including many of The SCO Group, Caldera, and old SCO's own former executives and other employees.
In October 1998, IBM, Old SCO and Sequent teamed up to collectively develop parts of Unixware and AIX into scalable 64-bit-ready ports for IBM's Power processors and Intel's AI64, or Itanium, under the banner of Project Monterey. But by then, it was already too late.
In February 1998, well before even the first prototype IA-64 chips were available, a skunkworks team at HP, with some assistance from Intel, began the work toward porting Linux to IA-64. By October 1998, around the same time that IBM, Old SCO and Sequent had finished negotiations, HP had completed the build toolchain. By January 1999, the Linux kernel was booting on an IA-64 processor simulator, months before the actual Itanium processor was available. In March 1999, at Intel, Linux was booting on the actual Intel Itanium processor. In April 1999, CERN joined the project for the port of the GNU C library and VA Linux Systems joined the project and rapidly improved the stability and performance.
In May 1999, the Trillian Project was founded and HP, VA Linux and Intel collectively provided their source patches to the Linux kernel for the Itanium port under the GNU general public license.
A bootable kernel alone however does not make an OS make. HP supplied the patches for the toolchain (initial GCC C/C++ compiler, gas assembler, ld linker). Intel supplied the test platforms, apache, EFI, FPSWA, SCSI, SMP, libm (the old Linux C libraries). VA Linux ported E, E-Term, XFree86, utilities
Re:Intel should subpoena AMD! (Score:5, Informative)
My original IBM PC/XT came with a technical reference manual which contains the complete BIOS assembler source code and complete circuit diagrams for every board in the computer. Since it was constructed using OTS ICs, someone single-minded enough could construct a whole PC based upon those specifications - and I am sure that the whole PC industry owes it to IBM for making available those specifications and hence giving rise to all the clones... The tricky part for the cloners is to 'clean-room' design a clone without infringing on IBM's copyright - an issue which IBM did take to court on more than one occasion.
That PC is long gone but I still have the original IBM technical reference manual. Its a nice hardcover ring-bound book. They don't make manuals like they used to!
Re:The processors were provided by Intel (Score:1, Informative)
There may have been mechanical samples of cartridges and carriers, but there was no Itanium silicon, prototype or otherwise, in April/March of 1999.
First Merced silicon booted up in Dupont, Washington, on or around August 27th, 1999. Some samples were available August 30th, 1999.
One of the first 64-bit operating systems that booted on Itanium was Mach 3.0.
Discovery laws.... (Score:2, Informative)
People can go to jail if they fail to disclose!
I work in litigation and subpoenaing someone with something as ridiculous as this is a great way to keep the other party busy and give yourself some extra time. In addition to that, it adds costs to the other party's litigation.
Sometimes, you can just keep subpoenaing and they won't be able to keep up. And generally when that happens, they will want to settle.
Wonder if Intel is going to have one of its attorneys claim legal professional privilege over the documents that they want to discover?
All fun and games I say!
Re:IBM running scared? (Score:3, Informative)
Intel already *is* a competitor (and has been, for a while).
Timeline is a little wrong. (Score:5, Informative)
The blurb for this story is a little misleading. IBM planned to do this and may have even already had the subpoena executed by the time SCO's motion was granted. The timing was coincidental not causal.
Re:Intel should subpoena AMD! (Score:3, Informative)
Re:*sigh* (Score:3, Informative)
What are they trying to pull here? That Intel was possibly behind SCO's litigation? I doubt it..
Lawyers get to make lots of money on this, but historically Intel has wanted to see big UNIX fail so it would help Xeon sales. Intel has never really been xNIX friendly although some of it's technology came from chips like the Alpha that were designed for UNIX.
This is now hurting Intel in that the most popular, and probably the best processor to run Linux is an AMD Athlon 64. And with competition from other chip sets Intel sales and margins are dropping.
The bottom line is if IBM can show Intel provided SCO the technology then in fact SCO has no claim, which I suspect be the case. IBM probably knows many SCO claims agqinst IBM were derived elsewhere as SCO hasn't innovated anything but business extortion since the early 80's.
When will it end?
Not soon enough.
Re:Mar ’99: Linux boots on Itanium™ proc (Score:2, Informative)
The "Itanium processor logic model" mentioned in the press release was a software simulation using the RTL description (written in ihdl) of the chip ("csim" to be exact). The simulator ran at an effective rate of about 1Hz from a netbatch queue amongst a huge farm of workstations in Santa Clara, and took weeks to complete (the simulation was not parallel).
The version of Linux that was booted (at 1Hz) was a highly stripped version of 2.2, ported by a team in Oregon independent from the Trillian efforts. The simulation took weeks to complete. Several months prior to that date, the same team booted Mach 3.0 in the same simulation environment.
Both of those kernels, as well as others configured for single & multi-processor with a few user-mode tests, were used during first silicon bring-up in late August of 1999.
The RTL source of the chip is used by additional tools to place and route signals and functional blocks (built from transistors and signal lines). That information is then used to produce masks, which are then used to produce wafers.
Trust me, as a guy that should know, there was no silicon until late August of 1999.
If I posted a photo of the wall-plaque that sits near my desk, it might convince you (tapeout July 4th 1999, samples August 30 1999), but I can't do that.