Stephen D. Susman
Charles R. Eskridge III
Thomas W. Paterson
James T. Southwick
SUSMAN GODFREY L.L.P
1000 Louisiana, Suite 5100
Houston, Texas 77002-5096
Telephone: (713) 651-9366
Ralph H. Palumbo
Matthew R. Harris
Lynn M. Engel
Lawrence C. Locker
SUMMIT LAW GROUP PLLC
1505 Westlake Avenue N., Suite 300
Seattle, Washington 98109-3050
Telephone: (206) 281-9881
Parker C. Folse III
Timothy K. Borchers
SUSMAN GODFREY L.L.P.
1201 Third Avenue, Suite 3090
Seattle, Washington 98101
Telephone: (206) 516-3880
Max D. Wheeler (A3439)
Stephen J. Hill (A1493)
Ryan E. Tibbitts (A4423)
SNOW, CHRISTENSEN & MARTINEAU
10 Exchange Place, 11th Floor
P.O. Box 45000
Salt Lake City, Utah 84145
Telephone: (801) 521-9000
IN THE UNITED STATES DISTRICT COURT
DISTRICT OF UTAH, CENTRAL DIVISION
CALDERA¹S CONSOLIDATED RESPONSE TO MICROSOFT¹S MOTIONS FOR PARTIAL SUMMARY JUDGMENT ON PLAINTIFF¹S CLAIMS OF "PREDISCLOSURE," "PERCEIVED INCOMPATIBILITIES," AND "INTENTIONAL INCOMPATIBILITIES"
Case No. 2:96CV 0645B
Judge Dee V. Benson
Magistrate Judge Ronald N. Boyce
TABLE OF CONTENTS
I. INTRODUCTION *
II. RESPONSE TO MICROSOFT¹S "STATEMENTS OF UNDISPUTED FACTS" *
A. Response To Microsoft¹s "Statement of Undisputed Facts" Regarding Plaintiff¹s "Predisclosure" Claim. *
B. Response to Microsoft¹s "Statement of Undisputed Facts" Regarding Plaintiff¹s Alleged Intentional Incompatibilities. *
C. Response to Microsoft¹s "Statement of Undisputed Facts" Regarding Plaintiff¹s "Perceived Incompatibilities" Claim. *
II. STATEMENT OF ADDITIONAL MATERIAL FACTS *
A. Introduction. *
B. 1988-1990: DR DOS Enters the Desktop Operating System Market. *
C. July 1991: Novell Announces the Merger With DRI. *
D. Fall 1991: Microsoft Plans to Make Windows 3.1 Incompatible With DR DOS. *
E. Microsoft Made Public Statements That Caused the Market to Expect DR DOS Would Not Be Compatible With Windows. *
F. Microsoft Selectively Excluded DR DOS From the Windows 3.1 Beta Program. *
G. Microsoft Ensured That Windows Would Be Incompatible With DR DOS. *
H. Microsoft Introduced Incompatibilities in Windows 3.1, Including the AARD Code, "Bambi," the XMS Check, and the Nested Task Flag Bug. *
I. Microsoft Intended That False Errors Would Cause OEMs and PC Users Not to Buy DR DOS. *
J. Microsoft¹s Campaign Succeeded In Scaring OEMs and Users Away From Buying DR DOS. *
a. Microsoft¹s response to the reports of errors: *
b. Statements from users and OEMs encountering incompatibilities created by Microsoft: *
c. Statements about press coverage of the problems: *
d. Statements asking if users can contact DRI: *
e. Statements recognizing that DR DOS was a better product and that it did not compete with Windows: *
K. Microsoft Publicly Denied the Truth About the Incompatibilities It Had Created. *
IV. SUMMARY JUDGMENT STANDARD *
V. ARGUMENT *
A. Microsoft¹s Anticompetitive Scheme to Eliminate Competition‹Which Included Beta Blacklisting, False Statements, Intentional Incompatibilities, and False Error Messages‹Violated Section 2 of the Sherman Act. *
1. Caldera¹s Claims Are Section 2 Claims and Should Be Evaluated Under That Standard. *
2. Microsoft¹s Predatory Scheme Plainly Violated Section 2. *
3. Microsoft¹s Predatory Scheme Caused Antitrust Injury. *
B. Microsoft Violated Section 2 When It Blacklisted DRI. *
1. Beta Blacklist. *
2. Microsoft Violated Section 2 When It Unlawfully Used Its Market Power in the Windows Market to Destroy Competition in the DOS Market. *
3. Microsoft¹s Blacklisting of DRI Was Both an Unlawful Refusal to Deal and Denial of Access to Essential Facilities. *
a. The Windows 3.1 Beta Program Constituted an Essential Facility. *
b. DRI Could Not Duplicate the Windows 3.1 Beta. *
c. The Denial of the Use of the Facility to a Competitor. *
d. The Feasibility of Providing the Facility. *
4. Microsoft¹s Justifications for Its¶ Conduct Are Pretextual. *
C. Intentional Incompatibilities. *
1. The Section 2 Standard Governs the Inquiry. *
2. Microsoft, In Any Event, Misstates the Intentional Incompatibility Standard. *
3. Microsoft¹s Predatory Conduct Gives Rise to Liability Under Either Standard. *
a. Bambi. *
b. Nested Task Flag. *
c. XMS Version Check. *
d. AARD Code. *
e. Windows 95. *
f. Other Incompatibilities. *
4. The Beta Process Is Not Immune From Antitrust Scrutiny. *
D. AARD Code False Error Messages. *
1. Microsoft Relies on the Wrong Standard for Evaluating Its False Error Message Code in the Windows 3.1 Beta. *
2. Even if the Disparagement Standard Did Apply, Microsoft¹s False Error Messages Give Rise to Section 2 Liability. *
a. The Error Messages Were False. *
b. The Beta Testers Were "Consumers" Who Reasonably Relied on the False Error Messages When Evaluating DR DOS¹ Compatibility With Windows. *
c. The False Error Messages Were Not Susceptible to Neutralization. *
3. There Is Substantial Evidence of Harm to Competition. *
4. The "Common Interest" Privilege Cannot Protect Microsoft From Liability for the False Error Messages. *
VI. CONCLUSION *
TABLE OF AUTHORITIES
Plaintiff Caldera, Inc. respectfully submits this Memorandum in Opposition to the following three motions:
Planning the Incompatibilities:
How shall we proceed on the issue of making sure Win 3.1 requires MS DOS. . . . Maybe there are several very sophisticated checks so that competitors get put on a treadmill . . . the less people know about exactly what gets done, the better.
September 30, 1991, e-mail from David Cole, MS-DOS/Windows Group Program Manager, to Brad Silverberg, Senior Microsoft Executive for MS-DOS and Windows, see Exhibit 206 to Consolidated Statement of Facts.
Explaining the Incompatibilities:
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 and buy MS-DOS. Or decide to not take the risk for the other machines he has to buy for in the office.
February 10, 1992, e-mail from Brad Silverberg to David Cole, see Exhibit 278 to Consolidated Statement of Facts.
Unmasking the Incompatibilities:
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.
July 23, 1993, e-mail from Andrew Schulman, independent software expert, to Microsoft, see Exhibit 369 to Consolidated Statement of Facts.
By the late 1980s, Microsoft¹s computer desktop operating system, MS-DOS, was a monopoly "gold mine," upon which Microsoft relied for the majority of its profits. Starting in 1988, DRI, and later Novell, threatened Microsoft¹s DOS monopoly by releasing successive versions of DR DOS, its competing operating system, that were both better and cheaper than MS-DOS. Microsoft responded by engaging in the pattern of predatory acts alleged in Caldera¹s First Amended Complaint.
A key component of Microsoft¹s anticompetitive scheme was to persuade the market that DR DOS was incompatible with Microsoft Windows. Windows was, by all accounts, the single most important application for any DOS to be capable of running during this time period‹and Microsoft knew it. Microsoft also knew that DR DOS was fully compatible with Windows 3.0. Microsoft undertook a plan to ensure that DR DOS would not be fully compatible with the next major release of Windows, Windows 3.1‹and that the market would know it‹by:
Each of these predatory acts contributed to creating fear, uncertainty and doubt that DR DOS could not run Windows 3.1 and future versions of Windows. And each act reinforced the other related acts. In combination, these acts materially contributed to eliminating DR DOS as a viable competitor in the desktop operating system market.
Microsoft attempts to "divide and conquer" Caldera¹s Section 2 claim by making separate motions for partial summary judgment directed at each related aspect of Microsoft¹s predatory conduct. Apparently, Microsoft hopes that if each bad act is viewed in isolation the nature of its scheme will not be obvious. In any event, the Tenth Circuit has rejected defendants¹ attempts to take a piecemeal approach in considering Section 2 claims:
Plaintiff¹s evidence should be viewed as a whole. Each of the Œsix things¹ viewed in isolation need not be supported by sufficient evidence to amount to a Section 2 violation. It is enough that taken together they are sufficient to prove the monopolization claim.
Aspen Skiing Co v. Aspen Highlands Skiing Corp., 738 F.2d 1509, 1522 n.18.
This Memorandum summarizes evidence‹much of it out of the mouths of Microsoft¹s senior executives‹that proves Microsoft engaged in a carefully planned and coordinated series of acts which were intended to, and did, exclude DR DOS as a competitor in the desktop operating system market. If Microsoft is correct, i.e., if Microsoft is entitled to summary judgment on Caldera¹s Section 2 claims, then that means the law permits a monopolist to exercise its market power in one market to foreclose competition in another by: secretly making its product incompatible with its competitor¹s complementary product; blaming the incompatibilities on its competitor; precluding the competitor from access to the product causing the incompatibility; and, hiding all of this conduct by doing things such as encrypting code and secretly disabling tools that would help in uncovering the predatory conduct. The Sherman Act does not, and never has, permitted this sort of anticompetitive conduct and Microsoft offers no good reason this Court should permit it.
Microsoft has unlawfully maintained its monopoly by use of exclusionary conduct that does not "further competition on the merits or does so in an unnecessarily restrictive way." Aspen Skiing Co. v. Aspen Highlands Skiing Corp. 472 U.S. 585, 605 n.32 (1985). Its summary judgment motions should be denied.
Caldera responds to Microsoft¹s numbered paragraphs as follows:
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.
Exhibits 277 & 278 to Consolidated Statement of Facts.
4. In response to paragraph 4, Caldera admits that Mr. Frankenberg and Dr. Hollaar testified that they would not have objected to a message identifying a lack of testing, but both Mr. Frankenberg and Dr. Hollaar objected to the error messages actually implemented by Microsoft as deceptive and misleading. See Deposition of Robert Frankenberg ("Frankenberg Dep.") at 320-21, Record Support, v.3 to Consolidated Statement of Facts; Hollaar Report at 13-14, Record Support, v.6 to Consolidated Statement of Facts.
5. In response to paragraph 5, Caldera admits that Microsoft tested pre-release versions of Windows 3.1 with various versions of MS-DOS. Caldera also admits that Microsoft did not devote development resources to fixing incompatibilities between Windows 3.1 and DR DOS. Rather, Microsoft devoted development resources to creating incompatibilities (and the perception of incompatibilities) between Windows 3.1 and DR DOS. See Statement of Additional Material Facts ¶¶ 41-49. Caldera further admits that Microsoft stated publicly that it did not test Windows 3.1 with DR DOS, but the statement, including the statement quoted by Microsoft ("We do no testing at all with DR DOS . . .") was plainly untrue. The statement was made in January 1992, yet in September 1991, during the Windows 3.1 beta cycle, Microsoft distributed a comprehensive DR DOS test plan, that included extensive testing with all versions of Windows. See Exhibit 184 to Consolidated Statement of Facts; see also Deposition of Brad Chase ("Chase Dep.") at 136-38, Record Support, v.1 to Consolidated Statement of Facts; Deposition of Thomas Lennon ("Lennon Dep.") at 198-203, Record Support, v.1 to Consolidated Statement of Facts (describing DR DOS testing efforts by Microsoft, including a "DR Hammerfest" intended to find DR DOS bugs, complete with prizes for those Microsoft programmers who found the most DR DOS bugs). Caldera admits that while Microsoft was blacklisting DRI from the Windows 3.1 beta program, Microsoft made public statements that it was DRI¹s responsibility to make any changes necessary to DR DOS to ensure compatibility with Windows 3.1. Yet, as described more fully below, Microsoft was creating incompatibilities between Windows and DR DOS, telling the industry that the incompatibilities were caused by DR DOS, and denying DRI access to the information necessary to fix the problems. See Statement of Additional Material Facts ¶¶ 42 & 48. See also FTC Deposition of Phillip Barrett ("Barrett FTC Dep.") at 101-02, Engel Decl., Ex. 14 (describing how the problem was with "Bambi," not DR DOS).
6. Caldera admits paragraph 6, except as follows: Windows 3.1 was not an "operating system," but required MS-DOS or DR DOS to run. See Consolidated Statement of Facts ¶ 210. Microsoft¹s description of its beta program and the purpose of the program is incomplete and inaccurate. Microsoft used the Windows 3.1 beta program not only for testing, but also for marketing purposes. See, e.g., Exhibit 24 to Microsoft¹s AARD Code Memo. at 11-12 (noting the marketing purposes underlying the beta program and reporting that only 37% of the beta sites reported problems). See also Consolidated Statement of Facts ¶ 228.
7. Caldera admits paragraph 7. See Consolidated Statement of Facts ¶ 212.
8. Caldera denies paragraph 8. The XMS version check, the Nested Task flag bug, "Bambi," and the AARD code (what Microsoft refers to as the "non-fatal error message") were all part of Microsoft¹s scheme to preclude competition in the DOS market. See, e.g., Bennett Report, Appendix F, Engel Decl., Ex. 9 (showing users encountering both the Nested Task error message ("Standard mode: Fault in MS-DOS Extender" error message) and the AARD code¹s non-fatal error message). Furthermore, these problems were created by Microsoft, not DRI. See Statement of Additional Material Facts ¶¶ 41-49, see also Caldera¹s Response to Undisputed Facts Regarding Intentional Incompatibilities, Section II.B., above.
9. Caldera admits paragraph 9, but notes the incompatibilities reported by the press were incompatibilities created by Microsoft, not DRI. See Statement of Additional Material Facts ¶¶ 41-49; see also Response to Undisputed Facts Regarding Intentional Incompatibilities, Section II.B., above.
10. Caldera admits paragraph 10, except as follows: End-users did not make up only a small subset of beta testers. As Microsoft¹s Exhibit 24 shows, of the 15,106 total beta sites, 5,607 of those sites were corporate sites‹which, of course, are end-users. See Exhibit 24 to Microsoft¹s AARD Code Memo. at 20. Another 255 sites were government sites (again, end-users of the product), and there were several other categories that appear to be end-users. Id. Thus, the single largest category of testers was end-users. See Consolidated Statement of Facts ¶ 228.
11. Caldera denies paragraph 11. As described in Exhibit 24 to Microsoft¹s AARD Code Memo., some sites returned beta applications without signed NDAs and some Windows Developer¹s conference attendees were merely handed copies of the Windows 3.1 beta at the conference without the "beta kit" containing documentation. Exhibit 24 to Microsoft¹s AARD Code Memo. at 7. Later in the beta cycle, beta testers were not required to sign NDAs, but rather were provided copies of NDAs they never had to execute. Id. Moreover, Microsoft selectively enforced the NDAs. Members of the trade press often signed the NDAs. See id. at 10. Microsoft allowed and encouraged disclosure by the trade, Engel Decl., Ex. 15, despite the NDAs, so long as the disclosure was favorable to Microsoft (as reports of Windows 3.1/DR DOS compatibility "problems" were). See Consolidated Statement of Facts ¶ 314.
12. Caldera admits paragraph 12, except as follows: The AARD code was developed by Aaron Reynolds, who had carefully researched and discovered specific differences between DR DOS and MS-DOS. See Statement of Additional Material Facts ¶¶ 44 n.4; see also Consolidated Statement of Facts ¶ 39. The AARD code was intended to detect DR DOS. See Exhibit 194 to Consolidated Statement of Facts (September 27, 1991, e-mail entitled "FYI: Windows message" and sent to Brad Silverberg and Brad Chase: "The check for dr dos better be perfect") see also Consolidated Statement of Facts ¶ 237.
13. Caldera denies paragraph 13. The AARD code was included for the express purpose of creating the impression that DR DOS was incompatible with Windows and to create enough fear and uncertainty to cause users to reject DR DOS. See Hollaar Report at 11-14, Record Support, v.6 to Consolidated Statement of Facts (explaining why Microsoft¹s excuse for the code is inconsistent with the code itself, how it was implemented and the error messages generated by it). Brad Silverberg, the Microsoft executive responsible for the code, summed up the purpose of the code as follows:
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.
Exhibits 277 & 278 to Consolidated Statement of Facts. Nor was there just one message, as Microsoft implies. The code was designed to trigger a false error message at five separate points. And the messages were not innocuous. They failed to explain that an error had not in fact occurred (see Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts (conceding no error had occurred)), they failed to identify that the messages were a product of secret, encrypted detection code, and they left the user with no knowledge about the true cause of the messages. See Hollaar Report at 13-14, Record Support, v.6 to Consolidated Statement of Facts; see also Consolidated Statement of Facts ¶ 231. Moreover, when users contacted Microsoft support they were not told any of these things‹instead they were told that switching to MS-DOS would solve the problem. See, e.g., Bennett Report, Appendix F at 45-46, Engel Decl., Ex. 9 (Microsoft Compuserve posting responding to users¹ concerns about the error messages: "You should be able to get rid of the message by using MS-DOS instead of DR-DOS"). The effect on DR DOS was devastating. See Barnett Report at 3-4 & 15, Record Support, v.6 to Consolidated Statement of Facts; see also Consolidated Statement of Facts ¶¶ 218-19, 230 & 235.
14. Caldera admits paragraph 14.
15. In response to paragraph 15, Caldera admits that Microsoft accurately quotes Mr. Frankenberg¹s testimony, but notes that Mr. Frankenberg testified further that a non-fatal error message would indicate an error has in fact occurred. See Frankenberg Dep. at 105, Record Support, v.3 to Consolidated Statement of Facts; see also Consolidated Statement of Facts ¶ 231.
16. In response to paragraph 16, Caldera admits that the AARD code did not modify DR DOS or prevent DR DOS from running. Caldera denies the remainder of paragraph 16. Microsoft suggests in this paragraph that generating false error messages is not an "incompatibility" for purposes of analyzing Microsoft¹s predatory conduct under the Sherman Act. Dr. Hollaar made no such concession. He specifically limited his answer to applying a narrow definition of incompatibility that required the error to interfere with the actual operation of the program rather than the creation of false error messages. He stated further that under another definition of incompatibility, the AARD code created an incompatibility. See Hollaar Dep. at 90-91, Engel Decl., Ex. 11. Moreover, there is no dispute that the message itself was false. The developer of the code that produced the false error messages conceded that there was in fact "no error." Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts.
17. Caldera admits paragraph 17, except as follows. Microsoft asserts that "very few communications with beta testers of Windows 3.1 occurred outside the CompuServe forum" without offering any support for this proposition. It is clear from the record that beta testers contacted Microsoft directly by telephone. See Exhibit 24 to Microsoft¹s AARD Code Memo. at 5-8. The volume of these communications is unknown, but it was sufficiently high to cause Microsoft to complain about it. Id. at 7.
18. Caldera admits paragraph 18, except as follows. It is not clear that all beta testers were covered by valid NDAs (see ¶ 11, above), nor is it clear that anyone routinely complied with NDAs. See Deposition of Steve Ballmer ("Ballmer Dep.") at 193, Record Support, v.1 to Consolidated Statement of Facts ("Well, the computer industry is not a very tight-lipped ship. If you tell‹a systems design preview is an event we would do for independent software vendors. 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"); see also Consolidated Statement of Facts ¶ 314.
19. Caldera denies paragraph 19. Every single DR DOS user that ran the Windows 3.1 Christmas beta saw the false error messages‹and they saw them every single time they attempted to run the beta. See Hollaar Decl. at ¶ 6. In addition, the record shows not only that users were concerned that the messages were the result of an incompatibility between DR DOS and Windows, but that Microsoft told users who encountered the messages that they should switch from DR DOS to MS-DOS. See Statement of Additional Material Facts ¶ 51; see also Consolidated Statement of Facts ¶¶ 218, 219, 230, 233 & 235; see also ¶ 20, below.
20. Caldera denies paragraph 20. It is surprising that Microsoft asserts that "Microsoft never posted a message in the CompuServe forum stating that the Œnon-fatal error¹ message was the result of incompatibilities between DR DOS and Windows 3.1." Maybe Microsoft intends only to assert that it did not use those exact words, because Microsoft plainly told users that the error messages were caused by DR DOS and switching to MS-DOS would solve the problem. In response to a Compuserve beta forum posting about "Non-fatal error detected: Error #2726" (i.e., the AARD code), Microsoft responded: "You should be able to get rid of the message by using MS-DOS instead of DR-DOS." See Bennett Report, Appendix F, at 45-46, Engel Decl., Ex. 9. Moreover, Microsoft never posted anything to clarify that the false error messages were not caused by any incompatibility between Windows 3.1 and DR DOS. See Consolidated Statement of Facts ¶¶ 230 & 235-36.
21. Caldera denies paragraph 21. Rather than improperly examining a Novell copy of the Windows 3.1 beta, near the end of the beta cycle DRI developers contacted Novell by telephone to confirm reports of errors it had received from customers. See ¶ 5 to Response to Undisputed Facts Regarding "Predisclosure" Claim, Section II.A., above. Meanwhile, Microsoft was busy directing one of its OEM representatives to steal a copy of a DR DOS 6 beta so that Microsoft could test it to come up with other FUD points. See ¶¶ 5 & 14 to Response to Undisputed Facts Regarding "Predisclosure" Claim, Section II.A., above.
22. Caldera denies paragraph 22. DRI was able to modify DR DOS to make it compatible with Windows 3.1 only after the commercial release of Windows 3.1. A version of DR DOS compatible with Windows 3.1 was not released until approximately one month after the commercial release of Windows 3.1. Constant Dep. at 29, Record Support, v.3 to Consolidated Statement of Facts. Moreover, Windows 3.1 is not an operating system. See ¶ 6, above; see also ¶¶ 4, 12 & 16 to Response to Undisputed Facts Regarding "Predisclosure" Claim, Section II.A., above.
23. In response to paragraph 23, Caldera admits that Microsoft, in response to concerns regarding the bad press it was receiving and expected to receive, disabled the false error messages so that they no longer appeared. Caldera denies that Microsoft decided not to include the false error messages in the commercial release of Windows 3.1 "because Microsoft was concerned about possible misperceptions of Microsoft¹s intentions." Microsoft disabled the error messages because the media and the industry were criticizing Microsoft for detecting DR DOS and including false error messages. Reynolds FTC Dep. at 76-77, Record Support, v.2 to Consolidated Statement of Facts.
24. In response to paragraph 24, Caldera admits that the false error messages did not appear when the commercial release of Windows 3.1 was run on top of DR DOS. Caldera denies that Microsoft disabled the code. Microsoft disabled the messages. The Windows 3.1 commercial release still ran the AARD code ran every time a user loaded Windows 3.1.
Deposition of Phillip Barrett ("Barrett Dep.") at 37-38, Engel Decl., Ex. 16.
PC User Magazine, July 4, 1990:
PC User Verdict: This is the first time I¹ve given any product an all "excellent" verdict, which speaks for itself.
PC Magazine, January 15, 1991:
DR DOS 5.0 does all the things you wish MS DOS did. It¹s features includeŠfull compatibility with MS DOS. . . . Everybody¹s DOS should be this advanced.
Exhibit 106 (emphasis added).
PC Magazine, February 12, 1991:
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.
Exhibit 109 (emphasis added).
DR DOS 5.0 runs every DOS app [application] I know. DR DOS 5.0 works successfully with Windows. . . . DR DOS 5.0 is vastly superior to MS/PC DOS 3.31 and 4.01.
DR DOS 5.0 is a "far superior product. . . ."
Exhibit 120 (Joachim Kempin, Microsoft¹s Director of Worldwide OEM Sales).
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.
Exhibit 110 (emphasis added).
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.
Given this, I suggest (at least for Systems) that we . . .
consider changing our apps to not run unless the OS [operating system] is our OS [MS-DOS].
Exhibit 280 (emphasis added).
. . . drdos has problems running windows today, and I assume will have more problems in the future.
You should make sure it has problems in the future.
Exhibit 197 (emphasis added).
PC User, September 25, 1991:
VERDICT: more of an operating system than MS DOS, with no obvious disadvantages.
PC Week, September 30, 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. Starting from a small base, DR DOS is clearly gaining market share.
Exhibit 200 (emphasis added).
. . . 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 . . . given that track record, it¹s going to be impossible to shake this "MS as follower" image. it¹s been difficult so far as it is.
therefore, maybe we should reorient our message slightly. instead of always insisting that we¹re the technology leaders, we should just reinforce our positioning of them Š
David Cole, MS-DOS/Windows Program Manager, worried:
DRI is getting perceived as the product innovator/leader because they look to be more active with new products. Users making a buying decision like the guy who appears to be in front doing the new stuff.
Any degree of incompatibility is enough to create fear, uncertainty & doubt among endusers when it comes time to buy new systems‹this suggests PC OEMs will take on a big risk if they ship DR-DOS with their systems.
Exhibit 126; see also Deposition of Sergio Pineda ("Pineda Dep.") at 37, Record Support, v.2 to Consolidated Statement of Facts; Barnett Report at 9 & 15, Record Support, v.6 to Consolidated Statement of Facts.
We need to create the reputation for problems and incompatibilities to undermine confidence in DR DOS 6; so people will make judgments against it without knowing the details or facts.
. . . dr dos and windows will get them complaints. . . . 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 (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).
DR DOS is not DOS, the standard that the industry has come to trust and rely on. . . . 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 (emphasis added).
There should be NO HELP for DRI. They are totally on their own. Do we know if DR has Win 3.1? They are NOT an official beta tester.
brad pls make sure we are not supporting DRI anywhere in the company with this stuff thx
Exhibit 158; see also Product Disparagement Response Statement of Additional Material Facts ¶¶ 19-20 & 22.
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. Yet selective exclusion is precisely what Microsoft did. See Product Disparagement Response Statement of Additional Material Facts ¶¶ 22-23.
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.
What is MS¹ official response to the charge that you folks have been deliberately shutting out DRI from the BETA program, and that you¹ve made 3.1 incompatible with DR DOS intentionally? I hear a lot of accusations to this effect, and some of them are down-right libelous. What¹s the word, Brad?
Exhibit 443. Silverberg responded:
Windows is an operating system. That¹s how we view it and certainly a sign of how it will evolve.
Id. (emphasis added); see also Exhibit 443 (Silverberg attempting to justify Microsoft¹s exclusion of DR DOS on the grounds that Windows and DR DOS are direct competitors, "Are the Redskins going to give their game plan in advance to the Bills?").
David Cole (MS DOS/Windows Group Program Manager):
Uhmm . . . denying DRI the VxD [virtual device driver] smells of an antitrust lawsuit. You¹re 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.
Exhibit 99 (emphasis added). The press similarly explained:
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 6.0, which challenges Microsoft¹s DOS monopoly.
Exhibit 254 (emphasis added); see also Product Disparagement Response Statement of Additional Material Facts ¶¶ 23-25.
Q: . . . and wouldn¹t inclusion . . . if it occurred . . . be a benefit to Windows?
A: It could be a benefit to Windows, but it would be a detriment to the overall Microsoft, and that¹s what they are looking at.
Q: It would be a detriment to Microsoft¹s sales of MS-DOS, right?
A: It could be, yes.
Deposition of Jerry Hausman ("Hausman Dep.") at 104-105, Engel Decl., Ex. 18.; see also Product Disparagement Response Statement of Additional Material Facts ¶¶ 26-27.
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.
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").
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.
"WILL BE VERY UNSURE OF COMPATIBILITY. WINDOWS IS CRITICAL."
"IBM MARKETING CONCERNS
Exhibit 268 at 5 & 8; see also Wightman Dep. at 312, Engel Decl., Ex. 4 (IBM concerned about DR DOS/Windows compatibility during negotiations). IBM ultimately decided not to license 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 [Aaron Reynolds] 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.
The OFFICIAL way to detect dr. dos is as follows.
1) set the carry flag
2) nt 2lh ax = 4452h
3) the carry will be clear if it is dr. dos, and set if it is pc-docs
Exhibit 201. Using this technique to detect DR DOS, Microsoft programmed the beta to display a fatal error message, "Invalid device interface. Unable to load," and then refuse to run. Users would not know that the message resulted from DR DOS detection code. Even putting aside the fact that Microsoft repeatedly misled the market by denying that it was engaging in this predatory conduct, there is absolutely no technical justification for the code. See Hollaar Decl. at ¶ 4; see also Barrett FTC Dep. at 100-10, Engel Decl., Ex. 14 (describing how original smartdrv problem was not caused by DR DOS and describing his beliefs that Cliff Garrett at Microsoft had contacted DRI using the false name Roger Sour).
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 boundary of rudeness. It is also fairly extreme compared to others in the product we have seen.
. . . .
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; see also Exhibit 238. Aaron Reynolds wrote and tested the DR DOS detection code, the "AARD Code." Reynolds Dep. at 30-31, Record Support, v.2 to Consolidated Statement of Facts.
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). The following month (November 1991), Microsoft made the decision to put the AARD code in the final beta of Windows 3.1. Exhibit 239.
Detection for the absence of MS-DOS will be in the Final Beta Release (AKA beta 3) . . . the message will say: Non-fatal error detected: error # (Please contact Windows 3.1 beta support).
Exhibit 248 (emphasis added). The fact that it was a nonfatal error was at least as disturbing if not more disturbing than a fatal error. See Hollaar Dep. at 133-34 & 147-48, Engel Decl., Ex. 11; Goodman Rebuttal Report at 12, Engel Decl., Ex. 21.
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.
I thought I¹d try RC 1 [Windows beta 3.1] on DR DOS 5.0 . . . 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?
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. . . .
Exhibit 443 (emphasis added).
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).
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); see also Exhibit 263 (Silverberg instructed the Windows 3.1 beta support group to post "a nice SOL [___ out of luck] message. bottom line is that he needs ms dos‹something that is compatible with windows").
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).
December 22, 1991:
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. . . . I¹m running DR DOS 6.0. . . . What can I do???
Last I heard DR DOS did not work with Windows 3.1. Since MS is not about to help DR clone DOS, they are not likely to help them (DR) solve their WIN 3.1 incompatibilities. It¹s all up to DR to fix their DOS problems.
. . . I wanted DR DOS for home because it provides a cheap method of doubling hard disk space + a lot of other utilities my home machine isn¹t budgeted for. Yet if Microsoft is going to make life difficult for DRI guess DR DOS isn¹t an option since I need to run the current betas.
Beta Site 1:
. . . . Has anybody got any confidence that DR will fix its WIN 3.1 problems?
Engel Decl., Ex. 22 (emphasis added).
We don¹t test against DR DOS. You should use MS DOS.
If you¹re using DR-DOS, I wouldn¹t expect it to work. Are you using
You should be able to get rid of the message by using MS-DOS instead of DR-DOS.
[Statement to a trade press reporter] Oh, 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¹s compatible with Win 3.1 or not. There is no code in Windows that says, "if DR-DOS then. . . ." We don¹t detect it.
[From a user:] Jeff, I talked with someone from Microsoft after I first reported the problem, and after the article in PC Week, and the claim is that there is a substantive problem with DR DOS, most probably in the memory handler.
Sorry, but Windows is designed and tested for MS-DOS. DRI claims 100% compatibility with msdos. if that were indeed true, then windows would just work.
Here¹s the straight story on this Marty. 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 any other system will result in unpredictable results. We are not working, nor do we plan to work with DRI on this issue.
[From a user:] The official line from MS about DR-DOS is that "Windows has not been tested with DR-DOS." That¹s probably about all you¹ll get out of them.
This is a realy big issue with us. DFM Systems ( the company I work for ) Manufactures a Touch Screen Notebook computer and planned on using Windows for Pen computing. We also "burn" DR DOS into a psudo drive in the BIOS. If Windows won¹t work with DR 6.0 it will be a big mess. I can get windows to come up, but so far it has mucho problems. With EMM386 ( it claims it ( windows ) can¹t load the driver, I can load the network drivers, and login, however, vpipx claims that the driver is not loaded, there are 2 or 3 error numbers that I have to <C>ontinue thru, and I haven¹t yet gotten SuperPCK to run, nor SuperStore. needless to say, performance is not pretty. I upgraded the machine I use day to day with DR 6 and had to resort to my floppy boot disk to continue with my daily work.
I¹m having mega problems getting this beta to install, and I run DR6.
I can¹t get past the second diskette when installing 3.1 beta release 2.
DRDOS 6 flatly refuses to run 3.1, in fact it even causes the new himem.sys to fail.
DRDOS 6 will *not* allow the beta to install. I¹ve left numerous msgs to Andy, none answered yet. Also called the tech line, no answers. Getting rather tired of no answers. Got confirmation from DRI that v6 won¹t work, and M-S and DRI aren¹t talking about it to each other, either.
Precisely why I use MS-DOS 5. Good luck.
Having total failure installing this beta with DR DOS v6. Lots of reports saying beta will not run with DRDOS at all. I can confirm it for you. What¹s the scoop now? Can MS send me a copy of MSDOS 5 as a lender for this testing? Send me a copy to replace DRDOS entirely??? I¹d be glad to give up DRI if they want to send me a copy of MSDOS5.
Build 60 runs great under DRv6 in enhanced mode, but croaks in standard mode.
My build 60 doesn¹t run with DRDOS 6 in any kind of mode. HIMEM.SYS even generates an instruction for me to call Micrososft.
It is true that 3.1 does NOT work with DR-DOS 6.0. I tried it on my ALR and 3.1 just refuses to install. (I had to uninstall DR-DOS to get back to MS-DOS 4.01.)
This confirms my finding that DrDOS v6.0 is NOT compatible with Windows version 3.1.
Thats right Windows 3.1 won¹t work at all (or at least in my trials) with DR-DOS v6.0. I stripped it down (DR-DOS that is), changed memory managers and anything else I could have thought of and nothing!
[In response to compatibility problems] I really must say that the good people of Microsoft have vastly reduced the confusion of which OS to upgrade to from 4.01!
Last I heard Dr DOS did not work with Windows 3.1. Since MS is not about to help DR clone DOS, they are not likely to help them (DR) solve their Win 3.1 incompatabilities. It¹s all up to DR to fix their DOS problems.
Also, I tried DR DOS on a couple of installations‹all had compatibility problems which I traced to DR DOS. We have installed MS-DOS 5 on these computers and the problems went away. We are recommending to our clients to stay away from DR DOS.
Cannot install under DR DOS, i tried both version 5 and 6, Boot under MSDOS 5 and install, still get the errors I mailed to you. I See in info from another Beta source, Smartdrv.exe will not load under DR DOS. Is there anything special I should do? I will try QEMM and 386MAX and try to get a config that will work.
[Microsoft responds:] DR-DOS has not been tested under Windows 3.1.
Has anyone else tried loading Build 61d under DR DOS 6.0? Setup gave several error messages and then Abended. Will try RC1 and advise. Uploaded MSD report and no response yet.
With NO mem mgrs installed at all, Setup for Build 61d & RC1 Abend with "Standard Mode: Fault in MS-DOS Extender" & a register dump.
I recently bought a copy of DR Dos 6.0 to try it out. After I had installed it I tried to load Windows 3.1 RC1. When I ran the setup program, it told me that the XMS manager that was loaded was not compatible with Windows. The DR Dos manuals say that it was compatible with Windows 3.0. Is there any type of update that will fix this problem so that Windows 3.1 will run under DR Dos 6.0? I would appreciate any help anyone could give me on this subject. Thanks.
Well, basically, the article stated that DRDOS 6 has trouble with Win 3.1 due to differences in memory management techniques, that Microsoft considers it DR¹s problem and isn¹t about to help, and that DR says they have been locked out of the Win beta process. I think that covers the highlights.
It¹s DR.DOS¹s problem is what I have read in the rag¹s I get.<g>
Is it permissable to ask Digital Research for assitance in problems with DRDOS6 and Win 3.1 (60) ?
My answer yesterday was a curt, but flat no don¹t you dare!!!!! Remember a thing called NDA???? I¹m strictly adhering to it, but wish MS would talk with DRI.
[Response from Microsoft] Jeff, Don¹t say anything about 3.1 to DRI.
Thanks for that info, Jeff. The irony is that DRDOS 6 has proven a far mmore stable Win 3.0 environment for me (better dos boxes than when under Dos5) and is, IMHO a far better product than even Dos5. I¹m surprised DR arent part of the beta program since they aren¹t exactly competitors in the GUI market but do have a fairly large customer base for their DRDOS products (many of whom will also be WIndows users). Perhaps MS don¹t like the way DR are in bed with IBM these days. All seems a bit silly to me. I¹m p****d off because there are things I simply can¹t do if I have to run Dos5 instead of DRDOS 6
I just prefer drdos for their enhancements to config.sys that let me switch among (at last count about 15) different setups by selecting from a menu.
DR DOS has worked fine. The problem with Stacker appears to be lack of integration with other utilities. With DR DOS, the disk cache and disk optimizer know all about compressed drives. You do not have to worry about accidentally running a utility that destroys your disk.
DR has since faltered by not agreeing to sign the Sears contract which included a guarantee to run future versions of Windows. With this misstep, Johnk, DebbyRea, and Don Hardwick were able to get Sears to sign up for MS-DOS 5.
Engel Decl., Ex. 23 (emphasis added).
[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 Dep. at 56, Record Support, v.3 to Consolidated Statement of Facts.
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); see also Exhibit 294 ("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 [Windows 3.1] FUD. . . .").
That¹s correct‹we have not made DRI a win 3.1 beta. . . .
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¹s compatible with Win 3.1 or not. There is no code in Windows that says, "if DR-DOS then . . .". We don¹t detect it.
Exhibit 443 (emphasis added).
Microsoft does not test Windows on anything other than Microsoft¹s MS-DOS. We don¹t have the development or testing resources, nor do we consider it our job to test Windows on other systems.
Engel Decl., Ex. 24 (InfoWorld, November 22, 1993).
I am wondering if we should change the detection words to say we failed to detect MS-DOS, rather than say we detected an operating system other than MS-DOS. The latter words would make people think we are looking for DR DOS . . . .
Id. (emphasis added).
I have stumbled across a really awful piece of code (with the initials) "AARD"! in four separate programs in Windows. . . . This AARD code is deliberately obfuscated, encrypted with XORs, attempts to disable a debugger. . . . But after much effort by myself and Geoff Chappell, we have found that the purpose of this code (in Windows!!) is to check for genuine MS-DOS by checking several otherwise-irrelevant things in the DOS data segment. In two beta versions of Windows, this code when run on DR DOS produced error messages. . . . Brad, I am extremely pissed at Microsoft. I have been trying to defend you guys against what I thought were stupid allegations, and now I find out that in fact the company has done something really bad. I have passed my findings on to the FTC.
It has never been the practice of this company to deliberately create incompatibilities between Microsoft system software and the system software of other OS (operating system) publishers. . . . The intended purpose of this disclosure message was to protect the customer and reduce the product support burden from the use of Windows on untested systems.
Exhibit 381 (Letter from Silverberg to Schulman in Dr. Dobb¹s Journal; emphasis added).
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 the other machines he has to buy for the office.
Exhibits 277 & 278.
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. . . .
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 (emphasis added).
Summary judgment is inappropriate unless the record shows there are no issues of material fact and the moving party is entitled to judgment as a matter of law. Fed. R. Civ. P. 56(c). In the context of antitrust cases, courts are reluctant to grant summary judgment on the issue of whether a particular type of conduct is anticompetitive. See, e.g., Ratino v. Medical Service, 718 F.2d 1260, 1268 n.23 (4th Cir. 1983) ("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.").
The antitrust laws permit‹indeed, encourage‹rivals to compete vigorously by producing better, cheaper, and more attractive products. Because of Microsoft¹s dominance, however, its actions must be "examined through a special lens: behavior that might otherwise not be of concern to the antitrust laws‹or that might even be viewed as pro-competitive‹can take on exclusionary connotations when practiced by a monopolist." Eastman Kodak Co. v. Image Technical Services, Inc., 504 U.S. 451, 488 (1992) (Scalia, J., dissenting) (citing 3 P. Areeda & D. Turner, Antitrust Law, ¶ 813 at 300-302 (1978)). When a monopolist such as Microsoft uses its power to "foreclose competition, to gain a competitive advantage, or to destroy a competitor," it violates the law. Eastman Kodak, 504 U.S. at 482-483 (quoting United States v. Griffith, 334 U.S. 100, 107 (1948)). Indeed, "[t]he anti-trust laws are as much violated by the prevention of competition as by its destruction." Lorain Journal Co. v. United States, 342 U.S. 143, 154 n.7 (1951) (emphasis added) (quoting Griffith, 334 U.S. at 107). Here, Microsoft did both.
To prove unlawful monopolization in violation of Section 2 of the Sherman Act, Caldera need only establish: (1) monopoly power, and (2) the acquisition or maintenance of that power through exclusionary conduct. See TV Communications Network, Inc. v. Turner Network Television, Inc., 964 F.2d 1022, 1025 (10th Cir.), cert. denied, 506 U.S. 999 (1992); see also Aspen Skiing Co. v. Aspen Highlands Skiing Co., 472 U.S. 585, 596 n.19 (1985); United States v. Grinnell Corp., 384 U.S. 563, 570-71 (1966).
Monopoly power is "the power to control prices or exclude competition," Grinnell, 384 U.S. at 571 (quoting United States v. E. I. du Pont de Nemours & Co., 351 U.S. 377, 391 (1956)), and "ordinarily may be inferred from the predominant share of the market" controlled by the alleged monopolist. Id. Market shares in excess of 60 to 70 percent are generally adequate to establish market power. See, e.g., Reazin v. Blue Cross & Blue Shield of Kansas, Inc., 899 F.2d 951, 967-70 (10th Cir.) (market share of approximately 60% supported jury verdict of monopolization), cert. denied, 497 U.S. 1005 (1990); see also Eastman Kodak, 504 U.S. at 481-82 (citing cases); 3A P. Areeda & H. Hovenkamp, Antitrust Law, ¶ 801a at 301 (1996) (reasonable to presume substantial market power when defendant¹s share of relevant market exceeds 70-75% for the five years preceding the complaint). Caldera has presented evidence that Microsoft exercised monopoly power in both of the relevant markets: the DOS market and the graphical user interface ("GUI") market. See Consolidated Statement of Facts 2 n.2 & ¶ 110. Microsoft nowhere denies this fact. Instead, Microsoft insists that its conduct was not exclusionary.
Exclusionary conduct is conduct that attempts to "¹exclude rivals on some basis other than efficiency¹. . . ." Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. 585, 605. Prohibited exclusionary conduct is conduct that impairs the opportunities of rivals to compete and does not "further competition on the merits or does so in an unnecessarily restrictive way." Id. at 605 n.32 (citation omitted); see also Multistate Legal Studies, Inc. v. Harcourt Brace Jovanovich Legal & Professional Publications, Inc., 63 F.3d 1540, 1550 (10th Cir. 1995), cert. denied, 516 U.S. 1044 (1996); Data General Corp. v. Grumman Systems Support Corp., 36 F.3d 1147, 1182 (1st Cir. 1994). In Aspen, the Supreme Court instructed that courts consider the impact of conduct on consumers, competitors, and the monopolist itself, as well as whether the conduct "impaired competition in an unnecessarily restrictive way." 472 U.S. n.32 (emphasis added). The monopolist¹s purpose for taking the challenged actions is helpful in determining whether the conduct is exclusionary. Id. at 602. As the Tenth Circuit has explained: "Predatory practices are illegal if they impair opportunities of rivals or are more restrictive than reasonably necessary for such competition." Instructional Systems Development Corp. v. Aetna Cas. & Surety Co., 817 F.2d 639, 649 (10th Cir. 1987) (emphasis added). The actions of a monopolist bear heightened scrutiny. Intergraph Corp. v. Intel Corp., 3 F. Supp. 2d 1255 (N.D. Ala. 1998); see also cases cited in Product Disparagement Response, Section III.B.
Microsoft attempts to avoid this standard by asking this Court to evaluate certain acts in a vacuum. For example, Microsoft seeks to have this Court consider the incompatibilities Microsoft intentionally created between DR DOS and Windows 3.1 without taking into account the fact that Microsoft blacklisted DRI from the Windows 3.1 beta program, thereby guaranteeing that DRI could not determine the cause of the incompatibilities and remedy them in a timely manner. The Tenth Circuit has specifically rejected this piecemeal approach to Section 2 claims:
Plaintiff¹s evidence should be viewed as a whole. Each of the Œsix things¹ viewed in isolation need not be supported by sufficient evidence to amount to a Section 2 violation. It is enough that taken together they are sufficient to prove the monopolization claim.
Aspen Highlands Skiing Corp. v. Aspen Skiing Co., 738 F.2d 1509, 1522 n.18 (10th Cir. 1984), aff¹d, 472 U.S. 585 (1985); see also cases cited in Caldera Inc.¹s Motion to Strike Microsoft¹s Partial Summary Judgment Briefs Relating to Substantive Antitrust Violations.
The question before the Court is thus a straightforward Section 2 inquiry that asks whether, taking account of the heightened standard applied to monopolists, Microsoft¹s conduct was exclusionary. This is not a close question. Microsoft¹s conduct in executing a plan to create "fear, uncertainty and doubt" ("FUD") as a means of driving DR DOS out of the market was anything but competition on the merits. Consider what the evidence shows:
Microsoft does not, of course, agree with all of these statements, but that is beside the point. At the very least these are disputed issues of material fact. And it is clear that none of this conduct can be justified as competition on the merits‹it is difficult to imagine how any of this could be could be characterized as anything other than an attempt to "¹exclude rivals on some basis other than efficiency¹. . . ." Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. at 605 (1985).
Antitrust injury is an element in a private antitrust damages action under Section 4 of the Clayton Act. Reazin, 899 F.2d at 960 (citations omitted). The Tenth Circuit has stated that a plaintiff seeking damages under the antitrust laws must show injury in fact, i.e., "a causal connection between the defendant's actions violative of the Sherman Act and the actual injury to the plaintiff's business." Instructional Systems, 817 F.2d at 650 (quoting King & King Enterprises v. Champlin Petroleum Co., 657 F.2d 1147, 1156 (10th Cir. 1981), cert. denied, 102 S. Ct. 1038 (1982)); see also Reazin, 899 F.2d at 962 n.15.
The standard is not difficult to satisfy. Under Tenth Circuit law, "a plaintiff¹s burden to show injury in fact Œis satisfied by its proof of some damage flowing from the unlawful conspiracy,¹ which may be established by reasonable inferences drawn from circumstantial evidence." Instructional Systems, 817 F.2d at 650 (quoting World of Sleep, Inc. v. La-Z-Boy Chair Co., 756 F.2d 1467,1478 (10th Cir.), cert. denied, 106 S. Ct. 77 (1985)). For instance, in Reazin, where Blue Cross had announced termination of plaintiff as a contracting provider hospital, it was sufficient that plaintiff had lost patients; reduced its price to retain market share; and spent money on advertisements to reassure patients that Blue Cross subscribers were still welcome. 899 F.2d at 962; see also Aspen Highlands, 738 F.2d at 1522-25 (antitrust injury shown where defendant's refusal to offer its three mountains in skiing package with plaintiff¹s mountain resulted in diminished revenue to plaintiff).
Moreover, Section 2 prohibits not only the acquisition of monopoly but its maintenance as well. Lorain Journal, 342 U.S. at 154 n.7. When a company maintains its monopoly position, by definition it prevents competition from occurring. There may be no visible change in prices or quantities, because the monopoly has been preserved, but the harm to competition exists nonetheless: prices are higher and output lower than would have been the case without the exclusionary conduct. For this reason, "[i]njury to competition is presumed to follow from the conduct proscribed by § 2." Walker v. U-Haul Co. of Mississippi, 747 F.2d 1011, 1013 (5th Cir. 1984) ("Section 2 of the Sherman Act . . . does not explicitly require a plaintiff to prove an injury to competition; the plaintiff must prove only the existence of monopoly power and the willful continued maintenance of that power."). Again, intent can be relevant to this inquiry: "Intent determines whether the challenged conduct is fairly characterized as exclusionary or anti-competitive." City of Chanute v. Williams Natural Gas Co., 955 F.2d 641, 654 (10th Cir. 1992) (citing Aspen Skiing Co., 472 U.S. 585).
Here, the evidence establishes a causal connection between Microsoft¹s predatory acts and injury to DR DOS¹ business. Microsoft¹s anticompetitive tactics, including its efforts during the Windows 3.1 beta program caused potential customers to select MS-DOS, rather than DR DOS, because they believed DR DOS would not run Windows. See, e.g., Barnett Report, Record Support, v.6 to Consolidated Statement of Facts. There is a clear link between the harm suffered and Microsoft¹s predatory acts. See id.; see also Statement of Additional Material Facts ¶ 65. DRI lost business as a direct result of these acts. For example, a potential corporate account told DRI that it was rejecting DR DOS 6.0 because of Microsoft¹s exclusionary refusal to allow DRI to beta test Windows 3.1. See id. ¶ 35. IBM, expressing concerns about DR DOS/Windows compatibility during the height of Microsoft¹s campaign to induce fear about DR DOS/Windows compatibility decided against licensing DR DOS. See id. ¶ 37. And even though Zenith Data Systems determined that the non-fatal error messages "in fact didn¹t reflect any operational problems or incompatibilities," it nevertheless abandoned consideration of DR DOS 6.0 because it feared Microsoft would "intentionally put code in Windows that would cause problems with DR DOS." See id. ¶ 60. DRI also lost Sears¹ business when Sears demanded a guarantee of compatibility with future versions of Windows. See id. ¶ 64. As Microsoft itself recognized, its tactics had the damaging effect desired. See Exhibit 256 ("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."); see also Exhibit 294 ("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 [Windows 3.1] FUD. . . ").
By eliminating DR DOS, Microsoft eliminated the only real competition it faced in the DOS market. Microsoft¹s market share in the DOS market averaged more than 90% between 1989 and 1992, and increased further after that time. Leitzinger Report at 12, Record Support, v.7 to Consolidated Statement of Facts; see also Engel Decl., Exhibit 9. With the demise of DR DOS, Microsoft¹s market share increased. Not surprisingly, the standard measure of market concentration, the HHI index, rose sharply after DR DOS effectively exited the market. Leitzinger Report at 44, Record Support, v.7 to Consolidated Statement of Facts.
At the same time, Microsoft eliminated any real price competition when it eliminated DR DOS. Competition from DR DOS had forced Microsoft to lower its MS-DOS prices by as much as 30-40%. Bill Gates recognized as much, and complained to others at Microsoft about it. See Exhibit 27 ("The DOS gold mine is shrinking and our costs are soaring . . . I believe people underestimate the impact DR DOS has had on us in terms of pricing."); see also Additional Statement of Material Facts ¶ 5, Kearl Report, appendices 1-4, Record Support, v.6 to Consolidated Statement of Facts. Thus, MS-DOS prices dropped when DR DOS entered the market, and rose after DR DOS was effectively eliminated as a competitor. Kearl Report at 26, Record Support, v.6 to Consolidated Statement of Facts.
Without DR DOS as a competitor, Microsoft also lost competitive pressure to innovate with respect to MS-DOS. Microsoft itself concedes that before DR DOS entered the market, Microsoft had allowed MS-DOS to stagnate. See Exhibit 38 ("[O]ver the last four years we have done very little with it [MS-DOS] technically . . ."). Hardware had outrun PC operating system capabilities, and Microsoft had failed to respond. See Goodman Report, Exhibit C, Record Support, v.6 to Consolidated Statement of Facts. While DR DOS was in the market, Microsoft was forced to innovate, adding features to match those of DR DOS. Id.; see also Exhibit 195 ("One of the most important stimulants for adding features [to MS-DOS 5.0] was competitive pressure from DR DOS 5.0 . . ."). In contrast, after Novell stopped active development of DR DOS in September of 1994, Microsoft stopped development of MS-DOS. With the exception of a minor update of MS-DOS from version 6.20 to 6.22, Microsoft has not released any new standalone versions of DOS since September of 1994. The harm to competition could not be more evident.
The remainder of this memorandum addresses more specifically the arguments raised by Microsoft, the standards Microsoft seeks to have applied and the evidence that undermines Microsoft¹s position. Under the Section 2 standard set forth above, none of this analysis is necessary or especially relevant‹it is plain that, at a minimum, Caldera has raised material issues of fact regarding whether Microsoft¹s predatory conduct violated Section 2, and that is all that is required.
Microsoft¹s beta blacklist crossed the line between lawful, vigorous competition and exclusion. Conduct of this type is predatory when it preserves a monopolist¹s market dominance: "[A] monopolist¹s unilateral refusal to deal with its competitors (as long as the refusal harms the competitive process) may constitute prima facie evidence of exclusionary conduct in the context of a Section 2 claim." Data General v. Grumman Systems Support Corp., 36 F.3d 1147, 1183 (1st Cir. 1994) (citing Eastman Kodak, 504 U.S. at 483 n.32).
Although even a monopolist has a right not to deal with its competitors, this right is qualified. Aspen, 472 U.S. at 600-01. The Supreme Court established the rule regarding one company¹s obligation to do business with another in United States v. Colgate: "In the absence of any purpose to create or maintain a monopoly, [Section 1 of] the act does not restrict the long recognized right of a trader or manufacturer engaged in an entirely private business, freely to exercise his own independent discretion as to parties with whom he will deal." United States v. Colgate & Co., 250 U.S. 300, 307 (1919) (emphasis added). But where the refusal to deal serves to monopolize, it is prohibited by Section 2. Eastman Kodak, 504 U.S. at 483 n.32; Aspen, 472 U.S. at 601-03; Lorain Journal, 342 U.S. at 155. Thus, Colgate does not protect a monopolist that "[r]etaliates against customers who have the temerity to compete with him, by cutting such customers off . . . in order to discourage competition." Olympia Equipment Leasing Co. v. Western Union Telegraph Co., 797 F.2d 370, 377 (7th Cir. 1986), cert. denied, 480 U.S. 934 (1987).
Microsoft¹s exclusion of DRI from the Windows 3.1 beta program was part of an overall plan to cause the market to believe DR DOS was incompatible with Windows, and thereby eliminate DR DOS as a competitive threat. The purpose and effect of Microsoft¹s plan was to maintain its DOS monopoly. As such, excluding DRI from the beta program violated Section 2.
A monopolist is not permitted to use its market power in one market to gain competitive advantage in another market. Berkey Photo, Inc. v. Eastman Kodak, Co., 603 F.2d 263, 276 (2nd Cir. 1979), cert. denied, 444 U.S. 1093 (1980) (use of monopoly power attained in one market to gain a competitive advantage in another is a violation of §2, even if there has not been an attempt to monopolize the second market); Eastman Kodak, 504 U.S. at 479 n.29 ("The Court has held many times that power gained through some natural and legal advantage such as a patent, copyright, or business acumen can give rise to liability if a seller exploits his dominant position in one market to expand his empire into the next"). The requirements for liability include: "[m]onopoly power in one market; the use of that power, however lawfully acquired, to foreclose competition, to gain a competitive advantage or to destroy a competitor in another market; and injury caused by the challenged conduct." Grand Light & Supply Co. v. Honeywell, Inc., 771 F.2d 672, 681 (2d Cir. 1985); see also Kerasotes Mich. Theatres v. National Amusements, Inc., 854 F.2d 135, 136-37 (6th Cir.), reh¹g denied, (1988), cert. dismissed, 490 U.S. 1087 (1989).
Microsoft had to market its power in Windows because, as the monopolist in the GUI market, it controlled basic product information indispensable to the business of almost every OEM and software developer. By cutting off DRI‹and publicly broadcasting this fact‹Microsoft knew that OEMs would fear the stability of Windows running on top of DR DOS, thereby causing them to license MS-DOS, instead of DR DOS. See, e.g., Statement of Additional Material Facts ¶ 37; Exhibit 256; Exhibit 294. Microsoft also knew that blacklisting DRI would ensure that it could introduce incompatibilities between Windows and DR DOS while preventing DR DOS from identifying the source of the incompatibilities, much less fixing them.
Placing the DR DOS development team on the beta blacklist was a raw exercise of monopoly power designed to force DR DOS out of the DOS market. Even Microsoft management knew this retaliation against DR DOS was illegal. See Statement of Material Facts ¶ 32.
As explained in Aspen Highlands, sacrifice of short-term benefits is evidence of anticompetitive purpose and nature. When the defendant there refused to accept coupons or permit a competitor to purchase tickets in bulk for inclusion in a package deal, thereby foregoing profits, the Court held that it was reasonable to conclude that the defendant "elected to forgo these short-run benefits because it was more interested in reducing competition in the Aspen market over the long run by harming its smaller competitor." 472 U.S. at 608. Here, Microsoft likewise was motivated by the long-term preservation of its monopoly and was therefore willing to sacrifice, in the near term, its relationship with both current and potential customers. This is a hallmark of monopolization: by excluding DR DOS, Microsoft gave up the benefits it obtained from the cooperative relationship it had previously enjoyed with DRI. Microsoft¹s goal was to have "Windows everywhere." That meant allowing Windows to run on DR DOS as well as MS-DOS. When Windows was not yet a monopoly product‹i.e., prior to the success of Windows 3.0‹Microsoft permitted DR DOS to participate in the Windows 3.0 beta program, and hence, to allow Windows 3.0 to run on DR DOS. Post-monopolization, Microsoft deliberately chose to forego Windows¹ ability to run on DR DOS‹and so forced any OEM seeking to install Windows to choose MS-DOS. At the same time, Microsoft sacrificed sales of Windows 3.1 to PC owners who used DR DOS as their operating system, and it sacrificed the benefits that would accrue to Windows if DRI was able to develop DR DOS features that would enhance the performance of Windows.
The case for liability is even stronger where, as here, a monopolist¹s refusal to deal denies a potential competitor access to an essential facility. The Tenth Circuit has addressed the "essential facilities" doctrine in several Section 2 cases involving refusals to deal. See, e.g., Tarabishi v. McAlester Regional Hosp., 951 F.2d 1558, 1568 (10th Cir. 1991), cert. denied, 505 U.S. 1206 (1992); City of Chanute, 955 F.2d at 647-49; McKenzie v. Mercy Hospital of Independence, Kansas, 854 F.2d 365, 368-70; and Aspen Highlands, 738 F.2d at 1520-22. The doctrine arose where "bottlenecks" were being abused to leverage monopoly power. See United States v. St. Louis Terminal Railroad Assoc., 32 S. Ct. 507 (1912) (association that controlled access to rail bridges spanning the Mississippi at St. Louis required to allow competing railroads use of facilities without regard to membership in association). A refusal to deal "may be unlawful because a monopolist¹s control of an essential facility (sometimes called a Œbottleneck¹) can extend monopoly power from one stage of production to another, and from one market into another." MCI Communications Co. v. AT&T, 708 F.2d 1081, 1132 (7th Cir. 1983), cert. denied, 464 U.S. 891 (1983).
Firms controlling an essential facility have an obligation to make the facility available on non-discriminatory terms. MCI Communications Co., 708 F.2d at 1132; Otter Tail Power Co. v. United States, 410 U.S. 366 (1973); Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. 585 (1985) (access to essential facility must be granted by ski lift owner controlling seventy-five percent of the ski lifts); Tic-X-Press, Inc. v. Omni Promotions Co. of Ga., 815 F.2d 1407 (11th Cir. 1987) (Omni arena was unique facility with substantial economic advantages; lack of viable alternative arenas gave the owner substantial market power).
The Tenth Circuit applies the following elements in evaluating an essential facilities claim:
(1) A monopolist is in control of a service or facility that is essential to competition in the relevant market;
(2) the competitor cannot duplicate, practically or reasonably, access to the service or facility;
(3) the monopolist has denied the competitor use of the service or facility; and
(4) it is feasible for the monopolist to provide access.
City of Chanute, 955 F.2d at 647.
In Aspen Highlands the Tenth Circuit explicitly approved and applied the doctrine. There, plaintiff controlled access to one mountain at Aspen and defendant controlled the other three. Suit arose when defendant refused to continue offering with plaintiff multi-day, multi-mountain packages for all four mountains as in past years. The court noted that defendant's refusal led to plaintiff's inability to compete in the market for multi-day, multi-mountain tickets. Yet by controlling three mountains, defendant could continue to offer such a ticket. The court found this "sufficiently analogous to satisfy the element of control of an essential facility." 738 F.2d at 1520-21.
More recently, the doctrine has been applied in the high-technology industry. See Intergraph Corp. v. Intel Corp., 3 F. Supp. 2d 1255 (N.D. Ala. 1997). Intel dominates the CPU (microprocessor) market. Intergraph is an OEM, dependent upon advance knowledge of forthcoming Intel chip-design advances. Without timely receipt of Intel¹s plans, Intergraph cannot make competitive computers immediately available. Intel¹s practice had been to provide Intergraph the advance specifications it needed, and in fact, Intel reviewed Intergraph designs to help "debug" Intergraph¹s products. When Intergraph attempted to assert certain patent protections of its own work, Intel precluded Intergraph from receiving future chip-design plans. The court entered a preliminary injunction against Intel:
Intel¹s refusal to supply advanced CPUs and essential technical information to Intergraph likely violates § 2 of the Sherman Act, because they are not available from alternative sources and cannot be feasibly duplicated, and because competitors cannot effectively compete in the relevant markets without access to them. Moreover, the court concludes that Intel has no legitimate business reason to refuse to deal with Intergraph. Intergraph has been a loyal and beneficial customer of Intel. The dispute over Intergraph¹s patent claims could be resolved separately without Intel denying Intergraph the essential CPUs and technical information it needs.
Id. at 1278.
Microsoft has not challenged that it exercises monopoly power in the relevant market. The threshold question, then, is whether access to the Windows 3.1 beta constitutes an essential facility.
The Intel court explicitly held that "[r]easonable and timely access to critical business information that is necessary to compete is an essential facility." Intel, 3 F. Supp. 2d at 1278 (citing Bellsouth Adver. & Publ¹g Corp. v. Donnelly Info. Publ¹g Inc., 719 F. Supp. 1551, 1566 (S.D. Fla. 1988), aff'd, 933 F.2d 952 (11th Cir. 1991). Similarly, access to advancing Windows technology was fundamental to DRI¹s attempt to carve out a niche of the DOS market; indeed, over time, nothing was more important. As far as GUIs were concerned, Windows was "the only game in town." Twin Labs, Inc. v. Weider Health & Fitness, 900 F.2d 566, 569 (2nd Cir. 1990). Microsoft has intellectual property protections for that software which create significant barriers to entry.
But DRI had been able to develop successive versions of DR DOS that did not infringe on Microsoft¹s intellectual property rights in MS-DOS, and, at the same time, were compatible with all popular DOS applications, including Windows. As Windows became widely-used, the ability to run Windows became an essential feature of DOS. Microsoft¹s own witnesses admitted that timely access to Windows product information was critical to the success of software products that ran in conjunction with Windows. See Consolidated Statement of Facts ¶ 199. Indeed, Microsoft¹s behavior is tacit admission that Windows was vital to DRI¹s ability to create competitive DOS-based operating systems and Microsoft knew that denying DRI access to such software would give Microsoft a competitive advantage in the DOS operating system market.
The plaintiff need merely demonstrate that it is practically or reasonably unable to duplicate the essential facility. See Cyber Promotions, Inc. v. America Online, Inc., 948 F. Supp. 456, 464 (E.D. Pa. 1996). Given the legal obstacles and Microsoft¹s market power, it is undisputed that it would have taken a substantial period of time for either DRI or Novell to develop a competitive GUI. Until July 1991, DRI did not know that it would be excluded from the Windows 3.1 beta program; indeed, Microsoft had included DRI in the Windows 3.0 beta program. See Consolidated Statement of Facts ¶¶ 205-09. Even if DRI had started a Windows-competitor project in July 1991‹and it was in no position to do so‹it would have taken years to complete. It would not and could not have duplicated the Windows 3.1 beta program, which would have been long since completed.
In addition, Microsoft¹s argument on that score misreads the law, and would force DRI and Novell‹which competed with Microsoft in only one market‹to enter an entirely new market. It would be akin to forcing a hypothetical railroad company competing with the defendant of United States v. Terminal R.R. Ass¹n, 224 U.S. 383 (1912), to enter the bridge-building market to remain competitive in the railroad market. The essential facilities doctrine in essence forces a monopolist to allow non-discriminatory access to its monopoly product; it does not require a competitor in another market to attempt to displace the monopoly product.
Microsoft does not dispute that it denied DRI access to the Windows beta program. The record is replete with evidence of Microsoft¹s attempts to ensure that the Windows beta releases were not disclosed to DRI. See Consolidated Statement of Facts ¶¶ 199-209; Statement of Additional Material Facts ¶ 63.
Microsoft easily could have provided Windows betas to DRI‹ in the same manner as beta programs, including the Windows 3.0 beta, had been distributed to DRI in the past, and as both subsequent beta programs and APIs were distributed to virtually every other legitimate software manufacturer who did not produce a competing DOS-based operating system. See Consolidated Statement of Facts ¶¶ 200-09. Indeed, a monopolist¹s duty to cooperate with a rival is stronger when the monopolist has a history of cooperating with the rival and did not have a valid business justification for its decision to terminate cooperation. Such reversal of cooperation is subject to heightened judicial scrutiny. See also Intel at 3 F. Supp. 2d 1255.
Business justifications are illegitimate when inconsistent with the facts of the case. See Aspen Highlands, 472 U.S. at 608-11. In Aspen Highlands, the Supreme Court rejected the business justifications offered by Aspen Ski Co., the defendant ski operator, for its decision to terminate an all-mountain lift ticket that it jointly offered with Aspen Highlands Skiing Corp., the plaintiff, because such justifications were not supported by the evidence presented:
In defending the decision to terminate the jointly offered ticket, Ski Co. claimed that usage could not be properly monitored. The evidence, however, established that Ski Co. itself monitored the use of the 3-area passes based on a count taken by lift operators, and distributed the revenues among its mountains on that basis. Ski Co. contended that coupons were administratively burdensome, and that the survey takers had been disruptive and their work inaccurate. Coupons, however, were no more burdensome than the credit cards accepted at Ski Co. ticket windows. . . . Ski Co.¹s explanation for the rejection of Highlands¹ offer to hire ‹ at its own expense ‹ a reputable national accounting firm to audit usage of the 4-area tickets at Highlands¹ mountain, was that there was no way to "control" the audit.
In the end, Ski Co. was pressed to justify its pattern of conduct on a desire to disassociate itself from‹what it considered‹the inferior skiing services offered at Highlands. The all-Aspen ticket based on usage, however, allowed consumers to make their own choice on these matters of quality.
Id. at 608-10 (emphasis added) (citations and footnote omitted); see also Image Technical Services, 125 F.3d at 1218 ("Neither the aims of intellectual property law, nor the anti-trust laws justify allowing a monopolist to rely upon a pre-textual business justification to mask anti-competitive conduct.").
Microsoft¹s actions are likewise inconsistent with any legitimate business purpose. It is illogical for Microsoft to deny DRI¹s (and later Novell¹s) DR DOS development team access to the Windows beta programs and APIs because they were "proprietary secrets," yet provide the software to hundreds of other legitimate software manufacturers, including other Novell software developers. See Consolidated Statement of Facts ¶ 200; see also Exhibit 20 to Microsoft¹s AARD Code Memo. (identifying cites by category). Each of these manufacturers had the ability to study and potentially to replicate Microsoft¹s software codes. Indeed, if Microsoft was concerned about Novell developing a GUI product competitive to Windows, as it claims in its summary judgment motion‹why did Microsoft allow Novell¹s developers, other than those working on DR DOS, access to the Windows 3.1 beta?
Although Microsoft may wish it were otherwise, there is not a different, more favorable standard that will shield its predatory practice of introducing DR DOS incompatibilities in Windows 3.1. This practice was, as explained above, part of Microsoft¹s overall scheme to create fear, uncertainty and doubt about DR DOS/Windows compatibility. The conduct is part of the conduct that underlies Caldera¹s Section 2 claim‹and that conduct is judged under the same Section 2 standard set forth above. Moreover, Microsoft¹s FUD campaign was part of an array of predatory tactics used by Microsoft. The proper standard for judging Microsoft¹s conduct is, therefore, not restricted to the standard used by some courts to evaluate pure intentional incompatibility claims, but is, rather, the standard applied in Section 2 claims generally. In addition to monopoly power and anti-competitive injury, Caldera need only establish that Microsoft attempted to "exclude rivals on some basis other than efficiency." Aspen Skiing Co., 472 U.S. at 605. See Section V.A.1., above. The evidence plainly supports that conclusion.
Even if Microsoft¹s conduct were viewed solely as an intentional incompatibility claim, liability would nevertheless result. Perhaps it is for this reason that Microsoft grossly mischaracterizes the legal standards that apply to the evaluation of such claims. According to Microsoft, product incompatibility results in liability only when the incompatibility (1) prevents the operation of dependent products, (2) is done "solely for the purpose of crippling a competitor," and (3) is devoid of technical merit. Microsoft¹s Intentional Incompatibilities Memo. at 2-3. This is not the law.
Microsoft¹s second requirement‹sole purpose‹is the most glaring of its mischaracterizations. Microsoft cites Transamerica as authority for this standard. In fact, the Transamerica court in that case rejected the sole purpose standard in favor of another standard entirely. See In re IBM Peripheral EDP Devices Antitrust Litigation, 481 F. Supp. 965, 1003 (N.D. Cal. 1979) ("Transamerica"), aff¹d and modified on other grounds sub nom., Transamerica Computer Co. v. IBM, 698 F.2d 1377 (9th Cir. 1983). In rejecting the sole purpose standard, the court reasoned that "discerning corporate intent is seldom easy, and, in any event, the law against monopolization is much more concerned with the effect of conduct rather than with its purpose." Id. at 1003.
Microsoft¹s first and third requirements are similarly ungrounded. They appear to have been pieced together from contextually dissimilar snippets of other cases. Microsoft uses the first requirement (preventing operation of dependent products) to argue that any sabotaging of DR DOS during the beta process cannot give rise to liability‹which makes little sense, given the important marketing role the beta process plays in introducing new products. See Section V.C.3., below. Microsoft¹s third proposed requirement (that the incompatibility has no technical merit) exaggerates the amount of judicial deference allowed to technological justifications for design decisions. See, e.g., Northeastern Telephone Co. v. AT&T Co., 651 F.2d 76, 94 (2nd Cir. 1981) (although design choice was found to be an "adequate" solution to technical problem, the fact that the problem could have been solved another way without creating incompatibility was evidence of anticompetitive conduct). In any event, even if the law were as favorable to monopolists as Microsoft argues it is, Microsoft would still be liable, as explained below.
The proper standard for judging pure incompatibility claims is set forth in Transamerica, the case on which Microsoft relies: "If the design choice is unreasonably restrictive of competition, the monopolist¹s conduct violates the Sherman Act." Transamerica, 481 F. Supp. at 1003 (citing Sherman v. British Leyland Motors, Ltd., 601 F.2d 429, 452 n.46 (9th Cir. 1979)); see also California Computer Products, Inc. v. IBM Corp., 613 F.2d 727, 735-36 & 744 (9th Cir. 1979) (test is whether defendant¹s conduct is "unreasonably restrictive of competition"). In determining whether a design choice is unreasonably restrictive of competition, a court is to consider the following factors:
Transamerica, 481 F. Supp. at 1003.
Intent and technical merit are, therefore, just two relevant factors to be considered in an incompatibility claim. Thus, even a design change that has some technical merit can give rise to liability if the design problem could have been solved without creating the incompatibility. Northeastern Telephone Co., 651 F.2d at 94. And despite Microsoft¹s assertions to the contrary, the technical merits of programming design decisions are not immune from scrutiny and are, of course, a proper subject of expert testimony. See Transamerica, 481 F. Supp. at 1003 & 1005; C.R. Bard, Inc. v. M3 Systems, Inc., 157 F.3d 1340, 1382 (Fed. Cir. 1998). That is all the more true where, as here, the so-called "design decisions" had no technical merit whatsoever. See Section C.3., below.
The Transamerica factors, furthermore, must be interpreted in light of the Supreme Court¹s later decision in Aspen Skiing Co., 472 U.S. 585 (discussed above). Aspen Skiing held that a monopolist¹s refusal to deal with a competitor results in liability where competition is unreasonably affected, especially when the refusal reverses an established pattern of dealing in that market or is a departure from the monopolist¹s conduct in similar, competitive markets. Id. at 603-04. Aspen debunks Microsoft¹s simplistic proposition that it has no duty to share information or do anything to promote compatibility other than to refrain from intentional acts whose sole purpose is to cripple a competing product.
Microsoft created incompatibilities between DR DOS and Windows 3.1 in at least four different ways and between DR DOS and other Microsoft programs in at least two different ways. None of these design decisions had any technical merit, and all prevented DR DOS from operating properly with Windows. The Windows 3.1 incompatibilities consisted of the following:
The other areas of incompatibilities arose out of: a module that was part of Windows for Workgroups called "Protman.dos"; the Korean (Hanguel) versions of Windows and some Microsoft applications programs; and, Windows 95. The evidence on each of these incompatibilities is discussed below.
Although Microsoft publicly denied ever doing so, Microsoft included code in a Windows 3.1 beta designed solely to detect DR DOS and then refuse to run. The code was included in Smartdrv, a module included with Windows and code-named "Bambi."
In 1991, Microsoft executives grew alarmed that IBM, the company that gave Microsoft its start, would soon announce its intention to license DR DOS. See Exhibits 198 & 197. In response to this concern and its concern that it had fallen behind DR DOS on technological merit, Microsoft decided to take advantage of its Windows monopoly. To do this, it undertook a plan to "make sure it [DR DOS] has problems [running Windows] in the future. . . ." Exhibit 197.
Microsoft introduced an incompatibility between DR DOS and certain versions of MS-DOS (including Compaq DOS) in Bambi. See Statement of Additional Material Facts ¶ 43. The programmer responsible for the problem fixed it, and Bambi functioned properly with DR DOS and the specific versions of MS-DOS that earlier had compatibility problems. See Statement of Additional Material Facts ¶ 43. Nevertheless, Phil Barrett, the lead developer on Windows 3.1, instructed the programmer to include code that would detect DR DOS and refuse to load. Barrett responded to the programmer¹s report as follows:
heh, heh, heh . . . my proposal is to have bambi refuse to run this alien OS ? Comments ? The approach we take is to detect dr 6 and refuse to load.
Exhibit 207 to Consolidated Statement of Facts. That is exactly what Microsoft did: in Smartdrive beta version 4.00.059 Microsoft included code that both eliminates the incompatibility with DR DOS and Compaq DOS and executes the DR DOS detection and refusal to load instruction as proposed by Barrett. Hollaar Decl. ¶ 4. The error message displayed did not tell the user what happened or why it happened. Once the message was displayed, Windows 3.1 then refused to run. See Statement of Additional Material Facts ¶ 43. Microsoft apparently obtained the information it needed to program this detection from DRI, by contacting DRI using a fictitious name. Consolidated Statement of Facts ¶¶ 256-58.
It is difficult to imagine a more blatant violation of Section 2 or, for that matter, the law as it applies to incompatibilities. The effect on DR DOS was obvious and drastic: the Microsoft program simply refused to run on DR DOS. And it did so by making it appear that DR DOS was incompatible with Windows. The effect on users was equally obvious and drastic: they could not run DR DOS with Bambi. More important, the detection and refusal to run code was not the product of "technological creativity," nor did it result in any technological benefit. Including the detection and refusal to run code did not allow Microsoft to implement some other desirable new feature‹it simply prevented DR DOS from working with Microsoft¹s product. Finally, although one could infer Microsoft¹s intent by the nature of the code itself and the complete lack of technological benefit associated with it, there is no need to do so. Microsoft answers that question directly: "heh, heh, heh . . . ." Exhibit 207. Microsoft¹s intent is further evidenced by its conduct during this time period: it consistently blamed DRI for any and all incompatibilities that arose during the Windows 3.1 beta cycle and it precluded DRI from gaining access to the information it would have needed to uncover the detection and refusal to run code.
Of course, under Section 2, none of this conduct can be justified. Microsoft cannot argue that including detection and refusal to run code was anything other than unnecessarily restrictive, nor can it argue that it amounted to competition on the merits. The code further demonstrates Microsoft¹s willingness to sacrifice short-run benefits‹revenue from Windows sales to DR DOS customers, goodwill, and increased compatibility between Windows and DR DOS‹to inflict harm on its competitor, which is the hallmark of anti-competitive conduct. See Aspen Skiing, 472 U.S. at 610-11. This is exactly the sort of conduct the antitrust laws seek to deter.
Microsoft also introduced an incompatibility early in the Windows 3.1 beta cycle that prevented users from installing Windows 3.1 with DR DOS. As part of the Windows 3.1 development process, Microsoft added something called DPMI support to Windows. Hollaar Decl. at ¶ 3. In the process of implementing DPMI support, Microsoft created an incompatibility between DR DOS and Windows. Id. The incompatibility resulted from the failure to include a single line of code that would have ensured the Nested Task flag was set properly when protected mode was initiated. As a result, when users tried to run Windows on DR DOS, Windows would refuse to load. The user encountered a fatal error message, which did not identify the cause of the problem. ("Standard Mode: Fault in MS-DOS Extender.") See Hollaar Decl. ¶ 3.
This incompatibility was introduced early in the beta cycle and was not remedied by Microsoft in the production release. The evidence shows that Microsoft knew about the incompatibility, knew the cause of the incompatibility, and knew how to remedy it. See Hollaar Decl. ¶ 3. To correct the error would have required the addition of a single line of code by Microsoft. Microsoft argues to the contrary, but Caldera¹s experts have determined that there was no technical benefit to Windows (or, for that matter, to any other program) that resulted from the introduction of this incompatibility. Id. It was not required for or even helpful to Windows in implementing DPMI or in running setup in Standard Mode‹in fact, it was a hindrance. Id. And it was contrary to accepted programming practices to fail to clear the Nested Task flag. Id. Moreover, if DRI had been allowed to participate in the Windows 3.1 beta program, it would have been a relatively simple matter for DRI to code a work around that would have eliminated the incompatibility. Id.
The incompatibility was serious, it was publicized, and users complained about it. See Statement of Additional Material Facts ¶¶ 62-63. For example, the trade press reported the problem in December 1991‹and DRI had no way to respond, because Microsoft had blacklisted DRI from the Windows 3.1 beta. See, e.g., Statement of Additional Material Facts ¶ 34. At the same time, customers were complaining to Microsoft about the problem, but Microsoft was simply blaming the problem on DR DOS. Engel Decl., Ex. 22. And Microsoft itself asserts, as an undisputed fact, that the reports of incompatibilities were widespread. See Undisputed Fact 7 in Microsoft¹s AARD Code Memo.
Just as Bambi satisfies both the Section 2 standard and Microsoft¹s alleged incompatibilities standard so, too, does the Nested Task flag incompatibility. The effect on DR DOS and consumers was the same: it prevented DR DOS from running with Windows. The incompatibility had no technical benefit; to the contrary, it was a programming bug that caused problems. It was not the product of any design creativity. And Microsoft¹s intent is plain from the facts: Microsoft blacklisted DRI from the beta program, thus ensuring whatever incompatibilities arose, DRI would not be able to respond to them. Furthermore, Microsoft knew the cause of the Nested Task flag problem yet refused either to remedy it or at least allow DRI to have access to the beta which would have permitted DRI to write code to avoid the problem. Instead, Microsoft publicly blamed the problem on DR DOS. There is no efficiency justification for this conduct, and there is no benefit to competition or consumers. To the contrary, this is another example of conduct designed to preclude competition. Finally, as is true with Bambi, Microsoft¹s willingness here to impair the performance of its own product‹Windows‹is a short term sacrifice characteristic of the exercise of monopoly power condemned in Aspen Skiing.
Microsoft included code in the setup program of Windows 3.1 that tested the internal version number of something called the extended memory specification, which is commonly referred to as XMS. See Hollaar Decl. ¶ 5. DR DOS failed the test; MS-DOS passed the test. The test was completely gratuitous‹the setup program that included the test made no use of XMS, so it did not matter what version it found. Id. The other Windows modules that made use of XMS had their own version checks‹and DR DOS passed all those version checks, because DR DOS¹ XMS was compatible with Windows. Id. Thus, Microsoft¹s setup XMS check accomplished one thing and one thing alone: it created another incompatibility with DR DOS. See id. This incompatibility was new to Windows 3.1; the problem had not occurred in previous versions of Windows.
This incompatibility, like Bambi and like the Nested Task flag problem, gives rise to liability under the general Section 2 standard and under Microsoft¹s alleged incompatibility standard. The incompatibility harmed DR DOS and DR DOS users by making it impossible to run DR DOS¹ memory manager with Windows. The incompatibility had no technical benefit‹the test was gratuitously included in a module that made no use of XMS and those that did included tests that DR DOS passed. To the extent intent is relevant, it is easily inferred. The test¹s only effect was to exclude DR DOS, it was implemented during the time DRI was blacklisted from the beta program, and it was done during a time period when Microsoft was including other code in Windows 3.1 designed specifically to prevent DR DOS from operating properly‹or at all‹with Windows.
Microsoft also included secret, encrypted code in five different modules in the third Windows beta. See Hollaar Report, Record Support, v.6 to Consolidated Statement of Facts. The code was designed to detect DR DOS and then display error messages. Id. The error messages did not identify the cause of the supposed error‹they simply told the user an error had occurred and, for several of the messages, halted operation and asked the user to decide whether to hit "enter" to terminate Windows or "C" to continue. Id. The messages also encouraged users to contact Microsoft. Id. The messages were false: as Microsoft itself admits, no error had occurred. See Statement of Additional Material Facts ¶ 48. The users did not know this, however, and Microsoft never revealed the truth. Indeed, when users contacted Microsoft about the errors they were told that they could eliminate the errors by switching from DR DOS to MS-DOS. See Statement of Additional Material Facts ¶ 58; Engel Decl., Ex. 22. All of this is described in more detail, in Section V.D., below.
This incompatibility too gives rise to liability and it does so regardless of the standard that is applied. Under Microsoft¹s alleged incompatibilities standard, the factors weigh heavily against Microsoft. The code¹s effect on DR DOS and its users was plain: it created alarming error messages, even though no error actually existed, leaving DR DOS and users with the clear impression that DR DOS was incompatible with Windows. One expert compares the messages to learning that you have a tumor but did not learn until much later that it is benign. There was no technical benefit associated with the messages‹indeed, they did nothing to improve Windows performance and, in fact, made Windows more difficult to maintain. See Hollaar Report at 5, Record Support, v.6 to Consolidated Statement of Facts. And Microsoft¹s intent could be inferred, but there is no reason to do so; Brad Silverberg, the Microsoft executive responsible for the code, explained why the false error messages were included:
Exhibits 277 & 278.
Microsoft also foreclosed all competition in the DOS market by altering Windows with the release of Windows 95 to run only with the MS-DOS packaged with Windows 95. Microsoft¹s argument that MS-DOS was equally disadvantaged by Windows 95 ignores the fact that MS-DOS is in fact packaged with Windows 95. The nature of the incompatibilities Microsoft created are discussed more fully in Caldera¹s response to Microsoft¹s "Technological Tying" motion.
Microsoft created several other incompatibilities with DR DOS. The dispute over the incompatibility Microsoft created in a version of Windows for Workgroups centers on a module of code call PROTMAN.DOS. Microsoft argues that the incompatibility was the result of a problem in DR DOS, not Windows for Workgroups, that there was no true incompatibility because the problem was eventually corrected by DRI, and that the incompatibility could not have been intentional because the PROTMAN.DOS code was written by a third party, a company called 3COM. All three arguments fail.
The only evidence Microsoft cites to support its claim that the problem resided in DR DOS is the deposition testimony of John Constant, the chief technical officer of DRI. In fact, however, Mr. Constant testified that the incompatibility resulted from a "very dubious technique" of programming by Microsoft. See Constant Dep. 175, Record Support, v.3 to Consolidated Statement of Facts. In light of the Transamerica test and Microsoft¹s obligations under Aspen Skiing, Mr. Constant¹s testimony alone is sufficient to defeat summary judgment. Moreover, Microsoft¹s argument that no incompatibility resulted because DRI eventually fixed the problem ignores the obviously detrimental effects of the delay in achieving incompatibility, as well as the damage to DRI¹s goodwill and reputation from having to issue corrective patches for a released version of its product.
Finally, Microsoft¹s intent argument is implausible; it asks the Court to believe that Microsoft had no interaction with the company that wrote a critical piece of code for Windows for Workgroups. Because no module of software code exists completely independent of others in the program, PROTMAN.SYS could not have been written in isolation and inserted into Windows without assistance from Microsoft.
Microsoft also asserts that Caldera has no evidence to support its claim that Microsoft included software locks in the Hanguel (Korean) versions of some of its applications products. Microsoft then points to marginalia written by a Novell attorney in October of 1990 indicating a lack of evidence and the absence of a Hanguel reading computer at DRI¹s European Headquarters to suggest that Caldera committed a Rule 11 violation by asserting this claim. See Microsoft¹s Intentional Incompatibility Memo. at 10. Microsoft must have neglected to check the deposition transcripts before making such remarks. The DRI Vice-President for Far Eastern OEM sales, Richard Dixon, testified that he witnessed the software lock in question. Through the work of engineers from Hope Electronics, who decompiled the code, DRI determined that the cause of the lock was an instruction Microsoft had placed in the application. See Dixon Dep. at 42-48, Record Support, v.3 to Consolidated Statement of Facts. The software lock demonstration and resulting code decompilation took place in Korea, not Europe. Id. Novell¹s attorneys later included the Korean software locks claim as part of their submission to the Federal Trade Commission in 1992. Engel Decl., Ex. 27 at ¶ 50. Given the instruction from Bill Gates that all Microsoft applications should detect and impede DR DOS, and Microsoft e-mail that indicates his instruction was followed for Microsoft¹s Hanguel versions, the locks in the Hanguel applications are consistent with Microsoft¹s internal documents, and with Microsoft¹s predatory strategy as a whole. Exhibit 30.
Microsoft claims it no longer has copies of the versions of Hanguel Windows and applications in question. Until recently, Caldera has tried unsuccessfully to obtain copies of them from other sources. Tests performed on the recently uncovered version of Hanguel Windows support Caldera¹s claims. The Hanguel Windows 3.0 includes the following error message:
Hanguel Windows 3.0 should be executed on Hanguel MS-DOS. For correct execution, please run on Hanguel MS-DOS.
The Hanguel Windows 3.1 includes the following error message:
Warning: Your DOS is not compatible with Hanguel MS-DOS. You may have some problems when you use Hanguel Windows 3.1
Hollaar Decl. ¶ 7.
Microsoft also argues that incompatibilities created in beta versions of Windows 3.1 are immune from antitrust liability because the purpose of the beta process is to discover and resolve incompatibilities. The argument suffers from several obvious defects. First, carving out a safe harbor for beta versions ignores the serious and clearly foreseeable impact that beta test programs have on marketplace acceptance of a product. See, e.g., Goodman Report at 4-6, Record Support, v.6 to Consolidated Statement of Facts. A number of witnesses in this case have testified about the devastating impact that incompatibilities in Windows 3.1 beta versions had on DR DOS. See, e.g., Deposition Theo Lieven ("Lieven Dep.") ¶¶ 229-30, Record Support, v.5 to Consolidated Statement of Facts (describing abrupt cessation of DR DOS sales after negative press articles about its compatibility based on review of Windows beta); Deposition of Jose Vasco ("Vasco Dep.") at 157-58, Engel Decl., Ex. 28 (DRI sales representative describing lost sales resulting from discussion of AARD code in Windows 3.1 Christmas beta raised at press conference); Corey Dep. at 268-73, Record Support, v.3 to Consolidated Statement of Facts (beta incompatibility tainted market in a very significant way); Dixon Dep. at 338, Record Support, v.3 to Consolidated Statement of Facts; see also Goodman Report at 6, Record Support, v.6 to Consolidated Statement of Facts. The CompuServe forum messages from Windows 3.1 beta testers provide additional evidence of the severe harm Microsoft inflicted on DRI during the beta process. See, e.g., Statement of Additional Material Facts ¶ 63 "DR DOS will *not* allow the beta to install. . . ." "Precisely why I use MS-DOS 5. Good luck."
Second, although, the major purpose of most beta testing is to work out incompatibilities, it is undisputed that Microsoft had no intention of working out incompatibilities with DR DOS. Indeed, it is undisputed that Microsoft excluded DRI from the beta process and publicly stated that it would render no information or assistance. Microsoft¹s purpose in excluding DRI was directly contrary to the purpose of beta testing: Microsoft sought to create incompatibilities and prevent DRI from remedying them. Consequently, the basic rationale Microsoft relies upon to support such a safe haven is completely absent here.
Third, these incompatibilities affected released versions of DR DOS. Novell/DRI was even forced to issue corrective updates to fix the Nested Task flag and XMS version check problems. Clifton Dep. at 226, Engel Decl., Ex. 13. As with a product recall, doing so is expensive, reduces customer goodwill, and cements the very fears about DR DOS that Microsoft intended to create.
As explained in the previous section, Microsoft¹s inclusion of false error messages in the Windows 3.1 beta was, in fact, yet another engineered incompatibility and that alone is enough to give rise to Section 2 liability. Under a tortured definition of "incompatibility," however, Microsoft insists the encrypted and obfuscated false error message code did not amount to an incompatibility. Thus, Microsoft argues, its predatory conduct must be judged under a different standard. Even putting aside the lack of any basis for this contention, it makes no difference: even under Microsoft¹s proposed standard, Microsoft is not entitled to summary judgment.
Microsoft ignores both the substance and letter of Caldera¹s claims to insist that Caldera¹s allegations regarding the AARD code are, in fact, a disparagement claim and thus must be evaluated under the law governing disparagement, separate and apart from Microsoft¹s other predatory acts. Microsoft¹s AARD Code Memo. at 1. Caldera, however, has not pled a separate disparagement claim. Rather, Caldera alleges that Microsoft¹s inclusion of false error messages in the Windows 3.1 Christmas beta was one of numerous predatory acts Microsoft committed in violation of Section 2‹all designed to preclude DR DOS from competing in the DOS market. See First Amended Complaint ¶¶ 49-53 & 72-77.
Despite Microsoft¹s attempt to recast Caldera¹s claims, Caldera¹s AARD code claims are not disparagement claims. Classic product disparagement occurs when one competitor makes statements disparaging another competitor¹s product. Where disparagement is alleged as the basis for antitrust liability, courts presume a de minimus effect on competition because "most consumers view statements about a competitor cynically, recognizing the inherent bias and lack of objectivity of such statements." American Professional Testing Serv., Inc. v. Harcourt Brace Jovanovich Legal & Professional Publications, Inc., 108 F.3d 1147, 1152 (9th Cir. 1997). Neither the definition of disparagement nor the rationale for presuming a de minimus effect on competition apply here. The false error messages left people with the impression that a real incompatibility existed between Windows 3.1 and DR DOS. There was no reason for consumers to know, or suspect, that they should view the false error messages "cynically" or as mere puffing by Microsoft.
In fact, what Microsoft did with the false error messages is akin to the following analysis: Imagine a world where Sony is the only TV manufacturer. Sony also makes VCRs. Rather than telling consumers that Panasonic makes inferior VCRs, Sony designs a detection mechanism in its TVs so that every time a consumer attempts to use a Panasonic VCR with the TV, an error message appears and makes it appear as if the VCR will not work with the TV. The message also tells the user to contact Sony. When the user calls Sony to find out what the problem is, Sony tells the user he or she should go out and buy a Sony VCR. This behavior is not disparagement; it is, however, precisely the type of behavior the antitrust laws were designed to prevent.
In support of its position that Caldera¹s AARD code allegations are governed by disparagement law, Microsoft relies on a single case, David L. Aldridge Co. v. Microsoft Corp., 995 F. Supp. 728, 747-50 (S.D. Tex. 1998). Notwithstanding Microsoft¹s representations, Aldridge does not hold that Section 2 claims regarding computer-generated error messages must be evaluated as if they were disparagement claims. See Microsoft¹s AARD Code Memo. at 1. As Microsoft well knows, the Aldridge court applied disparagement law to Aldridge¹s claims because that is how he pled them. See Ex. 29 to Engel Decl. (Aldridge complaint). The Aldridge court simply did not have to consider whether disparagement law was the correct standard to apply. Microsoft relies heavily on this case, though, and is attempting to create a new legal standard‹not based on any legal precedent‹but rather, out of nothing more than one plaintiff¹s strategic pleading decision. Unlike the plaintiff in Aldridge, Caldera has pled a Section 2 claim that involves a coordinated scheme of predatory and anticompetitive acts, all designed to instill fear, uncertainty and doubt about DR DOS¹s ability to run Windows.
Moreover, as is obvious from the Aldridge court¹s opinion, there are numerous reasons why disparagement law should not be applied to evaluate incompatibilities claims, whether or not they involve error messages. For example, the Aldridge court rested its holding in part on the fact that computer error messages disappear after the computer is turned off. 955 F. Supp. at 750. Apparently, the court believed that this meant the messages would have little effect, but Microsoft itself knows that not to be true‹it asserts here, as an "undisputed fact," that error messages are far more effective than written documentation or electronic documentation included with programs. See Microsoft¹s Statement of Undisputed Facts Regarding Plaintiff¹s "Perceived Incompatibilities" Claim ¶ 3. In any event, Aldridge is easily distinguished from this case.
Aldridge designed and sold a third-party software utility that improved the performance of MS-DOS and the performance of MS-DOS and Windows together, by shifting certain functions from the hard disk to random access memory. Id. at 733-34. When Microsoft subsequently designed Windows 95, it did so in such a way that when Windows 95 detected Aldridge¹s utility, a computer generated message appeared. Id. at 737. The message told the user that the utility might decrease the operating system¹s performance. Id. The user then had the option of obtaining additional information about the problem. Id. If the user chose "yes" and asked for more information, a second message appeared, explaining that the utility forced the operating system to operate in a slower mode. Id. The user could then choose to review two more messages that provided even more information regarding the problem. Id.
Aldridge did not participate in the Windows 95 beta program. Id. at 739. At least a year before Windows 95 was released, however, Aldridge learned from Windows 95 beta testers that Windows 95 displayed messages regarding Aldridge¹s product. Id. at 751. Despite this, Aldridge never asked Microsoft for a Windows 95 beta. Id. at 739. Aldridge¹s sales began declining even before the Windows 95 general release and, even though Aldridge ultimately developed a product that was compatible with Windows 95, the new product did not stop Aldridge¹s sales from plummeting. Id.
Aldridge alleged that Microsoft violated of the Sherman Act by disparaging Aldridge¹s product and by denying Aldridge access to an essential facility‹Windows 95. Id. at 747-48. On Microsoft¹s motion for summary judgment, the district court, consistent with Aldridge¹s complaint, applied the six-part disparagement test to Aldridge¹s disparagement claim. The court found that Aldridge raised factual issues about the falsity of two of the messages, about materiality, and about reliance. Id. at 750. The court also found that Aldridge had established that Microsoft published the messages to consumers who had little understanding of the subject matter. Id. The court, however, found that two of the messages were true, that the messages did not appear for prolonged periods (because they were not displayed when the computer was turned off), and that the messages were susceptible to neutralization. With respect to the final prong, the court noted that Aldridge did not ask Microsoft about the messages or attempt to upgrade its product to make it compatible with Windows 95, even though Aldridge had received reports from Windows 95 beta testers regarding the messages a year before the commercial release of Windows 95. Id. at 751 n.133. The court, thus, granted Microsoft¹s motion for summary judgment on Aldridge¹s disparagement claim.
In contrast to Aldridge, Caldera has alleged a coordinated scheme of predatory acts, including false error messages, beta blacklisting, intentional incompatibilities, per processor licensing, tying and other exclusionary conduct, that go far beyond those alleged in Aldridge. Aldridge¹s principal claim was disparagement, the messages Aldridge complained of were not part of a coordinated scheme to encourage users to contact Microsoft, only to be told to switch to MS-DOS. Nor was Aldridge blacklisted from the Windows 95 beta program; DRI actively sought to participate in the Windows 3.1 beta program but was turned down. As discussed more fully above, see Section V.A., the entire course of Microsoft¹s conduct must be considered before concluding that Microsoft has or has not violated Section 2.
Even if the disparagement standard did apply to Caldera¹s allegations regarding the AARD code, there would still be material issues of fact. Microsoft argues that the error messages were not "clearly false"; that the false error messages could not have reasonably induced reliance on the part of the beta testers; that the false error messages were not made to consumers, but rather to sophisticated users; and that Novell could have neutralized the damaging effects of the false error messages. Microsoft is wrong on all counts.
Every time the message appeared, the message falsely stated that there was an error. In fact, however, there was no error. Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts ("There is no problem."); Hollaar Report at 12-14, Record Support, v.6 to Consolidated Statement of Facts. To generate an error message when there is in fact no error is little different than pulling a fire alarm when there is no fire. Microsoft¹s argument, that the AARD code "did not create any actual incompatibility [because it] did not modify DR DOS or interfere with the operation of DR DOS in any way," is akin to saying that there is nothing wrong with shouting "Fire!" in a crowded movie theatre because it does not actually cause a fire.
Microsoft also argues that the error message cannot be "false" because it did not identify DRI or Novell by name. Not surprisingly, Microsoft fails to cite a single case stating that this is a requirement. Regardless, Microsoft specifically and repeatedly identified DR DOS as the cause of the error messages. See Statement of Additional Material Facts ¶ 52.
Finally, after arguing that the false error messages were "devoid of content" and said "nothing," Microsoft makes a puzzling alternative argument, conceding that although the false error messages may have suggested that there were incompatibilities between DR DOS and Windows 3.1, the messages are not actionable because they were "true." Microsoft¹s AARD Code Memo. at 6. The developer of the AARD code himself, however, testified that when these error messages appeared, there was no error. Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts. There is not a definition of "true" that can rescue Microsoft here.
Microsoft makes the misleading argument that because the false error messages were not included in the commercial release of Windows 3.1, the messages were not seen by "consumers having little understanding of the subject matter." Microsoft AARD Code Memo. at 8. The Windows 3.1 Christmas beta was released to over 15,000 users. These testers included end-users, corporations, government offices, members of the press and others. See to Response to Microsoft¹s AARD Code Undisputed Facts ¶ 10, Section II.C., above. This group was not, as Microsoft suggests, a specialized group of testers, highly trained and prepared to uncover the fact that the error messages were false error messages. The evidence on this point is strong. True beta testers should be reporting problems on a regular basis; only 37% of the Windows 3.1 beta sites returned even a single error report. Id. at ¶ 6. Moreover, Microsoft admits that the beta program was‹especially in the late stages‹much more than a testing program. It had an important marketing purpose, which explains the broad distribution and the low reporting statistics. Id.
Microsoft also glosses over the point that it alone had access to the source code for Windows 3.1. Thus, no one, with the exception of a few highly skilled software engineers, was in a position to discover the fact that the error messages were, in fact, false error messages. This task was made even more difficult by Microsoft¹s practice of deliberately obfuscating the source of the messages by encrypting the object code itself and by deliberately disabling the debugger‹the tool most useful in trying to uncover the source of the false error messages.
Every tester who ran the Christmas beta on DR DOS saw one or more of the false error messages. Every tester who viewed the dialogue on the Compuserve Forum site for the Windows 3.1 beta would have seen Microsoft¹s responses to questions about the false error messages. See Statement of Additional Material Facts ¶ 52. It was more than reasonable for beta testers to rely on Microsoft¹s representations about what caused the false error messages. After all, Windows 3.1 was Microsoft¹s product‹who better than Microsoft would know what was causing the error messages? There was no way these beta testers would know, or even suspect, that the error messages were false or that Microsoft¹s purpose in creating the false error messages was to make the user feel "uncomfortable" and to "think that the problem was DR DOS and go out and buy MS-DOS." Id. at ¶ 52; see also Goodman Rebuttal Report at 12, Engel Decl., Ex. 21. Moreover, there was no reason why beta testers would know, or suspect, that Microsoft was not telling the truth when it blamed the problems on DR DOS.
Finally, Microsoft fails to mention the fact that it encrypted and obfuscated the AARD code to keep secret its function and purpose. Contrary to Microsoft¹s assertion that those received the beta program were highly trained and unable to uncover the fact that the error messages were false, it was not until 1993‹two years later‹when a beta user finally deciphered the AARD code. Statement of Additional Material Facts ¶¶ 97-100. His reaction:
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.
Microsoft designed and encrypted code that caused false error messages to appear when the Windows 3.1 beta ran with DR DOS. Hollaar Report at 9-12, Record Support, v.6 to Consolidated Statement of Facts. Microsoft released the beta to over 15,000 test sites, including OEMs who were deciding whether to license DR DOS, the trade press who passed on information to the general public, and average PC users. See Response to Microsoft¹s Undisputed Facts Regarding the AARD Code ¶ 10, Section II.C., above. Microsoft posted messages on a Compuserve Forum suggesting that the error messages were caused by incompatibilities between DR DOS and Windows 3.1. See Statement of Additional Material Facts ¶ 52. Microsoft refused, and let the industry know that it refused, to provide DRI with a beta so DRI could identify the cause of the messages. Id. at ¶¶ 31-32 & 34-37. And, at the same time, Microsoft was warning users that Microsoft could only guarantee future compatibility between MS-DOS and Windows. Id. at ¶¶ 22-25. Given all of this, it is irrelevant that DRI "could have" subsequently designed code to remove the message or disable the detection mechanism. Microsoft¹s AARD Code Memo. at 10. By the time Windows 3.1 was commercially released, the damage to DR DOS was done. Microsoft itself recognized that the false error messages had the desired effect. See Reynolds FTC Dep. at 76-77, Record Support, v.2 to Consolidated Statement of Facts.
Microsoft incorrectly argues that Caldera must satisfy the six-part Areeda test and prove market harm. Microsoft¹s AARD Code Memo. at 3. As discussed in Caldera¹s Product Disparagement Response at Section C, this is not the law. The six part Areeda test is a substitute for proof of harm. See, e.g., National Ass¹n of Pharmaceutical Mfrs. v. Ayerst Labs., 850 F.2d 904, 916 (2nd Cir. 1988). As shown above, Caldera easily satisfies this test.
In any event, Caldera has abundant direct evidence that Microsoft¹s predatory acts harmed competition, including eliminating MS-DOS¹ only real competition‹DR DOS, eliminating price competition in the DOS market, and consequently, eliminating any competitive pressure on Microsoft to innovate. See Section V.A.3., above; see also Product Disparagement Response at Section E.
Microsoft makes a half-hearted attempt to convince this Court that the false error messages constituted a communication between Microsoft and the users of the Windows 3.1 beta program that was protected by the common interest privilege set forth in Section 596 of the Restatement (Second) of Torts. This is absurd. First, Section 596 sets forth the qualified privilege that exists in the context of defamation claims, not antitrust claims. Caldera has not claimed the false error messages were defamatory. Second, Microsoft does not cite a single case to support its position that communications protected by this common interest privilege are immune from the antitrust laws. The one case Microsoft cites never reached the issue because the court found that there was no common interest privilege. See California Energy Co. v. Southern California Edison Co., 1992 WL 330263, *3 (N.D. Cal. 1992). Third, even if common interest privileged communications were immunized from the antitrust laws, Microsoft has not established that it had the necessary common interest with its 15,000-plus beta program users. Common interest is limited to special relationships, such as fellow partners or officers of a corporation for profit. See Restatement (Second) Torts § 596 (1977), comment d. The limited, arms-length dealings between Microsoft and the Windows 3.1 beta users do not approach the special relationship requirement.
For all the above reasons, Caldera respectfully requests that the Court deny Microsoft¹s predisclosure, perceived incompatibilities, and intentional incompatibilities partial summary judgment motions.
DATED this 19th day of April, 1999.
SNOW, CHRISTENSEN & MARTINEAU
Stephen J. Hill
Ryan E. Tibbitts
Attorneys for Plaintiff, Caldera, Inc.