Attorneys for Caldera, Inc. DISTRICT OF UTAH, CENTRAL DIVISION
|
Navigation Notes for this document:
Select a topic heading in Blue and it will take you to the corresponding location in this document.
Select Return to return to the selected subject heading in the Table of Contents.
Select Table of Contents to return to the top of the Table of Contents.
INTRODUCTION
OVERVIEW OF THE CASE
SUMMARY JUDGMENT STANDARDS
CONSOLIDATED STATEMENT OF FACTS
1974-1981: THE ERA OF PERSONAL COMPUTERS BEGINS
"World's First Minicomputer Kit to Rival Commercial Models"
Popular Electronics, January 1975
Early Days of Digital Research Inc. and Microsoft Corp.
"Unable to agree to a deal, IBM turned to another small company, Microsoft, for what turned out initially to be a copycat product. Kildall was livid. He said: 'Here we were, in good faith, in negotiations with IBM and they came in with a complete rip-off.'"
Obituary, Gary Kildall, July 20, 1994
"Again, from the programmer's point of view, MS-DOS 1.0 was primarily a clone of CP/M."
Chris Peters, November 6, 1986
Seattle Computer Products, Inc. vs. Microsoft Corporation
II. 1981-1989: THE STAGNATION OF A STANDARD
"While DOS continues to be our most important and most profitable product over the last four years we have done very little with it technically."
Bill Gates, November 29, 1989
III. APRIL 1987-MAY 1990: ADVENT OF DR DOS
"Digital Research Inc., which formerly ruled the operating system world with its CP/M, is planning to take on Microsoft Corp. in the lucrative DOS market with DR DOS, its single-user offering compatible with MS-DOS 3.3."
PC Week, June 14, 1988
"DOS 4 is a mess to discuss -- bugs, too big, strange shell interface, who wrote it? DOS 4 has a terrible reputation."
Bill Gates, October 31, 1988
"Initial consensus from DOS management is that DRI has a product which competes very favorably against MS-DOS."
DOS and Windows Monthly Summary: April 1989
Microsoft Realizes Its Mistake
"We thought OS/2 would replace MS-DOS. We were wrong. We got distracted and didn't pay enough attention to the DOS standard."
Bill Gates, June 6, 1991
Monopoly Maintenance: Choosing the Weapons
"DR DOS: I expected to hear we had more of a problem with this. Apparently, we still haven't lost a lot of business. I want us to track this very closely."
Bill Gates, October 31, 1988
Resistance is Futile -- Prepare to be Assimilated
"Steve Ballmer had a promising discussion with DRI re: them licensing MS-DOS vs. competing with us. Steveb will follow up with Joachimk."
Russ Werner, December 18, 1988
"You never sent me a response on the question of what things an app would do that would make it run with MSDOS and not run DR-DOS. Is there any version check or api they fail to have? Is ther feature they have that might get in our way? I am not looking for something they cant get around. I am looking for something their current binary fails on."
Bill Gates, September 22, 1988
Warning Messages and Other Scare Tactics
"Bill Gates ordered to all application business units to include checking routines of operating environments and if it is Microsoft DOS, nothing will happen. But if it is non MS-DOS (such as DR-DOS), application will display messages saying that 'This application has been developed and tested for Microsoft MS-DOS. Since you use different environment, this application may not work correctly . . .' "
B. J. Bahk, August 9, 1989
Propaganda: Fear, Uncertainty and Doubt
"It only takes a couple of reports about non-compatibility to give the kiss of death to a PC: we've seen that on the hardware side as well as in the operating system area."
Jeremy Butler, September 22, 1989
Exclusionary Licenses: The Shape of Things to Come
"DOS being fairly cloned has had a dramatic impact on our pricing for DOS. I wonder if we would have it around 30-40% higher if it wasn't cloned. I bet we would!"
Bill Gates, August 6, 1989
"At this time we still offer DOS and Windows on per-system level. If there is any danger we will offer the DOS/Win combo license."
OEM Status Report, November 1989
Dreaming of The DOS/Windows Merge
"The strategic side is: . . . We put a bullet in the head of our would be competitors on DOS like DRI, Desqview, dos extenders etc."
Nathan Mhyrvold, May 9, 1989
"DOS remains the backbone though of both our software businesses. It is under extreme attack by high quality clones like DR DOS."
Bill Gates, December 1, 1989
DR DOS 5.0, THE REAL COMPETITION BEGINS
"In order for Leopard to have a bright future, it is necessary to immediately exploit our product superiority and gain name recognition. This is our opportunity and we must take advantage of it."
DR DOS 5.0 Launch Plan, March 14, 1990
Awards, Praise, and Compatibility
"Verdict: This is the first time I've given any product an all 'excellent' verdict, which speaks for itself."
PC User, July 4, 1990
Monopoly Maintenance: Building the Perfect Beast
"On the desktop, we have a strategic win today (monopoly). We must keep the desktop."
Presentation, Microsoft Executive Staff Retreat, May 10, 1990
"On the PR side, we have begun an 'aggressive leak campaign' for MS-DOS 5.0. The goal is to build anticipation for MS-DOS 5.0, and diffuse potential excitement/momentum from the DR DOS 5.0 announcement."
DR DOS 5.0 Competitive Analysis, May 2, 1990
"I took the opportunity to negotiate in German, sign our offer as is -- this is an agreed upon package deal or if you change any component, we will too. Second option: scratch the DOS clause, pay $35 for Windows instead of $15. . . . In my judgment they will hurt if they do not ship WIN and paying $35 for it is out of the question."
Joachim Kempin, March 26, 1991
"We are engaged in a FUD campaign to let the press know about some of the bugs. We'll provide info a few bugs at a time to stretch it out."
Brad Silverberg, July 22, 1991
Exclusionary Licenses: Triple-Whammy
"We are forcing them to NOT ship any DRI machines."
Ron Hosogi, September 10, 1990
"Opus agreement has finally been signed by Redmond. Another DRI prospect bites the dust with a per processor DOS agreement."
Microsoft OEM Status Report, October 1990
"The DR threat still lives, especially in the export section which needs a low priced DOS for XTs to be shipped to Eastern Block. We will maintain and utilize HEI's UPB situation to keep out DRI."
Microsoft OEM Status Report, September 1990
"The new contract is for three year term so that we don't have to worry about low end competition. This will be the first OEM in Mexico bundling Windows 3.0 on its system, and we eliminated DRI's chances with Printaform for at least 3 years."
Microsoft OEM Status Report, August 1990
Dreaming of the DOS/Windows Merge -- Part 2
"In a sense, you lock cloners out of the WIN4 market, but we only benefit from this if you increase the price of WIN4 to be that of WIN3 + DOS. Otherwise, we've destroyed the DOS market under WIN4, revenue-wise, so this is a phyrric victory."
Gordon Letwin, March 8, 1991
MS-DOS 5.0: Almost Better Late Than Never
"We're currently hearing from numerous callers (approx 150/day) who are experiencing severe incompatibilities with MS-DOS 5.00, to the point that PSS is unable to get the operating system to work successfully on their machines."
Microsoft PSS Report, June 13, 1991
JULY 1991-OCTOBER 1991: THE DRI/NOVELL MERGER
"I thought about it all night. Since I came here I said there were two things that concerned me related to Novell: one Novell partnering with IBM and two Novell coming at us at the desktop. Both fears have now come true."
Jim Allchin, July 17, 1991
"'We think [DR DOS 6.0] is excellent technology,' said Joseph Guglielmi, IBM's general manager of marketing and business development for personal systems. 'We're talking with Novell and DRI on a variety of alternatives,' Guglielmi confirmed."
Computer Reseller News, September 23, 1991
"'There was only one stipulation,' says Noorda, 'Gates told me, That DRI thing has to go.'"
Ray Noorda, January 24, 1994
VI. SEPTEMBER 1991-DECEMBER 1993:
DR DOS 6.0, ADVANCING THE STANDARD
"I think to be successful a DOS update has to . . . match the garbage that DR DOS does."
Bill Gates, March 6, 1992
Awards, Praise, and Compatibility -- Part 2
"Now, only months after the release of MS-DOS 5.0, DRI has again stepped ahead with the release earlier this month of DR DOS 6.0, which once again matches and exceeds the features and capabilities of Microsoft's product."
PC Week, September 30, 1991
Monopoly Maintenance: Polishing and Improving the Arsenal
"We need to slaughter Novell before they get stronger."
Jim Allchin, September 9, 1991
"There is an obvious conflict quickly approaching us, and I get the feeling we are not very prepared PR wise. The conflict is Windows 3.1 and DR-DOS. Apparently DRI is quite aware of our plans to not test with DR-DOS, our plan to not let them enter the Win 3.1 beta program, and our plan to detect the presence of MS-DOS and warn the user they are on an un-tested OS if MS-DOS is not detected."
David Cole, November 7, 1991
"fact is, I'm sure they already have win 3.1 anyways. with 10,000 betas, all it takes is one drdos user to send it to them. . . . so I'm sure they have win 3.1 and this is just a pr game."
Brad Silverberg, December 5, 1991
"What the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is dr-dos and then go out to buy ms-dos. or decide not to take the risk for all the other machines he has to buy for in the office."
Brad Silverberg, February 10, 1992
Intending Incompatibilities -- Part 2
"heh, heh, heh . . .
my proposal is to have bambi refuse to run on this alien OS. comments?"
Phil Barrett, September 30, 1991
"Objectives: FUD DR DOS with every editorial contact made."
MS-DOS 6 PR Plan, November 1992
"Further to our conversation yesterday, I am writing to confirm that Microsoft is unable to supply you Windows as a single product. Microsoft will only sell you Windows as a combined package with MS-DOS version 5."
Ellen Taylor, January 23, 1992
"look what znix is doing! cut those fuckers off."
Brad Silverberg, May 19, 1992
Exclusionary Licenses: Critical Mass
"I feel we are much too smug in dealing with Novell. Perhaps they didn't hurt us in DOS yet -- but it's not because of product or their trying. It's because we already had the OEMs wrapped up."
Jim Allchin, March 26, 1992
Choking on Vaporware -- Part 2
"the design preview has not leaked to the press are you surprised do you wish it would if so when"
Steve Ballmer, June 9, 1992
Implementing the DOS/Windows Merge
"Novell is after the desktop . . . This is perhaps our biggest threat. We must respond in a strong way by making Chicago a complete Windows operating system, from boot-up to shut-down. There will be no place or need on a Chicago machine for DR-DOS (or any DOS)."
Chicago Strategy Document, June 16, 1992
MS-DOS 6.0: Not a Bad Product, Except for the Data Loss Bugs,
Class Action Lawsuits, and the $120 Million Verdict
"The current number of US MS-DOS 6 Upgrade customers losing data (full or partial) is about 3/1000. I do not know how to define acceptable but this feels much too high to me."
Brad Chase, May 27, 1993
VII. DECEMBER 1993-SEPTEMBER 1994:
NOVELL DOS 7.0, DEAD ON ARRIVAL
"Who at Microsoft gets up every morning thinking about how to compete with these guys in the short term -- specifically cut their revenue. Perhaps we need more focus on this. . . . After their behavior in this FTC investigation I am very keen on this."
Bill Gates, July 21, 1993
Awards, Praise, and Compatibility -- Part 3
"if they really release the version with all this junk in it, it will mean that for three ms-dos releases in a row (5, 6 and 7), DR will have had our key features in their product 12-18 months before us."
Richard Freedman, March 26, 1993
Monopoly Maintenance: Pulling the Trigger
"This really isn't that hard. If you're going to kill someone there isn't much reason to get all worked up about it and angry -- you just pull the trigger. Angry discussions before hand are a waste of time. We need to smile at Novell while we pull the trigger."
Jim Allchin, September 18, 1993
Choking on Vaporware -- Part 3
"WOW -- If you are REALLY still telling the field the RTM is Sept 30 -- and if you are REALLY serious -- we have a ton of work to do VERY fast?!! Is this just propaganda mail???"
Mike Appe, April 7, 1994
"vERY CLEAR TO ME: nO CHICAGO, NO COOPERATION no beta, no alpha code, total war."
Joachim Kempin, May 18, 1993
"At the Exec Retreat in Feb, I suggested that we should lock up the LDS Church (and BYU) as a 100% MS account. . . . Were we to own his account, we would inflict an incredible amount of FUD on the new Novell/WP. The influence of the LDS Church in the Utah economy and culture is difficult to appreciate from a distance."
Mike Murray, April 5, 1994
Exclusionary Licenses: No Wiggle Room
"Compaq things they can distribute our os sw however they want. Joachim, you'll need to check the contract on this. If they think they can distribute however they want, again, it's a small step to putting other os software on the cd rom."
Brad Silverberg, October 1, 1993
Implementing the DOS/Windows Merge -- Part 2
"also he asked about chicago pricing. i said that since it's the combination of windows and msdos and more, you should expect a price in the same ballpark as windows + ms-dos."
Brad Silverberg, December 2, 1993
"We plan no new releases of MS-DOS after MS-DOS 6.22!!"
Microsoft Three Year Plan, April 1994
"Novell is considering selling Novell DOS to a third party, sources said. Among those said to be interested in buying the rights to DOS is Novell's former chairman and CEO Ray Noorda, sources said."
PC Week, August 22, 1994
VIII. JULY 15, 1994: UNITED STATES VS. MICROSOFT CORP.
"Microsoft's unfair contracting practices have denied other U.S. companies a fair chance to compete, deprived consumers of an effective choice among competing PC operating systems, and slowed innovation."
Janet Reno, July 16, 1994
IX. AUGUST 1995: DOS IS FINALLY . . . REALLY, REALLY WELL-HIDDEN
"I would hesitate to say that chicago is a complete redesign, one of the things about chicago is that while it's a big big improvement, it's still an incremental step forward. i would be afraid of scaring people off, thinking, whoa, i better let this settle down before i try it. it's a generation step forward, like a new Honda Accord."
Brad Silverberg, April 26, 1994
"It is our intention to finish the job the Justice Department left unfinished when it settled its antitrust complaint through consent decree."
Steve Susman, July 24, 1996
XI. MAY 18, 1998: UNITED STATES VS. MICROSOFT CORP. -- PART 2
"The lawsuit we filed today seeks to put an end to Microsoft's unlawful campaign to eliminate competition, deter innovation, and restrict consumer choice."
Joel I. Klein, May 18, 1998
Appendix A Table: Relevant Product Releases
* Source: Exhibit 5
Ivie Report, at 36-37
Appendix B Chart: DR DOS vs. MS-DOS: A Side-by-Side Comparison
* Source: Leitzinger Report, Exhibit 7
Appendix C Chart: OEMs That Microsoft Realized Were Considering DR DOS
* Source: Leitzinger Report, Exhibit 5
Appendix D Summary: Results of NSTL Compatibility Testing of DR DOS 5.0,
* Source: Leitzinger Rebuttal Report, Exhibit 3
Appendix E Summary: Results of XXCAL Compatibility Testing of DR DOS 6.0,
* Source: Leitzinger Rebuttal Report, Exhibit 4
Appendix F Summary: Results of Evan Ivie Compatibility Testing of
DR DOS 5.0 and DR DOS 6.0
* Source: Leitzinger Rebuttal Report, Exhibit 5
COMES NOW Caldera, Inc. complaining of Microsoft Corporation, and offers this Consolidated Statement of Facts in support of its forthcoming Responses to various Motions for Partial Summary Judgment now pending, and would show the Court as follows:
In 1916, Judge Learned Hand resolved the antitrust dispute pending in United States v. Corn Products Refining Company, 234 F. 964 (S.D.N.Y. 1916). The government charged that a starch producer had engaged in illegal monopolization. In evidence were typewritten memoranda from company executives, who had a custom of communicating with each other in this fashion. Judge Hand wrote: "The documents were never intended to meet the eyes of anyone but the officers themselves, and were, as it were, cinematographic photographs of their purposes at the time they were written." Id. at 978. A witness's attempts to contradict the validity of these memos, Judge Hand wrote, "served only to affect the general credibility of his testimony." Id.
Like the executives in Corn Products, Bill Gates and the senior executives at Microsoft never expected that their e-mail and other internal reports and communications would be produced and reviewed as a record of their anti-competitive conduct.(1) They were wrong. Those internal communications tell the story of Microsoft's predatory actions, contradicting in every material respect the "legitimate business justifications" put forth in Microsoft's various summary judgment motions. Judge Hand's conclusions over 80 years ago apply perforce today to a new industry dominated from its inception by Microsoft:
In the face of these memoranda, which for some strange reason were preserved, there can be no question in my mind of the continuous and deliberate purpose of the Corn Products Refining Company, by every device which their ingenuity could discover, to maintain as completely as possible their original domination of the industry.
234 F. 978
In this Consolidated Factual Statement, Caldera will highlight the glaring discrepancies between Microsoft's current proffer of justification for its anti-competitive conduct, in contrast to the documents and dialogue flying about between its highest executives at the time.
The evidence in this case -- including Microsoft's internal documents and deposition testimony of Microsoft employees, former DRI and Novell employees, and disinterested witnesses -- proves that Microsoft has maintained its monopoly in the desktop operating systems business through predatory conduct that excluded competitors from the DOS market, a market in which Microsoft had monopoly power.(2) Caldera's case covers a long period of time, but the basic thrust is straightforward.
In 1987, Microsoft announced its intention to discontinue the development of MS-DOS in favor of a new operating system product, dubbed OS/2. A company called Digital Research Inc. (DRI), which had helped develop the original DOS, immediately recognized Microsoft's blunder. Consumers still wanted DOS. Within a year of Microsoft's announcement, DRI released its own version of DOS called DR DOS. Microsoft initially reacted by trying to buy DR DOS from DRI. When DRI rejected the offer, Microsoft implemented a series of anti-competitive tricks that it perfected in years to come, such as spreading false stories about problems with DR DOS in order to create fear, uncertainty, and doubt (FUD) among consumers; falsely announcing the imminent release of non-existent products in order to freeze consumer demand (vaporware); and retaliating against computer manufacturers -- original equipment manufacturers (OEMs) -- who dared to license DR DOS. Still, DR DOS established its niche and enjoyed modest growth.
In June 1990, DRI raised the stakes by releasing DR DOS 5.0, a revolutionary DOS product. Microsoft launched a vicious campaign to destroy DR DOS 5.0 before its sales could take off.
Vaporware. First came the wave of vaporware. Within a week of DRI's announcement of DR DOS 5.0, Microsoft announced plans to ship within four months a comparable product: MS-DOS 5.0. Microsoft executives literally circled the globe, spreading word of MS-DOS 5.0 and thus deterring customers from purchasing DR DOS 5.0. This announcement was demonstrably false, as proven by Microsoft's own records. Finally, in June 1991 -- over one year after Microsoft's announcements -- MS-DOS 5.0 was released. Any momentum DRI should have gained from DR DOS 5.0 was dead.
FUD. Microsoft kept up the attack by launching a barrage of FUD against DR DOS 5.0. Microsoft's FUD strategy was to portray DR DOS 5.0 as full of technical glitches ("bugs") and incompatible with Windows 3.0 -- the then-current version of Microsoft's graphical user interface (GUI), which translates the word commands needed to run DOS into pictures on the screen. Neither charge was remotely truthful, as Microsoft well knew. Indeed, Microsoft's own documents reveal the predatory intent behind these spurious charges: convince customers that DR DOS was simply too risky a venture to justify crossing swords with a vindictive monopolist like Microsoft.
Tying. Simultaneously, Microsoft began bringing to bear its power in the Windows market, where Microsoft faced no competition. Increasingly, DOS users -- whether MS-DOS or DR DOS -- wanted to take advantage of Windows, which ran on top of DOS. To prevent consumers from using DR DOS with Windows, Microsoft began tying license for Windows to commensurate license of MS-DOS by either charging prohibitively high prices to any OEM that wanted to buy Windows alone, or prohibiting sale of Windows on its own altogether.
Exclusionary Licenses. During this 1990-1991 period, Microsoft also began deploying what would become its most effective weapon against DRI: exclusive licenses with OEMs. Although these licenses did not contain express exclusivity clauses, they utilized a collection of devices to create the same exclusive effect as an express contractual clause. Under these licenses, an OEM would have to pay Microsoft a royalty on every machine the OEM shipped regardless of whether the machine contained MS-DOS. This "per processor" term meant that an OEM could only ship a competing operating system if it was willing to pay twice: The OEM had to pay the maker of the competing system, such as DRI, and it had to pay Microsoft. Microsoft's licenses also required the OEM to make large minimum commitments with up-front payments for these commitments. Because Microsoft's pricing structure rewarded OEMs that made overly-optimistic minimum commitments, OEMs regularly had large pre-paid balances when their licenses expired. OEMs would forfeit these balances unless they renewed their license with Microsoft. Further tightening its stranglehold on OEMs , Microsoft dramatically increased the duration of these licenses to two, three, or even four years -- far in excess of the product life of MS-DOS versions. Microsoft's own documents show that these restrictive terms were introduced to ensure that no OEM could switch to DR DOS. In fact, almost no OEM that adopted one of Microsoft's restrictive licenses ever patronized DR DOS.
DR DOS expanded its market share slightly through 1991. In the Summer of 1991, DRI got a major boost in its effort to tackle Microsoft: DRI merged with Novell. This was a major competitive threat, and so Microsoft immediately tried to buy Novell. Novell ultimately refused. Microsoft responded with a vengeance, aiming its fury at the forthcoming version of DR DOS.
In the Fall of 1991, DRI/Novell released DR DOS 6.0, leapfrogging the features in MS-DOS 5.0 which Microsoft had released barely three months before. Microsoft pulled three special tricks out of its nasty bag to destroy DR DOS 6.0. 1. Beta Blacklist. Microsoft blacklisted DRI, and then Novell -- and ultimately anyone doing business with DR DOS -- from receiving test versions (or "betas") of Windows 3.1, which was being tested during the second half of 1991. Traditionally, software makers provide such test versions to makers of complimentary software so they can make appropriate changes to existing software and thus avoid huge compatibility problems every time a new piece of software is released. For example, DRI had used previous betas of Windows to assure consumers that DR DOS was compatible with Windows. But after cutting DRI and Novell off from the Windows 3.1 beta program, Microsoft made sure the world knew about it, and further sowed the seeds of concern about incompatibility between DR DOS and Windows by falsely stating it did not test DR DOS and thus could not ensure compatibility with Microsoft products like Windows. 2. AARD Code. In December 1991, Microsoft also inserted secret, encrypted code into the final Windows 3.1 beta -- a preview, marketing release -- that triggered a false error message whenever a computer was running DR DOS with Windows. 3. Intentional Incompatibility. Microsoft went further still, and designed both beta and released versions of Windows 3.1 to be incompatible with DR DOS simply to harm DRI.
Exclusionary Licenses and Tying. DRI's efforts to market DR DOS 6.0, also, collided head-on with the wall erected around OEMs by Microsoft's exclusionary licenses and tying of Windows and MS-DOS. While DRI and Novell tried to vigorously market DR DOS to OEMs during 1991 and 1992, OEMs simply could not afford to license DR DOS 6.0 even though it was a superior product. DR DOS 6.0 was cut off from the single most important customer base for operating systems.
FUD. On the off chance DR DOS 6.0 had any hope of survival, Microsoft unleashed another barrage of FUD against DR DOS 6.0 during 1991 and 1992. Microsoft put engineers to work searching for potential problems with DR DOS 6.0. After those engineers reported back a few problems -- none of which were more serious than problems in MS-DOS -- Microsoft made ominous (but false) statements that DR DOS suffered from a wide range of serious problems.
Vaporware. And once again, Microsoft reacted to the release of DR DOS 6.0 by immediately announcing the pending release of a competing product, MS-DOS 6.0, that was not even then on the drawing board. Microsoft outdid itself, describing a product that would not be released until four years later -- and only then as the DOS component of what is now known as Windows 95.
DR DOS sales plummeted in the first quarter of 1992, never to recover. Not realizing DR DOS was mortally wounded, Novell persisted, and in December 1993 released an updated version dubbed Novell DOS 7.0.
DOS/Windows Merge. In addition to the same anti-competitive conduct outlined above (exclusionary licenses, FUD, vaporware), Novell confronted Microsoft's final blow, which had been in the works at Microsoft for years. Since 1989, Microsoft executives realized that the ultimate solution to competition in the DOS market was to eliminate the DOS market in favor of Windows. Microsoft could accomplish this feat by simply incorporating DOS into Windows; in other words, Microsoft could use its uncontested monopoly in the Windows market to swallow the DOS market in one gulp. In 1993, Microsoft began preannouncing the development of a new product -- code-named "Chicago" -- that was supposedly an "integrated" Windows operating system, and which would eliminate the need for DOS. In the face of this announcement, and finding itself locked out of OEM business, Novell withdrew DR DOS from the marketplace in the Fall of 1994. Windows 95 was released in August 1995.
But Caldera has discovered Microsoft's little secret: What Microsoft continues to describe as an "integrated" operating system is what antitrust enforcers call an illegal tie. Windows 95 is nothing more than a bolting together of two easily separable products: updated versions of Windows and MS-DOS. But for Windows 95, DR DOS could have survived as a viable option for consumers. And with choice, the lower prices and innovations that had greeted the advent of DR DOS would continue to this day.
The Tenth Circuit admonishes that, in an antitrust dispute, "[p]laintiff's evidence should be viewed as a whole" -- not artificially segregated as in Microsoft's numerous motions for partial summary judgment. Aspen Highlands Skiing Corp. v. Aspen Skiing Co., 738 F.2d 1509, 1522 n.18 (10th Cir. 1984), aff'd, 472 U.S. 585, 604 (1985). As the Supreme Court notes, an antitrust plaintiff "should be given the full benefit of [its] proof without tightly compartmentalizing the various factual components and wiping the slate clean after the scrutiny of each." Continental Ore Co. v. Union Carbide & Carbon Co., 370 U.S. 690, 699 (1962). The fact that a monopolist such as Microsoft has engaged in a course of questionable conduct is powerful evidence of bad intent and also illuminates the true potential of a single act to cause harm -- a relatively minor blow to an already beaten body does more harm than a single uppercut does to a fresh fighter. See Photovest Corp. v. Fotomat Corp., 606 F.2d 704, 719 (7th Cir. 1979) ("Otherwise lawful practices may become unlawful if they are part of an illegal scheme"); City of Mishawaka, Indiana v. American Electric Power Co., 616 F.2d 976, 986 (7th Cir. 1980) ("It is the mix of the various ingredients of [defendant's] behavior in a monopoly broth that produces the unsavory flavor").
Microsoft is only entitled to summary judgment if it shows "that there is no genuine issue as to any material fact and that the moving party is entitled to a judgment as a matter of law." Fed. R. Civ. P. 56(c). The Supreme Court has stated that a "genuine issue" exists simply "if the evidence is such that a reasonable jury could return a verdict for the nonmoving party." Anderson v. Liberty Lobby, Inc., 477 U.S. 282, 248, 106 S. Ct. 2505, 2510 (1986). Three important points control this consideration of Microsoft's motions for summary judgment:
Id. at 250, 254-55, 106 S. Ct. at 2511, 2513.
Even brief discourse makes plain how inappropriate summary judgment is here: the case is factually complex; it is of undeniable and far-reaching public importance; numerous material facts are in dispute; and Microsoft's explanations of its conduct are starkly at odds with its own internal, contemporaneous documents. Indeed, Microsoft presents this Court with little more than a mass of baldly self-serving testimony from its own employees. But doubts as to the credibility of the movant's witnesses may alone lead this Court to conclude that a genuine issue exists. See C. Wright, A. Miller & M. Kane, 10A Federal Practice and Procedure: Civil 2d 2726 at 113 (1983). Where, as here, "the knowledge of the events or occurrences on which the action is based lies exclusively within the control of the party moving for summary judgment," courts are understandably reluctant to deprive the nonmoving party of the opportunity of testing the movants' or their witnesses' credibility in open court. Id. at 120. See Anderson, 477 U.S. at 255, 106 S. Ct. at 2513 ("Credibility determinations, the weighing of evidence, and the drawing of legitimate inferences from the facts are jury functions, not those of a judge"); United States v. Perry, 431 F.2d 1020, 1022 (9th Cir. 1970) (summary judgment inappropriate "where a trial, with its opportunity for cross-examination and testing the credibility of witnesses, might disclose a picture substantially different from that given by the affidavits").
The Supreme Court has counseled that summary judgment in antitrust cases be used sparingly. Poller v. Columbia Broadcasting System, Inc., 368 U.S. 464, 473, 82 S.Ct. 486, 491 (1962). The Tenth Circuit has long adhered to this position. See, e.g., City of Chanute v. Williams Natural Gas Co., 955 F.2d 641, 646 (10th Cir.), cert denied, 506 U.S. 831 (1992) ("We recognize the prevailing sentiment that summary judgment should be used sparingly in antitrust cases. . . . We remain mindful that summary judgment in antitrust case is disfavored"), overruled on other grounds, Systemcare, Inc. v. Wang Lab Corp., 117 F.3d 1137 (10th Cir. 1997) (en banc); Sports Racing Serv. v. Sports Car Club of Amer., 131 F.3d 874, 882 (10th Cir. 1997) ("We note that in a broad sense, summary judgment in antitrust caes should be used sparingly"). The Supreme Court has again stated recently that mere economic theory alone, in the absence of factual proof, will not support summary judgment. See Eastman Kodak Co. v. Image Technical Svcs, 504 U.S. 451, 471-478, 112 S.Ct. 2072, 2084-88 (1992). Especially here -- where Microsoft suggests pro-competitive reasons for its conduct -- the Court should allow these issues to be explored at trial.(3) "The question of whether a restraint promotes or suppresses competition is not one that can typically be resolved through summary proceedings. Rather, resolution must await a full-developed trial record. This is also particularly applicable in cases of novel antitrust claims." Ratino v. Medical Service, 718 F.2d 1260, 1268 n. 23 (4th Cir. 1983).
Caldera's evidence, and all reasonable inferences to be drawn therefrom, places sharply at issue the credibility of Microsoft employees who would explain away all difficulties in contradiction to, or in the absence of, contemporaneous documentation. As explained below, "the record reveals the existence of many unresolved questions of motive, intent, credibility, demeanor or issues of material fact that justify proceeding to trial." C. Wright, A. Miller & M. Kane, supra, 2732 at 312.
1974-1981: THE ERA OF PERSONAL COMPUTERS BEGINS
1. By the early 1970s, such companies as IBM, DEC and Xerox had developed single-user computers. None, however, were marketed to the general public, and each cost more than a luxury car. S. Manes & P. Andrews, Gates at 65. That changed in January 1975, when Popular Electronics announced the "World's First Minicomputer Kit to Rival Commercial Models." Id. at 63. The Altair 8800 -- a build-your-own kit available for $500 from MITS, Inc., of Albuquerque, New Mexico -- was a hit. Orders flooded in from enthusiasts and hobbyists. Id. at 63-67. See generally Exhibit 4 at 7-8 (History of the Microcomputer Revolution).
2. When the first "killer application" shipped in 1979 -- VisiCalc, an accounting spreadsheet -- corporations and small businesses began purchasing personal computers in large quantities. IBM took notice. By 1980, it was planning to enter this new market -- desktop personal computers -- with a model of its own offering more power, features and functionality. A new industry had begun. See Exhibit 4 at 14-15 (History of the Microcomputer Revolution).
Early Days of Digital Research Inc. and Microsoft Corp.
3. Digital Research, Inc. was founded in 1976 to pioneer the development of operating systems suitable for use on microprocessors (the central processing unit, or CPU) of what are today known as personal computers. DRI's founder and chairman, Gary Kildall, held a Ph.D. in Computer Science. In 1973 he developed a program called CP/M (Control Program for Microprocessors), which was one of the first operating system programs for personal computers. Williams Decl. at 3; see generally Exhibit 4 at 11-12 (History of the Microcomputer Revolution); Exhibit 5 (Chronology of Events in the History of Microcomputers).
4. CP/M quickly became the dominant operating system in the market for 8-bit personal computers in the late 1970s and early 1980s. See D. Ichbiah, The Making of Microsoft at 50-52. During this time DRI enhanced CP/M to optimize its capabilities for 8-bit microprocessors and created a family of CP/M based operating systems. Driven by the strength of CP/M products, DRI's revenues grew to over $54 million in 1984. Williams Decl. at 3; see Exhibit 13 (DRI Business Plan, August 1987).
5. Bill Gates and Paul Allen were intrigued by the Popular Electronics issue announcing the Altair 8800. They wrote MITS that they had a version of BASIC (a programing language) written and ready to run. No such code existed, but when MITS expressed interest, Gates borrowed from and quickly adapted DEC's RSTS-11 BASIC-PLUS. Gates at 70-71. MITS bought it. In short order, Gates dropped out of Harvard; he and Allen moved to Albuquerque; and by mid-1975, they formed Microsoft as a partnership. Id. at 82-84; Exhibit 5 (Chronology of Events in the History of Microcomputers).
6. Microsoft's initial focus was on programming languages, which required an underlying, compatible operating system. Microsoft chose the emerging standard, CP/M. The Making of Microsoft at 52. Gates visited Kildall in November 1977, and obtained a license for $50,000 cash. Gates at 120, 138.
7. In July 1980, IBM contacted Microsoft about IBM's undisclosed plans for a personal computer, and asked Microsoft to design compatible 16-bit versions of its most popular products: BASIC, COBOL, FORTRAN, Pascal and the BASIC compiler. Gates at 151-154. But IBM still needed an operating system. DRI was already planning a 16-bit version of CP/M, called CP/M-86. Microsoft had obtained a preliminary version, but had no right to sub-license. Id. at 154. Gates told IBM to contact Kildall. Exhibit 4 at 15 (History of the Microcomputer Revolution). IBM and DRI were unable to agree on terms for a CP/M license. Exhibit 330 (Kildall 11/13/92 letter).
8. Microsoft moved quickly to "design" an operating system for IBM. Tim Paterson, an engineer at a small Seattle-based OEM named Seattle Computer Products, had already designed in April 1980 his own 16-bit CP/M "clone," i.e., it mirrored CP/M's function calls. He dubbed it QDOS -- Quick and Dirty Operating System. Gates at 157. On January 6, 1981, Microsoft licensed QDOS (subsequently dubbed "86-DOS") for $25,000 -- while obtaining a right to sub-license, and without disclosure of IBM's interest. Exhibit 6 (License Agreement). Just prior to launch of the IBM PC in August 1981, Microsoft decided to buy the product outright. On July 27, 1981, Microsoft paid an additional $50,000 to Seattle Computer. Exhibit 7. Microsoft had its DOS, without any original work of its own, for a total price of $75,000.
9. Microsoft gave IBM a royalty-free license, but retained ownership rights to this DOS, which it planned to license to the clone OEM vendors sure to follow the IBM standard. See Exhibit 29. When the IBM PC launched in August 1981, two identical operating systems emerged: IBM offered PC-DOS 1.0 to its customers; Microsoft offered MS-DOS 1.0 to all other OEMs and their customers. Exhibit 12 at MSC00566789, -873) (Paterson interview transcripts); Exhibit 8 (Softalk for the IBM Personal Computer, March 1983, "Tim Paterson: The Roots of DOS").
10. Years later, Kildall's obituary summed up these events succinctly:
Unable to agree to a deal, IBM turned to another small company, Microsoft, for what turned out initially to be a copycat product. Kildall was livid. He said: "Here we were, in good faith, in negotiations with IBM and they came in with a complete rip-off."
Exhibit 428 (The Guardian, July 20, 1994)
Return
Table of Contents
11. The links from CP/M to QDOS to MS-DOS 1.0 are well-recognized. See Ivie Report at 34-36. Kildall noted that DOS "mirrored the 'de-facto industry standard' CP/M interface." Exhibit 330 (Kildall letter). The technical treatise Undocumented DOS provides a brief overview, and points to other works mapping the extensive similarities between CP/M and MS-DOS:
There is no question about MS-DOS's large-scale borrowing from CP/M. As Tim Paterson would write somewhat later in "An Inside Look at MS-DOS" (Byte, June 1983), "The primary design requirement of MS-DOS was CP/M-80 translation compatibility."
. . .
So MS-DOS began life as an enhanced clone of CP/M.
Exhibit 401 at 181-182 (A. Schulman, et al., Undocumented DOS) (citing Dr. Dobb's Journal, "CP/M vs. MS-DOS: A Technical Comparison").
See also Ivie Report at 34-36.
12. Microsoft's own programmers have readily acknowledged what was done. Only two people at Microsoft worked on MS-DOS 1.0. Reynolds Depo. at 8. One of them, Chris Peters, later testified when Seattle Computer Products sued Microsoft concerning the purchase of QDOS:
Again, from the programmer's point of view, MS-DOS 1.0 was primarily a clone of CP/M.
Peters Depo. at 12 (emphasis added)
Pascal Martin, product manager for MS-DOS 3.0, also freely admitted in a presentation on DOS history:
When it was first introduced, along with the IBM PC in 1981, MS-DOS Version 1 was basically a 16 bit adaptation of the CP/M operating system.
Exhibit 9 at WS209067
13. Microsoft's clone was up and running, and Microsoft was off and running towards industry domination.
II. 1981-1989: THE STAGNATION OF A STANDARD
14. Because operating systems facilitate program and data compatibility across systems, they are said to exhibit "network effects," a phenomenon where a product's value increases as more consumers use it. These effects lead to the market "tipping" to a preferred standard, making that standard difficult to unseat. Leitzinger Report at 5-6. Due to IBM's imprimatur, PC operating systems "tipped" towards DOS. Microsoft's own economic expert agrees that by 1985, MS-DOS was the standard operating system for personal computers. Schmalensee Depo. at 218-219. No non-Microsoft operating system has since come close to challenging Microsoft's dominant position. Id. at 219-220; see Exhibit 447.
15. At least by 1988, Microsoft's MS-DOS had secured a monopoly in the DOS market. See Kearl Report at 11; supra, at 2 fn. 2. With monopoly came complacency and stagnation. In November 1989, Gates told his top DOS developers:
While DOS continues to be our most important and most profitable product over the last four years we have done very little with it technically.
Exhibit 38 (emphasis added)
16. Microsoft abandoned product innovation, and put little effort into improving MS-DOS. By late 1987, industry criticism of the DOS platform noted the neglect:
Though still the dominant operating system for personal computers, MS-DOS is a dinosaur. By not adapting to the changing needs of program developers and users, DOS has become a dead end on the evolutionary path and is headed for extinction. It's played out, unfixable, and hopelessly inadequate for supporting the applications of the 1990s.
Exhibit 14 (PC Magazine, September 29, 1987)
Return
Table of Contents
III. APRIL 1987-MAY 1990: ADVENT OF DR DOS
17. A dynamic new leader, Dick Williams, took the helm DRI on January 5, 1987. Prior to Williams' arrival, DRI had been approached by several OEMs who, unhappy with MS-DOS and Microsoft's control of the operating system market, had urged DRI to develop a competing product. Within 30 days of taking control of the company, Williams had begun the development of DR DOS. Williams Depo. at 23-26.
18. John Constant, a DRI engineer in Hungerford, England, began development of DR DOS using an existing DRI product, Concurrent DOS.(4) Constant did no "reverse engineering" of MS-DOS. Rather, he built upon the DOS compatibility DRI had already developed in Concurrent DOS. Constant Depo. at 8-10, 22-23.
19. DR DOS 3.31 launched in May 1988. The industry greeted the arrival of DR DOS with great expectations. On June 14, 1988, PC Week gave the first report on DR DOS:
Digital Research Inc. (DRI), which formerly ruled the operating system world with its CP/M, is planning to take on Microsoft Corp. in the lucrative DOS market with DR DOS, its single-user offering compatible with MS-DOS 3.3.
. . .
Analysts and potential customers said an alternative to Microsoft's DOS could result in cheaper PCs as manufacturers pass on savings and operating-system costs.
Return
Table of Contents
Exhibit 15 (PC Week, June 14, 1988)
20. Microsoft, in its continuing neglect of the DOS standard, had already made a serious mistake. In April 1987, at Spring COMDEX -- the industry's preeminent convention and expo -- Microsoft and IBM jointly announced OS/2, the supposed successor to the DOS standard, which would be available by year's end on IBM's new PS/2 systems. See Exhibit 11 (internal Microsoft newsletter gathering media reports of announcement). This came to be known as the "DOS is dead" announcement.
21. Microsoft and IBM agreed to develop OS/2 under a "Joint Development Agreement," under which Microsoft also abandoned artistic control of the DOS standard.(5) Chestnut Depo. at 11 ("IBM was solely responsible for the development of DOS"); Werner Depo. at 35. Microsoft had approximately 200 developers actively involved in OS/2. Maritz Depo. at 44.
22. The last "pure" Microsoft version of MS-DOS was version 3.21, released at the end of 1985. Chestnut Depo. at 16-17. IBM took the laboring oar with version 3.3(6) and developed version 4.0 "[t]otally on their own . . . ." Id. at 11-12, 16. To clean up some of the bugs in PC-DOS 4.0 and develop MS-DOS 4.01, Microsoft had perhaps two, and at most six, developers working on code. Chestnut Depo. at 12-13; Lennon Depo. at 16.
23. Incredibly, DOS had become so unimportant to both IBM and Microsoft that no external beta testing was even worked into the development of PC-DOS 4.0 or MS-DOS 4.01.(7) Chestnut Depo. at 112-113.
24. Not surprisingly, DOS 4.x was widely perceived by the marketplace to be of poor quality.(8) Bill Gates conceded the point in a memorandum to his executive staff in October 1988:
DOS 4 is a mess to discuss -- bugs, too big, strange shell interface, who wrote it? DOS 4 has a terrible reputation.
Exhibit 18 at X177305
25. Gates reiterated these problems to his top DOS developers in November 1989:
Meanwhile the widespread belief that DOS 4 offers no real benefits, might have bugs, takes more memory and breaks things like redirectors has increased the piracy of DOS and made it more difficult to sell. People selling DOS add-ons have been doing excellent business. DR DOS is "as good as" our DOS so we get into purely price oriented negotiations.
Exhibit 38
26. The industry understood that, while Microsoft got behind OS/2, MS-DOS "was a -- sort of a dying product." Chestnut Depo. at 66.
27. Within one year of entry into the market, trade press concluded that DR DOS was better, faster and cheaper than MS-DOS, and was fully compatible with applications that ran on MS-DOS. PC Week reported on May 8, 1989:
DR DOS is 100 percent compatible with IBM's PC-DOS and Microsoft Corp's MS-DOS versions 3.x and later, but includes several features not present in those systems and costs OEMs two-thirds less, analysts say. . . .
"DRI is making big inroads with DR-DOS," said Fred Thorlin, an analyst with Data Quest.
"DR-DOS is important -- it is the first successful DOS clone and its success shows DOS is becoming a commodity," he said.
"Digital Research produced DOS the way it should have been done in the first place," said Paul Colvin, a computer consultant with PC Technologies Inc. in Los Angeles and a DR-DOS user. "It's a much cleaner, faster system than MS- and PC-DOS, and its cheaper."
Exhibit 25 (PC Week, May 8, 1989) (emphasis added)
28. Microsoft's internal evaluations confirmed that DR DOS was a strong competitor to MS-DOS. An April 1989 internal report titled "DOS and Windows Monthly Summary" reported:
Initial consensus from DOS program management is that DRI has a product which competes very favorably against MS-DOS.
Exhibit 26 at X568281
29. Mark Chestnut reported in November 1989 to Microsoft executive staff:
DRI offers "DR DOS," a DOS 3.3-level clone which offers some nice utilities and enhancements over and above standard DOS 3.3. DRI currently markets an OEM version of the product and competes mainly on the basis of price.
Exhibit 37 at X517297
Return
Table of Contents
Microsoft Realizes Its Mistake
30. Even Bill Gates viewed DR DOS as a serious competitive threat. He wrote to his executive staff on November 29, 1989, that "DR DOS is 'as good as' our DOS . . ." Exhibit 38. More importantly, Gates and Microsoft realized the need to wrest back control of future DOS development from IBM. See Chestnut Depo. at 13-15. On December 1, 1989, in a letter to Jim Canavino of IBM, Gates made the case to take back control of the languishing DOS development:
I think we have a great opportunity to kick off our move to single site development with DOS. We currently have versions 3.3 and 4.0 in the market. 4.0 was developed at IBM and was received poorly in the market. It was buggy and much larger than 3.3 (17K).
Working together to put together a DOS plan has been particularly frustrating for our team, and probably yours, since DOS gets little joint management attention. DOS remains the backbone though of both of our software businesses. It is under extreme attack by high quality clones like DR DOS. I think we can ease the frustration, cut resources, and most importantly improve DOS by moving now to single site planning and development here in Redmond.
Exhibit 39 (emphasis added)
31. By this time, Microsoft realized it had made a serious mistake -- PC users preferred DOS. At the launch of MS-DOS 5.0 on June 6, 1991, the outline for Bill Gates' MS-DOS 5 presentation contained the following slide and speaking points:
Customers won't easily abandon a standard
* Don't force them to make changes
* Don't ignore the importance of the standard
We thought OS/2 would replace MS-DOS. We were wrong.
We got distracted and didn't pay enough attention to the DOS standard.
The marketplace told us that it likes DOS, likes the benefits of the open DOS standard and told us that we should invest in moving the standard forward.
(This is the humble billg part.)
Exhibit 134 at MS5008500
32. Steve Ballmer had made a similar concession during a prior presentation at an OEM briefing on October 2, 1990:
When we introduced OS/2 back in 1987, we were on a replacement strategy. OS/2 would replace DOS. We gave speeches in which the only question was, "would OS/2 outsell DOS in 1990 or in 1991?" . . . We recognize that OS/2 will not replace DOS, not in the foreseeable future. Rather, OS/2 needs to be part of a family of operating systems that is upwardly compatible from DOS.
Exhibit 84 at X174606-607
33. What forced Microsoft to recognize its error in writing a premature obituary for DOS is simple: entry of DR DOS into the DOS market, and particularly, the innovations of DR DOS 5.0 in June 1990.
Monopoly Maintenance: Choosing the Weapons
34. Although Gates had abandoned MS-DOS in 1987 in favor of OS/2, he was soon aware of DR DOS and the revenue threat it posed to Microsoft. In October 1988, he wrote his executive staff:
DR-DOS: I expected to hear we had more of a problem with this. Apparently, we still haven't lost a lot of business. I want us to track this very closely.
Exhibit 18 at X177309
As outlined hereafter, Microsoft undertook a series of anti-competitive tactics designed to remove competition to the MS-DOS monopoly.
Resistance is Futile -- Prepare to be Assimilated
35. Initially, rather than deal with the threat of competition, Microsoft attempted to pay off DRI to exit the market.(9) In December 1988, Steve Ballmer and Dick Williams both attended a conference in England. Ballmer spoke privately with Williams, and stated Microsoft was "concerned about the MS-DOS 'standard.'" Williams Decl., 69. Ballmer proposed that DRI sell MS-DOS instead of DR DOS, and that each company license rights in the other's product. Id. Ballmer confirmed this meeting and proposal in his deposition. Ballmer Depo. at 43-51. An entry in Russ Werner's monthly report for December 1988 stated:
Steve Ballmer had a promising discussion with DRI re: them licensing MS-DOS vs. competing with us. Steveb will follow-up with Joachimk.
Exhibit 19 at X149435
36. Joachim Kempin, Microsoft's worldwide director of OEM sales, testified as to his follow-up meeting in January 1989 with Williams:
We basically offered DRI a certain amount of money for the use of [DR DOS] technology, and we proposed to them that instead of taking money that we would license the MS-DOS so that they could resell MS-DOS.
Kempin Depo. at 122
In essence, Microsoft was "trying to buy technology" it did not have. Id. at 125.
37. DRI was not interested in a long-term relationship with Microsoft, and so offered the DR DOS technology to Microsoft for $30 to $40 million. Kempin Depo. at 123-124. Microsoft refused to consider paying so much cash, and DRI walked away. See also Williams Decl., 71-73.
38. Within six months of the release of the initial version of DR DOS, Gates was directing his development staff to identify ways Microsoft applications could break DR DOS. On September 22, 1988, he had the following exchange:
You never sent me a response on the question of what things an app would do that would make it run with MSDOS and not run with DR-DOS. Is there any version check or api that they fail to have? Is ther feature they have that might get in our way? I am not looking for something they cant get around. I am looking for something that their current binary fails on.
This is a fairly urgent question for me and I have received nothing.
Exhibit 16 at X565988 (emphasis added)
39. Gates received a reply that day from Phil Barrett -- a top DOS and Windows developer -- that DR DOS approached perfect compatibility:
Here follow the three "differences" (between DR and MS DOS) that Aaron has been able to find so far. Except for these differences, the two OSs behave similarly, including undocumented calls.
The bottom line is that, given Aaron's current findings, an application can identify DR DOS. However, most apps usually have no business making the calls that will let them decide which DOS (MS or DR) they are running on.
Exhibit 17 (emphasis added)
40. Microsoft has been unable to produce copies of the Korean versions of their application software from this time period. Even so, evidence in the record suggests that -- consistent with Gates' directive -- Microsoft coded "software locks" into several of its Hangeul (Korean) applications, including Word, Works, and Excel. Dixon Depo. at 40-41. Caldera continues to seek copies of this software from third party sources. What is clear, however, is that Phil Barrett continued to think about Bill Gates' directive to find ways to "break" DR DOS. Barrett would have his chance with Windows 3.1. See infra, 245 and 251.
Warning Messages and Other Scare Tactics
41. DR DOS did not infringe MS-DOS, and Microsoft never made such a legal claim. Nonetheless, in Korea -- a country where OEMs early on considered DR DOS favorably -- Microsoft told OEMs in "open forum seminars" that "DR DOS was a copy of MS-DOS, and anybody that used that product would be sued by Microsoft." Dixon Depo. at 349-350. Microsoft confirmed this explicit verbal threat with veiled threats from its attorneys. Id.; see also Exhibit 40.
42. Apart from pure intimidation, Gates early on decided that Microsoft products should test whether DR DOS was running. If so, he wanted the user warned about using DR DOS instead of MS-DOS. He wrote on February 8, 1989, in a memo to his executive staff:
11. DR DOS
I want to make sure we get the message implemented in all our product. Languages are important. Windows is important. Applications are important. How can we spread the message about getting this done including the localized versions? (I guess we have to localize this message!) Russ--please let me know your action plan for this.
Exhibit 22 at X155957
See Gates Depo. at 95 (the "message" under consideration was "whether to indicate that somebody was running an untested configuration and whether to just notify them of that fact").
43. Within three months, Microsoft products were shipping with the "DOS clone check" warning message dictated by Gates. In May 1989, Mark Chestnut -- Microsoft's MS-DOS product manager -- reported:
DRI Competitive Response
The first MS product with the non-tested DOS warning code, Quick Pascal, was released. Tom Reeve and Cindy Kasin have committed to implementing it in all new MS application and language releases from this point forward, including international.
Exhibit 28 at MSC00474987
See generally Werner Depo. at 161-163.
44. By August 1989, the "DOS clone check" was being implemented on foreign versions of Windows, as evidenced by this message from the Microsoft Korean subsidiary:
Bill Gates ordered to all application business units to include checking routines of operating environments and if it is Microsoft DOS, nothing will happen. But if it is non MS-DOS (such as DR-DOS), application will display messages saying that "This application has been developed and tested for MICROSOFT MS-DOS. Since you use different environment, this application may not work correctly. . . ."
The question from MSCH is "How to check the DOS is MS-DOS or clone". MSCH wants to include such routine in Hangeul Windows so that Hangeul windows can run only Hangeul MS-DOS. Could you tell me to whom I can ask to resolve this problem?
Exhibit 30 (emphasis added)
45. When confronted with this document, Gates testified that no such check or message ever occurred. Gates Depo. at 136 ("We did not put that code into Windows"). Gates' testimony was not true. At least one Korean Windows version from this era contains this warning:
Hangeul Windows 3.0 should be executed on Hangeul MS-DOS.
For correct execution, please run on Hangeul MS-DOS.
Press any key to continue.
Harris Decl., 2-4
46. A similar DR DOS detection and warning was implemented in QuickPascal, Microsoft's implementation of the Pascal programming language. The QuickPascal message stated:
WARNING: Microsoft QuickPascal has been tested for use only with the MS-DOS and PC-DOS operating systems. Your use of this product with another operating system may void valuable warranty protection by Microsoft on QuickPascal.
Exhibit 20 at X0594692 (source code)
Other language products such as Microsoft QuickC, Programmers Workbench, and C 6.0 Setup had a similar message. Exhibit 401 (A. Schulman et al., Undocumented DOS). Russ Werner -- MS-DOS product manager at the time -- admitted to developing the message with assistance of Microsoft legal counsel. Werner Depo. at 168-169.
47. Regardless how widespread the ultimate implementation, Microsoft gained valuable experience in tactics designed to give the perception of shortcomings in DR DOS where none, in fact, existed. When working the AARD code into Windows 3.1 beta in November 1991, Microsoft elaborated on these lessons to create a false perception of DR DOS incompatibility. See infra 223-242.
Propaganda: Fear, Uncertainty and Doubt
48. Imperfect information and expectations play an important role in market perceptions of software products. Because compatibility is an essential requirement of competitive operating system offerings, market perceptions about that compatibility are vital to the product's market acceptance. Public statements that serve to raise "fear, uncertainty and doubt" (FUD) serve to alter all-important perceptions of compatibility. See generally Leitzinger Report at 19-20. As Microsoft' own personnel concede, the purpose of a FUD campaign is to raise an artificial barrier to entry by a competitor, by introducing and maintaining inertia in the decision-making process. Freedman Depo. at 64-65.
49. Microsoft was well aware of the potency of a FUD campaign. When closing a license with Acer in September 1989, Jeremy Butler played the FUD card to great effect against DRI, when explicitly pandering to the fears of an OEM:
It only takes a couple of reports about non-compatibility to give the kiss of death to a PC: we've seen that on the hardware side as well in as the operating system area.
Exhibit 34
50. Microsoft began pulling together "bug sheets," detailing supposed problems with DR DOS, to distribute to OEM account managers. On April 12, 1990, Bob O'Rear distributed to the domestic and international OEM sales force "a current list of known compatibility problems with DR DOS." Exhibit 45. The expectation was that OEM sales representatives "would use that information as they saw fit in competitive situations." Chestnut Depo. at 33. The bug sheet gives the appearance of instances of 100% incompatibility, as opposed to any qualification for possible work-arounds or whether system configuration contributed to the supposed problem. See generally Ivie Report at 19-21. Microsoft's many subsequent "bug sheets" would suffer this same, misleading defect. See infra 121, 125, 274, 385.
51. These FUD techniques would be refined and dramatically expanded following the launch of DR DOS 5.0. See infra 119-129, 265-280, 383-386. Indeed, in the era prior to DR DOS 5.0, Mark Chestnut -- product manager for MS-DOS 5.0 until November 1990 -- disagreed with tactics of "taking what you perceived to be a minor bug and trying to make a big deal, a big story out of it." Chestnut Depo. at 26; see also id. at 34-35. He also specifically killed a PR initiative to do "some kind of a systematic editorial calldown" because "[w]e didn't think that was appropriate." Id. at 38-39. Chestnut's successor in November 1990 -- Brad Chase -- was not so similarly restrained.
Exclusionary Licenses: The Shape of Things to Come
52. DRI made inroads almost immediately into several substantial, heretofore unchallenged Microsoft accounts. See, e.g., Exhibit 23 (Intel). This provoked Microsoft to consider ways to leverage its dominance in the OEM channel(10) to exclude DRI through its licensing agreements. See Appendix C.
53. The DR DOS threat drew the personal attention of Bill Gates at this stage of the game. He was personally involved in negotiations to keep DR DOS out of Microsoft accounts, and was intimately aware of the price erosion caused by DR DOS. For instance, when moving to close a license with Acer in September 1989, Gates talked with Acer's president, Stan Shih, and sent this directive to Microsoft's account managers:
Stan said if we did a special price for this it would not affect the diskette price so please do our best. I said all we are asking for is a chance to quote to thes people and avoid acer becoming the first real company to license DRDOS. He said fine he would make sure that happened.
Exhibit 33 (emphasis added)
54. Gates began thinking about how to protect Microsoft's DOS monopoly, with particular emphasis on the emerging power of its Windows graphical user interface. On May 18, 1989, Gates sent a memo to his executive staff specifically addressing "Operating Systems Strategy," and specifically noted his concern about falling revenue:
The DOS gold mine is shrinking and our costs are soaring -- primarily due to low prices, IBM share and DR-DOS. Making Windows a strong product benefits our gold mine and protects it in the following ways:
DR DOS. I doubt they will be able to clone Windows. It is very difficult to do technically, we have made it a moving target and we have some visual copyright and patent protection. I believe people underestimate the impact DR-DOS has had on us in terms of pricing.
Exhibit 27 at MS0048937 (emphasis added)
55. By August 1989, Gates began to think about a way to increase profits for every machine shipped by any OEM -- a definite precursor to per processor licenses. On August 6, 1989, in an e-mail directed only to his top lieutenant, Steve Ballmer, Gates wrote:
Basicly last year (I may get the numbers wrong) it was around $180M worldwide PROFIT. Assuming 12m machines thats $15 PROFIT per machine or giving IBM 1/3 of the market (a little high) $22.5 per non IBM machine. We have to drive that number up to around $45. . . . This means the price we can charge for windows will drive a lot of our future. Now how can we get this doubling per system thing to take place.
First, we have to make sure windows isnt easy to clone for both technical and legal reasons. Who is smart that thinks about this -- patents and such. I can do it at some point and I think we will be able to achieve it. DOS being fairly cloned has had a dramatic impact on our pricing for DOS. I wonder if we would have it around 30-40 % higher if it wasnt cloned. I bet we would!
Exhibit 29 (emphasis added)
56. In his memo of May 18, 1989, Gates had also challenged his senior managers to leverage Microsoft's use of the OEM channel to license MS-DOS:
5. OEM channel. Per system money from the OEM channel is the only proven way to make lots of money. It avoids worrying about copying, COGS [cost of goods sold] and end user marketing. We are good at it.
. . .
Of course, even a 20% increase would bring down over $30M to fund our increasing systems development costs.
Exhibit 27 at MS0048940-941 (emphasis added)
57. Joachim Kempin, worldwide director of OEM sales, was uniquely well-situated to know that despite its lack of innovation, Microsoft's DOS monopoly had permitted it to maintain a steady price -- notwithstanding a rapid decline in price for all other components of the personal computer. See Kempin Depo. at 41-42. Thus, in addition to searching for a way simply to exclude DR DOS and the erosion on price that competition there entailed, Microsoft was searching for a way to maintain higher prices even in the absence of innovation. On February 9, 1990, Kempin summarized current thinking on the issue:
OEM Pricing
The Manufacturer's View
OEM manufacturers are increasingly sensitive to added costs. The PC being a commodity and most OEMs not creating enough differentiation. PC pricing has become a dominant factor to gain market share. OEMs are pressuring us more and more to accept the fact that operating system software needs to follow their economy for scale model. Expressed in % of SRP per, today we are asking for 2-3 times as much money for MS DOS as we did 5 years ago.
The Microsoft View
Prices for MS DOS have been kept fairly unchanged over the last 4 years, not counting the undoing of some flat fee contracts. . . . If we cannot improve DOS significantly, the price eventually has to come down and follow the OEM pricing model.
Exhibit 42 at X581007 (emphasis added)
More significantly, Kempin also identified the possibility that Microsoft might use licensing tactics to require OEMs to pay a fee to Microsoft for every computer sold -- with or without MS-DOS:
If we could keep DOS prices constant and make all manufacturers pay for DOS, even for OS/2 systems, our upside would be approx. 100M$, yielding us $35.8 per system sold. A dream, no a challenge for OEM Sales and System Product Marketing to manage OS/2 and DOS pricing!
Id. (emphasis added)
58. Microsoft suggests that the per processor license -- a licensing scheme under which OEMs paid Microsoft a DOS royalty for every computer shipped regardless of whether the machine contained MS-DOS -- was originally dreamed up "in the late 1980s at the request of OEMs who wanted to simplify the administration of their per system licenses." Licensing Memo at 3. Microsoft cannot get its story straight, however. Bill Gates testified per processor licenses were first suggested by a Taiwanese OEM (Acer), who brought it up in his presence at a meeting in Taiwan. Gates Depo. at 43-44. Joachim Kempin testified it was Tandy in 1989. Kempin Depo. at 143-144. Microsoft's general counsel, Bill Neukom, in answering questions posed by the Korean Fair Trade Commission in 1992, contended the practice began in February 1990 at the request of two U.S. OEMs. Exhibit 276.
59. Fortunately, "when" and "where" the per processor license was first instigated is ultimately irrelevant. The Court will be well aware later in this brief that -- even if an OEM originally thought of the per processor license -- Microsoft implemented it as a primary method to exclude DR DOS. See infra 130-143, 299-306, 387-390.
60. Before attaining monopoly power in the GUI market(11) with Windows, Microsoft simply coaxed OEMs into accepting licenses excluding DR DOS by offering an attractive bundled price for MS-DOS and Windows together. For instance, DR DOS was identified early on as a threat in the Vobis account, which was a large German OEM. The Microsoft OEM status report for November 1989 states:
Also, they [Vobis] are interested in having Windows 3 on their computer systems as soon as the product is released. At this time we still offer DOS and Windows on per system level. If there is any danger we will offer the DOS/WIN combo license.
Exhibit 35 at X0596447 (emphasis added)
61. Alternatively, Microsoft would negotiate more favorable minimum commitment packages(12) for DOS and Windows combined, as opposed to Windows in the absence of MS-DOS. For instance, when closing a license with Acer in November 1989, where DR DOS was a threat, Jeff Lum proposed crediting some prepaid moneys on MS-DOS (also known as unspecified product billings, or UPBs) which might be lost, to its new Windows contract -- in short, a price break on Windows:
If we want to attract them using UPBs, we could apply some of the UPB to the new Windows license that is about to be signed which has a totally separate min commit schedule. Pros: this will be attractive to them since it will decrease their cash flow to us. Cons: we will get less NEW OEM revenue for FY90 by doing this.
Exhibit 36 (emphasis added)
62. After Windows 3.0 launched, and Microsoft found Windows becoming a standard, what once was a carrot became a stick. See infra 110-116, 281-284.
Dreaming of The DOS/Windows Merge
63. Although Windows 95 was still years away, Microsoft was already dreaming of a way to physically tie Windows to MS-DOS. As Caldera will demonstrate elsewhere below, Windows 95 is not an operating system built from the "ground up" like OS/2 or Windows NT, but is simply the fusion of an updated version of MS-DOS and an updated version of Windows. See infra 320-340, 391-401, 414-418.
64. The record of the decision to offer these two products together in a single box traces back prior even to Microsoft's OS/2 gambit. An interview transcript of Bill Gates from around 1986 states:(13)
Q. The future?
A. Well, you can't really say too much about the future. We always say . . . we believe in graphics user interface, but the way the graphics user interface works, you don't just want to throw it into DOS one day all of a sudden and say everybody's gotta have this if they want the next new version of DOS. It's an evolutionary thing, where some people realize they want it, and some won't, so you know, Windows we've done as an extension of MS-DOS that's optional. We can improve the buffering and the networking and stuff like that and still Windows just sits on top of it. If Windows ever gets to the point where 90% of the people are using it, then maybe we'll just stick it together and call it one product. . . . For now, we've decided to be flexible about that.
Exhibit 10 (emphasis added)
65. At every point when Microsoft considered merging MS-DOS and Windows into one product, the issue was always how best to foreclose other competitive markets. On May 8, 1989, Nathan Mhryvold -- Microsoft's principal technical strategist -- wrote the Microsoft executive staff about plans for a "Dos/Win merge," and noted:
Benefits
The good points of this approach are:
--The MONEY! This obviously will give tremendous systems revenue.
-- It also should give great apps revenue -- this is something like a 5X-10X increase in the total number of platforms on which we can sell our apps. Our success may not be completely linear in the market size, but it sure helps.
Those two are huge and obvious wins, and are the main reason to do this. The strategic side is:
. . .
--We put a bullet in the head of our would be competitors on Dos like DRI, Desqview, dos extenders etc.
Exhibit 24 at MS5001654 (emphasis added)
66. Mhryvold suggested no technological benefit -- in fact, his memo recognized extensive problems with the "merge," including how to convince OEMs to accept it, and whether the bundle could be coded to overcome poor quality. Id. Still, cash and bullets became a tempting reward.
67. As late as August 1989, Microsoft was planning to implement Mhryvold's idea. In a memo to the executive staff on August 15, 1989, Kempin wrote:
As I understand the release of WIN 3.0, available at the end of CY 89, will be a superior product and create exciting APPS-ISV momentum. This core product will be merged with DOS 4.x and made the standard OS/1 (?).
. . .
During the transition time from DOS and separate WIN 3.0 to OS/1 we will have to cease retail distribution of stand alone WIN 3.0 completely.
Exhibit 31 at X517570-571 (emphasis added)
Gates had previously suggested renaming the merged DOS/Windows product as "OS/1." Exhibit 27 at MS0048939.
68. Windows 3.0 ultimately launched in May 1990 without any forced bundle from Microsoft explicitly tying it to MS-DOS. A "Rude Q&A" prepared for the launch of Windows 3.0 contained an interesting talking point:
Q10. Are you going to merge DOS and Windows?
A10. We expect that some OEMs will bundle Windows with DOS, which is effectively a merge.
Exhibit 48 at X531048
With Windows 95, Microsoft merged MS-DOS and Windows, and OEMs no longer had a choice whether to bundle them.
69. In its first year of sales, DR DOS showed strong growth, especially in the OEM channel. DRI's management report for the fiscal year ending August 31, 1989, recorded the quick progress achieved by DR DOS:
General purpose operating systems (GPOS) revenues grew 43% from 1988. This included significant growth through OEM channels (62% over 1988) atrributable primarily to DR DOS. The company expects a minimum growth rate of 24% in 1990 as new functionality is provided with DR DOS and it gains even more widespread OEM acceptance worldwide.
Exhibit 32 at C0956284
Importantly for DRI, DR DOS's emerging sales success was taking shape with OEMs all around the globe. See id. (U.S. OEM growth of 46%; license of 1 million copies to Pacific Rim OEMs; European OEM sales for 1989 outstripping 1988).
70. Gates noticed the encroachment, noted the declining market share, and saw his revenue base eroding. See supra 30, 53-56. By the close of 1989, Gates had made his decision on how to handle the threat: Microsoft would take back control of the DOS standard from IBM. Exhibit 39. Microsoft knew well the weapons it had at its disposal as it laid future plans for MS-DOS.
IV. MAY 1990-JULY 1991: DR DOS 5.0, THE REAL COMPETITION BEGINS
71. By the late 1980s, PC users' two biggest complaints were, first, not enough memory, and second, limitations on "logical" hard disk size. The problem lay not in the hardware, but rather in DOS's inability to take advantage of increased memory size and increasingly large disk drives. Many popular and valuable software programs simply did not have enough room to be loaded on PCs with standard memory limited by DOS constraints, and users frequently complained of seeing the message, "You don't have enough free memory to run [your application]." Users faced a similar problem with hard disks. Disks larger than 32-megabytes were available, but since DOS could not recognize anything larger than a 32-megabyte disk, the new larger disks had to be "partitioned" into several drives, which created real problems for users. See Goodman Report, Exhibit C.
72. Despite the fact that users had been complaining about these problems for years, neither IBM nor Microsoft gave any indication that they were interested in, or planning on, resolving these issues for users. As such, the release of DR DOS 5.0 in June 1990 -- a product which solved these problems, and included numerous other improved functionalities as well -- was considered a breakthrough. Not only did the product include memory management and expanded disk drive capabilities, but it also included such other features as on-line help; the ability to sort file directory listings in a number of ways; a file transfer utility; and a very easy-to-use setup program to install the product. See Goodman Report, Exhibit C.
73. MS-DOS provided none of these features in June 1990 when DR DOS 5.0 shipped. See Appendix B. Comparable features in MS-DOS did not appear until one year later.
74. DRI recognized that DR DOS 5.0, code-named "Leopard," had a feature set clearly superior to MS-DOS. The DR DOS 5.0 Launch Plan recognized this critical moment in the product's and the company's life:
The Leopard launch marks the first time that DR DOS can truly compete head-to-head with Microsoft. . . . In order for Leopard to have a bright future, it is necessary to immediately exploit our product superiority and gain name recognition. This is our opportunity and we must take advantage of it.
Exhibit 43 at C0726133
75. Microsoft realized, too, that it was in the uncomfortable position of playing catch-up. It embarked on a series of anti-competitive tactics to deny DRI the revenue that should have flowed from DR DOS 5.0. See infra 83-154.
Awards, Praise, and Compatibility
76. Formal reviews after the launch of DR DOS 5.0 were overwhelmingly positive:
While Microsoft has been busy showing Windows 3.0 to the world, Digital Research has unleashed DR DOS 5 -- its rival to MS-DOS. . . .
Installation -- excellent
Ease of use -- excellent
MS-DOS compatibility -- excellent
Use of K's features -- excellent
Functionality -- excellent
Value for money -- excellent
*PC USER VERDICT This is the first time I've given any product an all "excellent" verdict, which speaks for itself.
Exhibit 61 (PC User, July 4, 1990)
The latest incarnation of DR DOS, Digital Research's MS-DOS clone, is an innovative and intriguing operating system that's thoughtfully designed. Version 5.0 is also packed with the extra features that Microsoft's own operating system should have (and might eventually have if the long-rumored MS-DOS 5.0 becomes a reality). As the people at DRI make very clear, its not pronounced Doctor DOS, although the analogy isn't far off the mark, since it indeed cures many (but not all) of MS-DOS's shortcomings.
Exhibit 69 (Byte, August 1990)
Compatibility and memory availability claims made by DR DOS 5.0's developer, Digital Research Inc., are supported by PC Week Labs' recent evaluation of the operating system, which was shipped in June.
Exhibit 71 (PC Week, August 13, 1990)
DR DOS 5.0 is an almost-perfect superset of MS-DOS 3.3 and 4.0. In the course of a normal day's work you probably wouldn't notice any difference between how you'd interact with MS-DOS or DR DOS. I found no compatibility problems with a broad selection of applications including several word processors, programming tools, debuggers, TSRs, DOS extender applications, 3Com network software, the various Norton Utilities, and (to my surprise) Windows 3.0.
Exhibit 78 (PC Magazine, September 25, 1990)
OPERATING ENVIRONMENTS
. . .
FINALISTS
DR DOS, Version 5.0
Digital Research is the microcomputer operating system company that predates Microsoft. As if to prove it hasn't lost its touch, DR DOS 5.0 does all the things you wish MS-DOS did. Its features include . . . full compatibility with MS DOS. . . . Everybody's DOS should be this advanced.
Exhibit 106 (PC Magazine, January 15, 1991)
No one is going to try a different DOS, regardless of the features it contains, if it does not run the applications already installed. DR DOS 5.0 meets that challenge. PC Labs' testing shows that for the most part, DR DOS 5.0 is interchangeable with MS-DOS. In fact, DR DOS 5.0 is at least as compatible with MS-DOS 3.3 as MSDOS 4.01 -- probably more so.
DR DOS 5.0 will run nearly any program that runs under MS-DOS, including Microsoft Windows 3.0.
. . .
Compatibility is not an issue with DR DOS 5.0.
. . .
DR DOS 5.0 is a completely competitive operating system built on an aggressive philosophy that promises to force innovation. In a stodgy software world that has changed only reluctantly, this technological breath of fresh air is certainly refreshing.
Exhibit 109 (PC Magazine, February 12, 1991) (emphasis added)
77. DR DOS 5.0 went on to win the Byte Award of Distinction, and PC Magazine Award for Technical Excellence. See Exhibit 105 (Byte, January 1991); Exhibit 106 (PC Magazine, January 15, 1991).
78. Infoworld confirmed that DR DOS 5.0 in fact exceeded MS DOS 5.0, which was released over one year later. Infoworld's review of DR DOS 5.0 yielded an overall score of 7.2, while its later review of MS-DOS 5.0 gave it an overall score of 6.8. Exhibit 130 (Infoworld, May 27, 1991); Exhibit 144 (Infoworld, July 8, 1991).
79. DR DOS 5.0 received endorsement even from within Microsoft itself. On April 15, 1991, Phil Barrett received the following review from one of his subordinates:
Last Thursday you asked me for a user's view of DR DOS 5.0. When I worked for David Weise's brother Ira, I used DR DOS 5.0 with a HUGE number of apps. I found it INCREDIBLY superior to MS DOS 3.31 and IBM DOS 4.01.
1) DOS compatibility
The most important reason to use ANY version of DOS is to run DOS apps. DR DOS 5.0 runs every DOS app I know.
DR DOS 5.0 works successfully with Windows (2.11, Win 386 2.11 and Windows 3.0 and 3.0a).
. . .
CONCLUSION:
DR DOS 5.0 is vastly superior to MS/PC DOS 3.31 and 4.01. It is about as good as MS DOS 5.0. Both have nearly identical features (386/UMB memory management, command history, help included in utilities, format-optional installation, high compatibility with existing DOS apps). I don't see any real 'cutting edge' advantage of one over the other.
Exhibit 123 at MS5061758, -760
80. This was high praise indeed. Microsoft knew it was facing a legitimate and credible threat, and escalated hostilities accordingly.
Monopoly Maintenance: Building the Perfect Beast
81. In May 1991, Microsoft's executive staff attended an annual executive staff retreat. Though perhaps not an explicit agenda item, monopoly maintenance was clearly on everyone's mind, as evidenced by the following presentation excerpt:
On the desktop, we have a strategic win today (monopoly)
We must keep the desktop
Exhibit 50 at X205851
This was not some random thought, but was a presentation by (among others) John Shirley (the outgoing president) and Brad Silverberg (an incoming executive from Borland taking charge of MS-DOS and Windows) made to (among others) Bill Gates and Steve Ballmer. Silverberg Depo. at 26. The direction of Microsoft as a company was discussed at this retreat. Id. at 33.
82. By the time of the Microsoft executive staff retreat in 1991, the focus on defending and extending the DOS market monopoly had sharpened considerably. Microsoft's president, Mike Hallman, gathered for discussion a collection of e-mails from Microsoft's top executives listing their "top ten priorities." The obsession over monopoly power is startling:
Kempin:
Defend our 80%+ DOS market share!
MacIntosh:
Keep and expand the systems "franchise":
a). identify the minimum acceptable DOS penetration (ie. 95%) and absolutely attain it and keep it!
Maples:
Retain leadership in the operating systems market for all desktop systems.
Mhyrvold:
1. Continue to be the dominant mainstream PC operating system standard.
Oki:
Maintain control of the desktop systems platform. DOS is still the gold mine. It is the cash cow that allows us to invest in other potential cash cow businesses.
Silverberg:
*Protect and expand the systems franchise so that Windows is the dominant standard. Windows needs to own both standalone machines as well as client-connected desktops.
There is the potential for the systems market to fragment so that there is no one dominant volume operating system, as there has been for the past ten years with DOS.
Exhibit 110 at MSC0107750, -751, -753, -759, -763, -768
83. Caldera alleges that, beginning with version 5.0 of DR DOS, Microsoft made preemptive announcements of forthcoming, competitive MS-DOS and Windows versions, and that such announcements "were knowingly false or misleading when made." Exhibit 1 at 46 (First Amended Complaint). This practice is commonly referred to in the industry as "vaporware" or "preannouncement." Microsoft does not contest the fact that it made preemptive announcements, or that it shipped its products months or even years after having originally been promised. Instead, Microsoft walks a razor-thin line arguing only that its preannouncements weren't "knowingly false" when made.(14)
84. A bit of background is in order to frame corporate knowledge at the time. Microsoft understood vaporware well. On October 1, 1990 -- five months after Microsoft begins its vaporware campaign against DR DOS 5.0 -- Nathan Mhryvold (in discussing a threat from Sun Microsystems) sent the following memo to the Microsoft executive staff, explaining why and how Microsoft could use preannouncement to crush the demand for a competitive product:
The purpose of announcing early like this is to freeze the market at the OEM and ISV level. In this respect it is JUST like the original Windows announcement. This time we have a lot better development team, so the time between announce and ship will be a lot smaller. Nevertheless we need to get our message out there.
We certainly do need to follow this announcement up with a good demo in 6-8 months when the SDK ships, but preannouncement is going to give Sun a real problem.
Exhibit 83 at X0195819 (emphasis added)
See also Exhibit 21 at X521396 (Mhyrvold, January 5, 1989: Microsoft "preannounced Windows, signed up the major OEMs and showed a demo to freeze the market and prevent VisiOn from getting any momentum. It sure worked -- VisiOn died, VisiCorp died, and DOS kept on chugging.").
85. Microsoft repeatedly suggests that its own internal schedules reflect the "truth" of the preemptive announcements its executives were making. Internal records, however, amply demonstrate that such schedules did not reflect reality. For instance, Windows 3.0 had shipped in May 1990 -- just as Microsoft began its vaporware announcements concerning MS-DOS 5.0. The "Windows 3.0 Post Mortem" contained the following remarkable admissions:
*Set by BillG (upper management) before feature definitions are outlined.
*Problem motivating people to achieve "fake" ship dates.
*Need to be more realistic in our schedules.
*Lying to people on the team about schedules. Morale hit to the team.
*How to separate out development schedules and the schedules we give to other groups (USSMD or upper management) without appearing to "lie" to the product team.
Exhibit 47 at X106462 (emphasis added)
86. The "MS-DOS 5.0 Postmortem Report" similarly reveals a "fake" schedule for MS-DOS 5.0:
Estimating the time required to accomplish any particular task is a skill usually acquired through experience, and with the mostly young DOS 5.0 team, it isn't too surprising that some time estimates were incorrect. However, it did seem at times that individuals were confused about how Program Management intended to use their time estimates. Some individuals produced estimates that represented best-case scenarios, rather than realistic ones, and then were surprised to see their best-case guesses show up on schedule charts. Others felt a lack of trust when they found their estimates questioned by Program Management. Better explanation of the goals and methods of scheduling could have helped clear up some of these problems.
Exhibit 195 at CMS00024709 (emphasis added)
87. With that background, Microsoft's reaction to DR DOS 5.0 is transparent. DR DOS 5.0 caught Microsoft personnel flat-footed. Mark Chestnut -- product manager for MS-DOS 5.0 until late 1990 -- testified that as of November 1989, the plan was simply to release a 4.1 upgrade product in 1990: "I didn't have any expectation that we would have a 5.0 product shipping in '90 after shipping a 4.1 product in '90, at that point." Chestnut Depo. at 82. Indeed, Microsoft had only taken back DOS development from IBM a mere four months prior to the announcement of DR DOS 5.0.
88. On April 1, 1990, Microsoft's preeminent MS-DOS architect -- Gordon Letwin -- posted a message to MS-DOS users "to solicit input from the 'power user' community" on what features and utilities to include in "a major upgrade to DOS." Exhibit 44. Far from a code-complete product nearing entry to market, such posting reveals a nascent version over a year away from shipping. Letwin himself had only recently been recruited back to the MS-DOS team by Bill Gates. Werner Depo. at 106.
89. On April 17, 1990, Letwin contacted Glenn Stephens -- DRI's head of development in Hungerford, England -- to recruit him to Microsoft's DOS team. Stephens Depo. at 322-323. Stephens and Letwin spoke for nearly an hour. Stephens testified:
[M]y impression was they weren't working on anything. Actually one of the things they were asking for me to work on if I went over there was a file system. Since that is a core component of the DOS operating system, to not already have an engineeer assigned to that tells me there is nobody working on it.
Stephens Depo. at 324-325
Stephens knew DRI "had a major leap on what Microsoft were about to do." Id. at 325.
90. On April 26, 1990, DRI announced DR DOS 5.0 at a trade show in England, stating it would be available within 8 weeks.(15) Microsoft immediately preannounced MS-DOS 5.0 to influential trade press, and succeeded in having articles run within one week in PC Week, Infoworld, and Computerworld. Chestnut summarized this (with attached articles) in a memo of May 2, 1990, to Microsoft executives titled "DR DOS 5.0 Competitive Analysis":
Competitive Response to DR DOS 5.0
On the PR side, we have begun an "aggressive leak" campaign for MS-DOS 5.0. The goal is to build an anticipation for MS-DOS 5.0, and diffuse potential excitement/momentum from the DR DOS 5.0 announcement. At this point, we are telling the press that a major new release from Microsoft is coming this year which will provide significant memory relief and other important features. This was picked up by the major weeklies in the U.S. and was the page 1 story in PC Week on 4/30 (see attached articles).
Exhibit 49 at X504358 (emphasis added)
91. Chestnut was quite busy during the two weeks following the DRI announcement. As noted above, he immediately contacted the magazines to leak plans for MS-DOS 5.0. Chestnut Depo. at 118. By April 30, 1990, Chestnut had met with two OEMs (Tandon and AST) to predisclose MS-DOS 5.0 and its supposed availability in September 1990, and to pump those OEMs for feature details about DR DOS 5.0. Id. at 102-103; see also Exhibit 46 (Tandon Meeting Report). By May 4, he prepared a "DR DOS Backgrounder" for the OEM sales force with a "feature comparison" for the vaporous and still-evolving MS-DOS 5.0. Chestnut Depo. at 123, 165-166, 169. OEM sales also received a "DOS 5 presentation with script," i.e., PowerPoint slides and speaking points. Id. at 124. Copies of the slides plainly disclose the product in detail and promise OEM availability in August and September 1990. Exhibit 53.
92. By early June 1990, Chestnut had given presentations in Redmond to three Japanese OEMs (NEC, Toshiba, Epson), and a Taiwanese OEM (Acer), and had trained the Taiwan OEM sales force to go forth and make their own presentations. Chestnut Depo. at 125. He then flew literally around the globe by the middle of June to meet with OEMs in Korea, Taiwan, Germany, England, France, Italy, and The Netherlands. Id. at 127-128. Some of the many OEMs he could recall meeting included Goldstar, Hyundai, Samsung, Olivetti, Siemens, Scion, Alcatel. Id. at 127-129. He met with at least 15 OEMs in Korea, and dozens of others in other countries. Id. The purpose of the trip was to fully disclose MS-DOS 5.0 plans, and to tell them that they could expect MS-DOS 5.0 by September 1990. Id. at 129.
93. Chestnut filed two reports summarizing his trip, and its success in creating enthusiasm for MS-DOS 5.0 among OEMs. Exhibit 56; Exhibit 70. Chestnut testified that his presentations and promised delivery date were of the sort that would prompt reliance by OEMs, and cause them to postpone any decision to move to DR DOS. Chestnut Depo. at 140. He admitted that, if he had promised what turned out to be the actual delivery date of June 1991-- rather than September 1990-- "I'm sure they would have been less excited." Id. at 141.
94. The directive also went forth from Joachim Kempin to the entire domestic and international OEM sales force: fog the marketplace with MS-DOS 5.0 vaporware. On May 14, 1990 -- the day Digital Research formally announced DR DOS 5.0 in the United States -- Kempin wrote:
They are trying to put the heat on us.
We are distributing to You a comparison between MS-DOS 5.0 and their version. Inform Your customers as discussed and keep them at bay.
Exhibit 51 at X570900 (emphasis added)
Kempin testified that, by "keep them at bay," he meant "keep the business with Microsoft." Kempin Depo. at 216.
95. Microsoft did get into the market a rough beta of MS-DOS 5.0 on June 15, 1990. Even before that beta shipped, however, Microsoft knew MS-DOS 5.0 was nowhere even close to a completed product that was competitive with DR DOS 5.0, and that features still had to be added. Chestnut Depo. at 102, 111. At an "MS-DOS 5.0 Plan Overview" given to IBM on the date the first beta shipped, Eric Straub -- one of the key developers on MS-DOS 5.0 -- disclosed:
Currently under consideration:
*Upper Memory Block (UMB) Support in EMM386
*Task switcher (winoldapp)
*File Transfer Utility
Exhibit 55 at MSC00285412
96. The MS-DOS 5.0 Postmortem Report explicitly admits that Microsoft was scrambling to identify and code features responsive to the compelling DR DOS 5.0 feature set:
One of the most important stimulants for adding features was competitive pressure from DRDOS 5.0, which we first learned of in the spring of 1990. The DR DOS feature set led us to add UMB support, task swapping, and Undelete.
Unfortunately, it took us some time to revise our schedules to match the changing product. We adjusted the schedule outward in small increments, and the end dates lost clarity and credibility inside and outside the team.
Exhibit 195 at CMS00024702 (emphasis added)
97. Following the release of Windows 3.0 in May 1990, Phil Barrett was immediately assigned to oversee the coding of MS-DOS 5.0, and basically "to spend a lot of time making dos 5 happen fast." Exhibit 52. His assessment of the team plan was not kind:
The schedules had not been really well thought through. There was a lot of engineering work that had to be done; testing, test plans. There was no beta test plan. There was just a lot of stuff that needed to be done. A lot of activities that needed to be completed in order to ship a product had not even been completed, not even been started at that point.
Barrett Depo. at 140-141.
See also Silverberg Depo. at 84, 92.
98. Notwithstanding this lack of clarity, Microsoft continued to tell the world to expect MS-DOS 5.0 before the end of the year. On July 2, 1990, Infoworld reported:
A new version of DOS that accesses significantly more memory is likely headed for an early release, according to beta testers, but Microsoft will only confirm the product will ship by the end of the year.
Exhibit 58 (Infoworld, July 2, 1990) (emphasis added)
Chestnut testified that he was the source for this story. Chestnut Depo. at 159-161.
99. But by then, even the "DOS 5.0 Plan Overview" (also dated July 2, 1990) indicated that MS-DOS 5.0 was not yet "code complete" -- with only an "actual projected" code complete date in July 1990. Exhibit 59. The next day, the MS-DOS 5.0 team circulated a report indicating a huge number of bugs in the initial beta that had gone out two weeks previously. Exhibit 60. On July 24, 1990, Silverberg submitted his "DOS 5.0 Plan -- Additions since 6/90," and revealed a list of new features still being added, and that both "code complete" and shipment to OEMs had changed to "TBD" -- to be determined. Exhibit 65.
100. Even so, on July 26, 1990, Ballmer gave a presentation to assembled financial analysts and specifically represented that MS-DOS 5.0 would "launch this year throughout the world." Exhibit 66. Ballmer's statement -- directed specifically to financial analysts that Microsoft knew would be reporting these discussions to the world -- was false as proven by Microsoft's own internal records.
101. Beyond this, Microsoft's schedules for MS-DOS 5.0 were of the "fake" variety David Cole had described regarding Windows 3.0 schedules. See supra 85. The MS-DOS 5.0 Postmortem specifically confirmed the schedules "represented best-case scenarios, rather than realistic ones." Exhibit 195. Further, the schedules were objectively unreasonable. Microsoft knew MS-DOS 4.01 was "buggy"; that the next version needed to be "rock solid"; and that it could not risk two poor versions in a row. Chestnut Depo. at 84-85. Microsoft apparently suggests that such a complicated product could be coded and done with beta test cycles in three months (mid-June to mid-August 1990) for release in September 1990. Yet Brad Silverberg, who took the reins in June 1990, immediately surmised this "was not a reasonable beta period." Id. at 174. When crossed with this, Chestnut would only weakly allow: "Answering the question now based on what I know now, I don't think it's realistic that we could have done that." Id. at 104. One of Caldera's technical experts opines that Microsoft's projections were objectively unattainable. Ivie Report at 38.
102. By the end of August 1990, Microsoft knew its tactics were working -- indeed, OEMs were already actually licensing MS-DOS 5.0., over ten months before launch. Exhibit 67. Chestnut's self-evaluation in his performance review for the period ending June 15, 1990 was quite candid: "virtually all of our OEMs worldwide were informed about DOS 5, which diffused DRI's ability to capitalize on a window of opportunity with these OEMs." Exhibit 62 at MSC008000363 (emphasis added); see also Exhibit 94 ("DR-DOS has not yet been able to gain any momentum in Korea. We have slowed them down with consistent seminars on MS-DOS 5.0 . . ."). See generally Goodman Report at 6.
103. By mid-October 1990, media investigators became concerned about Microsoft's veracity in its preemptive remarks directed at DR DOS 5.0. Paul Sherer of PC Week began pressing for interviews. On October 17, 1990, Sherer got through to Chestnut. Chestnut was worried:
I'm afraid that this guy is going to write that we are being open about DOS 5 beta because we are trying to pre-empt DR DOS 5 sales. I tried real hard to present a different point of view, but I don't think he bought it.
I'm concerned that this article may make us look bad. Can you guys follow up and see if we need to do some damage control?
This was the toughest interview I've done, I felt like Richard Nixon giving his "I am not a crook" speech.
Exhibit 87 at X207961 (emphasis added)
104. So concerned was Chestnut about the forthcoming article -- and the need for Microsoft to spin it appropriately -- that he sent this follow-up to Waggener Edstrom PR operatives the next day:
Having thought about it, this is how I would answer today:
. . .
- if we really wanted to pre-empt DR DOS sales, we'd be fully divulging the features of DOS 5, because they do in fact compare very favorable to DR DOS, ie we have all of the features that they offer plus a lot more. However, we have only acknowledged that DOS 5 exists and indicated some general directions, we have not divulged detailed feature info except under nda.
Exhibit 88 (emphasis added)
But in his deposition, Chestnut conceded that the "nda" (non-disclosure agreement) exception he referred to was a gaping hole through which to give OEMs vapor: the purpose of full disclosure of plans to OEMs by him and the OEM sales force was to preempt sales of DR DOS to that OEM, and all of his many travels and presentations in May and June of 1990 were directly targeted at achieving this effect. Chestnut Depo. at 194. See also infra at 314 (NDAs with ISVs and press also a fiction).
105. Paul Sherer's article, "Microsoft Outlines DOS 5.0 to Ward Off DR DOS," appeared in PC Week on October 22, 1990:
Although the release of Microsoft Corp.'s new MS DOS 5.0 operating system is months away, product details are emerging in a steady stream designed to put the squeeze on Digital Research Inc.'s (DRI's) DR DOS 5.0, observers said.
. . .
Microsoft -- in a shift in its policy of not commenting on unreleased products -- has been unusually cooperative in confirming details about MS DOS 5.0.
. . .
"I think they're putting out vaporware to make sure people don't switch," said Bob Berardino, a materials engineer for a Midwest electrical-component supplier and a DR DOS 5.0 user.
Exhibit 89 (Infoworld, October 22, 1990)
106. On November 5, 1990, PC Week reprinted a letter submitted by Brad Silverberg in response:
This is in response to your Oct. 22 story alleging that Microsoft released information about the upcoming Microsoft MS-DOS version 5.0 in an attempt to create fear, uncertainty and doubt regarding DRI's DR DOS 5.0.
The feature enhancements of MS-DOS version 5.0 were decided and development was begun long before we heard about DR DOS 5.0. There will be some similar features. With 50 million MS-DOS users, it shouldn't be surprising that DRI has heard some of the same requests from customers that we have. There will also be significant features unique to Microsoft MS-DOS version 5.0.
As for the timing of the leaks, it was not an orchestrated Microsoft plan nor did the leaks come from Microsoft. In the past, users expressed frustration when we neither acknowledged that a new product was in development nor gave a sense of our direction for the release. Thus, to serve our customers better, we decided to be more forthcoming about version 5.0.
Exhibit 90 (PC Week, November 5, 1990) (emphasis added)
107. The evidence directly contradicts the above italicized statements: (1) Microsoft added features to MS-DOS 5.0 purely in response to the DR DOS 5.0 feature set, supra 96; (2) Microsoft engaged in an "aggressive leak" campaign and proactively contacted the weekly magazines that prompted the initial stories, and disclosed plans to OEMs around the world, supra 90-93; and (3) Microsoft disclosed MS-DOS 5.0 plans to preempt DR DOS, not to serve its customers better, supra 90, 94. Indeed, Chestnut in his deposition was forced into a corner on these points, all of which happened on his watch:
I will acknowledge that part of the reason we were talking to the press and OEMs and so forth was to -- as a competitive response -- preemption, if you'd like, about DR DOS.
Chestnut Depo. at 190. (emphasis added).
108. Microsoft appears to have misled the government in the same way. The Department of Justice briefly looked into vaporware allegations. Bill Neukom -- Microsoft's general counsel -- submitted a letter to the Department of Justice on May 19, 1994. His misrepresentations are emphasized:
Reporters from PC Week, Infoworld and Computerworld contacted Microsoft for comments on MS-DOS 5.0. At the same time, Microsoft was concerned about reports that DRI was telling OEMs that Microsoft had no ongoing commitment to MS-DOS, and Microsoft's PR Department was advising product groups to be more responsive to inquiries about products under development to avoid a repeat of the problems caused by Microsoft's 'no comment' approach to questions about Windows 3.0 prior to its May 1990 release. Prompted by these concerns, Microsoft responded to the unsolicited inquiries of these three publications. Articles disclosing Microsoft's work on MS-DOS 5.0 were published in the April 30 editions of PC Week, Infoworld and Computerworld. Microsoft conducted no 'proactive' briefings on MS-DOS 5.0 with any reporter who wasn't under NDA.
Exhibit 423 (emphasis added)
Mark Chestnut directly contradicted these statements in his deposition in this case, and he (not Bill Neukom) was the man in charge of this campaign at the time Microsoft undertook it. Chestnut Depo. at 118 ("Aggressive -- it means that we were calling them, basically").
109. By Spring 1991, Microsoft's executive staff considered a presentation from Jeremy Butler -- a senior executive -- that "business tactics" of "destroying the competition" with "preemptive announcements" was a "questionable" practice. Exhibit 121 (emphasis added). But by that time, egregious damage had been inflicted on DR DOS sales.
110. Windows 3.0 launched in May 1990, and was rapidly adopted by OEMs and ISVs as the preferred GUI platform. Microsoft's coercion with Windows escalated markedly after attaining monopoly power.(16)
111. Stephanie Reichel was a Microsoft OEM account manager in Germany from Fall 1991 through Summer 1994 assigned to several key accounts. Reichel Depo. at 11, 222-223. She testified that she informed three of her OEM accounts (IPC, Actebis and Peacock) that the price for Windows alone would be higher than the price of Windows and MS-DOS combined -- a practice designed to exclude DR DOS. Id. at 100-101. Reichel testified that other Microsoft employees made similar threats. Id. at 296. Indeed, she testified that both Juergen Huels (her superior) and Jeff Lum (his superior) practiced this illegal technique themselves, and ordered their subordinates to do so as well. Id. at 97-98, 298-300. See also Dixon Depo. at 333-334 (testifying as to Asian practice).
112. A glaring example of this predatory conduct rose to the highest levels of Microsoft. Vobis Microcomputer AG, the largest German OEM, was DRI's prominent foothold in Germany and Europe. Vobis was a major seller of DR DOS versions 3.31 and 5.0. Beginning in 1989, Microsoft had tried to get Vobis to drop DR DOS and license MS-DOS exclusively. Kempin Depo. at 173. Microsoft became increasingly alarmed as other OEMs took note of Vobis' success with DR DOS 5.0, fearing those OEMs would license DR DOS 5.0 and further increase DR DOS' market share and reputation. See Exhibit 118 at X0590072 ("Amstrad and other German companies have been noticing Vobis' success and its' DRI bundling").
113. Microsoft's concern about Vobis extended to the highest levels of the company, with Steve Ballmer telling Brad Chase on the day he became MS-DOS 5.0 product manager "to eat, sleep and drink Vobis" until DR DOS was out of the account. Exhibit 100. Microsoft tried for more than 18 months to get Vobis to abandon DR DOS and sign a per processor license for MS DOS 5.0. See, e.g., Kempin Depo. at 173-177, 186-188, 193-194, 205-208, 221-223, 228-235. Still, Vobis' CEO, Theo Lieven, stubbornly refused, preferring to offer DR DOS 5.0, which he testified was "much better." Lieven Depo. at 26.
114. Finally, Joachim Kempin -- Microsoft's worldwide director of OEM sales -- met with Lieven. Kempin reported the meeting in a March 26, 1991 memo he sent to other Microsoft executives:
Interesting enough, Amstrad and other German companies have been noticing Vobis' success and its' DRI bundling. Leifen himself mentioned to us that he could influence DRI in their product development, etc. After talking to Manfred, it was obvious that Leifen was reneging on the deal. Round two: I took the opportunity to negotiate in German, sign our offer as is -- this is an agreed upon package deal or if you change any component, we will too. Second option: scratch the DOS clause, pay $35 for Windows instead of $15. You have until 04/01/91 to consider. . . . The proposal showed impact. . . . In my judgment they will hurt if they do not ship WIN and paying $35 for it is out of the question.
Exhibit 118 at X0590072 (emphasis added)
In short, Kempin told Lieven it would cost more to license Windows alone than it would to license MS-DOS and Windows together. Two days later, Vobis signed a license for MS-DOS. Lieven Depo. at 56 (referring to Vobis license).
115. Lieven testified that this conversation took place as documented by Kempin. Lieven Depo. at 51-55; see also Reichel Depo. at 95-96. Kempin, too, admitted that he did it, and justified it as being "pretty mad" at Vobis for continuing to ship DR DOS. Kempin Depo. at 250; see generally id. at 248-254. Kempin also testified he knew this type of conduct to be "wrong." Id. at 50-51. When confronted with this document at his deposition, even Gates admitted that "Kempin did make a mistake." Gates Depo. at 248. Gates insisted, however, that Ballmer "got involved" to clarify with Vobis that no such naked tie was actually intended. Id. at 248-249. At his later deposition, Ballmer denied any such undertaking. Ballmer Depo. at 115.
116. Microsoft has not challenged Caldera's factual allegations concerning its use of a naked tie. Indeed, Microsoft sales personnel apparently used whatever "tying" leverage they had with any product, whenever they had it, to keep out DR DOS. In April 1991, when closing out the negotiations on the Amstrad account in England -- another high-profile OEM favorable to DR DOS -- the Microsoft account manager reported: "It's not Roback who's tying the mouse to DOS -- it's me! -- I like the idea of even the most tenuous hook to keep DR one step behind us." Exhibit 124.
117. A final point on the Vobis incident is in order: Microsoft's tactics grew even more brazen when it realized it had not immediately ended Vobis' example-setting promotion of DR DOS. At the time Vobis signed the MS DOS 5.0 license agreement, it had unused copies of DR DOS 5.0 under an existing license, and so continued to sell DR DOS 5.0 to its customers. Subsequently, Microsoft invited Lieven to its headquarters in Redmond, Washington. During the visit, Kempin offered to pay Lieven between $50,000 and $100,000 to "stop selling DR DOS." Lieven Depo. at 104-106; see Reichel Depo. at 212; Kempin Depo. at 281 (admitting "[w]e might have talked about it"). Lieven accepted Kempin's offer.(17) Lieven Depo. at 104-105. Microsoft funneled the money through a "marketing fund" account to Vobis. Id. When asked whether Gates had knowledge of what Kempin had done, Stephanie Reichel -- Microsoft's Vobis account manager -- testified that both Bill Gates and Steve Ballmer were aware of the cash payment.(18) Reichel Depo. at 216-217.
118. Microsoft also put together a press release on DRI's loss of the Vobis account for release in the United States, to leverage momentum in Europe to the United States. See Exhibit 334 ("It is also important to note that this account is DRI's largest account in Europe and this kind of media will do damage to DRI's campaign to compete against us"); Lematta Depo. at 135-138, and 143 ("For instance, when we have done announcements we would say, Here are the OEMs who are supporting this particular product. It's in the area of momentum.").
119. Microsoft also reacted to DR DOS 5.0 by pulling together successive "FUD sheets" to distribute to the field. For instance, in September 1990:
Chestnut:
The following is a summary of compatibility problems that we have verified with DR DOS 5.0 based on internal testing and results from an outside test lab. This is a technical summary of confirmed problems with DR DOS 5.0. Comparisons between MS-DOS 5.0 and DR DOS 5.0 have been addressed in previous mail and so are not discussed here.
This information is being provided to assist in disproving DRI's claims that DR DOS 5.0 is 100% compatible with MS-DOS. It is, however, very confidential information and should be provided to customers only under non-disclosure.
Kempin:
Love. Try to get it into publications asap.
Exhibit 76 at X575655 (emphasis added)
120. Microsoft account managers were directed to share purported "serious problems" with OEMs considering a switch to DR DOS. See Exhibit 73; Reichel Depo. at 49.; Chase Depo. at 64. At the same time, Microsoft withheld (or misrepresented) exonerating evidence. As to DR DOS 5.0, Chestnut testified he hired an outside testing lab to "beat the thing" to death, Chestnut Depo. at 46, but they found it to be compatible with Windows 3.0. Id. at 47, 54. When providing resultant "FUD points" to outside PR personnel, however, his cover sheet betrayed its lack of candor and balance:
Attached is a summary of dr dos 5 compatibility issues. The compatibility testing was done by an outside testing lab -- I have their formal write-up if you need it. The Windows 3.0 compatibility testing was done internally.
Exhibit 85 at X208033
121. Plainly, Microsoft was withholding independent tests confirming DR DOS 5.0 compatibility, while ginning up its own tests to give the appearance of "incompatibility." Caldera has been unable to recreate many of these purported incompatibilities, and determined that others were easily patched. See Ivie Decl. (addressing false and misleading statements about DR DOS 5.0 in Exhibits 73, 76 and 85).
122. Kempin testified that as of April 1991, DR DOS 5.0 had been "a far superior product to MS-DOS for the preceding nine months." Kempin Depo. at 263. As the launch of MS-DOS 5.0 approached, Microsoft realized that an ongoing FUD campaign was of the utmost importance in head-to-head competition. Sergio Pineda oversaw FUD marketing tactics leading up to and beyond the launch of MS-DOS 5.0. In May 1991, he circulated to all OEM account managers for their use the second issue of what he called the "DOS Connection." Pineda Depo. at 37. He expressly stated the theme of the campaign:
Any degree of incompatibility is enough to create fear, uncertainty & doubt among endusers when it comes time to buy new systems -- this suggests that PC OEMs will take on a big risk if they ship DR-DOS with their systems.
Exhibit 126 (emphasis added)
123. On October 15, 1990, Microsoft's outside public relations firm, Waggener Edstrom, had advised:
Over the next couple of months, Kathryn and I are going to be in touch with a lot of editors regarding MS-DOS 5.0. We'll basically be covering all the key editors except for the weeklies and we'll be talking to them about other things.
We recommend that we *informally* plant the bug of FUD in their ears. "Have you heard about problems with DR DOS?" "That security feature is a neat idea and, gosh, such a feature would be great, but it's just too easily circumvented." "Gee, it's unfortunate that DR DOS can't be loaded high all the time. MS-DOS 5.0 can." We'll do this very tactfully.
*If Digital Research came to Microsoft for help making DR DOS work with Windows, would Microsoft help them? Maybe not?
Exhibit 86 (emphasis added)
124. In line with this, Pineda specifically focused the FUD attack on future versions of Windows:
How should we sell against DRI
. . .
For OEMs committed to shipping Windows, only we can ensure 100 percent compatibility with future versions of DOS and Windows.
Exhibit 80 (emphasis added)
Yet at the time, Microsoft already had in hand a report from an outside testing lab that "tested DR DOS with Windows and found the two compatible." Exhibit 157; see Pineda Depo. at 42-47. Qubie -- a British OEM -- confirmed that it was "perfectly OK to run DR DOS and Windows on top of it." Harvey Depo. at 23.
125. In July 1991, Pineda circulated a separate report devoted to his "MS-DOS 5 vs. DR DOS 5 Comparison," which also contained specific speaking points on purported flaws in DR DOS 5.0. Exhibit 141. This summary, drawn as it was from earlier "bug sheets," contained the same misleading information. See supra 119-121. Moreover, MS-DOS suffered many of the same -- or worse -- problems. See Ivie Decl.
126. Microsoft also later contracted National Software Testing Laboratories (NSTL) to test DR DOS yet again "with networking software, a memory manager, dos and win apps and anything else you can think of that might raise some degree of incompatibility." Exhibit 116. NSTL reported its results in a document dated June 28, 1991. NSTL reported again that DR DOS 5.0 was compatible with Windows 3.0. Exhibit 139.
127. Yet when Novell announced in July 1991 its intended merger with DRI, the NSTL report leaped to the fore of Microsoft's FUD campaign. On July 22, 1991, Brad Silverberg outlined the plan to fellow executives:
DR-DOS has lots of compatibility problems. We commissioned NSTL not long ago to run tests and they found many problems with DR-DOS . . .
We are engaged in a FUD campaign to let the press know about some of the bugs. We'll provide info a few bugs at a time to stretch it out.
Exhibit 151 (emphasis added)
128. Silverberg testified this drip-feed technique was designed "[f]or maximal effect . . . to arm the press with factual information about the shortcomings, incompatibilities and bugs that DR DOS possessed." Silverberg Depo. at 165. As Brad Chase stated by e-mail, the purpose of a "slow leak" program was "to short circuit Novell DOS before it gets off the ground," and to "make it hard for customers or oems (ibm???) to consider dr. dos seriously." Exhibit 150. Microsoft's own economist testified that such a drip-feed technique was not efficiency-enhancing conduct. Schmalensee Depo. at 412-413.
129. Moreover, the reported NSTL incompatibilities were incorrect. NSTL tested 34 applications on DR DOS 5.0. Of these, NSTL reported that 29 worked without failure in a variety of networked and stand-alone environments. NSTL reported that the remaining five applications failed with DR DOS 5.0. See Appendix D. Subsequent testing demonstrates that only two of these application failures were true errors -- and of these two errors, MS-DOS 5.0 experienced even more serious errors with one of the programs than did DR DOS 5.0. See Ivie Report, Attachment 12.
Exclusionary Licenses: Triple-Whammy
130. DRI identified small OEMs as an original, primary target and growth opportunity -- a segment long-ignored by Microsoft. Williams Decl. at 65. Microsoft noticed this strategy, and altered its focus accordingly. See Exhibit 120 at MS5010350 (Joachim Kempin, April 8, 1991: "Another important accomplishment of the OEM organization over the past two years has been an attitude change towards smaller customers. Particularly in the US, we have started focusing on smaller accounts and developed a lot of them into loyal (DOS/WIN/Mouse/per system) customers. Five years ago we wouldn't have even talked to them, while today we understand them as an important growth opportunity."). See Appendix C.
131. Microsoft wanted its DOS monopoly uncontested. When closing a per processor license with an insignificant OEM, the account manager reported:
This will not be a major customer for Microsoft in the near future. But, we still wanted to prevent losing them to DRI.
Exhibit 166 at MS0012114
132. Ron Hosogi stated Microsoft's licensing attack succinctly: "We are forcing them to NOT ship any DRI machines." Exhibit 75.
133. How Microsoft "forced" OEMs away from DR DOS derived from the synergy of its licensing triple-whammy: per processor licenses, minimum commitments subject to forfeiture, and increased license duration. Attached hereto as Exhibits 57 and 214 are exemplar licenses evidencing all three. Each practice, and its devastating impact to DR DOS, is detailed below.
134. Microsoft recognized the per processor license as perhaps the most effective weapon in Microsoft's arsenal against DR DOS.(19) When competition for accounts increased after DR DOS 5.0 hit the market, Jeff Lum directed his sales team on July 23, 1990:
All DOS 5.0 Amendments need to be finalized. Push for "all processors" if you don't have it for DOS today, or else add 15% for "per machine" basis.
Exhibit 64
135. Chestnut testified that, in the many months leading up to the launch of MS-DOS 5.0, the repeated objective was "to have per processor DOS 5 licenses for any OEM account that was in the business of manufacturing desktop PCs." Chestnut Depo. at 208-209; see also Exhibit 107 (Chestnut OEM status report); Exhibit 63 (Hosogi notes reflecting instruction to seek per processor licenses). Reichel testified this directive came from as high up as Kempin, who told OEM account managers "to get a per processor license to get DR DOS out of an account." Reichel Depo. at 303. Kempin confirmed that his "preference" was a per processor license. Kempin Depo. at 150, 234.
136. The purpose and effect of the per processor license was summed up quite simply by an OEM witness subpoenaed by Microsoft. Gary Bachelor worked in sales for several OEMs (including Commodore, NCR and NEC) during his 20 years in the computer industry. He testified on cross examination:
Q. Do you know what a per-processor license is?
A. Yes.
Q. Can you describe that for the jury?
A. You pay based on every single processor unit that is shipped out the door. So everything you build you pay a license fee on.
Q. And you pay that license fee whether or not you actually load the operating system on the machine?
A. Correct. If the unit goes out the door, you pay.
Q. And if you have a per-processor license with one vendor, and you decide to put some other vendor's operating system on the machine, you will in effect pay twice for the operating system for that machine, won't you?
A. Yes.
Q. Let's go back in time to the decision -- to the point in time that you were making the decision to go with DRI.
You didn't have a per-processor license with Microsoft at that time, did you?
A. No.
Q. If you had had a per-processor license, you wouldn't have entered into negotiations with DRI, would you?
A. I doubt it.
Bachelor Depo. at 67-68.
See also Lieven Depo. at 45: "[I]t's obvious that Microsoft tried to keep people buying that product, so when they have paid all the PCs for that license, why should they change to another product? Everybody knows that. That is not -- no secret."
137. Repeated entries in Microsoft OEM status reports starkly reveal awareness that per processor licenses excluded DRI from the market:
Opus agreement has finally been signed by Redmond. Another DRI prospect bites the dust with a per processor DOS agreement.
Exhibit 81 (emphasis added)
Hyundai Electronics INC. (HEI)
DRI is still alive. We are pushing them to sign the amendment on processor based license. This will block out DR once signed.
Exhibit 96 at MS0049007 (emphasis added)
Congratulations are in order for John "DRI Killer" McLaughlan (No, he isn't having another baby) who signed a $2.5M agreement with Acbel (Sun Moon Star). The agreement licenses DOS 5 per processor on a worldwide basis for 3 years (they will be replacing DRI DOS which they currently ship outside the US).
Exhibit 101
Trigem
Their new agreement is per 86/286/386 processor sytem license for DOS3/4/5. No more DR-DOS from Trigem.
Exhibit 102 (emphasis added)
Hyundai Electronics (HEI)
-- DRI visited Hyundai executives and the pricing issue was raised again. The new license is a per processor deal, which allowed us to completely kick out DRI.
Exhibit 108 at X556822 (emphasis added)
Liuski, which has been an MS-DOS PP [packaged product] customers for several years now at a run rate of approximately 25k-27k per year, has signed a license for MS-DOS 4.01 & 5.0. The PER PROCESSOR license is a one year license at a one year minimum of 18k units per year at a royalty rate of $35. On the surface this would seem like a decrease in revenues. They currently pay $50 for MS-DOS PP (remember there are cogs in the $50). The reason for the conversation to royalty is to retain their loyalty to MS-DOS. They were seriously considering DRI product, thus we needed to be more aggressive.
Exhibit 119 at X0590013 (emphasis added)
Budgetron is the one account in Canada where DRI's presence was very strong. Budgetron's market is strictly the low end VAR (or dealer) who would endure DRI DOS for a lower priced machine. This new contract guarantees MS-DOS on every processor manufactured and shipped by Budgetron, therefore excluding DRI.
Exhibit 125 at X190989 (emphasis added)
138. DRI salesmen likewise testified that, when they tried to license DR DOS to OEMs already under a per processor license with Microsoft, they were shut out of the account. Dixon Depo. at 325-328 (Asia); Singh FTC Depo. at 24-26 (United States).
139. Microsoft suggests that OEMs were free to depart from the per processor licensing scheme, and that price differentials between license types were "relatively minor." Licensing Memo. at 2, 5-7. This is disingenuous. Microsoft was well aware of the price points and margin pressures that OEMs were experiencing. OEM executives and developers deposed during this lawsuit confirmed that even slight price differentials between the per processor and per system licenses meant that only the per processor license was a true option. Leiven Depo. at 43-44; Frankenburg Depo. at 69-70 (one to two dollar differential "was significant" to Hewlett Packard); Apple Depo. at 16-17, 32-33; Bachelor Depo. at 66.
140. Indeed, Microsoft emphasized these onerous price differentials in negotiations with OEMs. Caldera has received very few price quotes from Microsoft in the hundreds of boxes of documents produced. But a letter to AST on September 14, 1990, reveals that Microsoft was presenting much more than a $1 or $2 difference:
MS has a per processor price, per system price and a per copy price. Our per processor price has the lowest royalty rate. This agreement is based on paying royalties for every processor shipped. MS-DOS does not have to ship out with every system. Per processor agreements list all processors in the back of the licenses from 8086/8088 to 80486. An exception would be made with multi processor systems. Please recall that we have additional per system pricing available for other products like Windows 3.0 if you have a per processor license in place. Our next generation is a per system license which means that you would pay the royalty for every system shipped which is listed in the license. Our last agreement is a per copy license. This means that you offer MS-DOS as an option and pay the royalty whenever you sell MS-DOS regardless of the hardware.
. . .
100k 250k 500k
Per Processor $24 $18.5 $17.5
Per System $37 $31.5 $25
Per Copy $45 $40 $30
Exhibit 77 (emphasis added)
141. Microsoft was even more aggressive when the OEM was attempting to negotiate some wiggle room on the per processor requirements specifically in favor of DR DOS. Commodore Business Machines was quite interested in DR DOS, but on September 26, 1990, received the following letter from its Microsoft account manager:
Within this letter is the DOS 5.0 pricing proposal that you have requested.
You have indicated to me that you will be making your decision based on a weighted average, and that this weighted average needs to be significantly below your current $11.00 per unit price. You also mentioned that your price needs to be very competitive on the low end, as this is where you see the majority of your margin pressure. In our original conversation, you presented me with two price scenarios. One, you want a price if you were to take all of your consumer machine business (75% total units sold) to DRI. Two, you offered me the opportunity to quote such a competitive price that you will not need to take your business to DRI. You have also mentioned several times that price is the only factor in this decision. Let me address both of these price scenarios.
If you were to take your consumer machines to DRI, this is what would happen. Your DOS contract would go from a per processor agreement to a per copy agreement, when it expires at the end of January. A per processor agreement keeps your price low, because we offer a premium price to those customers who bundle our product with every processor. For those customers who choose not to bundle our product on every processor, their price is adjusted accordingly. This price adjustment reflects the decade of work we have invested in making our DOS product an Industry standard that is compatible with practically every personal computer on the market today. What does this mean to you? If you choose to take your consumer business to DRI, your unit volume decreases 75% and you no longer have a per processor agreement. Therefore, your new price on all DOS products will jump to $30.00 per copy.
What I propose is that we offer you a substantially lower price on 8086 machines (where the majority of your business is), and adjust your royalties on the higher end processors. Specifically, your pricing under this new agreement would be:
8086 $6
80286 $10
80386 $16
80486 $16
Using the figures from FY90, your weighted average would be $8.22.
Exhibit 79 at X221348-349 (emphasis added)
142. Consider what Microsoft actually offered above: a per copy license for 55,000 units for a total cost of $1.65 million; versus a per processor license for 220,000 units for $1.8 million. For DRI to get Commodore to use DR DOS on 75% (165,000) of its units, DRI would have to price DR DOS at less than $1 per copy. DRI's predicament, and Microsoft's economic coercion of OEMs, are plain.
143. Indeed, Microsoft actually chose to forego short-term revenue simply to block out DRI under the per processor license. The discounts offered by Microsoft, particularly as they related to per processor license agreements, acted as payments to the OEMs to avoid distributing DR DOS. These payments came in the form of heightened margins from the distribution of computers containing Microsoft products. Leitzinger Report at 16; Leitzinger Rebuttal Report at 2-4. See also Lieven Depo. at 30, 43-44 (Microsoft offered to cut per processor price from $18 to $10 to remove DR DOS); Kempin Depo. at 243. Leitzinger's regression analysis of Microsoft's OEM sales data reveals that, where DR DOS was a threat to the OEM account, the average per processor rate was 57.6% less than the rate paid under a per copy license where DR DOS was not a threat. Leitzinger Rebuttal Report at 5-6.
144. As outlined in Dr. Leitzinger's report, Microsoft coupled the use of aggressive minimum commitments with prepaid balances to raise the cost to an OEM to switch to an alternative operating system. During the life of a Microsoft contract, OEMs could find themselves over-committed with respect to units of Microsoft products. Given the nature of Microsoft's mandatory (and non-refundable) minimum commitment payments (usually made quarterly), these OEMs faced the prospect of forfeiting that prepaid balance (referred to as a PPB, or UPB, unspecified product billing), or signing a new agreement with Microsoft to partially recoup the prepaid balance. See Leitzinger Report at 13-14, 16-18. Microsoft understood well the likely response for a majority of these OEMS.
145. Robert Frankenberg, former Vice President of Hewlett-Packard Company, submitted a sworn declaration to the FTC in December 1992 on behalf of Hewlett-Packard. He averred as to Microsoft's pattern and practice in this regard:
Under this arrangement, the OEM contracts to pay a certain amount based on total machines that are expected to be shipped. The per-unit royalty price is a function of the minimum commitment: e.g., the OEM may pay at one per-unit rate for an expected shipment of 100,000 Intel-based computers, and a lower rate for 250, 000. The OEM must pay the minimum commitment under the contract whether or not actual shipments reach the agreed level. If actual shipments fall short of the commitment level, the OEM is still obligated to pay the agreed amount, though the shortfall amount of machines may be rolled over into new commitment levels either in the remaining years of the contract or in a new contract. Because the OEM gains more favorable royalty pricing with higher minimum commitments, there is an incentive to err on the high side. If the OEM has paid upfront according to the minimum commitments, and has not shipped the expected amount of computers, the OEM has in effect overpaid under the contract rate for the MS-DOS copies already shipped. But losses are partially recoupable only if a contract is renewed with Microsoft and the part of the old commitment levels are rolled over into a new contract.
Frankenberg Decl. at 37 (emphasis added)
146. Microsoft plainly manipulated minimum commitments to its advantage. An internal memo entitled "Discussion of Prepaid Balances, Worldwide OEM, Q90-4" contains the following admission:
Prepaid balances have become a by-product of the way we conduct our OEM business. They are well understood by our OEMs. They also have definite benefits, tying customers to us.
We can use prepaid balances to encourage OEMs to license more of our systems products, increase our market penetration and create opportunities for increased sales of our application products.
Exhibit 98 at X200770 (emphasis added)
147. As with per processor licenses, Microsoft's OEM status reports reveal that Microsoft used minimum commitments to block DR DOS:
HYUNDAI ELECTRONICS INC. (HEI)
-- The DR threat still lives, especially in the export section which needs a low priced DOS for XTs to be shipped to Eastern Block. We will maintain and utilize HEI's UPB situation to keep out DRI.
Exhibit 74 at X561629 (emphasis added)
Through adjustments to the minimum commitments for OS/2 and DOS Shell in order to get a Per Processor DOS/Shell agreement, we have effectively reduced our expected revenue for FY91 to less than $3 Million. . . . The major goal was to go Per Processor, and we are within weeks of signing this three year commitment. Albeit still at a very good royalty, but Per Processor is a major commitment from HP.
Exhibit 122 at X0597322 (emphasis added)
Will sign WIN and DOS per proc. LICENSE this Friday. . . . This will include all of Compuadd's notebooks (386sx up) which they had never licensed for Win. The only concession we had to make was to let them recoup 500k prepaids this Q.
Exhibit 302 (emphasis added)
148. A series of license renewal letters between Microsoft and Logicraft, an OEM, in November 1990 demonstrates the use of prepaid balances to leverage a license renewal for MS-DOS:
Logicraft:
We are pleased to inform you that we would like to renew our license agreement for MS-DOS 3.3 binary which expires on September 30, 1990.
For the current contract, our cumulative minimum commitment may exceed the earned royalties to Microsoft by a few hundred licenses. Under the terms of our contract, these prepayments are recoupable. We propose to sell these licenses in the first quarter of the term of the new agreement, or until we have used all of them.
Microsoft:
I would like to briefly talk about the prepaid balance. You used the word "inventory" a couple of times when referring to Logicraft's prepaid balance. Logicraft committed to pay Microsoft $300,000 over two years regardless of how many units actually shipped. It was Logicraft's responsibility to recoup this amount during the two year term of this licence. . Please understand that once the term of a license expires, any outstanding prepaid amount, legally, belongs to Microsoft. Fortunately, Microsoft is usually willing to work with an OEM to allow them to recoup an existing balance when a new license is signed.
Logicraft:
I am glad that you said in your letter of October 22, that "fortunately, Microsoft is usually willing to work with an OEM to allow them to recoup an existing balance when a new contract is signed." Because this was our expectation based upon past representations as well.
Microsoft:
Microsoft must be sensitive to antitrust regulation of providing exceptional considerations to specific customers. Based on this concern, Microsoft has decided that it will continue to stand by the proposal offered to Logicraft on November 28. This proposal reduces the minimum unit commitment from 1,000 per year to 500 at a per unit royalty of $225. It also provides the opportunity to recoup 50% of royalties that exceed this minimum commitment against the current prepaid balance. Microsoft feels this is a fair proposal since it reduces your current commitment by half and allows you to recoup against the prepaid balance.
The purpose of our negotiation is not for the sole purpose of providing Logicraft with an opportunity to recoup the prepaid balance, but rather to sign a new license in order that Logicraft may continue to distribute MS-DOS.
Exhibit 92 at MSC00082227, -230, -231, -233 (emphasis added)
149. Notwithstanding Microsoft's stilted language above, OEMs knew the truth. Theo Lieven of Vobis testified candidly: "They were quite flexible in that [recoupment], because then they knew that the customer will make a new contract with them. . . . Otherwise, you lose them [prepaid balances]." Lieven Depo. at 79-80.
150. Experience shows that the life cycle of a DOS release was somewhat less than two years.(20) Even so, at least by 1990, the standard Microsoft license for MS-DOS stated a two-year term, Kempin Depo. at 15, and thus exceeded the expected lifespan of the product. This had the effect of blocking entry by DR DOS. This practice, too, was clearly targeted against DR DOS.
151. Robert Frankenberg specifically addressed this practice in his Declaration to the FTC in December 1992:
There are yet other aspects of Microsoft's licensing practices that make competition with Microsoft even more difficult. Microsoft typically wants long-term contract commitments for these per processor agreements, at least two years, and even three. In fact, Hewlett-Packard was offered a four-year contract, which we accepted because it contained the most favorable terms of the options presented to us. Because OEMs probably assume everyone else in the industry is tied into these per processor agreements, and Microsoft does give an additional small price break for longer terms, there is a strong incentive to accept long-term agreements. For probably most OEMs, an entrant like DR DOS that does not provide high-end functionality in a high-margin hardware niche is effectively foreclosed from competing for OEM business because of long-term per processor agreements.
Frankenberg Decl. at 39 (emphasis added)
152. During the push for MS-DOS 5.0 licenses prior to launch, Microsoft began increasing license duration to three years. Microsoft's Price Guidelines indicate a $1 discount to OEMs acceding to the three-year lock, and a $1 penalty to OEMs seeking a one-year term. Exhibit 314; see also Exhibit 143.
153. The blocking effect was well understood:
Printaform
The new deal is effective 10/1 for DOS 4.01/5.0 in Windows 3.0 on all 286, 386, and future 486 systems. They will license DOS 3.3 on the 8088's. The new contract is for a three year term so that we don't have to worry about low end competition. This will be the first OEM in Mexico bundling Windows 3.0 on its systems, and we eliminated DRI's chances with Printaform for at least 3 years.
Exhibit 68 at X0590649 (emphasis added)
Microsoft's increasing push for three-year license duration is evident elsewhere in Microsoft's status reports and pricing proposals. See, e.g., Exhibit 79; Exhibit 101.
154. Kempin acknowledged that, upon signing a three-year license, the chance that an OEM would sign with another operating system was "relatively small." Kempin Depo. at 269. In his deposition Theo Lieven drew an apt analogy:
When you -- when you -- when you today decide to buy your milk for the next three years from one supplier and you make prepayments, you never go to another grocery or to another store to have a look . . . .
Lieven Depo. at 100
Return
Table of Contents
Dreaming of the DOS/Windows merge -- Part 2
155. In the wake of the IBM/Microsoft "divorce" and the launch of DR DOS 5.0, Microsoft found itself in a two-front war: on the high end, "NT" would be fighting IBM's OS/2; on the low end, MS-DOS would continue fighting DRI's DR DOS.(21) Microsoft chose the one weapon in its arsenal that neither IBM nor DRI had at its disposal: Windows. Specifically, Microsoft began planning for Windows to provide a common GUI for both NT and MS-DOS.
156. Paul Maritz was the senior Microsoft executive who oversaw this project. He crystallized this strategy in a memo to Microsoft executives on August 14, 1990:
1. Our long-term product strategy is Windows on DOS and Windows on OS/2. . . .
Our goal is to simplify our message to ISVs and focus all of our development and marketing energy behind the Windows API. We are evolving our OS/2, Windows and NT OS/2 development efforts away from the redundant process we have today towards a single-API, scalable desktop operating system. Future Windows will span user requirements from low-end DOS systems to high-end OS/2 systems.
A decision has been made to redirect our energies toward a truly "Windows-centric" strategy for the desktop. As a first step in this direction, NT development has been switched from 32-bit PM [Presentation Manager, a dead-ended GUI] to 32-bit Windows APIs effective now.
The model we want to present to customers and ISVs is a single, consistent Windows interface running on DOS, on the 32-bit OS/2 base, and eventually on NT. As radical as this may sound, very little has changed near term and we want to avoid giving the appearance to customers or ISVs that we are abandoning OS/2.
Exhibit 72 at X191122-123 (emphasis added)
157. The expressed strategy quickly took hold. On October 1, 1990, Gates gave a presentation on "Information at Your Fingertips" that showed "Win 4.0" sitting atop MS-DOS for shipment in 1993. Exhibit 82. Ballmer's presentation at an OEM briefing the next day elaborated the point at length:
But the key message here is, we've developed a strategy that lets Windows, instead of being something that just runs on DOS, be an environment that spans DOS and OS/2. So, the success and energy and work that we and you will put into Windows will also fuel the success of the high-end, mission-critical operating system which we all need as part of our product lines.
Today Windows is a great thing on the individual PC. Our challenge with Windows is to broaden its appeal, to if you will, put Windows everywhere.
On the high-end or power platforms, we are putting Windows on OS/2. . . .
In order to give ISVs a consistent target across DOS and OS/2, we will also provide a set of libraries that let you host a 32-bit Windows application on top of DOS with DOS Windows. These tool kits to build 32-bit Windows applications will be available in 1991.
Exhibit 84 at X174610-611 (emphasis added)
158. By the end of 1990, two teams at Microsoft were at work separately building components that Microsoft would ultimately choose to merge into a single product: Windows 95. On November 16, 1990, in a memo titled "Windows Everywhere" that circulated to the DOS and Windows business unit, David Cole explained:
Right now there are 6 separate development teams in the DOS/Win BU working on Windows and DOS:
. . .
c) The Windows 4.0 team. A 3rd Windows development team is focused on "Information at your Fingertips" technology. This includes the new data storage model, context indexing, and new shell that go in Windows 4.0. These components will be built in a "portable" fashion so they can be used for Windows on OS/2 3.0 as well as for Windows on DOS.
. . .
e) The DOS 6.0 Team. This team is focused on advanced DOS technology which among other things will allow 32bit Windows to work even better on DOS.
Exhibit 95 at CMS00014869 (emphasis added)
159. In early 1991, Microsoft distributed a white paper entitled "Personal Computing: The Second Decade Begins." Exhibit 103. Microsoft there acknowledged that no technical barrier prevented Windows and DOS from being developed as separate products essentially forever, nor did any technical reason compel their merger:
Our customers have told us clearly that they want us to protect their investments. Rather than encouraging customers to migrate to new software environments (as Microsoft attempted with IBM in its effort to market OS/2 as a replacement for DOS), Microsoft is providing constant, well-integrated enhancements to a single graphical environment. Of course, DOS will continue to evolve with new releases.
There are no foreseeable technological barriers to this approach: Microsoft is adding new technologies -- such as object-oriented user interface functions, file systems, programming environments, and distributed computing capabilities -- to Windows and DOS in this evolutionary manner.
Exhibit 103 at MSC00265002 (emphasis added)
160. Having gotten its message out, Microsoft began to wrestle with thorny packaging and marketing issues inherent in its ultimate goal: lock out DRI and other competitors. Gordon Letwin -- one of Microsoft's chief architects of DOS projects back to the very origins of the company -- stated the concern succinctly on March 8, 1991, in his email to Microsoft executives on the "Win4, DOS6, Win/N Merge":
So the question that you raise is, "what role does DOS 6 play? Can we just cancel the project?" First, I'll reitterate the original DOS 6 goals.
. . .
-- Reclaim market from Cloners
your proposal only half way addresses this. In a sense, you lock cloners out of the WIN4 market, but we only benefit from this if you increase the price of WIN4 to be that of WIN3 + DOS. Otherwise, we've destroyed the DOS market under WIN4, revenue-wise, so this is a phyrric victory.
Exhibit 113 (emphasis added)
Maritz testified that the "WIN4 " referred to by Letwin was "the project that became Windows 95." Maritz Depo. at 70, 71. See also Exhibit 117 (report to Silverberg, March 1991: development to continue on two tracks, but "we can easily merge the two" to "deter cloners"; what products to release "are strictly packaging issues, and our development approach does not dictate which one we pursue").
161. Microsoft executives continued to recognize that no technological advantages were gained from offering Windows and DOS together as an integrated package. In an interview reprinted in PC User on June 19, 1991, Ballmer confirmed just the opposite, and that the products could be offered both separately and together with a combined installation:
Q. What about the relationship between DOS and Windows? Or, to put it another way, is Windows ever going to incorporate DOS and become an operating system itself?
A. Today, Windows is an operating system. It has a loader and a memory manager, it has processes and can launch processes, it has paging; it's an operating system in every way except that it doesn't have a file system. Windows leverages on the DOS file system, and also the DOS program loader. So Windows is mostly an operating system, and it has been designed synergistically with DOS to run alongside DOS.
Q. But why not put the file system and other functions in Windows so that GUI users can have a single operating system?
A. Good question. There's a little bit more we can do, and we'll certainly be providing OEMs with an installation program that installs DOS and Windows as if they were one product. But not all hardware vendors want to sell Windows and not all end-users want to run Windows. And there is nothing we give up technically by offering Windows and DOS separately; any new features in DOS will be designed totally to make sense in the context of what is going on in Windows.
Exhibit 137 (emphasis added)
Return
Table of Contents
MS-DOS 5.0: Almost Better Late Than Never
162. Microsoft could not keep DRI at bay with vaporware and FUD forever. At some point, it had to ship the long-promised MS-DOS 5.0 (which, incidentally, would carry no significant feature advantage over DR DOS 5.0). As Microsoft neared the release to manufacture, internal development records acknowledged growing awareness that it was going to have to ship MS-DOS 5.0 into the market with known bugs. See, e.g., Exhibit 112; Exhibit 115; Exhibit 114.
163. The decision to ship with known bugs is, in fact, by no means surprising. What is surprising is that Microsoft would premise a large part of its FUD campaign against DR DOS based on identical considerations and concerns. As Brad Chase summarized on May 6, 1991, shortly prior to the launch of MS-DOS 5.0:
We want to fix bugs, but we also want to make good use of our time. Ongoing bug fixing for "minor" bugs is how you end up taking two years to do your next major version. We have all met to make decisions about whether bugs were severe enough to be fixed and I am comfortable that, barring new and significant information or an obvious mistake, we should keep to our decisions.
We do not want lots of different versions of the code out there (a PSS and customer nightmare) and must minimize maintenance releases.
Exhibit 128 at MSC00818946 (emphasis added)
164. The fact is, bugs happen. See Silverberg Depo. at 59 ("there's no such thing as a product without any bugs, as a software product without any bugs"); Lipe Depo. at 132-133 ("it all depends upon the bug and the severity and how likely it is that someone is going to hit that bug and then how annoying it will be to them if they do hit it."); Barrett Depo. at 95-98 (explaining trade-offs in determining which bugs to eradicate before launch); Lennon Depo. at 121 ("there's always a number of those that exist at shiptime"); Lematta Depo. at 131 ("They're inevitable. It's the nature of software development.").
165. Apart from the hypocrisy (and thus, dishonesty) of Microsoft's FUD campaign, internal records reflect that Microsoft put into the market a product with serious problems. Within one week of the launch of MS-DOS 5.0, Microsoft product support services (PSS) was crying out for additional support to handle the flood of incoming bug reports:
We're currently hearing from numerous callers (approx 150/day) who are experiencing severe incompatibilities with MS-DOS 5.00, to the point that PSS is unable to get the operating system to work successfully on their machines. Problems range from occasional hangs to total lock-ups of their machines that require the removal of hard drives in order to boot from a floppy. In these cases the uninstall does not allow them to return to the previous version of DOS and they can ultimately lose all information from the hard drive.
Exhibit 136 at X567055 (emphasis added)
166. Within three weeks, the problems had not abated:
Given the fact that PSS has 96% busy rate (i.e. only 4% people get through), we can safely assume that the bugs that we have received so far from PSS are only a tip of the iceberg.
Exhibit 142 (emphasis added)
167. By July 26, 1991, Freedman had reduced the turmoil into a single document describing the "frequent and dangerous" bugs and PSS problems. Exhibit 154. He testified at length that the bugs described within this document were indeed serious, and were evident even on such pre-eminent systems as those offered by Dell. Freedman Depo. at 83-94.
168. By August 3, 1991, Microsoft decided to do "a silent release of Dos 5.0a to address some data corrupting bugs in Dos 5." Exhibit 160 at MSC00800829. And so -- at the same time the FUD drip-feed against DR DOS continued -- Microsoft placed a "silent release" of MS-DOS 5.0a into the marketplace without acknowledging that, in fact, users had been injured by its original release. See Exhibit 165.
JULY 1991-OCTOBER 1991: THE DRI/NOVELL MERGER
169. In early 1991, Microsoft executives identified Novell as the most significant competitive threat on the horizon. Jim Allchin expressed his concern about "Novell and desktop" to Steve Ballmer on February 26, 1991:
I have heard and now read (Infoworld) about a possible desktop OS being developed at Novell. What I have heard is that it will be 386 based and run DOS programs better than DOS. (I have not heard about Windows GUI functionality being considered.) I consider this a severe threat.
We need to consider every move we make regarding Novell with the specific understanding that they will probably attempt a run at the desktop. Novell is in the best position to impact our position -- possibly more than Unix.
Exhibit 111 (emphasis added)
170. On July 17, 1991, the threat became reality when Novell announced its intent to merge with DRI and establish its own presence on the desktop with DR DOS. Microsoft executives exchanged numerous e-mails in response to the announced merger, and the level of concern is quite remarkable. See Exhibit 148. Allchin's views provide apt summary:
I thought about it all night. Since I came here I said there were two things that concerned me related to Novell: one Novell partnering with IBM and two Novell coming at us at the desktop. Both fears have now come true.
Exhibit 280 at X0196202
171. Within a week of the announcement, Microsoft had analyzed the merger, and realized Novell's strategy was sound -- and threatening. On July 25, 1991, Richard Freedman summarized the concerns for the executives to review:
The offensive scenario presumes Novell is actively developing products to compete with Win Peer and NT, and ultimately plans to enter the standalone OEM DOS business. It is this worst-case scenario we're focusing on.
. . .
This scenario assumes Novell aims to own the desktop, both server and workstation, and assumes they'll attempt to do this first by integrating Netware and DR DOS, and then, having legitimized DR DOS, by going after standalone OEM DOS business. IBM licensing DR DOS is a major X factor in this scenario.
Exhibit 153 (emphasis added)
On the whole, Microsoft had a good understanding of Novell's strategy.
Return
Table of Contents
172. The DRI/Novell merger was completed in October 1991. Ray Noorda -- Novell's CEO and Chairman -- believed that acquiring DRI and DR DOS would prove beneficial to all aspects of Novell's business. DR DOS would expand Novell's product line and for the first time place a Novell operating system directly on the user's desktop, rather than the back-office server. Both Noorda and Williams felt that Novell's credibility with OEMs, greater resources, and stronger marketing and sales forces would immediately give DR DOS the heightened market presence needed to step up the competition with Microsoft in the desktop operating system market. Noorda Depo. at 222-224; Exhibit 196 at 18 (Novell S-4 Registration Statement).
173. In addition to offering DR DOS as an advanced desktop operating system to standalone users, Noorda also envisioned a strategy for DR DOS to benefit Novell's existing networking business. Through ownership of DR DOS, Novell intended to respond to customer demands for better-coordinated and tightly-integrated desktop and networking environments. Noorda Decl. at 18; see also Exhibit 149 (Novell press release).
174. Noorda also intended the DRI acquisition to bring Novell and IBM closer. IBM had shown interest in DR DOS for quite some time. In May 1991, IBM publicly showed DR DOS compatibility with, and support of, OS/2. Exhibit 130 (Infoworld, May 27, 1991). By June 1991, Silverberg and others were notified that IBM was in negotiation with DRI, and that "[h]igh level mgmt at IBM is interested in moving away from MS in the DOS business, if at all possible." Exhibit 133.
175. In the week following announcement of the DRI/Novell merger, trade press reported the larger IBM/Novell alliance taking shape:
Looming above the Novell/DRI merger is the specter of IBM, which stands to capitalize by reselling DR DOS, thereby freeing itself from its dependence on Microsoft's DOS.
Exhibit 152 (PC Week, July 22, 1991)
176. Brad Silverberg fixated on the possible IBM/Novell relationship as a clear danger:
The more I think about it, the more convinced I am that IBM will license DR-DOS now from Novell. After DR-DOS 6 comes out later this year (before october), IBM will ship it on their dos based machines, and call it PC-DOS 6.0 (echoes of what we've done with OS/2 3.0 by taking the next version number away from the "rightful owner").
If you were IBM and wanted to strike hard at Microsoft, you'd do it. To gain power, IBM's got to take it away from Microsoft, and our power starts with DOS.
Exhibit 151
177. On September 23, 1991, IBM strongly endorsed DR DOS 6.0:
"We think [DR DOS 6.0] is excellent technology," said Joseph Guglielmi, IBM's general manager of marketing and business development for personal systems.
"We're talking with Novell [Inc.] and DRI on a variety of alternatives," Guglielmi confirmed.
Exhibit 190 (Computer Reseller News, September 23, 1991)
The article broadly disclosed the breadth and depth of the "alliance" IBM intended to forge with Novell.
178. Within a week, Bill Gates was on record publicly vowing to retaliate against IBM should it move to DR DOS:
In an interview with PC Week, Microsoft Chairman and CEO Gates threatened to retaliate by selling DOS for new IBM computers. Currently, Microsoft sells only upgrade versions of DOS directly, while all DOS sales for new PCs are handled by OEMs.
"If they endorse DR DOS, I can offer people the real product," said Gates. "It may enable me to go after a large [new] business." He said he would not pursue DOS sales for other OEMs' computers.
Exhibit 200 (PC Week, September 30, 1991)
179. Microsoft realized that if IBM announced support for DR DOS, numerous OEMs were likely to follow. Exhibit 215. By October 16, 1992, Brad Chase submitted to the executive staff the formal plan for "Response if IBM ships DR DOS" -- complete with approved press releases, FUD points, and a Rude Q&A. Exhibit 219. The main attack, however, would be a single package of MS-DOS 5.0 and Windows 3.0, offered directly to purchasers of IBM PS/2 systems. Id.
180. Due to the threatened retaliation, and because of the intense FUD Microsoft created concerning future compatibility with Windows, see infra 195-264, IBM withdrew from consideration of DR DOS shortly before the launch of Windows 3.1. See, e.g., Exhibit 268.
181. Gates did not want to compete against Novell on the desktop. He called Noorda on July 18, 1991 -- the day following the DRI/Novell merger announcement -- and stated that he wanted to institute merger discussions. Gates made very clear, however, that prerequisite to any Microsoft/Novell merger was the divestiture of DRI. Gates told Noorda "that DRI's got to go." Noorda responded that the merger Gates was proposing might have problems getting government approval, but Gates declared that he knew how to handle the government. Noorda Decl. at 5; see also Exhibit 407 (National Review, January 24, 1994) ("'There was only one stipulation,' says Noorda, 'Gates told me, That DRI thing has to go'"). Gates admitted to making the call, and to raising the question whether DRI would have to fall by the wayside. Gates Depo. at 294-295.
182. Noorda assumed that Microsoft's overture was made in good faith, and so informed Novell's Board of Directors that he was pursuing Gates' offer. Shortly thereafter, a series of talks commenced between the companies and their lawyers when Noorda and Gates met in the American Airlines lounge in the San Francisco airport. The talks continued sporadically for the next eight months, primarily focusing on the antitrust problems posed by the merger and how to win FTC approval. See Noorda Decl. at 6-12; Exhibit 374; Exhibit 182. Gates generally confirmed this course of events in his deposition. Gates Depo. at 294-295.
183. In March 1992, however, Noorda called off the meetings when Microsoft, without warning to Novell, announced its acquisition of Fox Corporation. Adding Fox (and thus the separate desktop database market) to the equation exacerbated the problems of getting FTC approval and convinced Noorda that Microsoft did not intend to complete a merger with Novell. Noorda Decl. at 9; Exhibit 374.
184. In retrospect, Noorda viewed the entire negotiations as a ploy by Gates to hobble the development of DR DOS as a competitor to MS-DOS. By merely initiating the discussions, Microsoft assured that DRI's integration into Novell would be complicated and slowed. Noorda Decl. at 11-13.
185. In its many Motions for Summary Judgment, Microsoft does not deny or rebut Caldera's allegations on this point. See Exhibit 1, 48 (First Amended Complaint).
VI. SEPTEMBER 1991-DECEMBER 1993:
DR DOS 6.0, ADVANCING THE STANDARD
186. In September 1991 -- just three months after Microsoft released MS-DOS 5.0, and only two months after DRI and Novell announced their intended merger -- DRI released DR DOS 6.0. Once again, DRI surpassed the features available in the then-current version of MS-DOS. The most important new feature in DR DOS 6.0 responded to users' increasing need for more and more hard disk space by adding on-the-fly compression. This allowed users to store more data in less space. Other new or significantly improved features in DR DOS 6.0 included: task switching (which allowed users to "jump" back and forth between programs); a greatly improved disk cache (which improved performance); improved memory management; and full on-line help for DOS commands. Goodman Report at 20-22. See also Appendix B.
187. DRI hewed tightly to a DR DOS core-product strategy, and crisply executed its design goals: to "maintain aggressive introduction schedule to stay a full generation ahead of latest MS-DOS release at all times" and to "select features based primarily on end-user appeal and/or demonstrable end-user benefit . . . ." Exhibit 93 at C0519438.
188. Gates also acknowledged that the DR DOS 6.0 feature set was compelling. In ordering plans for "Astro" -- the code name for MS-DOS 6.0 -- he stated:
Has anyone ever sent me a proposed list of ASTRO features?
. . .
I think to be successful a DOS update has to have the following features:
. . .
--match the garbage that DR DOS does
Exhibit 285
Return
Table of Contents
Awards, Praise, and Compatibility -- Part 2
189. As with its predecessor DR DOS 5.0, when DR DOS 6.0 shipped in September 1991, positive reviews immediately followed:
Keeping one step ahead of Goliath, Digital Research this week announced and shipped DR DOS 6.0 -- its reply to Microsoft's recently released MS DOS 5.0. Judging from our first look at Digital's most recent operating system, DR DOS 6.0 offers an impressive list of DOS management features and better memory management.
Exhibit 180 (Infoworld, September 16, 1991)
VERDICT More of an operating system than MS-DOS, with no obvious disadvantages.
Exhibit 193 (PC User, September 25, 1991)
DR DOS has a lot going for it. DRI had already made significant headway against MS-DOS earlier this year with DR DOS 5.0 and DRI's successful "Toss Your DOS" campaign. Microsoft's release of MS-DOS 5.0 this summer was clearly in response to the growing acceptance of DR DOS 5.0.
Now, only months after the release of MS-DOS 5.0, DRI has again stepped ahead with the release earlier this month of DR DOS 6.0, which once again matches and exceeds the features and capabilities of Microsoft's product. Though starting from a small base, DR DOS is clearly gaining market share.
Exhibit 200 (PC Week, September 30, 1991) (emphasis added)
Best of COMDEX/Fall
Byte Magazine
WINNER: -- Best Utility Software: Company: Digital Research Inc., Monterrey, CA Product: DR DOS 6.0
Exhibit 228 (Business Wire, October 24, 1991)
DR DOS 6.0 from Digital Research is a brawny mixture of operating system and utilities that appears to stand just a shade taller than its market rival MS-DOS 5.0.
Exhibit 303 (Compute, June 1992)
190. Infoworld again conducted its review. The final score for DR DOS 6.0 was a 7.6, as compared to a revised score of 7.1 for MS-DOS 5.0. Exhibit 235 (Infoworld, November 4, 1991). Merely reviewing the title of other articles indicates the strong praise that greeted DR DOS 6.0. See, e.g., Exhibit 232 (Byte, November 1991, "Digital Research Creates a Better DOS"); Exhibit 233 (PC/Computing, November 1991, "DR DOS 6.0 steals the thunder from MS-DOS in nearly every area"); Exhibit 244 (PC Magazine, November 12, 1991, "DR DOS 6.0 leapfrogs MS-DOS 5.0 with task switching and RAM"); Exhibit 249 (PC Sources, December 1991, "DR DOS: the worthy competitor"); Exhibit 260 (PC World, January 1992, "Staying a few steps ahead of MS-DOS"); Exhibit 271 (Computer Shopper, February 1992, "DR DOS 6.0 is an operating system that really works").
191. Significantly, DR DOS product support received lavish praise from satisfied users, while reaction to MS-DOS product support was not kind:
DR DOS and OS/2, though not hugely represented in terms of the number of respondents, got high ratings for overall satisfaction.
. . .
Still, the smaller numbers were certainly devoted numbers. DR DOS was the clear winner, the only package that scored above average both in overall satisfaction and in technical support.
. . .
Product support was DR DOS's show -- it lacks market share, but satisfied users applauded. DR DOS was the highest-rated in overall technical support, followed by OS/2. It is conspicuous that Microsoft, the vendor of almost half the entries in this category, does not provide a toll-free line. Only Quarterdeck and Novell offer 800-number support. Novell provides its support for 30 days; Quarterdeck's support is unlimited.
Exhibit 366 (PC Magazine, July 1993)
Monopoly Maintenance: Polishing and Improving the Arsenal
192. Paul Maritz testified that "with [Novell] purchasing DR DOS, it was clear that they had decided to compete in the desktop operating systems business, something that had not been explicit beforehand." Maritz Depo. at 101. Steve Ballmer further testified that, with Novell merging with DRI and IBM considering a license of DR DOS, "we were at the most nerve-racking time in our company's history." Ballmer Depo. at 178.
193. When DRI announced that DR DOS 6.0 would hit the streets in September 1991 -- the month prior to the finalization of the merger with Novell -- executives at Microsoft went ballistic, with Allchin again leading the charge:
We must slow down Novell. . . . As you said Bill, it has to be dramatic. . . .
We need to slaughter Novell before they get stronger.
Exhibit 175 (emphasis added)
194. Novell was not just a serious threat to MS-DOS, but was the single competitor in the best position to damage Microsoft on the whole. Jim Allchin made the case to his fellow executives plainly in March 1992:
I still don't think we take them as serious as is required of us to win. This isn't IBM. These guys are really good; they have an installed base; they have a channel; they have marketing power; they have good products. AND they want our position. They want to control the APIs, middleware, and as many desktops as they can in addition to the server market they already own.
We need to start thinking about Novell as THE competitor to fight against -- not in one area of our business, but all of them.
If you want to get serious about stopping Novell, we need to start understanding this is war -- nothing less. That's how Novell views it. We better wake up and get serious about them or they will eventually find a way to hurt us badly.
Exhibit 349 at MS7079459
See also Exhibit 321 at WE025862 ("Novell is after our business and we expect the big push to start this fall. . . . If 1992 was the year of the IBM attack, clearly 1993 is the year of the Novell attack. The difference is that Novell is a better technical and marketing company and they have broad and strong customers and channel loyalty.").
195. FUD -- and specifically, claims that DR DOS would actually cause Windows to break -- became the focus of an intense Microsoft attack following the DRI/Novell merger announcement. On November 7, 1991, David Cole summarized the plan, and the need for appropriate PR "spin":
There is an obvious conflict quickly approaching us, and I get the feeling we are not very prepared PR wise. The conflict is Windows 3.1 and DR-DOS. Apparently DRI is quite aware of our plans to not test with DR-DOS, our plan to not let them enter the Win 3.1 beta program, and our plan to detect the presence of MS-DOS and warn the user they are on an un-tested OS if MS-DOS is not detected.
Exhibit 238
In addition, Microsoft also made several code changes to Windows 3.1 to ensure that DR DOS 6.0 would not run with either betas or the final release version of Windows 3.1. See infra 262-264.
196. To block out DR DOS, Microsoft began explicitly informing OEMs that Microsoft "would guarantee that Windows would not work with DR DOS, and that if they licensed DR DOS they would be making a vital mistake in the marketplace having a product that wouldn't work with Windows." Dixon Depo. at 337; see Reichel Depo. at 61-62, 101.
197. Robert Frankenberg, who at the time was Vice President at Hewlett Packard, testified as to his and the industry's perception of this campaign:
[T]here was a significant amount of fear, uncertainty, and doubt in the industry surrounding whether [DR DOS] would remain compatible with Windows, and that had a significant impact on whether people believed that it would continue to be a viable platform.
Frankenberg Depo. at 56.
198. Customarily, when incompatibilities arise between two products, the practice in the industry is to remedy, or at least promise quickly to remedy, the incompatibilities. This is particularly true with respect to software such as Microsoft Windows, which is designed to run with thousands of other programs. The business rationale is straightforward: The more programs with which the software is compatible, the more users are likely to purchase it. See Ivie Report at 17.
199. One of the purposes of sending beta versions of Windows to independent software developers is to permit them to produce compatible products. Cole Depo. at 88-89. Early and open access to the betas and beta support is critical to having compatible products ready for launch in sync with Windows. Cole Depo. at 90; see also Barrett Depo. at 91-92. Microsoft knew that if the DR DOS development team had been a Windows 3.1 beta site, it would have helped them make DR DOS compatible, and permit them to allay public fears of incompatibility. Chase Dep. at 131-132, 136.
200. Windows and DR DOS were complementary products, and thus did not compete. See Exhibit 448 (diagram depicting relation of applications, Windows, and DOS); Schmalensee Depo. at 393-396. Windows is a graphical extension of the underlying DOS operating system, whether that be MS-DOS or DR DOS. Werner Depo. at 114-115. As such, during the beta test cycle for Windows 3.0, Microsoft readily permitted DR DOS to participate. Constant Depo. at 29, 192; Constant Decl. at 8-9, 17-18. As to Windows 3.1, it is beyond dispute that Microsoft allowed numerous companies to be beta sites even though they competed against Microsoft in some other market.(22)
201. As development of Windows 3.1 began, Microsoft came quickly to the question: would it continue to allow DRI to participate in the beta program? Microsoft knew certain changes it was making to Windows would render Windows incompatible with DR DOS, particularly as to the Windows 3.1 LoadHi VxD.(23) DRI had received early specifications of the VxD, and when DRI followed up in November 1990 with requests for revisions, developers at Microsoft began escalating the question:
Chatterly:
I think it has been decided that Digital Research will not be supported. Rich Abel should have the list of vendors whom we do not want to support. Quite some time back DRI was sent a very early version of the VxD. I don't know what to tell them. I guess, we must somehow politely let them know that we don't want to support them. I don't feel very comfortable in this situation and would not want to deal with Digital myself.
Quigley:
What do we do with this? I think its reasonable to give them the latest version of this VxD and tell them it is unsupported.
Abel:
I think what [Quigley] suggests is reasonable. I'm of the opinion that people like dri get this stuff anyway and we need to give equal access to equivalent third parties to this sort of info.
Exhibit 97 (emphasis added)
202. By December 2, 1990, the question had escalated to David Cole and Phil Barrett:
Cole:
Uhmm . . denying DRI the VxD smells of an anti-trust lawsuit. You are not supposed to use your control of one market, in this case Windows, to influence another market, in this case DOS. err something like that.
I think this will blow up if we don't give them the VxD.
Barrett:
lets just let legal tell us what our options are. If there is potential for antitrust or what ever, they will tell us.
Exhibit 99 (emphasis added)
203. Rich Abel ultimately sent DRI the revised VxD. Exhibit 217 (Ewald memo on acquisition). When Silverberg learned of this, he instructed that DRI receive no further cooperation. Thus, DRI is conspicuously absent from the beta distribution lists for Windows 3.1 dated May 31, 1991. Exhibit 131.
204. Even so, DRI later requested, and received, a portion of code identified as the "task switching api." This provoked quite an outburst by Silverberg on June 10, 1991:
Jain:
As I was telling you that Digital Research is on our list as a recipient of Task switching API but the surprising thing is that the address we have is in UK. I wonder if they have a branch in UK or there is some other company with the same name.
Silverberg:
I want to know how the got sent the task switch api. I have a hard time believing this, and a harder time accepting it. dri development is in the uk.
after I learned that we sent dr the win vxd I went on a rampage and everyone assured me dr was off of all our mailing lists.
how could this happen?
Exhibit 135
205. A mere four days before Novell and DRI announced their merger, Microsoft had formalized its beta policy into something called the "WINDOWS/DOS BETA BLACKLIST." DRI (but not Novell) is listed on this first "beta blacklist" from July 13, 1991. Exhibit 146.(24)
206. On July 17, 1991, the day the DRI/Novell merger was announced, the beta blacklist became a prominent issue. David Cole ranted:
We cannot let DR DOS get beta versions of Windows. Surely something in the agreement must cover a "redefinition" of what the heck the "company" is.
We should have a telegram issued first thing in the morning from MS legal which forbids Novell to hand beta Windows over to DR.
Bradsi, is this too drastic?
Exhibit 147 (emphasis added)
207. Conversations among Microsoft executives over the following days made clear that the concern was not that DRI or Novell might be working on a "clone" of Windows. The concern was simply to ensure that DRI had plenty of trouble getting DR DOS to work with Windows. On July 28, 1991, the question was resolved at the highest levels of Microsoft:
Arnej:
Valid comments. We can't expect our engineers to know how to handle "black-list" issues unless we clearly communicate how to handle. From an FTC standpoint situations like this could be very dangerous, and should probably be handled by higher management.
In addition what happens if DRI actually buys a Support Advantage contract? Does the sales team know not to sell it to them. If they sell DRI a contract, I cannot see how we can refuse support.
Ballmer:
brad pls make sure we are not supporting DRI anywhere in the company with this stuff thx
Silverberg:
We are not going to change our products to work with them and we're not going to help DRI determine what they need to do to change their products to support ours.
Exhibit 155 at X584923 (emphasis added)
208. The next day, Silverberg made sure that Microsoft product support services had directly received his instruction:
We should not be providing Digital Research any assistance getting their os to work with our software. Our software supports ms dos, not dr dos. It's completely up to them to figure out and resolve any problems that may occur.
Exhibit 156 (emphasis added)
209. Because DRI was now clearly on notice of Microsoft's intent, it submitted a formal request to become a beta site. Brad Chase testified that DRI's request was reasonable. Chase Depo. at 123-124. But on August 2, 1991, Silverberg specifically denied the request:
Digital Research would like someone to become a beta site. They would like to enable their operating system to support Windows 3.10. Specifically they need to modify the Load Hi VxD (now part of VMM) allowing their memory manager to function correctly.
Um, I don't think so.
kala, please make sure this request doesn't get filled.
Exhibit 158
210. Microsoft knew that it faced a dilemma: Windows and DR DOS did not compete, and thus no legitimate pro-competitive reasons existed to withhold the beta. Discussions among the Microsoft executive staff led to a most Orwellian resolution. On August 15, 1991, Silverberg reported to his development team dealing with the beta blacklist issue:
We recently decided to start referring to Windows as an operating system in our communications, not a graphical environment or user interface for dos. we should be consistent in the new usage. thanks.
Exhibit 164
Microsoft thus began propagating the fiction that continues to this day: Windows and DR DOS somehow competed, and so it was "okay" to exclude DRI from the beta test cycle.(25)
211. When beta testers called in with questions concerning the interoperability of Windows 3.1 and DR DOS, they were explicitly informed that Microsoft did not want Windows to work with DR DOS. On October 31, 1991, Andy Hill told his Windows 3.1 beta staff:
For beta testers that report problems w/ DR DOS and 3.1:
DR-DOS is an untested and therefore unsupported operating system. MS-DOS (or OEM versions of it) is required for Windows. Using DR-DOS with Microsoft Windows is at the sole risk of the user. We don't support it.
Exhibit 231 (emphasis added)
See also Hill FTC Depo. at 69-70; Frankenberg Depo. at 295-297. On November 11, 1991, a DR DOS user informed DRI that he had called Microsoft about rumors of Windows 3.1 problems, and "was quite rudely told that, 'there are several detrimental incompatibilities with the upcoming release of Windows 3.1 and DR DOS 6, but it is not our problem!'" Exhibit 247.
212. On December 9, 1991, the first report of the DRI beta blacklist hit the pages of PC Week, in an article titled "Microsoft won't help fix DR-DOS--WIN 3.1 woes." The magazine clearly articulated the realities of the situation:
Microsoft officials have said they won't help Digital Research Inc. (DRI) resolve incompatibilities between Windows 3.1 -- over which the companies don't compete -- and DRI's DR DOS's 6.0, which challenges Microsoft's DOS monopoly. Users have reported problems getting DR DOS and the beta version of Windows 3.1 to work together, and the two appeared incompatible in an examination by PC Week last week. Microsoft works with DRI's parent company, Novell Inc., to ensure that NetWare works with Windows, despite competition between NetWare and Microsoft's LANManager.
Microsoft has also helped vendors of memory-management products, including Qualitas Inc. and Quarterdeck Office Systems, update their respective 386 Max and QEMM-386 products for Windows 3.1. DR DOS uses similar technology. However, Microsoft officials say Windows is designed and tested only for MS-DOS.
Microsoft is not obligated to help DRI ensure DR DOS compatibility with Windows 3.1, said Jonathan Lazarus, general manager of systems marketing for Microsoft in Redmond, Wash.
"It's not my problem," said Lazarus. "It's their problem."
. . .
The compatibility problems appear to be caused by changes Microsoft made to the Windows interface for third-party memory managers.
"We had to do things to get 386Max to work with 3.1," said Paul Tarlow, Qualitas' director of technical marketing in Bethesda, Md. "Our developers spend as much as a couple hours a day on the phone with Microsoft's top developers. They've been absolutely helpful." In an examination of the Windows 3.1 beta, PC Week found the incompatibility problems centered on the DR DOS MemoryMax memory manager.
Exhibit 254 (PC Week, December 9, 1991) (emphasis added)
See also Exhibit 257 (Infoworld, December 16, 1991) ("Microsoft balks at fixing DR DOS, Windows bugs; DRI cites responsibility to users"). The industry was now on notice that revisions to Windows 3.1 had made it incompatible with DR DOS, and that Microsoft intended to keep it that way as long as possible.
213. Claire Lematta was the PR operative at Waggener Edstrom in charge of the Windows 3.1 release. She had previously advised Silverberg, on November 7, 1991, of the dangerous course Microsoft chose:
PR is going to have limited ability to help you if Microsoft is deliberately and selectively keeping DRI from participating in the beta program. That is, if you are making a special case of them that is not consistent with the way that the beta program is being administered for the rest of the industry.
Exhibit 238
214. When Lematta inquired of Silverberg concerning the above PC Week story, Silverberg made clear the intent of this entire ruse:
fact is, I'm sure they already have win 3.1 anyways. with 10,000 betas, all it takes is one drdos user to send it to them.
they admitted (in an interview in hong kong computerworld) that they had msdos5 beta. so I'm sure they have win3.1 and this is just a pr game.
Exhibit 251 (emphasis added)
215. The beta blacklist thus had nothing to do with any purported threat of a coming Windows clone. Neither did it have anything to do with the notion that Windows 3.1 and DR DOS were competitors. Instead, it had to do with FUD: Microsoft would manipulate the beta blacklist to its advantage, propagating a story to the world that DR DOS would not be able to achieve compatibility with new versions of Windows, while Novell's hands were tied to rebut these slurs and innuendos. In further conversations with Pam Edstrom -- Lematta's superior -- on December 10, 1991, Silverberg patently displayed the nature of the FUD involved:
oem's and corporations that are thinking about standardizing on dr-dos now have reasons to worry about their decision. they know they will have problems now, and they know we are not going to help dr-dos compete with us.
Exhibit 256 (emphasis added)
216. The tactic worked. On January 20, 1992, DRI was notified, for instance, by a potential corporate account of its decision to reject DR DOS 6.0:
What I feel is the most important factor however, is the rift developing between Digital Research and Microsoft. By this I mean Microsoft not allowing you to beta test Windows 3.1. Since the users who would be most inclined to switch to DR DOS are also using Windows, this one factor is of particular concern.
Exhibit 266 (emphasis added)
Chatter on Microsoft's beta CompuServe forum reflected similar conclusions on the issue. See, e.g., Exhibit 443 ("if Microsoft is going to make life difficult for DR I guess DR DOS isn't an option since I need to run the current betas").
217. The tactic worked so well, in fact, that Novell approached Microsoft towards the conclusion of the Windows 3.1 beta program with the proposal for a cooperative outlook in the future. Microsoft's arrogance was astounding:
Silverberg:
You'll enjoy this. We just got from Novell a proposal for a new project:
"Under this Development Project, known as Corvette, Microsoft will license EMM386 and HIMEM memory managers in their Source Code to Novell and will provide technical support to Novell in Novell's effort to make DR-DOS compatible with all current and future version of Microsoft Windows 3.1 and Windows NT."
Cole:
I'm rolling on the ground laughing . . . . . :)
Barrett:
And I thought them Utah folks were drug free . . .
Allchin:
I hate them.
Exhibits 281, 282, 283
218. Windows 3.1 launched worldwide on April 6, 1992. Exhibit 290. Users immediately bombarded Microsoft PSS with requests concerning problems with setting up Windows 3.1 over DR DOS. During the beta cycle, Silverberg had told beta support to "post a nice SOL [shit-out-of-luck?] message. bottom line is that he needs msdos -- something that is compatible with windows." Exhibit 263 at X0594633. This hardcore approach continued even with users of the actual, shipping product. On April 9, 1992, Microsoft PSS reached the following decision:
georga:
What can we tell a customer about compatibility or non with DR DOS 6? . . . Can we give them a workaround, or tell them to buy MS-DOS 5?
Hill:
The standard response is: Windows is only tested with MS-DOS operating systems. DR-DOS claims to be 100% compatible with MS-DOS, so if that is true, then the user shouldn't have any problems.
There is really nothing we can do.
Exhibit 291 (emphasis added)
219. Yet Silverberg directed PSS that same day to take an even stronger tack:
windows is designed and tested for ms-dos. not dr-dos. it says MS-DOS on the box, not MS-DOS or DR-DOS . . . this is what to tell the world (in a nice way). using a system other than ms-dos puts the user at his own risk. it says this very clearly first thing in the readme.
there is another "fix" for them: use ms-dos. that should be mentioned in addition to telling them that digital research is providing them with a new version.
Exhibit 292 (emphasis added)
220. Microsoft PSS followed through. A disgruntled end-user in Canada wrote Novell in July 1992:
This morning I called Microsoft Canada looking for help. They told me I've purchased the WRONG operating system and that MSDOS 5 is the only answer. To help me correct the error of my ways (purchasing DRDOS 6) they will help me by exchanging my Digital Research products for Microsoft products providing, I give the letter outlining my problems and disappointment with your products and support.
I personally do not want to be part of your battles with MS, I just want my PC up and running Windows 3.1, can you please help me by faxing me step by step instructions to make this happen or just say switch to MSDOS and I will.
Exhibit 317 (emphasis added)
221. Novell was inundated with letters and requests from DR DOS users trying to get Windows 3.1 to run. Exhibit 296 is a sampling of such letters dated between April 27 and June 30, 1992. These letters reflect exactly the sorts of problems and complaints open, customary beta tests are designed to circumvent.(26)
222. Novell quickly shipped an update to allow DR DOS 6.0 to run under Windows 3.1. Exhibit 293 (PC Week, April 20, 1992) ("DR DOS 6.0 Update Runs Under WIN 3.1"). But the damage was done. When coupled with the AARD code and intentional incompatibility episodes -- discussed next -- users began to perceive the malevolence of Microsoft's intent and its ability to make that intent reality. OEMs and end users abandoned DR DOS in droves.
223. Bill Gates said it best: "Every message coming out of a computer has the potential for being confusing." Gates Depo. at 101-102. Microsoft leveraged this fact to maximum effect in what its attorneys now claim to be the "benign" message that was the AARD code.
224. In December 1991, Microsoft released a beta version of Windows 3.1 that -- unbeknownst to users, testers, and the press -- included secret encrypted code designed to produce false error messages when users tried to install and run Windows 3.1 on DR DOS. The messages themselves told the user that an "error" had occurred, but failed to describe the error, the cause of the error, or whether it was safe to proceed. Microsoft carefully hid the code in five different modules, encrypting it to make it difficult for anyone to discover that the "errors" were not errors, but rather were messages generated by obfuscated code as part of Microsoft's campaign to persuade users that DR DOS was incompatible with Windows. Hollaar Report at 2-14.
225. The record is unclear exactly when the AARD code was dreamed up for the Windows 3.1 beta cycle. Even the author of the code testified to no knowledge of who instigated this coding excursion. Reynolds Depo. at 17-18; see also Cole Depo. at 104-105. By September 27, 1991, however, plans were sufficiently advanced to generate debate -- and dissent -- within Microsoft:
Chase:
Two cents from richf and I:
1) The check for dr dos better be perfect. otherwise you could be in a heep of trouble (ex comes up on compaq or zenith dos). Moreover, this check better be good enough so that dr dos does not work around it and prevent the message from coming up
2) The message has to be consistent with our other error messages (caution box etc.) and avoid making us look bad. The message below, in my opinion, leads us open to bad PR -- it surely is the outer boundry of rudeness. It is also fairly extreme compared to others in the product we have seen.
3) The point is to tell users we don't work and that they should proceed with caution -- we can do this more professionally
Abel:
I hate this whole thing. I think it's totally rude, reinforces the image that users have of us as the evil ones, etc.
Exhibit 194 (emphasis added)
226. Reynolds wrote and tested the code himself in approximately seven days. Reynolds Depo. at 30-31. By November 8, 1991, the decision had been made to implement the AARD code in the final beta of Windows 3.1. See Exhibit 239.
227. Microsoft chose to work covertly, rather than in open communication with the developers and end-users that it purportedly wanted to help:
5. What will be in the Final beta
Detection for the absence of MS-DOS will be in the Final Beta Release (AKA beta 3) but the message will not. Instead, the message will say: Non-fatal error detected: error # (Please contact Windows 3.1 beta support)
This will allow us to widely test our detection scheme, but not cause undue PR problems.
Exhibit 248 at MS7003705-706 (emphasis added)
228. The Windows 3.1 beta containing the AARD code shipped just prior to Christmas in 1991, and went out to a staggering 12,000 to 15,000 sites. Cole Depo. at 178; Exhibit 290. This Christmas beta was deemed a "preview" beta, which was "a marketing tool to get the product into the hands of people making buying decisions." Barrett Depo. at 77 (emphasis added). Members of the press also got this beta. Id.; Cole Depo. at 178.
229. Microsoft anticipated that the non-fatal error message would be alarming and controversial, and that as a PR matter, they would need to lie:
Hill:
Janine has brought up some good questions on how we handle the error messages that the users will get if they aren't using MS-DOS.
-- The beta testers will ask questions. How should the techs respond: Ignorance, the truth, other?
-- This will no doubt raise a stir on Compuserve. We should either be proactive and post something up there now, or have a response already constructed so we can flash it up there as soon as the issue arises so we can nip it in the bud before we have a typical CIS snow-ball mutiny.
Cole:
Let's plead ignorance for a while. We need to figure out our overall strategy for this. I'm surprized people aren't flaming yet, maybe they won't.
Exhibit 262 (emphasis added)
230. Chatter on the forum began almost immediately. Such postings were, and would remain, available for viewing by all beta sites -- which included significant OEMs, corporate buyers, influential end-users, and media analysts. Hill FTC Depo. at 28, 30-31, 121-122. Caldera tracked down the following postings related to the AARD code:
December 22, 1991:
I get build 61D downloaded and installed. I am reporting the effect on reported problems.
I was able to install build 61D on my laptop using MS-DOS 5, with no problems. However, when starting this, under DR DOS, I get a non fatal error number 2726 upon startup. I enter C to continue. Everything appears to work properly anyway. I realize that this is most probably due to problems with DR DOS.
December 28, 1991:
While setting up a beta test on DR DOS 6.0 the following was noted:
Non fatal error detected error number 4D53
I will make a report on the correct form after I try to reproduce the problem on another machine with DR DOS 6.0.
January 12, 1992:
I don't know about you but I have encountered some problems using DR DOS 6.0 with 3.1. Even with my config.sys and Autoexec.bat stripped down, I still get an error message on startup, but performance was adequate, despite the non fatal error.
Of note is an article I read in a local computer freebie magazine, that accused MS of designing 3.1 to not work with DR DOS 6. I assume (hope) that this is not true.
January 22, 1992:
I am receiving an error: non fatal error 2726 when starting Windows 3.1. Windows then starts correctly, but this error is printed every time Windows is started. The problem goes away if I boot under Compaq DOS 3.1. My regular operating system is DR DOS 6.0. Is there an incompatibility between DR DOS and Windows?
February 14, 1992:
I got some trouble with WIN 31 (final beta) on setup over a previously installed Windows 3.0 -- after starting setup (automatic mode) the message -- non fatal error detected number 453 -- appeared. Setup continued its work but after copying all files setup quits with standard mode: fault inms-DOS extender. I'm running DR DOS 6.0 on a compatible 386/DX with 4MB -- I tried to setup also with a minimalized config and autoexec (without any memory optimumization) without success. What can I do???
March 4, 1992:
Beta Site:
I thought I'd try RC 1 on DR DOS 5.0, in standard mode. Everything seems to work identically to MS-DOS 5 (I would prefer MS-DOS, though). However, a funny message is displayed.
Non fatal error detected: error number 2726
Please contact Windows 3.1 data support.
Press ENTER to cancel, or C to continue.
(Well, I * am * contacting beta support . . .)
If I press C, it works okay. However, this messes up my "automatic" batch test file I have. Is there any way to eliminate this message?
Microsoft:
Greg, you should be able to get rid of the message by using MS-DOS instead of DR DOS. You should send in a copy of bootable DR DOS floppy disk, with the error number written on the label. Send it to: Andy Thomas, Microsoft Building 3/1155, One Microsoft Way, Redmond, WA 98052-9953
Exhibit 443 (emphasis added)
231. The foregoing messages objectively reveal that the beta sites believed the error message to indicate a compatibility problem with DR DOS 6.0. Cole testified that the term "non-fatal error" could, in fact, give the impression of actual incompatibility:
Well, like, non-fatal error generally refers to the case where an error had occurred but it's not fatal to the product, meaning the product, you know, probably won't crash in the next few minutes or whatever.
Cole Depo. at 102
See also Werner Depo. at 235-236 ("A nonfatal error message is a message that -- about some event that's going to occur that is an error, but it won't crash your system").
232. Yet the author of the AARD could not have testified more clearly that the error message represented a false incompatibility: "There's no problem." Reynolds Depo. at 79.
233. The AARD code episode directly impacted OEM review of DR DOS. Testimony establishes that OEMs discussed the error message amongst themselves. Harvey Depo. at 24-25. Stephanie Reichel, the Vobis OEM account manager, testified that Theo Lieven, Vobis' CEO, specifically expressed he was "concerned" about the nonfatal error message. Reichel Depo. at 58. Bruce Fryer, product strategy manager of Zenith Data Systems in 1992, testified his software engineers ran afoul of the AARD code during beta tests of Windows 3.1 on DR DOS. Fryer Depo. at 59. These engineers determined that "this error message in fact didn't reflect any operational problems or incompatibilities." Id. at 110. Even so, Zenith abandoned any further consideration of DR DOS 6.0 based on fear that "Microsoft might intentionally put code in Windows that would cause problems with DR DOS." Id. at 112. Other OEM deponents testified that a "nonfatal error" would cause "a great deal of concern among the testers." Bachelor Depo. at 80-81. This was "[b]ecause we wanted compatibility in the products," and "those nonfatal error messages could cause just those sorts of concerns . . . ." Id. at 81. See also Frankenberg Depo. at 105 ("Well, it would be an indication that this software wasn't completely bug free, that it had problems of some type in interacting with other software on the system . . . ."); Harvey Depo. at 27 ("It means there is something wrong").
234. While beta testers debated the AARD code's cryptic meaning, Microsoft executives debated how to respond to the questions raised by the beta sites. On January 17, 1992, Cole escalated the following beta report:
Beta Site:
After your message, I took some time to work on the problem a little. I can make the problem go away if I boot from a floppy with compaq dos ver 3.31. My regular operating system is DRDOS 6.0. Is there an incompatibility between DRDOS and Windows?
Hill:
Here's the first time a tester has outright asked us this question. How do we respond?
Cole:
bradsi, it's time to set the wheels in motion on this. I have a feeling the meat is in the water. . . .
Here's the response I'd like to post:
Windows 3.1 is designed and tested only on MS-DOS and OEM versions of MS-DOS version 3.1 and higher. Running Windows on an operating system other than MS-DOS will cause unpredictable results.
So that our Windows customers are fully aware of the hazards of running Windows on a non-supported operating system, Windows detects for the presence of MS-DOS and warns the user if it is not found. The final beta includes this detection code and the non-fatal error message you are seeing. The final product will contain a more complete warning message, and as with the final beta, the user will be allowed to continue using Windows.
Our goal here is to help the user get Windows up and running in a stable environment. As you may have noticed, Windows 3.1 also warns the user about incompatible TSRs.
Exhibit 264 at X0594619-620
235. No such response was ever posted to clarify the situation. Instead, Microsoft left its beta sites in ignorance as to the true cause of their "problems" -- or worse, for Microsoft PSS also advised the forum that "you should be able to get rid of the message by using MS-DOS instead of DR DOS." Exhibit 443. Worse still, some OEMs who called in were told that "Windows was not supposed to work with DR DOS." Reichel Depo. at 61-62.
236. For his part, Brad Silverberg gave exceedingly misleading explanations for the "nonfatal error" messages. On January 20, 1992, he posted on the CompuServe forum this message: "There is no code in Windows that says, 'if DR-DOS then . . .' . We don't detect it." Exhibit 443. When interviewed in April 1992 upon the release of Windows 3.1 -- after the decision not to activate the AARD code beyond the beta cycle -- Silverberg stated "there's no code inside Windows that checks 'is this MS-DOS?'" Exhibit 288 (PC World, April 1992). Neither answer was the whole truth: the former failed to disclose "but we do detect MS-DOS"; the latter failed to disclose "but we did check that during the final, preview beta."
237. Throughout January and February 1992, Microsoft executives debated and wordsmithed what "message" should be inserted in the released version of Windows 3.1.(27) Microsoft's purported justification now -- that PSS asked it be included to aid support -- is not mentioned.(28) Instead, the goal was "to spin this more towards the notion that windows and ms-dos are two integral pieces to one operating system, not separate independent pieces." Exhibit 265. At the same time, the executives looked for a clever way to say the detection was not of DR DOS, which -- semantics aside -- it plainly was. Indeed, at one point as late as January 28, 1992, the message was to state: "The Windows setup program has detected another operating system on your machine." Exhibit 270. This prompted Silverberg's concern:
i am wondering if we should change the detection words to say we failed to detect ms-dos, rather than say we detected an os other than ms-dos. the latter words would make people think we are looking for drdos . . . .
Exhibit 270
238. By February 7, 1992, Silverberg reported that "steveb said put in a kindler gentler message." Exhibit 275. This prompted an exchange between Cole and Silverberg three days later that laid bare the exact purpose behind this entire scheme:
Cole:
A kind-gentle message in setup would probably not offend anyone and probably won't get the press up in arms, but I don't think it serves much of a warning. BillP made an excellent point, what is the guy supposed to do?
Silverberg:
what the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is dr-dos and then go out to buy ms-dos. or decide to not take the risk for the other machines he has to buy for in the office.
Exhibit 277
Exhibit 278 at MS5050849-850 (emphasis added)
Brad Chase, on the other hand, testified it was improper "to make a beta customer feel uncomfortable." Chase Depo. at 119.
239. Ultimately, the code was disabled in the final version by executive decision concerned over the negative "PR impact." Exhibit 279. But those within Microsoft's marketing group recognized that the AARD code and related FUD had taken its toll on DR DOS. On April 21, 1992, Chase received this report and recommendation:
SQUEEZE DR:
It's truly a wonderful thing that we've done to DR's sales in the last 2 mos. Some of this was due to W31 FUD, much was due to our price promo.
Other things to consider:
-- OS/2, DR- DOS: Can we do anything with Astro to screw OS/2 or DR-DOS compatibility claims?
Exhibit 294
Industry observers came to realize the same effect. See Exhibit 326 (PC Magazine, September 15, 1992) ("fears of incompatibility, especially with Windows, have kept DR DOS at bay").
240. In 1993, Andrew Schulman and Geoff Chappell -- two clever and incredibly thorough technology buffs -- succeeded in de-encrypting and unraveling the mysterious AARD code. Schulman passed along their findings to the FTC, and also engaged in some conversations concerning the AARD code with Silverberg. Exhibit 363.
241. Silverberg trotted out the same justification -- product support -- that Microsoft trots out in its summary judgment motions now. Schulman adroitly rebutted those arguments in a simple missive to Silverberg on July 23, 1993:
Yes, vendors, including MS, should have the right to avoid having to do tech support for others' buggy products. Thus, it might have been ok for Windows to issue warnings when running on DR DOS. For example, I believe VC++ does this when running on OS/2 2.0, which has an apparently very crummy DOS emulation.
But if that is the goal, the code can be very simple: check for the presence of whatever environment is treated with suspicion, and put up a clear warning message.
Now, if MS simply wanted to avoid taking on the burden of the tech-support for DR DOS, then surely there were other ways to do this?
If Windows has such strict requirements for what it expects in an underlying DOS, couldn't MS document the necessary specifications?
Why the purely arbitrary test that only MS-DOS would pass, and then why encrypt it, obfuscate it, and attempt to disable a debugger that's stepping through it?
No, I think the code is very sleazy.
Exhibit 369 at MS5037291-292 (emphasis added)
242. Schulman published his findings on the AARD code in the September 1993 issue of Dr. Dobb's Journal, "Examining the Windows AARD Detection Code." Exhibit 381. Dr. Dobb's Journal subsequently reprinted letters exchanged between Silverberg and Schulman in its January 1994 issue. Exhibit 403. Specifics from all of these articles will be discussed and developed as pertinent in Caldera's separate legal brief related to Microsoft's summary judgment motion concerning the AARD code.
243. Following Novell's announcement of its impending merger with DRI, Microsoft executives began to consider implementing intentional incompatibilities in the war against DR DOS. On July 17, 1991, Allchin proposed to Microsoft's top five executives, that "we . . . consider changing our apps to not run unless the OS is our OS." Exhibit 280 at X0196202.
244. By September 1991, Microsoft became increasingly concerned about the possibility of a partnership between IBM and Novell involving DR DOS. See supra 174-180. Conspicuously, at the same time Microsoft explicitly laid plans to make changes to Windows 3.1 that would thwart its compatibility with DR DOS 6.0. On September 27, 1991, Silverberg and Allchin corresponded:
Silverberg:
after IBM announces support for dr-dos at comdex, it's a small step for them to also announce they will be selling netware lite. maybe at comdex, maybe sometime soon thereafter. but count on it.
we don't know precisely what ibm is going to announce. my best hunch is that they will offer dr-dos as the preferred solution for 286, os2 2.0 for 386. they will also probably continue to offer msdos at $165 (drdos for $99). drdos has problems running windows today, and I assume will have more problems in the future.
Allchin:
You should make sure it has problems in the future. ;-)
Exhibit 197 at MS5053975 (emphasis added)
245. Scarcely four hours later, Silverberg asked Barrett what he was planning to do in response to Allchin's suggestion:
Silverberg:
can you tell me specifically what we're going to do to bind ourselves closer to ms dos? since you haven't been replying to my messages, I don't know how to interpret your silence. Let me emphasize the importance; ibm is going to announce the drdos deal at comdex (almost 100% certain).
OK?
Barrett:
Sorry for the silence -- dont interpret it as ignoring you.
The approach that ralph and I have discussed is to use a vxd to 'extend' dos by patching it. In this case, we would create a subfunction in the findfirst/findnext family-findabunch to allow filemanager to make a single call to get directory information. We would not patch unknown OSs and, most likely, would only patch MS DOS 5.x. The big advantage here is that it provides a legitimate performance improvement. However, it wont prevent us from running on foreign OSs (unless we explicitly decide to refuse to run) -- they just wont run as fast.
Is this the approach you want to take? Or would you prefer a simple check and refuse to run? Thats a lot easier but clearly quite defeatable. I'll come and talk to you about it.
Silverberg:
let's talk.
Exhibit 198 (emphasis added)
246. On September 30, 1991, Cole put the question explicitly to Silverberg and Barrett as to how and where Windows 3.1 would be designed intentionally incompatible with DR DOS:
It's pretty clear we need to make sure Windows 3.1 only runs on top of MS DOS or an OEM version of it. I checked with legal, and they are working up some text we are suppose to display if someone tries to setup or run Windows on a alien operating system. We are suppose to give the user the option of continuing after the warning. However, we should surely crash at some point shortly later.
Now to the point of this mail. How shall we proceed on the issue of making sure Win 3.1 requires MS DOS. We need to have some pretty fancy internal checks to make sure we are on the right one. Maybe there are several very sophisticated checks so that competitors get put on a treadmill. Aaronr had some pretty wild ideas after 3 or so beers, earleh has some too. We need to make sure this doesn't distract the team for a couple of reasons 1) the pure distraction factor 2) the less people know about exactly what gets done, the better.
Please advise.
Exhibit 206 (emphasis added)
247. Cole now disclaims any recollection whatsoever as to anything having to do with this e-mail or its subject matter. Cole Depo. at 212-218, 221-225. Neither Cole nor any other witness would testify as to any recollection as to what was done to ensure incompatibility. See Silverberg Depo. at 176-196; Barrett Depo. at 193-194.
248. But that a decision had been made -- and that all on the coding team knew DR DOS was to be incompatible with Windows 3.1 -- is clear. When Silverberg directed that the team change all text displays in Windows 3.1 from "DOS" to "MS-DOS," Cole responded:
I don't understand this. Are you saying you want the "DOS" prompt to become the "MS-DOS" prompt?
Given the fact the Win 3.1 will only run on MS-DOS, the rest of this seems a bit silly.
. . .
I personally don't think this is going to matter squat since we will only run with MS-DOS. However, we're checking with user-ed on the impact. We are past visual freeze, so this won't be an easy change.
Exhibit 221 (emphasis added)
Exhibit 222 (emphasis added)
249. As well, when considering blacklist issues raised by the coming DRI/Novell merger, Silverberg stated on September 24, 1991:
novell can certainly test themselves with dr-dos. but cannot distribute our beta to digital research.
. . .
remind kaikal that we do not support windows on DR DOS. they are on their own. < there are plenty of problems, too. hee hee >.
Exhibit 191 (emphasis added)
250. On October 29, 1991, Freedman reported that he had tested a Windows 3.1 beta on DR DOS 6.0, and that Windows 3.1 ran just fine: "In short, I haven't seen any basic kernel incompatibilities." Exhibit 230. Silverberg knew, however, that the latest build was designed to fail on DR DOS 6, which prompted his question back to Freedman: "which version of win 3.1?" Id.
251. Microsoft's arguments now -- and denial by its developers that they intentionally broke DR DOS -- are starkly at odds with a series of e-mails between its developers on September 29 and September 30, 1991:
Stevens
I tracked down a serious incompatibility with DR-DOS 6 -- They don't use the 'normal' device driver interface for > 32M partitions. Instead of setting the regular START SECTOR field to Offffh and then using a brand new 32-bit field the way MS-DOS has always done, they simply extended the start sector field by 16 bits.
This seems like a foolish oversight on their part and will likely result in extensive incompatibilities when they try to run with 3rd part device drivers.
I've patched a version of Bambi to work with DRD6, and it seems to run Win 3.1 without difficulty. This same problem may have caused other problems with Win 3.1 and swapfile under DRD6.
It is possible to make Bambi work, assuming we can come up with a reasonably safe method for detecting DRD6.
Barrett:
heh, heh, heh . . .
my proposal is to have bambi refuse to run on this alien OS. comments?
The approach we will take is to detect dr 6 and refuse to load. The error message should be something like 'Invalid device driver interface.'
mike, tom, mack -- do you have a reliable dr6 detection mechanism?
Cole:
It should say unsupported version of DOS.
Exhibit 208 (emphasis added)
Exhibit 207 at MS0098786 (emphasis added)
Exhibit 205 (emphasis added)
Exhibit 199
252. "Bambi was Microsoft's code name for its updated disk cache utility, included with Windows 3.1. Silverberg DOJ Depo. at 498. A disk cache is intended to improve system performance, by taking advantage of available memory to minimize the number of times a computer has to read from and write to a disk. When it works correctly, it speeds performance because information stored in memory can be accessed much more quickly than information stored on a disk. In any event, a September 30 progress report on "Bambi" reported that Barrett's plan had been implemented:
Bambi v.35 has passed developer testing. The primary change fixes a major problem with accessing logical units on external hard disks. Also, DR DOS is detected (needs testing!) and bambi refuses to load.
Exhibit 204 at MS5049398 (emphasis added)
253. Microsoft made direct misrepresentations to the industry when questioned in December 1991 on this exact issue:
Microsoft officials said they have not deliberately made Windows 3.1 incompatible with DR DOS. "We're not going to do anything to prevent them from running," Lazarus said.
Exhibit 254 (PC Week, December 9, 1991) (emphasis added)
254. Silverberg first heard on October 8 that the detection worked, and forwarded this message to Ballmer, Chase and Lennon:
thought you'd appreciate . . . the following excerpt from janineh's win 3.1 beta report:
. . .
Windows 3.1 doesn't run w/ Dr DOS. We sent one person MS DOS 5.0 to use and RandyM is working w/ another large acct. This may stop them from going to Dr Dos 6.0.
Exhibit 216
255. Barrett's question about how to detect DR DOS 6.0 had in fact led to direct contact with DRI to obtain the information by which Microsoft would then code in the incompatibility. On September 30, 1991, a Microsoft programmer -- "cliffg" is his e-mail alias -- stated: " I got the previous mailings info from DR personally. I have a person I can get internals from." Exhibit 202. Later that day, he posted an e-mail stating:
The OFFICIAL way to detect dr. dos is as follows.
1) set the carry flag
2) int 2lh ax = 4452h
3) the carry will be clear if it is dr. dos, and set if it is pc-docs
Exhibit 201
256. "Cliffg" had called DRI and identified himself as "Roger Sour" and requested information necessary to detect DR DOS 6. What transpired is set forth in a letter of October 24, 1991, from DRI to the mysterious "Roger Sour":
It has come to my attention that on September 30, 1991, you contacted the Digital Research Technical Support Department for assistance with DR DOS 6.0. You provided the serial number 1182-0000-006934 to our Technical Support Analyst, Andrew Dyson, and proceeded to ask if there was a way for a program to detect if it is running under that operating system. While this information is not generally handed out, we try to maintain a very cooperative policy toward software manufacturers. In following that policy, Andrew described the technique to do so.
When Andrew asked why you needed the information, you indicated that you were developing portions of the new cache software for the future Windows 3.1 and that you had found a "problem in the DR DOS 6.0 Memory Control Blocks (MCB)". As I understand it, your goal is to identify the presence of DR DOS 6.0 so that your software will terminate itself after warning the end-user that an "unsupported DOS" is being used. Usually, when a software manufacturer feels that something in our operating system is preventing their application from running well, that company works with us to resolve the actual, perceived, or potential conflicts.
Exhibit 229 (emphasis added)
257. Phil Barrett replied on November 1, 1991:
I am the Development Manager for Microsoft Windows 3.1. As such I was given the letter sent by you and addressed to 'Roger Sour' or Director of Windows Development. This was a very odd piece of mail to receive in that there is no one at Microsoft by the name of Roger Sour. Further, whoever this Mr. Sour is, he certainly does not speak for Microsoft. Perhaps you may have been the victim of a prank.
Exhibit 234 (emphasis added)
258. Five days later, on November 6, 1991, the FTC contacted Microsoft about this DR DOS detection scheme. Cole's e-mail summary is evidence that the mysterious "Roger Sour" was well known to them all:
Just got a call from debrav who is dealing with the FTC stuff. The FTC called her this morning and said that DRI called and informed them that Microsoft had moved a couple of DOS guys to the Windows team and that these guys were putting code in Windows that would detect DR DOS and prevent Windows 3.1 from running on DR DOS.
I informed debrav of the latest plan of record, and said she absolutely needed to talk with billp and petermi on the issue before proceeding.
The bothersome part is where the hell is DRI getting their information. Are they just speculating? Seems like a pretty risky thing to do with the FTC? Did they interpret "Roger Sour" thing broadly and conclude we are doing it for Windows?
hmm. . . . .
Exhibit 237 (emphasis added)
259. Barrett's reply to Cole suggests that Microsoft took steps to obstruct any flow of information to the FTC that would aid its investigation:
They are getting very accurate information from an internal source. I dont want a witchhunt but this is out of control. Buck, this is pretty important, I talked to brad and he is in agreement that we should ferret out the leak. The call was most likely made to DR technical support between Sept 29 and Oct 4. I can get the specific number but the tech support angle may be a smoke screen and so we might need to check calls to a wider area (maybe monterey). I have suspicions about one specific person but dont want to say in email.
Exhibit 236 (emphasis added)
260. To close the loop on this sordid tale, DRI again contacted Barrett in response to his previous letter:
Thank you for your letter dated November 1, 1991. I take it from your letter that you do not know who Roger Sour is, that there is no problem between the Windows 3.1 and the DR DOS 6.0 memory control blocks and that Microsoft has no intention of identifying the presence of DR DOS 6.0 so that Windows 3.1 will terminate itself or otherwise inconvenience the end-user because the end-user is running DR DOS instead of MS DOS. Please let me know immediately if my understandings are incorrect.
Exhibit 246 at X0592152 (emphasis added)
261. Barrett replied only as follows:
Thank you for your letter dated November 14, 1991. Because Windows 3.1 is an unreleased product, I cannot disclose details as to specific features or functions in that product.
Exhibit 250
262. "Bambi" was not the only apparent incompatibility with DR DOS introduced by Microsoft during Windows 3.1 beta testing. Microsoft added a gratuitous version check to the Windows 3.1 SETUP program -- the program that installs the Microsoft Windows files onto the user's disk -- which made it impossible for Windows to install on a normal DR DOS system. The check served no purpose, although any user who tried to install Microsoft Windows 3.1 on a DR DOS system was told:
The XMS driver you have installed is not compatible with Windows. You must remove it before SETUP can successfully install Windows.
The message was not just misleading, it was wrong. SETUP was testing for version 2.6 or higher of the XMS driver; DR DOS reported version 2.5. Yet SETUP itself made no use at all of XMS, see Cole FTC Depo. at 18, and any other modules that did make such use, they worked fine with DR DOS' reported version of XMS. See Hollaar Decl. (addressing XMS bug). Thus, although DR DOS' XMS driver was compatible with Windows 3.1, Microsoft's SETUP program made it appear to users as if it were not. And were there any doubt about whose "problem" the error message was, this is the type of compatibility issue that would have been easily resolved during usual and customary beta cycles -- if Microsoft had permitted DR DOS to participate.
263. Microsoft also introduced a bug that would cause a fatal error when users tried to run Windows 3.1 with DR DOS. The bug appeared early in the beta cycle and was included in the production release of Windows 3.1. The fatal error message read "Fault in MS-DOS Extender," and prevented users from installing Windows 3.1. The error resulted from Microsoft's failure to clear what is called the "nested task flag," which is essentially a simple "on/off" switch on the processor. Microsoft knew about the problem; knew the cause of the problem; and knew how to fix it. See Reynolds FTC Depo. at 69-74. Microsoft blamed the problem on DR DOS, however, while preventing DR DOS from fixing the problem (by precluding DRI from participating in the Windows 3.1 beta program). See Hollaar Decl. (addressing nested task flag bug). Microsoft claims the bug was essential to a new feature in Windows 3.1 -- the ability to run setup in "standard" mode -- but that is simply not true. The bug was unnecessary and in fact made it more difficult to take advantage of this new feature. Id. Again, this "problem" could have been cured during an open beta cycle -- and the industry would have known Novell was working with Microsoft to correct the issue.
264. As to "Bambi," it is clear that a Microsoft programmer had already fixed any purported "bug" in DR DOS 6.0, but was instructed to detect the presence of DR DOS and refuse to run. See supra 251. At least one version of SmartDrive was sent to beta sites containing code that explicitly checked for DR DOS (via INT 21h function 4452h -- a hexadecimal code that stands for "DR"). See supra 252. With the detection code in place, SmartDrive displayed a "fatal error" message: "Invalid device interface. Unable to load." Importantly, this version of SmartDrive would have worked with DR DOS but for Microsoft's decision to "detect" DR DOS 6.0 and "refuse to load." See Exhibit 208. The "patch" for DR DOS compatibility referred to in Exhibit 208 was not removed, and so the only thing causing DR DOS to "break" was further code inserted by Microsoft. Caldera is prepared to demonstrate this false error at trial. Hollaar Decl. (addressing SmartDrive bug).
265. The above tactics were all part of Microsoft's intensified FUD campaign against DR DOS focusing on Windows compatibility. Bear in mind that in June 1991, Microsoft had received the NSTL report finding Windows 3.0 to be compatible with DR DOS. See Exhibit 139. Notwithstanding the NSTL report, Brad Chase had all along directed that purported Windows incompatibility be raised with OEMs under threat from DR DOS:
you need to be clear to them that dr dos and windows will get them complaints. dr dos' memory manager does not support windows in 386 enhanced mode (major problem) and in general is difficult to set-up.
in addition, they will get even more questions later as we update ms-dos 6 and windows as dr dos could not be compatible.
Exhibit 159 at MSC00556588-589 (emphasis added)
also ask them if they really want to risk their reputation on their brand new machines with a brand new unproven poorly tested os. what if it doesn't work with the next version of windows? they could literally blow their whole pc business -- first impressions are hard to overcome if they blow it.
Exhibit 173 (emphasis added)
266. When, on September 9, 1991, Digital Research announced availability of DR DOS 6.0, Chase took this brand of FUD to a new level. He directed his marketing staff:
Issues to bring up if given the appropriate opening:
1. Future DR DOS incompatibility with Windows -- KEY here is not to say we will purposefully prevent compatibility w/DR DOS. But if given the chance it is OK to say the truth -- that we only test windows on Microsoft supported operating systems, so there's really no way to know in the future what will work and what will not.
Exhibit 176 (emphasis added)
267. The OEM sales force followed Chase's directive, and advised OEMs that Microsoft would only test Windows 3.1 on MS-DOS. Reichel Depo. at 53-54, 56. Chase admitted he had no way of knowing whether or not DR DOS would be compatible with the next version of Windows. Chase Depo. at 109.
268. More importantly, Microsoft did test DR DOS -- and in fact tested it with Windows in September 1991. When DR DOS 6.0 hit the market, Microsoft quickly obtained a copy of the product, and asked its DOS testers to engage in a "DR Hammer Fest." Exhibit 181. Assignments went out on September 19, 1991:
Lennon:
I know you have already seen the test plan but here it is anyway. I also have Eric, myself and Fernando looking at this. To avoid pollution I am going to leave development out of this until something turns up which needs specific development attention. You will get mail throughout the day as interesting stuff turns up. I will write a daily report which summarizes the days finds. . . .
It will take a total of two to three days to complete. . . .
BRENTK (Windows testing)
[Windows/DR DOS 6.0 testing suite outlined]
Exhibit 184 at MS5065265-266
The Windows testing suite specifically included a test of DR DOS 6.0 on "Windows 3.1Beta2." Id.
269. In self-evaluation for his performance review for the year ending June 1992, Chase wrote he "[d]rove detailed effort to internally and externally test DR DOS 6." Exhibit 304 at MSC008000307; see also Chase Depo. at 145 ("This is testing"). Lennon testified that his staff had previously examined DR DOS 5.0 "and took a look at some things like how it performed and some compatibility issues and that sort of thing." Lennon Depo. at 150. He confirmed that the tests of DR DOS 6.0 mentioned above were run by Microsoft's "testers" and were overseen by a "test manager." Id. at 207, 211, 219. He also testified this group took "a pretty good look" at DR DOS 6.0, and that "to use our testers at all would be unusual." Id. at 220. He was fairly certain no such test array had been run on any other DOS. Id.
270. That Microsoft directly lied to the industry on this point is firmly established. On January 20, 1992, in reply to a Windows 3.1 beta tester, Silverberg posted the following message on the CompuServe forum:
I forgot to say that Windows is designed and tested to work with MS-Dos. We do no testing at all with DR DOS and we do not know first hand whether it is compatible with Win 3.1 or not.
Exhibit 443
271. Chase and Pineda summarized the test results in a report to the OEM sales force in October 1991:
Summary
DR DOS 6.0 is DR DOS 5.0 plus some new utilities, many of which are catch-up features. It should be positioned a 5.1 release. It weaknesses are that it's:
Sloppy
. . .
Dangerous
. . .
a poor Upgrade
. . .
a poor Clone
. . .
And Windows 3.1 is not being tested on DR DOS 5.0 or 6.0.
Exhibit 210 at X569154
272. Wholly absent from the report was any balanced view to be derived from the test findings. Microsoft testers examined DR DOS on September 19 and 20, 1991, and reported their findings:
Briantc:
3) Personal feelings about the product . . .
To be honest, in my limited testing, the only major app that DR-DOS had a problem was Windows (or is that the only problem that Windows had was with DR-DOS?). Everything else seemed to work o.k.
The task switcher is nice and fast, but that seems to be more a function of disk speed than anything else. But I don't know of any time in my life when I had 20 apps that I needed to switch between.
Tonyka:
3) Anything you like about DR-DOS that we should add to future MS-DOS versions
DR MEM program output looks sharp; layout is clearer and offers more info than ours.
DOSBOOK online help looks pretty fancy and helpful.
DR SETUP lets user tune system after installation. This concept is good but their implementation is not useful enough.
4) Any general comments.
I hate to say I find more stuff I like than I don't like, but that's looks like it, at least for today's testing. Let's find some big bugs tomorrow.
Honkeatc:
3) Anything you like about DR-DOS that we should add to future MS-DOS versions.
Hhrrummph, here goes: [there follows a long list of praise]
4) Any general comments.
I like two key ideas from DR-DOS 6:
a) The availability of an automaton (SETUP) to manipulate the config.sys and autoexec.bat.
b) The user's capability to write script programs (both for startup and otherwise) that fit a more "contemporary" style with more up to date structures. The additions are modest but I think in the right direction.
Sidnam:
1) bugs in DR-DOS that are not in MS-DOS. no glaring ones. . .
. . .
3) like about DR-DOS that we should add to future MS-DOS versions
[there follows a long list of praise]
Markl:
Quick application testing:
The applications testing results were as follows: [finding DR DOS to work with 386Max, Fastback, Lotus Metro, Lotus 123 3.1, Qemm 386, and Turbo Debugger 386]
For the most part, DR Dos ran okay.
Exhibit 188 at MS5054063-064 (emphasis added)
Exhibit 186 at MS5055916 (emphasis added)
Exhibit 185 at MS5065293 (emphasis added)
Exhibit 183 at MS5065300 (emphasis added)
Exhibit 187 at MS5065203-204 (emphasis added)
273. The issue is starkly illuminated in the "DR DOS 6, Rude Q&A" circulated on October 16, 1991:
Q. What do you think of DR DOS 6?
A. DR DOS is not DOS, the standard that the industry has come to trust and rely on.
DRI didn't implement all the MS-DOS APIs nor all the function calls. While DR DOS does run many MS-DOS applications, our own review suggests that it has a significant compatibility problem with a range of the leading applications and utilities.
Exhibit 218 at MS7033542 (emphasis added)
274. Microsoft also did a formal memo on the results of its test, which Freedman characterized as the "principal idea" on how to "derail Dr DOS." Freedman Depo. at 227-228. This was distributed on October 17, 1991, to customers and the press as "A First Look at DR DOS 6.0." Id. at 228; Exhibit 220. Microsoft again conveyed blanket claims of incompatibility, without reference to severity or ability to implement a work-around. See supra 50, 121. The memo also incorporated findings by an outside testing laboratory, which contained numerous errors. See infra 277; see also Ivie Decl. (addressing false and misleading statements about DR DOS 6.0 in Exhibit 220).
275. Yet no one looking objectively at these reports (which were circulated to the OEM sales force) in comparison with what was actually being reported during the tests, could conclude that Microsoft was intent on making honest and not misleading statements about DR DOS 6.0. Indeed, Silverberg made clear that he did not want consumers to know the facts:
This is a very important point. We need to create the reputation for problems and incompatibilities to undermine confidence to drdos6; so people will make judgments against it without knowing details or fats.
Exhibit 227 at MSC00726593 (emphasis added)
See also Freedman Depo. at 10-11 ("perception is the most important -- it's the important determining factor, since what people think and what is actually true aren't necessarily connected, and what they believe is more important"). And Microsoft's own economist testified as to the dramatic impact to such a campaign: "A reputation for releasing inferior software will make it more difficult for a software vendor to induce customers to pay for new products or new versions of existing products." Schmalensee Depo. at 410.
276. As Microsoft drove its marketing efforts toward the launch of MS-DOS 6.0, the tidal wave of FUD swelled. The "MS-DOS 6 PR PLAN" from November 1992 summarized the ongoing tactics:
OBJECTIVES
*Build momentum for MS-DOS 6 and pre-empt DR DOS 7
COMPETITIVE ISSUES
Objectives: FUD DR DOS with every editorial contact made.
Strategy: Position new features of MS-DOS 6 while positioning DR DOS as a less stable product with poor MS-DOS functionality.
Develop key DR DOS FUD points for all press tours.
Message: DR DOS is incompatible, and if it's not compatible, it's not MS-DOS. It is a closed, proprietary system being designed for use with Netware and Netware Lite.
Exhibit 328 at MS0116030-031 (emphasis added)
See also Exhibit 241 ("DR DOS Action Item Summary," November 8, 1991: "establish DR DOS as an incompatible product that has bugs and lacks robustness").
277. As with DR DOS 5.0, Microsoft contracted with an outside testing laboratory to test DR DOS 6.0. This time the lab was XXCAL Testing Laboratories, and Microsoft told them it wanted "dr dos 6 put through the ringer." Exhibit 168. XXCAL understood that the "[t]esting was intended to identify bugs, inconsistencies, and functionality errors related to the operation of . . . DR DOS 6.0." Exhibit 245 at MS0116577 (XXCAL Report). XXCAL examined 38 applications; they also tested some of the DR DOS commands and checked for DR DOS compatibility with some peripheral devices. Id. XXCAL claimed that five of the applications failed with DR DOS. Id. Subsequent testing demonstrated that, in fact, DR DOS 6.0 had problems with only two of these five applications. Ivie Report, Attachments 11 & 13. And when Microsoft disseminated information regarding the problems identified by XXCAL, it conveniently ignored the fact that MS-DOS 5.0 had similar, or even more significant, problems with some of these applications as well. Id. Professor Ivie, through thousands of hours of comprehensive testing with all of the leading applications during the relevant time period, has confirmed that in fact DR DOS 6.0 was a highly compatible, surprisingly bug-free product. Ivie Report at 32-33. See Appendix F.
278. Freedman testified it was "a reasonable marketing tactic" for DRI to use its CompuServe forum for product support. Id. at 94. Even so, to round out its bug sheets on DR DOS, Microsoft monitored the DR DOS CompuServe forum, downloaded any reports of trouble, and distributed for use by OEM sales. Barrett Depo. at 169-172; see Exhibit 189 (Silverberg directing that "we should read the compuserve messages carefully in the dr forum for bug reports or other problems"); Exhibit 240 (sample download by Brad Chase).
279. These "smear sheets" -- as Freedman preferred to call them at the time -- were also leaked to industry "gossip columnists" and "rumor columns." Id. at 79. When pressed as to his purpose, Freedman had a convenient lapse of memory:
Q. So what you were trying to do was get buzz in the industry, rumor, whispers, gossip, that DR DOS was an unstable product, right?
A. I don't remember.
Freedman Depo. at 80
280. There is no question that these tactics worked. A report from the field stated:
We will let you know when this closes. Please advise whomever put together the two documents about DR DOS, the press blurb list and the multipage tech expose, that THEY saved this deal (so far) for Microsoft. . . .
As FUD is our witness, we will never go hungry again.
Exhibit 261
Return
Table of Contents
281. Direct ties into Windows continued through this period, and was indeed discussed among executives at the highest levels of Microsoft. When renegotiating Compaq's Windows license, Silverberg and Kempin had the following discussion on September 30, 1991:
Silverberg:
you're asying that when someone buys compaq dos for $99, they also get windows for free. but if you want windows alone, it costs you $150.
and compaq wants windows for free.
am I missing something why this is good for us?
Kempin:
Do not see this as a price issue. They will pay. Remember IBM did not pay for DOS, but see what happened! See the strategic value: It will have lots of followers = DRI can't compete for now.
Exhibit 203 at MS7090738 (emphasis added)
282. Especially with smaller OEMs, Microsoft account managers tied Windows and MS-DOS. On January 23, 1992, for instance, a Microsoft account manager sent this letter to Diamond Trading, a small British OEM:
Further to our conversation yesterday, I am writing to confirm that Microsoft is unable to supply you Windows as a single product.
Microsoft will only sell you Windows as a combined package with MS-DOS version 5.
Exhibit 267
283. Roger Harvey -- whose OEM, Qubie, was a leading proponent of DR DOS -- testified:
They just said they had changed the way in which they market the product, instead of it being available as two separate packages it now came as an integrated package, which was DOS and Windows 3.11 or DOS and Windows for Workgroups 3.11, take it or leave it.
Harvey Depo. at 33.
Harvey initially believed "it was because of our high profile selling DR DOS that they had changed the rules for us," but later learned "they had changed them for everybody." Id. at 34; see also id. at 62-63, 67, 74-75.
284. Microsoft representatives in fact taunted DRI with the fact that it was refusing to sell Windows to customers who did not also buy MS-DOS. Sandy Duncan (Microsoft's United Kingdom OEM Sales Manager) informed Tony Speakman (an OEM salesman for DRI) that DRI customers could not get Windows from Microsoft, and that if ever asked, he would deny that this was going on. Duncan gloated that he knew this conduct was serious and illegal, which was why he would deny it if ever asked about it. Speakman Depo. at 208-211.
285. By this juncture, Microsoft knew that its use of the beta blacklist against DR DOS had been quite effective. It thus expanded its beta blacklist campaign to retaliate against any OEM or ISV that would dare choose to associate with DR DOS.
286. Denial of access to Windows development and beta information was first hinted at when IBM flirted with Novell and DRI about a DR DOS bundle. Nathan Mhyrvold graphically expressed his views to Silverberg and Ballmer on September 11, 1991:
If they do bundle Dr Dos, then fuck'em. They get to hear about our new releases and new features on announcement day -- just like other retail stuff.
Exhibit 177
287. Following the launch of Windows 3.1, Silverberg began to wield Windows as a club against anyone disloyal to MS-DOS. On May 15, 1992, he happened to notice a press release:
Press Release:
Novell, Desktop Systems Group has introduced an update to its DR DOS 6.0 operating system that makes it fully compatible with Microsoft Windows 3.1
Z-Nix Inc. (Pomona, Calif.) has bundled DR DOS 6.0 and Microsoft Windows 3.1 with its Super Mouse II and Cordless Super Mouse products. "We've been testing the two products from top to bottom for a month now, and have uncovered no incompatibilities," said C.J. D'Angelo, vice president of sales. "We are confident our OEMs and endusers will be equally successful."
Silverberg:
look what znix is doing! cut those fuckers off.
Exhibit 301 (emphasis added)
288. Microsoft's retaliation against Z-Nix is shocking. Within three weeks of Silverberg directing that Microsoft "cut those fuckers off" for consorting with DR DOS 6.0, Microsoft's legal department demanded an audit of Z-Nix's entire business. Exhibit 311. After Z-Nix refused to comply with the grossly overbroad demand, Microsoft's ginned up a copyright and trademark infringement action against Z-Nix. In a "Z-Nix Case Rude Q&A" of June 23, 1992, Microsoft acknowledged, "Last month we heard they had negotiated a contract with Digital Research for DR DOS. Do you think they would expect a contract with us if they have one with DR DOS?" Exhibit 310. Z-Nix counterclaimed on July 24, 1992, alleging Sherman Act violations for its Windows tie, product disparagement, slander, and abuse of judicial process and fraud on the court. Exhibit 320. Microsoft subsequently entered into a confidential settlement. Z-Nix was forced to file for bankruptcy in or around 1995.
289. Microsoft also put ISVs on the beta blacklist for consorting with DR DOS:
Koch:
Since we have send an NDA to Multisoft, do you still want them listed on the No Pre-Release list?
We can list them as 'to be cleared by xxx person' if you want to sreen them for future shipments.
Slivka:
Let's leave them on for now. It is unfortunate we have no record of what they did to earn our displeasure in the first place. Perhaps bradsi or philba remember?
Barrett:
the only thing I recall was their licensing of their cache to dr.
Exhibit 341 (emphasis added)
290. Microsoft in fact began using the beta blacklist to retaliate widely against any of its perceived industry enemies. Having been soundly defeated by Stac Electronics and ordered to pay damages of $120 million, see infra 344, Stac was cut off from anything further to do with Windows betas:
Chase:
Remove Stac from the beta thanks
Donaldson:
They have been taken "off beta". Do you want them added to our "no pre-release list"?
Chase:
yes.
Exhibit 344
See also Exhibit 354 at MS0073802 (letter from Central Point Software to Microsoft: "I do object to Microsoft's statement that, since we had done the ad, we might be put at the end of the line for receiving information on future operating releases and may receive late betas.").
291. This type of information would permeate the industry, and put OEMs and ISVs on notice not to associate with DR DOS. Microsoft does not challenge Caldera's allegations concerning this retaliatory conduct, which effectively tied access to Windows' information to the purchase of MS-DOS. See Exhibit 1, 3, 79 (First Amended Complaint).
Exclusionary Licenses: Critical Mass
292. During the 18 months between the launch of DR DOS 6.0 and MS-DOS 6.0, Microsoft aggressively continued the licensing practices that were so successful in blocking out DR DOS in anticipation of the launch of MS-DOS 5.0. On March 26, 1992, Allchin wrote to Gates that, while other initiatives were necessary, the licensing triple-whammy had stopped DR DOS in its tracks:
I feel we are much too smug in dealing with Novell. Perhaps, they didn't hurt us in DOS yet -- but it's not because of product or their trying. It's because we already had the OEMs wrapped up.
Exhibit 349 at MS7079459 (emphasis added)
293. DRI and Novell salesmen repeatedly ran into the wall erected by Microsoft's licensing practices. Their testimony confirms that OEMs refused to license DR DOS due to the exclusionary nature of licenses for MS-DOS. See, e.g., Speakman Depo. at 355-357, 361; Gunn Depo. at 245-248; Dixon Depo. at 325-328. Tony Speakman summarized his concern on May 1, 1992:
I know of other OEMs currently being pressurized to sign long-term restrictive agreements and strongly believe that if we do not act quickly we will find ourselves locked out from substantial business for another two or three years.
Exhibit 300
294. The exclusionary nature of Microsoft's minimum commitment practices were so well-established that they found their way into Microsoft's Board of Directors Report for the fourth quarter of 1991 :
Because prepaid balances can be recouped with royalties from products shipped in succeeding quarters, prepaid reduce the amount of revenue we will recognize related to future customer shipments. On the other hand, prepaid balances not only smooth the revenue stream somewhat, but, in the face of increasing competition (Novell/DRI, IBM), make it costly for a customer to move to a competitor.
Exhibit 104 at MS0164489 (emphasis added)
295. OEM status reports from the era reveal that Microsoft was using a "UPB Reduction Plan" to continue to wage war against DR DOS. See, e.g., Exhibit 209; Exhibit 170 ("I believe $2.3M PPB is favorable balance for us to push Samsung at our site. (not too big and not too small)"); Exhibit 226 ("Be ready to merge their agreements with UPB issue"; "close new 3 year agreement with UPB plan"); Exhibit 253 ("The risk with this is that there is no loyalty with our package product customers. Their cost to switch to DR-DOS is minimal since they have no long term financial committment with Microsoft").
296. Indeed, the "OEM Sales Business Manual, Policies and Procedures" from September 1992 notes: "When properly managed at moderate levels, PPB [pre-paid balances] can benefit Microsoft." Exhibit 324 at MS0013277.
297. At the same time, Microsoft was increasing the duration of its licenses. At a presentation in June 1991 to the Microsoft OEM sales force, the "Strategy Against DRI" -- indeed, one of the "Key Objectives for FY92" -- was to "Push Longer Term Per Processor Contract." Exhibit 132. See also Exhibit 145 at X518126 (Kempin memo, July 1991: "Secure long term contract with OEMs, whereby the standard contract length should be three years instead of two to deny entry . . .").
298. Microsoft's OEM reports from this era make repeated reference to the "competitive defense against DR DOS provided by 2-3 year license agreements." Exhibit 167; see also Exhibit 255 at X0597052 ("Joon Park closed Samsung license much to my relief. It is a 3 year per processor license agreement."); Exhibit 211 at MS7090708 ("aggressively go after existing DR DOS accounts and keep them out of our current ones . . . secure long term MS-DOS 5.0 contracts (three or more years) whenever possible"); Exhibit 225 at MS7031119 ("MS will verify if DR is a real threat or a device to obtain lower royalties . . . if the threat is real I suggest MS lower their high volume royalties for the 386 SX to $10 and increase the term of the agreement to three years"); Exhibit 226 (repeated reference to closing new three-year agreements).
299. And, of course, Microsoft continued to wield the per processor license. OEMs resisted, but realized they had little choice, as evidenced by this complaint to Microsoft on March 4, 1992:
While we understand your desire to force ZEOS to pay Microsoft a software license fee for every computer system we sell, this would substantially disadvantage us in the marketplace. It would handicap our ability to compete and would, if agreed to by us, needlessly result in higher prices for our product for those who ultimately decide to purchase from us.
It is imperative that we be able to offer customers, upon request, computer systems which do not include Microsoft operating systems. We clearly do not feel we, or our customers, should be forced to pay Microsoft a royalty on your software when it is not supplied or desired.
Exhibit 284 (emphasis added)
Microsoft ignored this request for an exclusion, except to the extent the requested exemption applied to computers for the federal government. Exhibit 286.
300. Microsoft permitted no variance. When Novell attempted to secure a license with Dell in November 1991, Dell explained the realities of its per processor license with Microsoft:
Due to the contract with Microsoft DR DOS needs to be offered on a no cost basis except for the upgrade program cost.
Exhibit 242 at A0116293 (emphasis added)
301. Microsoft has claimed that it granted exemptions to OEMs distributing MS-DOS under per processor licenses to allow them to distribute an alternative operating system without paying Microsoft its royalty due under those licenses. Microsoft purports to identify 27 such instances among the thousands of OEMs worldwide. Licensing Memo. at 5. Yet Microsoft cites nothing other than an interrogatory response to the DOJ to support this contention, which neither attaches the licenses nor identifies pertinent language. That response does not unambiguously demonstrate that Microsoft's exemptions were to per processor licenses. In fact, according to Microsoft's interrogatory response, the first such (unidentified) exemption occurred in 1988, which predates Microsoft's use of per processor licenses. See supra 58.
302. In any event, direct evidence contradicts Microsoft's assertions. A British OEM --Viglen -- wrote Microsoft on June 5, 1992, to express its dissatisfaction with not being permitted an exemption to the per processor license, or the option of a shorter term:
Although we have signed this contract which I understand is the best that we could negotiate, I would for the record like to point out the three issues which we are not entirely happy with.
The first issue which you have addressed in your letter dated the 14th of April, 1992 is the long term (3 years) nature of the contract. I understand from your letter that any issue of pricing and commitments can be reviewed in the course of the three years if concern is raised. If this is the correct assessment of your letter then I am quite happy with that.
The second issue is the fact that the only OEM agreement you have been prepared to offer us on MS-DOS and Windows is a per processor license. Our main concern here is that a small proportion of our business involves providing Non Microsoft operating systems such as networks and others to our customers who require it. This means that we will be paying a royalty to Microsoft even though we would not be supplying Microsoft products. We have tried many times even to get exemption on named models on which we would not be supplying Microsoft products but this has not been accepted by yourselves, neither has a per copy license based on the same volume of business.
Exhibit 306 (emphasis added)
303. Other OEMs reported as well that Microsoft would only offer per processor licenses. See, e.g., Exhibit 300 (Opus). One U.S. OEM -- U.S. Micro Express -- provided succinct testimony in this regard through the sworn declaration of its Vice-President:
3. In order to obtain licensing rights to MS-DOS from Microsoft, we were required to enter into an OEM Agreement with Microsoft which stipulates that we must pay them a license fee for every system shipped, regardless of whether or not we use MS-DOS on that particular system.
4. We were not given the option of licensing MS-DOS on any other basis. Foregoing a license for MS-DOS altogether was not an option. MS-DOS is used by a substantial segment of the industry and our business would not survive if we were not able to offer it to our customers.
5. Prior to our being forced to sign the OEM agreement with Microsoft, we used DR DOS on some of our systems. Both before and after entering into the OEM agreement, we have had requests from some customers for DR DOS that we have not been able to fulfill. We consider DR DOS to be a good and viable product but have since been precluded from considering it seriously even for a small number of our systems because of the CPU licensing arrangement. Margins and competition are such in our business that we could not afford to use DR DOS and pay a double license -- one to Microsoft under the OEM agreement and one to Novell for using DR DOS.
6. It is my understanding that Microsoft commonly insists on this form of licensing arrangement in its license agreements with OEM's. I believe DR DOS will be unable to make significant headway in the DOS market so long as this licensing practice is permitted.
Exhibit 367
304. Microsoft tightened the screws on more than just small OEMs. Even OEMs as large and powerful as Dell felt the crunch. On September 8, 1992, Kempin became personally involved with the renegotiation of the Dell license:
DELL has two options to play or not to play. If they want a cheap per copy deal they won't get it. Build to order is not helping us to grow share. In addition I am mad at them looking at their NOVELL LITE promo in their catalogue. If they associate themselves with NOVELL and DRIs product quality and believe we will do a shitty job as well, all the power to fail to them. We will not have a remote diagnostic feature, may be next version-looks like most other OEMs don't need it so let's go with them and build share.
Carl, increase pressure: tell them that the offer expires 14/10/92, because we have alleady too many companies who want to participate in the launch. If they want a discussion referr them to me. Steveb is on vacation and I don't want him to get involved. If they call Billg intercept the call.
Exhibit 325 (emphasis added)
305. Another of Microsoft's major justifications for per processor licenses is to assert it combats piracy and counterfeiting. But where is contemporaneous proof of this assertion? Where in Microsoft's documents are there studies before-the-fact indicating what impact Microsoft expected per processor licenses to have on the issue? Where are studies after-the-fact indicating whether or not per processor licenses had lessened piracy? Microsoft's own economist testified he was unaware of any such contemporaneous documents. Schmalensee Depo. at 351, 367; see also Leitzinger Report at 35-38. Microsoft's economist also admitted that per processor licenses were an imperfect way to deter piracy, and that Microsoft implemented such licenses with OEMs posing no threat of piracy. Schmalensee Depo. at 335-336, 343.
306. Despite such after-the-fact machinations by Microsoft's legal counsel to try to avoid antitrust liability, the contemporaneous documents are replete with rhetoric about the effect of per processor licenses on DR DOS:
We have told EMI that we will discuss direct licensing with them if we can get MS-DOS "per processor" and lock out DRI. I dont want to do this but if they are really shipping 20K PC's a month loaded up with DRI -- I have no choice. IF this continues and EMI grows in the mass merchant channel then other oems in this channel will start looking at DRI as a cheap alternative.
Exhibit 212 (emphasis added)
looks like it is not as bad as we may think. However, I still think we should get a version ready for per processor deals and lock Novell OUT! I will work with Johnlu to make this happen.
Exhibit 329 (emphasis added)
Return
Table of Contents
Choking on Vaporware -- Part 2
307. MS-DOS 5.0 shipped in June 1991. DRI leapfrogged Microsoft a scant three months later, when it released DR DOS 6.0 in September 1991. In the wake of the DRI/Novell merger announcement and the possible IBM/Novell alliance, Microsoft executives were worried that DR DOS 6.0 would be available "at least a year ahead of MS-DOS 6." Exhibit 153.
308. Microsoft immediately returned to the vaporware that had served it so well following the announcement of DR DOS 5.0. On August 5, 1991, PC Week reported:
Now -- less than two months since the release of DOS 5.0 -- Microsoft officials are talking about DOS 6.0 and the features it will share with OS/2. Some of us are feeling deja vu.
It seemed a remarkable coincidence 15 months ago that Microsoft officials offered their most candid comments to date on the DOS 5.0 effort during the very week that once-formidable rival Digital Research Inc. released DR DOS 5.0. . . .
Microsoft's discussion of DOS 6.0 is the latest in a series of vaporous visions that company officials have recently offered, such as "Windows-32" and its New Technology kernel, formerly referred to as OS/2 3.0. Though corporate buyers welcome information that helps them plan for and smoothly migrate to new technologies, these visions offer little such useful information.
Exhibit 161 (PC Week, August 5, 1991)
309. In December 1991, Microsoft leaked to an industry gossip columnist that "DOS 5.1" would be bundled with data-compression software known as Stacker "when it ships early next year. Adding data compression also takes a swipe at DR DOS 6.0 with Superstor." See Exhibit 252 (Infoworld, "Gates hopes that Stacker will give DOS 5.1 wings to fly past DR DOS," December 9, 1991). But even by November 1991, Microsoft developers were only acknowledging that "DR/Novell is a serious threat," and debating "strawman" features for MS-DOS 5.1. Exhibit 243 at MSC00743673. No final specifications or schedules exist, and no product labeled MS-DOS 5.1 ever shipped.
310. Silverberg also proactively gave presentations to OEMs on other future MS-DOS plans. On September 6, 1991, in a presentation to NCR,(29) he discussed Microsoft plans:
DOS: Coming Soon . . .
MS-DOS 6
100% DOS 5 compatibility
Platform for Windows, including Win32
Exploit 386
Installable file system
Improved installation, configuration, administration
Improved network support
Unified approach to localization: EJAL
Enhanced support for mobile computing
We want your input!
Exhibit 171 at MS7006895-897
311. Yet one month before, Silverberg was specifically advised that version 6.0 "was not defined yet and we need to know what it is before we ship it." Exhibit 162. Silverberg admitted that disclosure of a new version of MS-DOS as "coming soon" does not comport with shipping 18 months later -- as was the case with MS-DOS 6.0. Silverberg Depo. at 128; see also Exhibit 179 (Silverberg presentation to Tandy on September 16, 1991).
312. On September 16 and 17, 1991, Microsoft officials extensively briefed scores of OEMs assembled in Seattle. Silverberg "discussed in considerable depth" the plans Microsoft had for MS-DOS 6.0. Exhibit 192. Silverberg disclosed that MS-DOS 6.0 would be available "in 1993," and described the product to the assembled groups of OEMs:
-- Features: pre-emptive multitasking, threads, better memory management, networking services, protect mode device driver model, etc.)
--It was disclosed that "Windows 4" (not official name) will require DOS 6 as it will depend on DOS for key services listed above.
Exhibit 192 at MS5054207
313. That product (or rather products: Windows 4 + DOS 6), as well as that described to NCR and Tandy, was not even a close relation to the MS-DOS 6.0 that actually shipped in March 1993. Silverberg admitted that the product(s) disclosed in September 1991 were a rough approximation of what ultimately hit the market in August 1995: Windows 95. Silverberg Depo. at 121, 124-125; see also Ballmer Depo. at 180-181. As such, Microsoft was telling the world in September 1991 -- the month DR DOS 6.0 shipped -- that "coming soon" was that which never arrived: the separate DOS component of Windows 95.
314. Microsoft's manipulations with vaporware are astounding. Microsoft's attorneys defend its presentations to customers and the media as somehow being cloaked in secrecy by non-disclosure agreements (NDAs). But Microsoft's executives concede no such secrecy exists. For instance, as to plans for Windows NT, Ballmer wrote Jon Lazarus in April 1992:
the design preview has not leaked to the press are you surprised do you wish it would if so when
Exhibit 307
Ballmer's explanation of this e-mail was to explicitly recognize the fiction of NDAs. He testified that "99 percent of the time" these plan presentations made it to the press, with or without NDA:
If you tell 50 independent software vendors something, you're going to find it's under a Non-Disclosure Agreement, the high, high, high, high, high, high probability is that that will be in the press the next week.
Ballmer Depo. at 193, 194
See also Exhibit 323 ("Create industry excitement by going out on a mini-tour week of August 17 under 'non-disclosure' and showing MS-DOS 6.0 beta to the industry 'talkers.' . . . We would need to make sure that our presentation includes at least one piece of information on MS-DOS 6.0 that is just TOO good not to pass on.").
315. Microsoft knew it could never deliver in the announced time frame anything closely approximating the technical advances it was describing. By February 1992, Silverberg acknowledged the falsity of the preannouncement of the DOS component of Windows 95:
i agree that we don't want to negatively affect msdos6. but realistically, msdos6 is still quite a ways off. we need to have a close look at it, too, to see what's essential and what's not. i presume msdos won't be until mid-to-late '93. I don't see how we can hold the fort with msdos 5.0 until then. if dri was smart, they'd put us on a release treadmill. . . . once you lose a lot of ground it is very very hard to pick up. we need to stop losing ground while making progress towards the ultimate "major leap" msdos6. clearly the trick is to not make kernel changes and just add bought utils.
Exhibit 274 (emphasis added)
316. On February 3, 1992, Cole advised Silverberg that "DRI is getting perceived as the product innovator/leader because they look to be more active with new products. User's making a buying decision like the guy who appears to be in front doing the new stuff." Silverberg agreed that "dri is already perceived as being ahead," and that Microsoft needed to put DRI on the "product treadmill" by releasing interim versions:
too many will just be a churn. but we can't just sit on the sidelines till msdos6, hoping fud and leaks will carry us.
Exhibit 273 (emphasis added)
317. Not until the end of February 1992, was Microsoft "designing" a new version of MS-DOS -- code-named "Astro" -- specifically to counter the DR DOS 6.0 features. Microsoft dubbed this release MS-DOS 6.0. Actually, Microsoft just bought some utilities competitive to the DR DOS feature set and bundled those. Silverberg Depo. at 128-129. A presentation from that era makes the point only too well:
Astro
MS-DOS 5 kernal + cool new utilities = MS-DOS 6 = $$
"Checkbook" release
Acquired and in house developed utilities. Philosophy: Get excellent products with low share for cheap
Defend DOS. Stay aggressive. Put Novell/DR on treadmill.
Hold position until big step forward, Cougar
Exhibit 272 at MS0073285
318. When Microsoft announced its revised plans for MS-DOS 6.0, it conveniently dropped the product into the same release framework that it had outlined by vaporware previously as the DOS component of Windows 95. On July 6, 1992, PC Week reported:
Microsoft also plans to release in the first half of next year a new version of DOS lacking most of the features that had been expected in DOS 6.0, such as multitasking, which allows users to run several DOS programs concurrently.
. . .
Rather than architectural restructuring, the upgrade will add utilities aimed at Novell Inc.'s DR DOS, Maples said. DR DOS 6.0 has file-compression technology that MS-DOS 5.0 lacks, although Maples wouldn't confirm planned features. Architectural work is still under way for an even later DOS version, Maples said.
Exhibit 315 (PC Week, July 6, 1992)
319. As a point of interest, MS-DOS 6.x became Microsoft's highest-volume version of MS-DOS ever, and generated hundreds of millions of dollars revenue. See Wecker Report. But for innovation by DRI, Microsoft would never have released any MS-DOS 6.x products, and would thus have foregone this revenue. But for Microsoft's rampant vaporware, much of this revenue would rightfully have flowed to DR DOS 6.0.
Implementing the DOS/Windows Merge
320. Both the DRI/Novell merger and the anticipated IBM/Novell alliance were alarming on many fronts. Jim Allchin wrote Gates and Ballmer in September 1991, urging the hardest of hardcore responses to the many threatening advances Novell was making:
The news on the street continues to confirm the IBM and Novell announcements this week. DRDOS 6, Novell bundling . . . and IBM reselling DRDOS are the words. Still no real data on the details.
MS Response:
. . .
2. integrate Windows with DOS. Common install. Make it so that there is no reason to try DRDOS to get Windows. . . .
We must slow down Novell. The strongest action that we could take would be to include networking with Windows for essentially a zero uplift in price (maybe minor COGS uplift). As you said Bill, it has to be dramatic.
Net net: We must sell *lots* of Windows.
And we should not charge (much, if anything) for low end networking. We need to slaughter Novell before they get stronger.
Exhibit 175 (emphasis added)
321. This was the impetus of the "Chicago" project -- Windows 95, the DOS/Windows merge that destroyed competition in the DOS market. From that point forward, Microsoft quit dreaming about the DOS/Windows merge, and began to implement it. Allchin's suggestion would resonate within the "Chicago Strategy Document," circulated eight months later, on June 16, 1992. See infra 328.
322. Since 1990, Microsoft had been trying to develop a compelling combined package of MS-DOS and Windows, while at the same time continuing to offer each product separately. Phil Barrett testified that it "had been a long-standing desire of Bill Gates to build a combined product." Barrett Depo. at 42. The idea was "to have it appear to the user as if it was one product" even though "you still had DOS and Windows separate." Barrett Depo. at 47.
323. Efforts prior to 1991 to merge Windows and MS-DOS -- code-named "Captain" -- "were halted by lack of OEM interest." Exhibit 174. Between May and September 1991, Microsoft drew up several specifications for a project called "Slick," which would have combined various versions of Windows with MS-DOS.(30) Tom Lennon characterized these as "basically an installation that could cover both the install of -- it's basically a merging of the DOS and Windows install." Lennon Depo. at 125. The "Slick" plans never resulted in a completed product.
324. By early 1992, "Janus" was designed to provide first-time Windows 3.1 purchasers, who were using some older version of DOS, with an upgrade to MS-DOS 5.0. Thus, for the first time, Windows 3.1 and MS-DOS 5.0 came in the same package. A draft press release for one of the "Janus" offerings quotes Silverberg in April 1992 as saying "we have integrated Windows and MS-DOS for the first time." Exhibit 289 at MSC00054520 (emphasis added).
325. Because the components were also offered separately, Janus failed. But through failure, Microsoft learned a strategic lesson that drove Windows 95. The "Janus postmortem" stated:
Upgrade Janus
Premise
A spinoff of the Blue Janus development effort, Upgrade Janus was an attempt to up-sell MS-DOS 5 Upgrades to first-time purchasers of Windows 3.1.
Status
[Upgrade Janus] sold 32K units [worldwide] in its life. It is now obsoleted by the MS-DOS 6 Upgrade.
Lessons learned
. . .
An asynchronous release of an integrated MS-DOS upgrade/Windows product has a narrow market. However, the concept of upgrading MS-DOS and Windows at the same time, I believe is very appealing if we can sych up their releases. Enter Chicago.
Exhibit 259 (emphasis added)
326. "Chicago" was the code name for the Windows 95 project. In May 1992, Maritz reported that "Chicago" was being designed as the "next major version of Windows & MS-DOS." Exhibit 298. An unidentified draft presentation from this era explicitly notes that "Chicago" would be "Windows & new MS-DOS packaged together." Exhibit 299 at MS0088377 (emphasis added). Maritz confirmed this presentation appeared to have been written by someone at Microsoft knowledgeable of the "Chicago" project in the 1992-1993 time frame. Maritz Depo. at 137-138.
327. Silverberg's self-evaluation in his performance review for the year ending in June 1992 also confirmed this packaging:
A sizeable effort was devoted to the development of the "next generation" MS-DOS that will serve as the underpinnings for the Windows "Chicago" release, which will be an integrated MS-DOS/Windows operating system, as well as MS-DOS 7.
Exhibit 305 at MSC008000318 (emphasis added)
328. On June 16, 1992, Silverberg and his team circulated the seminal "Chicago Strategy Document." The planning memo made two important points: (1) "Chicago" was being designed primarily to block out Novell; and (2) whether or not MS-DOS and Windows would ever ship separately was simply a marketing (as opposed to a technical) matter:
Chicago is the code name for the next major release of Windows from the Personal Systems Group. It's an integrated and complete Windows operating system which starts with the basic functionality found today in MS-DOS, Windows, and soon to be released Windows for Workgroups. It adds overall improved ease of use, enhanced workgroup function, ease of finding and sharing information, advanced operating system performance, and enables new application capability.
. . .
Competition in the operating system business is intense. There are a number of dire competitive threats which Chicago must address.
. . .
Novell is after the desktop. As you know, they have acquired Digital Research and are now working hard to tightly integrate DR-DOS with Netware. We should also assume they are working on a Windows clone and/or that they are working on a virtualized DOS environment which will run standard mode Windows as a client. This is perhaps our biggest threat. We must respond in a strong way by making Chicago a complete Windows operating system, from boot-up to shut-down. There will be no place or need on a Chicago machine for DR-DOS (or any DOS). Since we don't expect Novell to go away anytime soon, Chicago must ship with great Novell client support. We must build all the things into Chicago which are required to make it THE ideal Netware client.
. . .
Products to ship
. . .
While Chicago is being developed as a single integrated Windows operating system, it's being designing and built so that 3 specific retail products can be packaged up and sold separately. Which products actually ship other than full Chicago is a marketing issue.
. . .
1) Windows for Workgroups. This is the full Chicago product which includes all the function currently found today in MS-DOS, Windows, and Windows for Workgroups, plus the improvements outlined above.
2) Windows. This release contains all the function currently found today in Windows and MS-DOS, plus the non-workgroup related improvements above. This product would exist solely as a lower price point Windows. If the majority of users will pay more money for full Chicago, this product will not exist.
3) MS-DOS. This release contains all the function currently found today in MS-DOS, plus the improvements outlined above which not specific to Windows. This includes the ability to run multiple DOS apps, each in their own virtual machine, and pre-emptively scheduling them.
Exhibit 309 at MS0072604, -613 (emphasis added)
329. Cole admitted to being the author of the document, in the sense that he typed up the team's ideas. Cole Depo. at 108-109. A cover sheet to Microsoft's outside PR firm shows this document went to Gates, Ballmer, Maritz, Allchin and several other highly-placed executives. Exhibit 308. A formal "Chicago Feature Specification" circulated three months later. Exhibit 327.
330. In his deposition, Silverberg repeatedly testified that "Chicago" changed after this strategy document, and that Windows 95 actually bore little resemblance to the project outlined there. See Silverberg Depo. at 252 ("We didn't do that. There was a period of time where we considered that as a possibility and we decided not to pursue that path."); at 261 ("There was a code name floating around called Chicago. In fact, what was being worked on at that point beared almost no relationship to what actually shipped as Chicago."); at 262 ("In 1992 what we were thinking about in terms of something called Chicago changed pretty dramatically by the time we actually shipped something, just as notions of Windows 4.0 changed. . . . In 1992 these were some of the things we were considering, and that's not what we did."); see also Id. at 251, 264, 265, 271.
331. Silverberg -- who had lied to PC Week about MS-DOS 5.0 vaporware, and to beta sites and end users about the AARD code -- appears to have perjured himself on this issue. In the November 14, 1994, issue of MicroNews (an internal Microsoft newsletter), Silverberg sat for an interview after Windows 95 entered its beta cycle:
Q: What happens after Windows 95?
Silverberg: We have a very clear sense for our mission: making PCs easy to use for everyone. In terms of the features for Win 96 and Win 97, we're still at the brainstorming stage. The next stage is to distill that down into something more achievable. We did a really good job of Windows 95 in that regard.
Recently I discovered a document on my hard disk called "STRATEGY.DOC." It was written in June of '92 to communicate to the team and to the executives what the key elements of Windows 95 (it was Chicago then) were. Then we boiled it down to what we called the 10 Commandments of Windows 95. I thought, "This should be funny, reading what we thought two years ago that this product was going to be." As I read it, what struck me was, "Wow! We had really nailed it! We built that product!" So, before we had even gotten that deep into writing any of the code, we clearly understood what that product was and stayed focused on building it. In fact, we had articulated it so well that I was just blown away. We made the right choices. What seemed compelling in 1992 is just as compelling and exciting in 1994.
Exhibit 433 at MSC00346441 (emphasis added)
332. Indeed, after the "Chicago Strategy Document," the only real question left was how to best disclose the DOS/Windows merge to the world for maximum effect. When Brad Chase raised marketing issues about the "future of DOS plan," Silverberg replied on June 28, 1992:
actually this is a very tough question with debate now happening at the billg, steveb, paulma, jonl, bradsi level.
one school of thought says that we start talking about ms-dos 7 soon in vague ways to let people know msdos lives. another is to absorb ms-dos into windows -- Windows will be our integrated os and msdos gets absorbed into it.
Exhibit 313 at MSC00308725
333. Through the end of 1992 and into 1993, Microsoft executives gave presentations explaining "Chicago" with a graphic showing Windows 4 sitting atop MS-DOS 7. See e.g. Exhibit 331; Exhibit 339. With the graphic, OEMs were told that "if you purchased Windows '95 or Chicago, there would be no need to buy a DOS product. . . ." Reichel Depo. at 229 (explaining Gates presentation to OEMs at PC Windows Show in October 1992).
334. When the media picked up these pre-announcements by Microsoft, a theme in press reports emerged that "Chicago" would be something akin to "NT Lite."(31) In December 1992, debate erupted among Microsoft executives about whether to describe "Chicago" as a brand-new operating system, or as a continuation of Windows as a GUI running with DOS. Contrary to Microsoft's position taken in this litigation, Silverberg and Ballmer both acknowledged that MS-DOS lived and breathed within the "Chicago" project:
Ballmer:
I really dislike NT lite we do not need NT lite we need two things windows the thing for ms-doss and windows NT Pls the concepts are sinking in II would characterize chiocago as MD-dos based do we think otherwise
Silverberg:
I understand all the reasons why NT Lite is bad. When I first heard it I hated it too. I still don't like it.
Yet, I've found that it's the term people say back to me when I explain Chicago to them. 32-bits, 32-bit api, full prot mode, integrated dos. they say, "Oh, it sounds like NT Lite".
So I expect that NT Lite is a term the press will latch onto and use to describe chicago.
Ballmer:
we have to avoid that i do like using win 4 now what is yuor reaction to that
Silverberg:
windows 4.0 for MS-DOS sure eliminates a lot of confusion in peoples' minds. it also cements the fact that yes, there will be a future to windows on ms-dos.
Exhibit 332 at WE006986 (emphasis added)
Exhibit 333 (emphasis added)
Exhibit 334 (emphasis added)
335. On December 15, Claire Lematta -- the Waggener Edstrom PR operative in charge of the "Chicago" project -- reported that she, Silverberg, Lazarus, and a couple of others would meet to discuss whether to "[k]eep Chicago code name or change to 'the next version of Windows on MS-DOS'? Windows 4.0?" and "[h]ow much to disclose about merging Windows and MS DOS in Chicago." Exhibit 335.
336. Lematta reported the results of this meeting to Ballmer and others the next day, including the following decisions:
We will always refer to Windows NT as a superset of Windows for MS DOS.
As a family of operating systems, both Windows for MS DOS and Windows NT will share common technologies:
We will NOT refer to Chicago as Windows NT lite, although this positioning will be inevitable with the press. We will combat it.
We will emphasize that MS DOS continues, and that Chicago will require MS DOS. We will not refer to a "merged" product.
Exhibit 337 (emphasis added)
See also Exhibit 336 (Lematta notes from meeting).
337. Lematta elaborated on these decisions in January 1993 in a "Chicago Q & A" she prepared in anticipation of planned "Chicago" design previews and the increasing interest of the press:
Q. What is Chicago?
A. Chicago is a code name that refers to the next version of Windows on MS-DOS.
Q. Is Chicago the next version of Windows?
A. No, the next major version of Windows that will ship is Windows NT. Our goal is to ship Windows NT in the first half of 1993. Chicago is the code name for the next version of Windows on MS-DOS.
Q. If Chicago refers to the next version of Windows on MS-DOS, and there is no code name for MS-DOS by itself, then does this mean there will not be another MS-DOS stand-alone product after MS-DOS 6?
A. Chicago is a code name for the development work for both Windows on MS-DOS and MS-DOS by itself. The work is proceeding in parallel. There will be future versions of MS-DOS as a stand-alone product.
. . .
Q. Are you planning to merge Windows and MS-DOS?
A. No, we are not planning to merge the products. We will continue to evolve both and work to make them work together better, while exploiting advances in desktop PC hardware. We are committed to continue to release new versions of MS-DOS.
Exhibit 343 at MS7095630, -633 (emphasis added)
338. Clearly, as of the beginning of 1993, MS-DOS was being designed and extended separately under the "Chicago" umbrella. Microsoft wanted to have it both ways: leave room for a DOS/Windows merge in "Chicago" to kill the DOS market, and yet have MS-DOS available (at least as vaporware) to squelch any near-term advances or interests generated by DR DOS. On January 13, 1993, Silverberg wrote:
we are in an odd position here. ms-dos is both a strength and a weakness. to say that windows doesn't run on dos anymore would open the door to our competitors to say ms has killed dos. ibm and novell will claim -- they are doing this already especially novell -- that ms has abandoned dos and they are now the standard bearer. fact is, though, that despite all the complaints and lack of respect dos gets, it is the foundation of this company's livelihood and well-being. appx 40% of the entire company's profits come from dos . . . it's a franchise we have to protect.
. . .
in addition, we need to ensure that our system is well integrated, so the user just sees one system.
Exhibit 340 (emphasis added)
339. Microsoft made plain statements to the media that "Chicago" would destroy any chance Novell had in the DOS market:
In an interview Friday, senior executives at Microsoft were skeptical that any of its rivals in operating software could make much headway by offering alternatives that promised Windows and MS-DOS functionality. Microsoft plans new versions of Windows and MS-DOS that will make it "virtually impossible" for Novell, Sun or IBM to guarantee that their operating software will run future Windows and MS-DOS applications, said Michael Maples, an executive vice president.
Exhibit 348 (Wall Street Journal, March 15, 1993) (emphasis added)
340. "Systems Strategy Presentations" given throughout 1993 continue to present graphics showing MS-DOS 7.0 succeeding MS-DOS 6.0, and "Chicago" succeeding Windows 3.1. See e.g. Exhibit 346.
MS-DOS 6.0: Not a Bad Product, Except for the Data Loss Bugs,
Class Action Lawsuits, and the $120 Million Verdict
341. In March 1993, Microsoft finally released MS-DOS 6.0, which carried no significant feature advantage over DR DOS 6.0 -- released 18 months before. If anything, MS-DOS 6.0 was riddled with the most severe bugs of Microsoft's history of DOS releases. Infoworld magazine first broke the story on April 26, 1993, in its article titled "Users frustrated with trouble filled Microsoft DOS 6.0 installation." Exhibit 355. By May 26, 1993, Microsoft was forced to comment on the issue in a statement giving an "outline" of the "bugs." Exhibit 359.
342. Chase revealed the severity of the data-loss problem the next day in his internal report to the Microsoft executive staff. Exhibit 362 ("The current number of US MS-DOS 6 Upgrade customers losing data (full or partial) is about 3/1000. I do not know how to define acceptable but this feels much too high to me."). In response, Ballmer directed that Microsoft not tell the truth, but instead seek a "new level of cleverness in our naming" so that Microsoft could charge for the subsequent bug fix. Exhibit 361; see also Exhibit 449 ("Elroy" feature set including "Numerous bug fixes").
343. Microsoft launched "Elroy" as MS-DOS 6.2 in November 1993 (IBM had recently shipped PCDOS 6.1); slapped a price on it of $9.95 as an upgrade to MS-DOS 6.0; and was immediately hit with several class action lawsuits complaining that customers should not have to pay for bug fixes. See, e.g., Exhibit 440, 6 (Miller v. Microsoft); Exhibit 382, 13-15 (Steussy v. Microsoft); Exhibit 432, 26, 28, 31 (Davis v. Microsoft). The media saw through the charade:
A crude analogy might be if somebody sold you a razor that caused nicks and then became your Band-Aid supplier even as it used your patched face to advertise a new, improved line of blades.
Exhibit 393 (Chicago Tribune, November 7, 1993)
344. Microsoft, which had struggled to catch up to the technical advantages offered by DR DOS 6.0 and its compression technology, faced problems on other legal fronts. Stacker, made by Stac Electronics, produced a retail disk compression technology similar to that offered by DR DOS 6.0. Microsoft initiated licensing discussions with Stac to quickly obtain this technology. Exhibit 287. Microsoft then refused to pay Stac for the use of its Stacker technology. Thereafter, Stac won a $120 million jury verdict against Microsoft for patent infringement by the copycat disk compression system Microsoft ultimately included in MS-DOS 6.0. See Exhibit 412 (Central District Almanac, "Anatomy of a $120 Million Verdict"); Exhibit 410 (letter to OEMs and resellers informing them of verdict, and fact disk compression was being yanked from MS-DOS 6.2).
345. Not to belabor the point, but even Silverberg admitted that "[d]ata loss is a severe problem." Silverberg Depo. at 67. And even with all the bug fixes that went into MS-DOS 6.2, these data loss problems recurred. See Exhibit 409 ("We now have three confirmed data loss problems in MS-DOS 6.2"). And all this, while swelling a tidal wave of FUD against DR DOS 6.0.
VII. DECEMBER 1993-SEPTEMBER 1994: NOVELL DOS 7.0, DEAD ON ARRIVAL
346. In late-December 1993, Novell introduced a significant further upgrade to DR DOS under the name Novell DOS 7.0. Again, DR DOS added features users were waiting for and no MS-DOS product had. The two most important new features in Novell DOS 7.0 were peer-to-peer networking and the multitasking program manager. Peer-to-peer networking allowed users to network together computers without the burden and expense of installing and configuring a server. The multitasking program manager was a feature no other Microsoft product had previously had; this feature allowed users to start one DOS application running, and then switch to another one while the first one continued to work in the background. Goodman Report at 22. See Appendix B.
347. The release of Novell DOS 7.0 demonstrated that Novell would continue the DR DOS strategy of offering customers a DOS product an entire generation ahead of Microsoft. Novell added to the product's appeal by offering a close compatibility with Novell's networking products:
As with DR DOS 5.0 and 6.0, Novell is now defining the next generation of DOS products with Novell DOS 7, which integrates networking and provides superior underlying DOS technology to support that integration.
Exhibit 370 at NV002987
348. Gates was growing weary of competition with Novell. On July 21, 1993, he told his executives he wanted Novell punished for daring to challenge Microsoft's monopoly:
Who at Microsoft gets up every morning thinking about how to compete with these guys in the short term -- specifically cut their revenue. Perhaps we need more focus on this.
. . .
After their behavior in this FTC investigation, I am very keen on this.
Not many CEOs would be brash enough to direct senior executives to retaliate against a company for raising legitimate antitrust concerns with the federal government. But Gates wanted Novell plunged into a "death spiral,"(32) and his minions followed through. Novell announced its withdrawal of DR DOS from the market just over one year later.
Awards, Praise, and Compatibility -- Part 3
349. When Novell announced its feature set for Novell DOS 7.0 on March 26, 1993, Microsoft knew again that DR DOS had hit the mark.(33) Richard Freedman -- MS-DOS product manager since MS-DOS 6.0 -- wrote Chase and Silverberg:
if they really release a version with all this junk in it, it will mean that for three ms-dos releases in a row (5, 6 and 7), DR will have had our key features in their product 12-18 months before us (kernel in HMA, compression, VxD/multitasking). given that track record, it's going to be impossible to shake this "MS as follower" image. it's been very difficult so far as it is.
Exhibit 350 (emphasis added)
350. Reviews for Novell DOS 7.0 again confirmed that Novell's direction for DR DOS was what users and the industry wanted:
Vanilla DOS is history. Novell's innovative version 7 includes built-in peer-to-peer network software, several powerful utilities, and preemptive multitasking. This could be the best DOS yet.
Exhibit 386 (PC World, October 1993)
Of the three new DOSes, only DOS 7, from network market leader Novell, has built-in networking capabilities. This is big news for connected DOS users who hunger for network software that's integrated into the operating system.
Exhibit 402 (PC World, January 1994)
351. Bruce Fryer, formerly product strategy manager for Zenith Data Systems, testified that his software engineers tested Novell DOS 7.0 and "preferred" it over MS-DOS 6.0, largely due to capability and compatibility concerns. Fryer Depo. at 18-19. Indeed, Fryer testified Novell DOS 7.0 had "50 percent less incidents or problems than MS-DOS", and received fewer technical support calls. Fryer Depo. at 26.
Monopoly Maintenance: Pulling the Trigger
352. Novell was attacking Microsoft on several fronts. Jim Allchin -- whose Windows NT was facing its own battle against Novell's NetWare -- took up Gates' directive that the time had come to put Novell out of Microsoft's misery. On September 18, 1993, he surveyed the state of the competitive situation between them, and concluded the time had come for decisive action:
Sentiment is against us. We can and MUST turn this around. As we become more aggressive against Novell product and marketing-wise, we must get our mouth in order. The press, etc. is very sketical of us so one slip up and we get set back quite a ways.
This really isn't that hard. If you're going to kill someone there isn't much reason to get all worked up about it and angry -- you just pull the trigger. Any discussions beforehand are a waste of time. We need to smile at Novell while we pull the trigger.
Exhibit 383
Return
Table of Contents
Choking on Vaporware -- Part 3
353. Novell's intended plans for version 7.0 greatly worried Microsoft. As early as July 1992, Microsoft was considering how best to preempt Novell's first DR DOS offering by spreading vaporware about "Chicago." One strategy would be to tell the world Novell's DOS would not run on "Chicago." On July 9, 1992, Maritz wrote:
reminder to write up what you think . . . Novell is going to do with DR-DOS 7 and Netware. We need to be prepared.
. . .
I think we are going to have to:
a. ensure that we keep focus on DOS5/DOS6 as the right choice for the average user -- are we doing enough to ensure that the Windows integrations is spiffy enough. We need to be thinking about how we handle PR on this. Already I started to get rumblings from Paul Sherer that MS's next DOS is "nothing special." Should we leak some more info on DOS 6 before the Novell campaign gets in full swing and we get accused of inventing DOS 6 as a too little/too late solution???
b. In the corporate market we should probably start to raise the profile of Ssparta and then Chicago -- we have to keep the focus on Windows as the way to go, and start to undermine Novell's story that DOS and Windows decision can be made entirely separately. Maybe we need a coporate Chicago tour later this year that under NDA shows how we are going to mate DOS and Windows and shows how Chicago technically cant work on DR-DOS.???
Exhibit 316 (emphasis added)
354. Silverberg took up this same issue three days later, on July 15, 1992, with orders to Chase. His short-term strategy included leaks of MS-DOS 6.0, in tandem with "Chicago":
i'd like to hear in more detail your plans for advance pr on msdos6. hwo are we going to build momentum? how will we set the agenda for msdos? not let novell drive the dos message and be viewed as the new owner of dos? we need to work out our message for how we take msdos forward and tie it into window? these are very tricky tough issues.
i am wondering if we aren't playing things too close to the vest right now. we cannot let the "too little too late" or "glass half full" perception take hold. we need to let the world know we are working on --multiple-- versions of msdos at the same time, and set a positive message/momentum for astro.
Exhibit 319 (emphasis added)
355. Within two weeks, the "MS-DOS 6 Marketing Plan" was clearly laid out:
Marketing Objectives
. . .
3. Keep Novell/DR from gaining momentum
Pre-empt DR DOS 7 PR
Position DR DOS 7 as a proprietary operating system
Freeze DR DOS 7 out of the channel
Keep DR from signing any major OEMs
Exhibit 258 at MS5008679
See also Exhibit 328 ("MS-DOS 6 PR PLAN," November 1992)
356. Microsoft made its initial leaks immediately, which were reported in PC Week on August 3, 1992:
Microsoft officials have confirmed that they are working on a utilities-based DOS upgrade, but declined to comment on specific features.
. . .
DOS 6.0 is one of two versions under development by Microsoft, said officials in Redmond, Wash. The company is continuing the development of a version of DOS that includes architectural changes, such as the ability to multi-task DOS applications on a 386. This version also has significant components of Windows built in, sources said. These architectural revisions were originally slated for MS DOS 6.0, but Microsoft instead decided to first release an upgrade intended to keep up with the competition -- namely, Novell Inc.'s DR DOS.
Exhibit 322 (PC Week, August 3, 1992) (emphasis added)
357. Microsoft thereafter began to dribble out leaks -- and make presentations -- consistently disclosing that "Chicago" would be released to the market in 1993 or 1994. See e.g. Exhibit 338 (Infoworld, December 28, 1992) ("another version of DOS is only a year or two away. That version will be a real 32 bit operating system, but only under Windows on a 32 bit processor. This new version, which will likely include Windows in the same box as DOS, has been referred to as both DOS 7.0 and 'Chicago' "); Exhibit 331 (presentation to Gateway, November 24, 1992, showing release of MS-DOS 7.0 in 1994); Exhibit 339 (presentation to Far East OEMs, 1993, showing release of MS-DOS 7.0 in 1994); Exhibit 346 ("System Strategy Overview" presentation, March 1993, showing release of MS-DOS 7.0 in 1994).
358. Microsoft was not bashful about making specific representations in this regard. In a January 1993 memo to ISVs entitled "The Future of Microsoft Windows," Microsoft stated:
Chicago is the code name for the successors to MS-DOS 6.0, Windows 3.1 and Windows for Workgroups that we plan to release early in 1994 to target the volume desktop and consumer market.
Exhibit 342 at CMS00032598 (emphasis added)
359. In conjunction with the March 1993 launch of MS-DOS 6.0, Infoworld reported -- in a story titled "Microsoft outlines plans for 32-bit stand-alone OS Blueprint for Windows 4 leaves DOS in the Dust" -- that "Chicago" would be out in a year, and that DR DOS would be a dead letter:
Chicago will actually result in two separate systems offerings -- DOS 7 and the next version of Windows, which will not need DOS to run, Maritz said. . . . Officials repeatedly said the two projects would emerge from Microsoft's development teams in 1994. Last December, company officials said Windows 4 would be available in 1994.
Exhibit 347 (Infoworld, March 15, 1993) (emphasis added)
360. At the launch of MS-DOS 6.0 on March 30, 1993, Gates himself spread a bit of vaporware as to "Chicago":
Gates said MS-DOS 7.0 -- code named "Chicago" internally at MICROSOFT -- will be out in a year. . . . Gates said DOS 7.0 will be "Windows for DOS and DOS itself."
Exhibit 351
Claire Lematta -- one of Microsoft's top outside PR operatives -- testified that this type of preannouncement could qualify as vaporware in the industry. Lematta Depo. at 108.
361. All of these vaporous statements appear -- by both circumstantial and direct evidence -- to have been made in bad faith, or worse, were knowingly false when made. On April 7, 1993, Cole sent the following e-mail to Maritz and Silverberg:
I'm really counting on you to keep mum about the potential Chicago schedule slip, even within systems. All plans should proceed toward April. Apparently carl stork knows about the situation and will probably loosen his belt, if he even hints at this to Intel we are really screwed. The pressure must stay on. Making statements to the Cairo group really has potential to screw us up. Same for OLE. For now it must be M4, M5, M6 then April.
ok?
Exhibit 352 (emphasis added)
362. Two days later, Cole reported to Gates that internal schedules were, as always, of the "fake" variety he had identified as long ago as May 1990 with Windows 3.0, see supra 85:
Getting this product out quickly is serious business for us. The original RTM goal we established was Dec 93. I don't think anyone believed this date, but we built our feature set and scheduled for that goal. As expected the minimum compelling feature set could not be completed and tested in time. The team was not making the optimistic progress planned for in the schedule.
Exhibit 353 at MS0073067 (emphasis added)
363. One of the chief architects of Windows 95 testified that "at least until the feature set was completely defined for a new release like Windows 95, any schedule is going to be largely meaningless." Lipe Depo. at 90 (emphasis added). Lipe confirmed the Windows 95 feature set was still changing all the way into mid-1994. Id.
364. Even so, a steady stream of details continued to emanate from Microsoft. Presentation slides promised "the release date as mid-1994." Exhibit 360.
365. Microsoft's vaporware even found its way into mainstream media. On June 15, 1993, U.S. News and World Report reported:
ALTHOUGH MICROSOFT EXECUtives are focusing primarily on this year's operating systems -- DOS 6.0 and Windows NT -- some details about next year's DOS and Windows releases are beginning to emerge.
MS-DOS will continue to be improved as an end-user environment but not as a development environment, says Brad Chase, general manager, MS-DOS. . . . In addition, he says, "We may put things in MS-DOS that will help Windows apps run faster."
Code-named Chicago, the next version of Windows will not need DOS in order to run.
Exhibit 364 (emphasis added)
366. Microsoft's vapor tactics were, in fact, quite blatant. Microsoft anticipated Novell DOS 7.0 to hit the market in Fall 1993. On July 8, 1993, Tony Audino advised Chase and Silverberg:
The marketing team has developed and is executing a plan for restoring confidence in MS-DOS 6 with customers NOW! All tactics in this plan will be completed by the end of July.
. . .
Novell DOS 7
1) All of the same tactics from PC-DOS apply here as well. We presently anticipate a Sept release and we will be prepared.
2) Prepare positioning and "leak" of MS-DOS 7 to coincide with Novell DOS 7 announcement.
Exhibit 373 at MS7082661-662 (emphasis added)
367. PC Week reported the leaks on August 16 and August 23, 1993. Exhibit 376 (PC Week, August 16, 1993) ("Microsoft: Next MS-DOS Will Diverge From Past"); Exhibit 378 (PC Week, August 23, 1993) ("Will OS roads diverge with MS-DOS 7.0?"). Microsoft e-mail reveals that Silverberg himself made contact with the reporter. Exhibit 375.
368. Richard Freedman -- MS-DOS product manager at the time -- testified that he had no knowledge of any such leak by Silverberg. Freedman Depo. at 116-117. Freedman also testified that any such leak as to MS-DOS 7.0 alone (as opposed to "Chicago") would have been vaporware, in his estimation, because "there was never a formal schedule and a launch plan and a marketing team and the whole nine yards for this thing." Id. at 118; see also id. at 125, 134, 161-162.
369. When Novell DOS 7.0 shipped in December 1993, "Chicago" vaporware grew even worse, if that is possible. In January 1994, Microsoft invited "key technical press" to attend its "Professional Developers Conference" and, moreover, sent a letter from Chase to "all press" to continue to disclose that "Chicago is scheduled to ship in the second half of 1994." Exhibit 404.
370. Such disclosures continued to be out of step with developers' internal views. On April 7, 1994, a schedule circulated to Microsoft marketing personnel that "Chicago" would be released to manufacturing on September 30, 1994, provoking the following comment:
WOW--If you are REALLY still telling the field the RTM is Sept 30--and if you are REALLY serious--we have a ton of work to do VERY fast?!!
Is this just propaganda mail???
Making me nervous about getting the channel lined up this fast if you are serious. . . . .
Exhibit 418 at MSC00286698
371. The vapor continued unabated. On April 10, 1994, Rick Sherlund of Goldman, Sachs & Co Investment Research, the leading financial analyst of Microsoft Corporation, reported as follows:
We visited with mgmt of MSFT yesterday. No change in estimates or purchase recommendation of the stock. We have outlined some of the highlights of our visit below.
We met with the product manager of Chicago (upcoming new version of DOS and Windows) who indicated the product is still on schedule to ship later this calendar year.
Exhibit 421 at MSC00286997 (emphasis added)
372. At the "Microsoft Windows 'Chicago' Reviewers Workshop" on May 12, 1994, Microsoft vented plans to over 100 industry journalists. In his presentation, Silverberg disclosed:
Schedule and Packaging for Windows "Chicago"
Ship: 2H 1994
Exact packaging decisions are not yet final
Exhibit 422 at MSC00246109
The "post mortem" of the reviewers' workshop indicated that the continuing vaporware had worked quite successfully, and that Microsoft could look forward to several cover stories on "Chicago" that Summer of 1994 -- fully one year before the launch of Windows 95 in August 1995. See Exhibit 424.
373. Even as late as July 30, 1994, presentations were being made by Microsoft personnel indicating that "Chicago" would ship before the end of 1994. See Exhibit 429. By that time, Microsoft's plans for "Chicago" were omnipresent and effervescent. See Exhibit 426 ("Microsoft: Makes Data on Windows 'Chicago' Available Online Worldwide"); Exhibit 425.
374. Shrouded in the fog of this vaporware, which included representations that Windows 95 would not need DOS to run, see supra 339, 359-360, 365, Novell announced in September 1994 that it would withdraw from active development and marketing of further versions of DR DOS. See infra 406. With the pressure finally off, Microsoft issued this statement on December 20, 1994:
Microsoft Corporation today announced that Windows 95 may not be available until August 1995. The company made this announcement based on its continued commitment to deliver a vigorously tested product of the highest quality.
Exhibit 435
Return
Table of Contents
375. While moving towards the "Chicago" beta test cycle, Microsoft continued to use denial of access to Windows information to punish anyone promoting or associating with DR DOS:
Silverberg:
I talked to the ceo of insignia at the show. i forget his name, sorry, he was an english guy.
the issue is that i've heard thru the grapevine that insignia promoted dr dos to apple instead of msdos, for inclusion in their new machine that has a 486. he was caught off guard by my question and i could see from his reaction that yes, there is truth to this rumor. . . .
we talked for a bit, and it's clear that they are actively telling oem's about dr dos. are they promoting dr dos? that's more a matter of judgement but it's clear that they are steering oems to dr dos and letting oem's know drdos is a viable alternative to ms-dos for the cost-sensitive oems (and who isn't cost sensitive).
i let him know that this presented a conflict to us -- giving him access to windows source when he is out promoting dr dos instead of ms dos. while we didn't agree on the definition of "promote," i think he got the message.
Kruger:
You must have spoke w/ Phil Bousfield. Nick Samuels is no longer the chairman.
Novell is practically giving away DR-DOS. Insignia wants Apple to buy SoftPC.
Silverberg:
Yes, it was Phil Bousfield.
Insignia may not agree that they were "promoting" DR DOS. But Phil agreed that yes they do make sure Insignia runs on DR DOS, that they tell OEMs it runs on DR DOS, and that OEMs can choose whichever they prefer.
I am not going to provide source code to someone who is out there promoting DR DOS.
Exhibit 395 (emphasis added)
376. That day, December 2, 1993, Kruger sent a threatening letter to Insigna pertaining to access to Windows code:
I'd like to be very open about a sensitive issue that was brought to my attention.
Specifically, we are aware that Insignia has been promoting DR DOS to Apple. I don't believe Apple will bite (excuse the pun), but the fact that Insignia spent what appears to be more than a few cycles treading these waters is big concern for us.
The deal to provide Windows code for SoftPC, and our discussions to revisit MS-DOS and Windows royalties, are directed at Windows running over MS-DOS. We know from experience the implausibility of trying to support multiple OS code bases (especially where the installed base/yearly shipments are so trivial) and therefore elected to focus on MS-DOS. We would expect Insignia to follow suit.
This subject is even more relevant given Insignia's request for us to deliver Chicago M5 source code in advance of the Chicago beta test period. I would like to comply, but now need to convince Brad Silverberg (VP, Personal Systems) that Insignia's intentions are in line with ours. Brad's approval is required for all Windows 3.x/Chicago source code shipments.
Would it be possible to get a concise letter stating Insignia's position and commitment?
Exhibit 396 (emphasis added)
377. Microsoft determined to permit access to Windows' information only to OEMs and ISVs working exclusively with MS-DOS. OEMs associating with any other DOS were blacklisted:
Specter:
As we suspected, AST will stand on stage with IBM next week and announce that they will sign a license with IBM for OS/2 and other related products. These other related products will include PC-DOS. They will offer these products only to their customers that request them.
Kempin:
vERY CLEAR TO ME; nO CHICAGO, NO COOPERATION, no beta, no alpha code, total war.
Adler:
Pls add AST to the no-ship list for Chicago & Snowball materials.
Siilverberg:
they should understand that if they ship pcdos, they are at war with us.
Specter:
understood.
Exhibit 356
378. The retaliatory decision to implement the beta blacklist was made at the highest levels of Microsoft, and without fear of the size of the corporation involved:
Press Release:
In an effort to create a common framework for interoperability between applications on all desktop platforms, seven industry-leading hardware, software and networking companies have united to form the Component Integration Laboratories (CIL). APPLE COMPUTER, Inc., IBM, NOVELL, ORACLE, TALIGENT, WordPerfect Corporation, and Xerox Corporation participated in the announcement made today at the Windows Solutions Conference here.
"When end-users can access information they need from across an entire enterprise, they will achieve extraordinary gains in productivity," said Dennis Andrews, president of XSoft division of Xerox.
Silverberg:
Here's part of the reason. You'll see XSoft got the first quote and one of the leaders of this effort. There are other reasons, I'll give you a call.
As I mentioned I discussed the issue with BillG a few weeks ago and he agreed that we should not at this time give xsoft the beta. CIL was a big part.
Maples:
Called him and told him no deal. Said CIL was the big issue. He said that 75-80% of his business in from Windows and that he felt at a competitive disadvantage. I told him that maybe he should drop out of CIL. Said he did not want to but would consider.
He raddled his saber a little asking if anyone had legally challenged us on betas.
Exhibit 391 at MS7093801-802 (emphasis added)
379. Microsoft's purpose was clear, as subsequent discussion of the Xerox beta blacklist confirms:
seems like we are being a little paranoid about them. I don't really see them as a systems threat. I think they have gotten the word that they need to play ball with us.
Exhibit 405 (emphasis added)
380. At this point, Novell also approached again to specifically request that Novell be permitted access to the forthcoming Chicago betas to ensure compatibility of future versions of DR DOS. As before, and for the same reasons, the request was denied. Exhibit 371; Exhibit 372; Exhibit 385.
381. In Spring 1994, as "Chicago" entered its beta cycle, Microsoft extorted onerous NDAs that would block independent developers from providing development feedback to Novell for three years if they agreed to be a beta site:
1. GRANT OF LICENSE. Microsoft grants COMPANY the right to use the PRODUCT only for the purpose of testing the compatibility of COMPANY's application product(s) which operates in conjunction with the PRODUCT, and for evaluating the PRODUCT for the sole purpose of providing feedback to Microsoft. The Product shall not be used in the development of a COMPANY product or technology that is competitive with the Product, including the technology known as OPENDOC, WABI, clones of Windows, and operating system products, including Personal NetWare, Novell DOS Development (DR-DOS), UNIXware.
. . .
4. CONFIDENTIALITY. The PRODUCT is confidential and proprietary to Microsoft and its suppliers.
In no event shall COMPANY disclose the PRODUCT to the development teams of any operating system products, including Personal NetWare, Novell DOS Development (DR-DOS), UNIXware, WABI or other clones of Windows, or any teams that are developing successor operating systems to the foregoing, or to any individual on the development team working on OPENDOC. In consideration of the license granted herein, for a period of three (3) years COMPANY agrees to prohibit any authorized individuals who have had access to the PRODUCT from participating in the design and/or development, feedback, or guidance of a COMPANY product or technology that is competitive with the PRODUCT, the technology known as OPENDOC, WABI, clones of Windows, and operating system products, including Personal NetWare, Novell DOS Development (DR-DOS), UNIXware, without Microsoft's express written permission.
Exhibit 413 (emphasis added)
382. By the middle of 1994, even diehard supporters knew to stay far, far away from DR DOS. See, e.g., Exhibit 354 (letter from Central Point Software to Microsoft: "Going back to the negotiations of our agreement, you made yourself completely clear that contractually you would not allow us to do business with DR-DOS, or any third party that shipped DR-DOS on more than 50% of their systems . . . and we have not!").
383. As almost an afterthought, Microsoft continued its FUD campaigns. Having run DR DOS through the wringer twice previously, Microsoft knew the drill. Silverberg casually tossed off the positioning statement in an interview reprinted May 19, 1993:
Q. Are you concerned the forthcoming DOS versions from IBM PC DOS and Novell DOS will cut into your current 90 per cent share?
A. I don't think much will change. It's too late for IBM. All of the major OEMs, including some parts of the IBM PC company, have signed up for MS-DOS. . . . [As for Novell DOS] what's the point? Why take the risk with all the compatibility problems that DR DOS has had? Even IBM didn't do that.
Exhibit 357 (PC User, May 19, 1993) (emphasis added)
384. That FUD had become perfunctory was reemphasized in April 1994, in the "Desktop Operating Systems Mission" memo addressing threats to the upcoming launch of Windows 95:
Competitive marketing strategies
. . .
Novell
. . .
Position DR DOS as "as incompatible as ever."
Exhibit 415 at MS7066243
385. As with DR DOS 5.0 and 6.0, Microsoft pulled together several specific FUD sheets to distribute on Novell DOS 7.0. See, e.g., Exhibit 390 ("MS-DOS vs. DR DOS Comparative Review"); Exhibit 399 ("Novell DR-DOS 7 and Personal Netware Product Bundle Analysis"); Exhibit 406 ("Novell DOS 7 and Personal Netware"). These "bug sheets" continued to make unverifiable, unsubstantiated, blanket claims of incompatibility. See supra 50, 121, 274. Microsoft also continued to make purported problems seem worse that reality. See Ivie Decl. (noting false and misleading statements about Novell DOS 7.0 in Exhibits 390, 399, and 406).
386. But even at this late stage of the game, Gates' continuing preoccupation with Novell as the biggest threat to Microsoft's desktop operating system monopoly led to recommendations that Microsoft engage in seemingly trivial conduct to dispirit or disrupt Novell. An e-mail to Gates on April 5, 1994 reveals the shameless extreme:
At yesterday's Exec Staff meeting you asked what else could be done to attack Novell/WP. At the Exec Retreat in Feb, I suggested that we should lock up the LDS Church (and BYU) as a 100% MS account. While this may not be Novell's or WP's largest account, it is certainly an emotionally and psychologically important account. Were we to own this account, we would inflict an incredible amount of FUD on the new Novell/WP. The influence of the LDS church in the Utah economy and culture is difficult to appreciate from a distance.
I recommend we throw some significant weight at this account. . . . In addition, it would be great for Billg to make time for a trip to Salt Lake City to meet with church leaders. It may be possible to leverage your mother's membership on the KIRO board (KIRO is owned by a subsidiary of the Church, Bonneville Communications).
Exhibit 417 (emphasis added)
Return
Table of Contents
Exclusionary Licenses: No Wiggle Room
387. OEMs rebelled against the short leash by which Microsoft held them. Advances in technology could -- or rather, should -- have opened competition for OEM installation. Microsoft would have none of that. During negotiations with Compaq, Silverberg made the following observations to Gates and Kempin:
1. Compaq wants to stop preinstalling Windows and instead provide our OS's on a CD for installation by the customer. They would have windows and NT (and maybe wfw) on the cd.
I think we should strongly encourage Compaq to continue preinstallation. Preinstallation is a great thing for us -- we own the territory. It gives customers a good first experience, being able to boot right up. I suspect the number of accounts who clear off the hd is small. We can work with them on streamlining their mfg and optimizing the odks for their needs.
Further, once our os's are off the machine and on to a CD, then it is a small step for the oem to want to put other, non-ms sw on that cd, like OS/2, Novell, etc. . .
2. Compaq thinks they can distribute our os sw however they want. Joachim, you'll need to check the contract on this. If they think they can distribute however they want, again, it's a small step to putting other os software on the cd rom.
Exhibit 387 (emphasis added)
388. The per processor licensing noose continued to tighten. One OEM, Zenith Data Systems approached Microsoft about a "carve out" -- exemption from their per processor obligations where customers did not want to use MS-DOS -- but was informed "it was not Microsoft's policy to make exceptions to this pricing model." Id. at 48, 50-51. Zenith went so far as to design a computer system that could not run on MS-DOS -- the only wiggle room it could think of to get Novell DOS 7.0 onto its systems. Fryer Depo. at 37-39. Zenith ultimately chose not to release this MS-DOS-disabled system, as it robbed customers of the ability to choose at any time which operating system they preferred. Id. at 40-41. And Zenith shipped no Novell DOS 7.0 system because "we would end up having to pay Microsoft a royalty for MS-DOS at the same time." Id. at 35; see also id. at 120.
389. By the middle of 1994, the Department of Justice was winding down its inquiries into Microsoft's licensing practices. On March 2, 1994, Gates engaged in an e-mail exchange with an interested reporter, Wendy Goldman-Rohm, wherein he trotted out the same tired justifications for per processor licenses that Microsoft was forwarding to the Department of Justice (and which Microsoft rolls out again in this lawsuit). In short, he explained it as a volume discount. Exhibit 411. Caldera's economist has readily rebutted Microsoft's contentions in this regard, as volume discounting is taken care of elsewhere in Microsoft's pricing structure, i.e., the step-down in price associated with increasing volume. Leitzinger Rebuttal Report at 2-3. Indeed, a "low-volume customer opting for a per-processor license would see a much bigger discount than a high-volume customer who did not." Leitzinger Rebuttal Report at 3. Even Microsoft's economist testified per processor licensing is not a volume discount, but is instead "a discount for a closer relationship or for something approaching exclusivity." Schmalensee Depo. at 341-342.
390. More interesting, however, is the fact that Microsoft in 1994 was also considering how it would license Windows 95 to the world. On April 4, 1994, in a memo titled "OEM Sales FY '95 Goals, Strategies, Facts," Kempin made the most startling admission:
Goals:
. . .
2. Ensure at least 80% of all new Windows PCs are being shipped as "Chicago PCs" by Q4 FY'95.
. . .
At the same time, I expect us to change our licensing policy to reflect the following:
We are considering true volume pricing.
Exhibit 416 at MS7049582, -584 (emphasis added)
Return
Table of Contents
C. Implementing the DOS/Windows Merge -- Part 2
391. At some point after December 1993, Microsoft executives made the decision not to offer MS-DOS 7.0 on a stand-alone basis. Maritz Depo. at 109. All plans would proceed towards one merged product: Windows 95. No Microsoft executive or developer would admit when this momentous decision was actually made, or who actually made it. See Maritz Depo. at 18-19, 106-109, 167; Silverberg Depo. at 279; Ballmer Depo. at 198-199; Freedman Depo. at 136-138; Lipe Depo. at 80, 88-89.
392. Several specifications and planning documents for a stand-alone MS-DOS 7.0 exist. On May 24, 1993, Richard Freedman -- DOS product manager -- circulated the "MS-DOS 7 Product Plan Strawman" to propose a feature set. Exhibit 358. On August 20, 1993, the project was dubbed "Chico" as "a placeholder code name for MS-DOS based on Chicago." Exhibit 377 at CMS00030374. On October 6, 1993, an "MS-DOS 7 Review" laid out different ideas for deriving a DOS offering from "Chicago." Exhibit 388. On October 20, 1993, Gates, Ballmer, Maples, Maritz and Silverberg received a recommendation from Freedman that MS-DOS 7 be "Chicago Neutered," i.e., a product that did everything except run Windows applications. Exhibit 389. On December 23, 1993, the project had been code-named "Felix" in a preliminary plan because, like "the cartoon cat with the same name . . . MS-DOS is a product which just won't die. . . ." Exhibit 398 at CMS00010048.
393. Microsoft began to plan the actual marketing and pricing of "Chicago." Since everyone knew it was Windows and MS-DOS in a single package, the then-current combined price of MS-DOS and Windows became the assumed base price. A memo to Maritz in September 1993 titled "Windows Enhancement Business Opportunity" stated:
Our model assumes MS-DOS 7.0 will be available on a stand-alone basis to the small number of OEMS (< 10%) who do not sign up for Chicago, and to non-Windows users that want to upgrade to MS-DOS 7.0. We are assuming OEM pricing for Chicago of $35 per unit, approximately the same as the combined prices for MS-DOS and Windows.
In FY95, Windows OEM revenue increase sharply because the revenues that formerly would have flowed to MS-DOS transfer to Windows.
Exhibit 384 at MS7048953-954 (emphasis added)
394. Silverberg confirmed this approach in December 1993, when he summarized his conversation with an interested reseller:
also he asked about chicago pricing. i said that since it's the combination of windows and msdos and more, you should expect a price in the same ballpark as windows + ms-dos. . .
Exhibit 395 (emphasis added)
395. Kempin made the exact point in December 1993, as well:
Ballmer:
1. we have no plan to use chicago to increase oem royalty rates that I knwo of I expect most oem's togo base which will have the same royalty essentially as wfw [Windows for Workgroups] today right JK??
Kempin:
YES MS-DOS + WFW = CHICAGO BASE
Exhibit 397 at MSC00347104
396. At the same time, Microsoft labored to create the illusion of an integrated operating system, where in fact Windows was simply running in conjunction with MS-DOS. In conversation with his technical developers, Silverberg instructed as follows in November 1993:
Straub:
BrianRey was telling me that there's discussion about not having an easy/documented way to start chicago real-mode (eg like MS-DOS F5 clean boot) w/o starting Windows. Is this true?
Adler:
yes.
We are pushing Chicago as not just Windows on top of DOS. That perception is broken pretty badly if you boot into DOS and type WIN. It also creates problems if people start expecting Chicago to run atop MS-DOS 6.x or DR/Novel DOS of any variety.
Why would we want to boot direct to DOS?
Silverberg:
customers should just boot to windows and not have to type win. if you want some f5 thingie on boot to clean boot dos and then bail out, that's fine. especially if there's a way to get from there to chicago.
i do NOT want an option on bootup to ask the user whether he wants to boot to chicago or stop.
Exhibit 392 (emphasis added)
397. Silverberg's illusion is maintained for the average user. However, by simply changing the "boot GUI" setting from "1" to "0," Windows 95 boots to "the same old MS-DOS command prompt" and a DOS that "should be compatible and should be as functional as MS-DOS 6.-whatever." Lipe Depo. at 97. By typing "WIN," the user can launch to a Windows environment -- the exact technique when launching from, e.g., MS-DOS 6.0 to Windows 3.1. See also Hollaar Report at 19.
398. Microsoft PR also stepped up efforts to confirm positioning that DOS was nowhere within "Chicago." On January 10, 1994, in a letter sent to "all press explaining the coverage policy and providing them general information about Chicago," Microsoft stated:
Chicago Questions and Answers . . .
What are the key benefits and features of Chicago? What features will Chicago not have?
Chicago will be a complete, integrated protect-mode operating system that does not require or use a separate version of MS-DOS, implements the Win32® API, and provides pre-emptive multitasking and multiple threads of execution for 32-bit applications.
Exhibit 404 at MSC00346032 (emphasis added)
399. Presentations into 1995 through the launch of Windows 95 also reflected this change. In April 1995, Gates gave a presentation with a graphic showing MS-DOS and Windows packages blending to create Windows 95 -- a distinct contrast to prior graphics that revealed Windows 4.0 sitting atop MS-DOS 7.0. Exhibit 437.
400. In this case, Microsoft trots out the notion that Windows 95 is some sort of mysterious new operating system designed from the ground up. But in April 1994, when discussing "Chicago positioning" internally, Silverberg forcefully asserted the contrary:
I would hesitate to say that chicago is a complete redesign. one of the things about chicago is that while it's a big big improvement, it's still an incremental step forward. i would be afraid of scaring people off, thinking, whoa, i better let this settle down before i try it. it's a generation step forward. like a new Honda Accord. A redesign for sure, a big step forward for sure, a "car ahead" as they like to say, but still retains the best parts of their heritage.
Exhibit 420 at MSC00514926 (emphasis added)
401. Of course, to the world (as to this Court) Microsoft was telling a much different story.
402. Microsoft had repeatedly told the market to expect on a stand-alone basis the DOS functionality ultimately shipped in Windows 95. Microsoft made such promises as long ago as September 1991, when the project was still numbered as MS-DOS 6.0. See supra 310-313. Microsoft later renumbered that promised version to MS-DOS 7.0. The promises continued, and Gates stated at the launch of MS-DOS 6.0 that users could expect MS-DOS 7.0 by early 1994. See supra 360. Silverberg made similar promises in May 1993. Exhibit 357 (PC User, May 19, 1993) ("Chicago will be fully bootable. . . . there's also a version of the operating system that we'll pull out and ship as DOS 7.0").
403. Nonetheless, by April 1994, Microsoft executives had decided to pull the plug, for the worldwide product planning overview for 1995 to 1997 announced:
MS-DOS:
We plan no new releases of MS-DOS after MS-DOS 6.22cfcs [first customer shipment] May 31, 1995!!
Exhibit 414 at MS0160411
404. MS-DOS was dead -- at least as a stand-alone product. Yet Microsoft was still engaging in vaporware to keep DR DOS at bay. For in April 1994, Richard Freedman instructed the sales force as follows:
here is my standard answer on "where is ms-dos 7?"
the bottom line is that if customers want ms-dos 7, we'll do it, and we'll ship it a few months after chicago.
if we do an ms-dos 7, it will be chicago without the gui.
but if customers insist on ms-dos 7, we'll build it. [never leave an opening for novell or ibm.]
Exhibit 419 (brackets in original)
Return
Table of Contents
405. In April 1994, at age 70, Ray Noorda turned over the day-to-day management of Novell to the new president and CEO, Bob Frankenberg, a Hewlett-Packard executive hired as Noorda's successor. Noorda retired from Novell's Board of Directors in November 1994; Frankenberg replaced him as Chairman; and the transition was complete. Exhibit 434 (Novell press release).
406. Throughout the Spring and Summer of 1994, Frankenberg reviewed Novell's product lines and business plans to determine the course he would chart for the company's future. He decided to focus on Novell's strengths in networking and the NetWare product line -- and to concede the DOS market to Microsoft. With his experience as an OEM executive, Frankenberg knew Microsoft had completely shut DR DOS and Novell DOS out of the OEM channel through long-term per processor licensing and other tactics, and had effectively destroyed any chance of securing the revenue stream necessary to justify continuing development and marketing expenses. And he knew Microsoft had positioned the forthcoming release of "Chicago" as the end of the DOS market altogether. Seeing little chance of breaking Microsoft's iron grip on the desktop operating system market, in August 1994 Frankenberg determined that Novell should discontinue development and active marketing of Novell DOS 7. Frankenberg Depo. at 264; Exhibit 400 ("1994 Business Plan"); Exhibit 430 ("Novell DOS Business Planning"); Exhibit 431 (PC Week, August 22, 1994).
407. Though Microsoft positions Caldera's charges in this case as a "purchased lawsuit," even industry observers at the time knew that Noorda still believed in DOS, and still wanted Microsoft to have its come-uppance:
Novell is considering selling Novell DOS to a third party, sources said. Among those said to be interested in buying the rights to DOS is Novell's former chairman and CEO Ray Noorda, sources said.
Exhibit 431 (PC Week, August 22, 1994)
Return
Table of Contents
VIII. JULY 15, 1994: UNITED STATES VS. MICROSOFT CORP.
408. In June 1990, the FTC commenced an investigation of Microsoft for possible antitrust violations, originally directed towards market division concerns between IBM and Microsoft. The focus rapidly shifted towards Microsoft's monopolization of the DOS market. With one of five commissioners recusing, the FTC deadlocked twice, on February 5, 1993, and August 20, 1993. Microsoft continually suggests this was exoneration, but that is not so. In a letter of August 20, 1993, the FTC explicitly informed Microsoft that it should draw no inferences regarding antitrust violations:
The Commission has conducted an investigation involving possible violations of the Federal Trade Commission Act by Microsoft Corporation. Upon further review of this matter, it now appears that no further action is warranted by the Commission at this time. Accordingly, the investigation has been closed. This action is not to be construed as a determination that a violation may not have occurred, just as the pendency of an investigation should not be construed as a determination that a violation has occurred.
Exhibit 379 at C016572 (emphasis added)
409. As well, the Korean Fair Trade Commission had by then launched and concluded its own investigation of Microsoft's licensing practices, with specific focus on per processer requirements, minimum commitments, and 3-year terms. See Exhibit 108 ("We have some indications that the Korean Government is trying to challenge our per processor contracts under Korean trade law"). Microsoft's records indicate that the Korean government found that such terms "may restrain trade" and "requested the terms be altered." Exhibit 295 at X0598561; see also Exhibit 297 (legal opinion to Novell). Thereafter, the Korean government took an active role reviewing and approving licensing terms Microsoft proposed to Korean OEMs. See, e.g., Exhibit 318 (Microsoft OEM status report indicating Korean FTC refused to approve subsequent terms offered Goldstar, Qnix, Trigem, and others).
410. On August 20, 1993, the very day that the U.S. FTC closed its investigation, the Department of Justice opened its own. In September 1993, Novell filed a complaint against Microsoft for anti-competitive practices in Europe with the European Commission. Exhibit 365 (attachments omitted). These matters were not subject to a vote, but instead to prosecution. Within a year, Microsoft capitulated. On July 15, 1994, it entered into a Consent Decree with the Department of Justice and made an Undertaking with the European Commission. Exhibit 2 (Consent Decree); Exhibit 3 (Undertaking).
411. Through the Consent Decree and the Undertaking, Microsoft agreed that, as to any "Covered Product,"(34) it would not enter into any license agreement that:
Exhibits 2 and 3
412. Microsoft has suggested this defeat was somehow a victory, and was in fact no finding of liability. Attorney General Janet Reno saw things differently, and said so on July 16, 1994:
Microsoft's unfair contracting practices have denied other U.S. companies a fair chance to compete, deprived consumers of an effective choice among competing PC operating systems, and slowed innovation.
Exhibit 427 at CMS00018866
413. The Assistant Attorney General in charge of the Antitrust Division, Anne K. Bingaman, expressed a similar sentiment:
Microsoft is an American success story but there is no excuse for any company to try to cement its success through unlawful means, as Microsoft has done with its contracting practices.
Exhibit 427 at CMS00018867
Return
Table of Contents
IX. AUGUST 1995: DOS IS FINALLY . . . REALLY, REALLY WELL-HIDDEN
414. Although Microsoft has told the world otherwise, Windows 95 is nothing more than an updated version of MS-DOS packaged together with an updated version of Windows. Hollaar Report at 15-26. The relationship between DOS and Windows in Windows 95 is no more complex than it was with prior versions of DOS and Windows -- versions that were sold as separate products. Hollaar Report at 19-20. Caldera's experts have separated the DOS and Windows components in Windows 95 with little effort. The remaining products function as stand-alone versions of DOS and Windows; the DOS, for example, easily runs DOS programs. See Hollaar Report at 15-26. The decision to put the two products together and sell them as a single product was nothing more than a packaging decision, made by Microsoft's executives. See, e.g., Lipe Depo. at 80; Maritz Depo. at 18-19.
415. Caldera elicited candid testimony from two key individuals on the Windows 95 project: Richard Freedman (a Windows 95 product manager) and Phil Barrett (a lead developer on MS-DOS 5.0, Windows 3.1 and, until his departure in October 1994, Windows 95). Barrett's testimony is devastating to Microsoft's defense:
Q. I think when you and I talked about it before, you described Windows 95 as DOS and Windows stuck together with baling wire and bubble bum?
A. That is a fair if colloquial representation of it, yes.
Q. And what do you mean by that?
A. That basically, yes, there is DOS on the underlying -- under the hood there is DOS. There is a form of DOS, a version of DOS that was -- and I don't know all of the details of what developed. I don't understand all they did there, but you can actually produce a bootable DOS diskette. There is still 16-bit code inside.
Q. And when you said they were tied together with baling wire and bubble gum, you were referring to the amount of integration between DOS and Windows in Windows 95?
. . .
A. Yes.
Q. Is it your understanding that the relationship between DOS and Windows in Windows 95 is the same as it was between DOS and Windows in prior versions such as DOS 6.x and Windows 3.x?
. . .
A. There's a similar relationship.
Barrett Depo. at 60-61
416. Barrett was perfectly clear that it was not required for there to be a single product to take advantage of any advances in Windows 95. To the contrary, "[i]t could have been done as two separate products." Id. at 63. The only "technical" advantage of having a single product was to have a single installation. Id. at 63-64. But when pressed, Barrett admitted that the actual design challenge was the same whether it was a single combined installation program, or a separate DOS-then-Windows installation. Id. at 66-67. Moreover, one OEM testified that the single installation makes the process more difficult, and certainly did not save any time. Harvey Depo. at 31-32.
417. As for Freedman, he plainly admitted that demand for DOS functionality continued; that "MS-DOS functionality certainly became part of Windows 95"; that "Windows 95 actually has enhanced MS-DOS functionality in it that is not in MS-DOS 6.2"; and that "the continuing enhancement of MS-DOS was going to take place under the umbrella of Windows 95." Freedman Depo. at 129, 137, 140, 205. He also admitted that it was feasible to separate out the DOS component to ship separately: "Again, anything is feasible. The question is, is it worthwhile." Freedman Depo. at 178; see also Maritz Depo. at 15-16; Silverberg Depo. at 278-279; Lipe Depo. at 108; Reynolds Depo. at 151. Paul Maritz, who was in charge of the product above Brad Silverberg, could not recall Microsoft seeking any input from any OEMs or ISVs as to whether single or multiple products were preferred. Maritz Depo. at 20.
418. In the face of such testimony, the only question for the Court is this: Why does Microsoft get to be the only company satisfying the need for improved DOS technology simply by virtue of its Windows monopoly?
419. In October 1994, Bryan Sparks, a Novell engineer, left Novell and founded Caldera, Inc. Sparks approached Ray Noorda, Novell's former chairman, and obtained initial funding from the Noorda Family Trust to develop Linux-based operating system products. Sparks Depo. at 5-6 (November 4, 1998). Linux is "open technology" available for free over the Internet. See www.caldera.com. Unlike Microsoft's Windows 95, 98 and NT products, Linux is not proprietary and is readily available to users and developers. Sparks Depo. at 5-6 (November 4, 1998).
420. Sparks believed that Linux would be more valuable bundled with DR DOS, and also believed that DR DOS could be sold into the emerging market for embedded devices. Sparks Depo. at 6-7 (November 4, 1998); Sparks Depo. at 26 (July 28, 1998). In May 1996, Caldera approached Novell seeking a license for the DR DOS business. Sparks Depo. at 25 (July 28, 1998). Due to Noorda's long-standing faith in DOS and its potential, and because he believed Novell had ample grounds to have brought suit against Microsoft, see generally Noorda FTC Affidavit, the negotiations quickly moved from simply licensing Novell DOS to purchasing the technology and the associated claims asserted in this suit. On July 23, 1996, using additional funding from Ray Noorda, Caldera executed an Asset Purchase Agreement transferring Novell's rights in Novell DOS to Caldera. Exhibit 438. On that same day, Caldera filed this suit against Microsoft. Sparks Depo. at 28-31 (July 28, 1998).
421. Caldera's attorneys have been adamant from the beginning:
"It is our intention to finish the job the Justice Department left unfinished when it settled its antitrust complaint through consent decree," Susman said.
Exhibit 439 (Associated Press, July 24, 1996)
XI. MAY 18, 1998: UNITED STATES VS. MICROSOFT CORP. -- PART 2
422. On October 20, 1997, the Department of Justice (DOJ) filed a petition seeking to hold Microsoft in contempt for violating the 1994 Consent Decree. Specifically, the DOJ claimed Microsoft's bundling of Windows 95 and Internet Explorer, an internet browser, violated the Consent Decree's prohibition on conditioning the licensing of any "covered product," including Windows 95, on the purchase of any "other product." Exhibit 441 (Petition to Show Cause Why Microsoft Should Not Be Held In Contempt). The DOJ alleged no substnative antitrust violations at that time.
423. Microsoft claimed its actions were consistent with the Consent Decree because the tying prohibition "in and of itself shall not be construed to prohibit Microsoft from developing integrated products." See Exhibit 2, IV.E(i). The Consent Decree, however, in no way defines the term "integrated products," and indeed, the DOJ was not focused on Microsoft's tying practices at the time the Consent Decree was negotiated. Rather, the DOJ focused on Microsoft's licensing practices. Exhibit 442, 7 (Affidavit of Richard Urowsky). Windows 95 was itself over one year away from release at the time the Consent Decree was negotiated.
424. The District Court for the District of Columbia granted a preliminary injunction against Microsoft's tying practices, which was later dissolved as procedurally improper. See United States v. Microsoft Corp., 147 F.3d 935, 943-944 (D.C. Cir. 1998). The case was remanded for further factual development to determine whether the combination of Windows 95 and Internet Explorer created even a plausible claim of consumer benefit.
425. On May 18, 1998, before the D.C. Circuit's decision was released, the DOJ filed a substantive antitrust complaint against Microsoft, accusing it of engaging in tying and exclusive licensing with respect to Windows 95 and Windows 98 in violation of the Sherman Act. Exhibit 444 (Complaint). Joel Klein made clear that the Antitrust Division intended to end Microsoft's continuing monopolistic practices once and for all:
"The lawsuit we filed today seeks to put an end to Microsoft's unlawful campaign to eliminate competition, deter innovation, and restrict consumer choice."
Exhibit 445 (Press release, May 18, 1998)
426. The DOJ dropped the Consent Decree litigation, and instead pursued its substantive antitrust claims. That trial is currently underway in Washington, D.C.
Return
Table of Contents
Caldera offers the foregoing Consolidated Statement of Facts in support of its forthcoming Responses to Microsoft's Motions for Summary Judgment.
|
|
Respectfully submitted, Parker C. Folse III |
I hereby certify that on April ____, 1999, true and correct copies of the above and foregoing instrument (Case No. 2:96CV0645B, U.S. District Court, District of Utah, Central Division) were sent via Federal Express to:
|
Richard J. Urowsky James R. Weiss |
James S. Jardine William H. Neukom
Charles R. Eskridge III |
1. The vast majority of Caldera's exhibits come from documents produced by Microsoft, many of which consist of internal e-mail. Caldera has attempted to reproduce all extracts identically, typos and all, without reference to "sic" or some similar convention. Ellipses denote omitted material. Where emphasis is added, it is noted. Explanatory inserts are set off in brackets. Return
2. Caldera defines the relevant market -- "the DOS market" -- as follows: "[T]he market for MS-DOS operating system software and functionally equivalent software . . . designed to run on personal computers using Intel x86 or Intel x86-compatible microprocessors ('PCs')." Exhibit 1 at 1. (First Amended Complaint); see also Kearl Report at 3-11. Microsoft's many summary judgment motions do not challenge this definition. Neither does Microsoft assert it lacked monopoly power in the DOS market. Nor could it. See, e.g., Ballmer Depo. at 139 ("Low 80 percent market share"); Werner Depo. at 82 ("Probably about 80. 80, 85 percent"); Chestnut Depo. at 91 ("greater than 90 percent"); Freedman Depo. at 156-157 ("95 percent"). Even Microsoft's economist agreed Microsoft has monopoly power in a "static" sense. Schmalensee Depo. at 274-275. Return
3. Microsoft's repeated references to Matsushita Electric Industrial Co. v. Zenith Radio Corp., 475 U.S. 574, 106 S.Ct. 1348 (1986), and related cases are misplaced. First, Matsushita concerned the quantum of evidence necessary to prove an antitrust conspiracy -- not unilateral conduct such as Microsoft's. More importantly, the allegations in Matsushita concerned a purported 20-year conspiracy to sell products below cost in the United States in hopes of putting American competitors out of business, whose market share had actually increased during those years. The Court refused to imply an implausible conspiracy from mere evidence of parallel conduct. Moreover, the Court found the evidence of price cutting to go to the heart of consumer benefit intended to derive from the antitrust laws. See Kodak, 504 U.S. at 478, 112 S.Ct. at 2088. Caldera's allegations clearly touch on conduct unrelated to cutting prices or other consumer benefit. And there is nothing implausible about what Microsoft set out to do to DR DOS, nor did Microsoft fail in its effort to dominate the market. Under Tenth Circuit law, Matsushita is inapplicable. See Instructional Systems Develop. Corp. v. Aetna Casualty & Surety Co., 817 F.2d 639, 646 (10th Cir. 1987). Return
4. CP/M sales suffered following the introduction of the IBM PC using Microsoft's MS-DOS operating system. DRI responded by retooling its operating system products to make its CP/M-based products compatible with DOS. In particular, DRI built DOS compatibility into its Concurrent CP/M operating system, which eventually evolved into DRI's Concurrent DOS product. Williams Decl. at 4-5. Return
5. Microsoft and IBM entered into a "Joint Development Agreement" in June 1985, to cross-license source code and confirm future development responsibilities. Gates at 285-286. IBM took over DOS development, and Microsoft committed to focus on OS/2. Gordon Letwin -- Microsoft's chief DOS architect -- described it as IBM having "artistic control" over the DOS standard. Gates at 315. Return
6. MS DOS 3.3, released in August 1987, was viewed as a "do nothing OS" by corporations, but was a default choice because it was a relatively safe and stable. Freedman Depo. at 28-29.Return
7. "Beta testing" is commonly used in the software industry to improve the quality and reliability of new products. The software developer gives pre-release versions of a new software product to OEMs and other users that will test it with a variety of configurations and applications, and report findings to the developer. Goodman Report at 4. Return
8. Phil Barrett testified that "[t]here were a number of what we called, somewhat jokingly, user-hostile features that were added [by IBM]." Barrett Depo. at 37-38. Because IBM's PC-DOS 4.0 was received so poorly by the market upon its release, Microsoft did a bit of additional work to clean up the most glaring bugs before releasing its own MS-DOS 4.01. Brad Silverberg, who was brought to Microsoft from Borland in the Summer of 1990 to oversee design and development of MS-DOS 5.0, readily conceded that MS-DOS 4.01 was riddled with bugs and a memory hog. Silverberg Depo. at 49, 55-58; see also Exhibit 41 (development presentation related to deposition testimony). Theo Lieven, CEO of Vobis Microcomputer AG -- the leading German OEM -- testified as well that "MS-DOS 4.01 has -- had a very bad reputation." Lieven Depo. at 25-26. Roger Harvey, primary shareholder of Qubie -- a British OEM -- concurred. Harvey Dep. at 14. See also Werner Depo. at 85, 109; Chestnut Depo. at 16, 18-19; Freedman Depo. at 22-23. Return
9. This tactic had worked previously. A company named Phoenix had developed to market its own BIOS, a "basic input/output system" which managed peripheral devices such as printers, disk drives, and monitors. DOS has its own BIOS, and so Phoenix had the capability of bringing to market a DOS clone. Kempin admitted that: "The source for DOS was 'given' (10k) to Phoenix in return for not developping a comparable clone product." Exhibit 91. Return
10. "OEMs" (original equipment manufacturers) are the actual companies assembling and selling PCs. Licensing applications and operating systems through this channel is a high-volume, lucrative way of doing business. Return
11. Caldera has defined the "GUI market" as "the market for graphical user interfaces that run on top of DOS Software." Exhibit 1, 64 (First Amended Complaint); see also Kearl Report at 27-30. Microsoft does not appear to contest this definition as a point in its summary judgment motions. Return
12. Minimum commitments are discussed at length, infra 144-145. Return
13. This transcript was produced to Caldera in conjunction with documents pertaining to a 1986 lawsuit brought by Seattle Computer Products. Return
14. Microsoft elaborated its public position in early 1995, in its "White Paper on Vaporware in the Software Industry." Exhibit 436. Return
15. DR DOS 5.0 shipped by the end of June 1990, following a slight delay "to perform additional testing on the product to ensure the highest level of compatibility possible with Windows 3.0," which shipped in May 1990. Exhibit 54; see also Constant Decl. at 17-18. Return
16. Maritz wrote in February 1993 that "Windows has become an OEM phenomenon. We have 80%+ market share." Exhibit 345; see also Werner Depo. at 129-130, 134. Caldera's economist concludes that Microsoft has had monopoly power in the GUI market since at least 1991 with the introduction of Windows 3.1. Kearl Report at 30. Microsoft has not challenged Caldera's allegation of market power in the First Amended Complaint. Return
17. When Vobis renegotiated its MS-DOS, after the demise of DR DOS, Microsoft nearly doubled the royalty rate, to $17. Lieven Depo. at 110. Return
18. Microsoft employed this tactic -- disguised cash payments to cease an OEM from shipping DR DOS -- on other occasions. See, e.g., Exhibit 173 (Microsoft account manager reporting that Cardinal had purchased "several hundred thousand dollars" of DR DOS, and so "[w]e are addressing their issues of price and absorbing their prepaid"); Exhibit 213 (Microsoft account manager noting that CompuAdd Express had already purchased a large order of DR DOS 6.0, and so was considering ways to "buy back" that order). Notwithstanding his own conduct towards Vobis, Kempin testified, "I think it's a mistake to do that." Kempin Depo. at 279. Return
19. Application software was not typically offered on a per processor basis. Kempin Depo. at 44, 46.Return
20. See Appendix A. Time between launch of MS-DOS versions 1.0 and 2.0 was 19 months (August 1981 to March 1983); between versions 2.0 and 3.0 was 18 months (March 1983 to August 1984); and between versions 5.0 and 6.0 was 22 months (June 1991 to March 1993). Caldera ignores the large passage of time between versions 3.0 and 4.0, and between 4.0 and 5.0, as atypical, due to Microsoft's neglect and stagnation of the standard. See supra 15-16, 22-23. Time between launch of DR DOS versions 5.0 and 6.0 was 15 months (June 1990 to September 1991). Time between launch of DR DOS 6.0 and Novell DOS 7.0 was 27 months (September 1991 to December 1993), though this must be discounted due to the DRI/Novell merger and Microsoft's distracting proposal of its own merger with Novell. See infra 181-184. Return
21. Microsoft's "NT" technology was derived from work Microsoft had done for OS/2 3.0, which was under development at the time IBM and Microsoft dissolved their development relationship. See infra 334 fn. 31. Return
22. A Windows 3.1 beta distribution list dated May 31, 1991, indicated 2155 sites would receive the first beta, including Lotus, WordPerfect, Ashton-Tate, Banyan Systems, Borland, Intuit, and just about every other major software developer imaginable. Exhibit 131. Microsoft competed against these developers in applications markets for word processing, spreadsheets, database management, and many others. Return
23. The "VxD" layer in Windows lies at the crossroads between DOS and Windows. See Exhibit 446 (drawing of relationship by Phil Barrett). It is essential that any DOS developer either have access to any changes made to the VxDs or an accurate specification detailing the changes. Return
24. Exhibit 140 contains all subsequent versions of the "beta blacklist" that Caldera identified in Microsoft's production. Return
25. For proper perspective, the Court should know that Microsoft at this exact juncture instructed its OEM field operatives to swipe a DR DOS 6.0 beta if the opportunity arose, so that it could be reviewed by developers of MS-DOS. On September 5, 1991, one of Brad Chase's subordinates wrote: "On my travel my OEM customers, I've managed to view DR DOS 6.0 on several occasions. During these visits, I have been able to lay my hands on the final beta release of the product together with the glossy outer packaging that they are going to use when the product is launched. . . . Would you like me to send the disks and package to you as a matter of urgency." Brad Chase replied: "Wow you bet. Please send these disks and all other information the fastest way possible." Exhibit 169. Within a week, the DR DOS 6 beta copies had been received, distributed to developers to compare to MS-DOS 5.0, and raked over the coals to come up with FUD points. Exhibit 178. Return
26. The letters in Exhibit 296 are noteworthy for another reason: all were well aware of Microsoft's uncooperative beta policy, and many were suspicious that the problems they were encountering were intentional incompatibilities. Return
27. Cole testified at length about approaches considered and rejected as to the "message." Cole Depo. at 132-142, 191-205. Exhibit 269 gathers executive debate on the "message" issue from January 17 through February 11, 1992, and indicates Gates and Ballmer were intimately involved. Return
28. Andy Hill, the person in charge of the Windows 3.1 beta program, was unaware of any such purported product-support initiative. Hill FTC Depo. at 64-65, 69. Return
29. As a sidelight, Brad Silverberg -- trapped in the vaporware inference to be drawn from this presentation -- attempted to distance himself from it. So vigorous were his denials that he even denied the handwriting on the first page of the exhibit was his. But clearly it was, based on a handwriting exemplar he gave moments later. Compare Exhibit 171, with Exhibit 172 (handwriting exemplar). See Silverberg Depo. at 115, 132-134. Return
30. See, e.g., Exhibit 127 ("Merged DOS/Windows Product); Exhibit 129 ("Slick Spec (Win 3.0 + DOS 5.0)"); Exhibit 138 ("OEMSlick Spec (Win 3.0 + DOS 5.0)"); Exhibit 174 ("Slick Plan (Win 3.1 + DOS 5)"). Return
31. This was not true, because unlike Windows 95, Windows NT is not simply a package of DOS and Windows, but rather is an entirely new operating system, designed originally as a network operating system to compete with Novell NetWare. See generally Hollaar Report at 20. Novell's NetWare was the preeminent network system, and had introduced a scaled-down version called NetWare Lite. Return
32. The "death spiral" is somewhat of a term of art at Microsoft. On October 18, 1991, Mike Maples enquired of several executives: "I would like to ask you to invest half a day with me following Comdex. What I would like to brainstorm is how to push Excel over the top and Lotus out of business." To which Silverberg replied: "I'd be glad to help tilt lotus into the death spiral. I could do it friday afternoon but not saturday." Exhibit 223. At a management conference in June 1992, one of the "6 Core Strategies to build share" included "Drive competitors into a death spiral," complete with objectives and tactics. Exhibit 312 at MS0124910. Ironically, other discussion there focused on "Our Image" and how to overcome the industry perception of "Microslop," "Microshaft," and "Microsleaze." Id. Return
33. Although originally slated for release in late Summer 1993, Novell briefly delayed release of Novell DOS 7 until December 1993, Exhibit 394, due primarily to Novell's decision to include Novell's peer-to-peer networking product, Personal NetWare, in the final version of Novell DOS 7. Personal NetWare was also released as a standalone product in January 1994. Tucker Depo. at 273; Corey Depo. at 231-232; Exhibit 380. Return
34. The term "Covered Product" generally included the binary code of MS-DOS 6.22, Windows 3.11, Windows for Workgroups 3.11, the "Chicago" project (i.e., Windows 95), and any predecessor or successor versions of any of them. Exhibits 2 and 3. Return