UNITED STATES OF AMERICA et al v. MICROSOFT CORPORATION, No. 1:1998cv01232 - Document 700 (D.D.C. 2002)

Court Description: Attachment 3Proposed MOTION for Settlement Memorandum of the United States in Support of Entry of the Proposed Final Judgment by UNITED STATES OF AMERICA. (Attachments: # 1 Appendix A - Comparison of Court of Appeals' Findings on Liability to Provisions of the Revised Proposed Final Judgment# 2 Appendix B - U.S. v. Microsoft Newspaper Notice# 3 Appendix C - Declaration of David S. Sibley)(Hesse, Renata)

Download PDF

UNITED STATES OF AMERICA et al v. MICROSOFT CORPORATION Doc. 700 Att. 3 APPENDIX C DECLARATION OF DAVID S. SIBLEY Dockets.Justia.com IN THE UNITED STATES DISTRICT COURT FOR THE DISTRICT OF COLUMBIA UNITED STATES OF AMERICA Plaintiff, v. Civil Action No. 98-1232 (CKK) Next Court Deadline: March 6, 2002 Tunney Act Hearing MICROSOFT CORPORATION, Defendant DECLARATION OF DAVID S. SIBLEY DECLARATION OF DAVID S. SIBLEY I. Qualifications and Introduction 1. My name is David S. Sibley. I am the John Michael Stuart Centennial Professor of Economics at the University of Texas at Austin. I received the degree of B.A. in Economics from Stanford University in 1969 and a Ph.D. in Economics from Yale University in 1973. In addition to my current teaching responsibilities, I have taught graduate level courses in economics at the University of Pennsylvania and Princeton University. Prior to joining the University of Texas, I was Head of the Economics Research Group at Bell Communications Research. I have also served as a Member of the Technical Staff in economics at Bell Laboratories. During the last thirty years, I have carried out extensive research in the areas of industrial organization, microeconomic theory, and regulation. My publications have appeared in a number of leading economic journals, including the Journal of Economic Theory, Review of Economic Studies, Rand Journal of Economics, American Economic Review, Econometrica, and the International Economic Review, among others. I am also the coauthor (with Steven J. Brown) of a leading textbook on monopoly pricing, THE THEORY OF PUBLIC UTILITY PRICING, which was first published by Cambridge University Press in 1986. 2. I have consulted extensively for various firms and agencies, both in the United States and abroad, on antitrust and regulatory matters. In 1998, I was retained by the U.S. Department of Justice (“DOJ”) to examine the competitive effects of contractual restrictions in agreements between Microsoft Corporation (“Microsoft”) and personal computer original equipment manufacturers (“PC manufacturers” or “OEMs”), Internet access providers (“IAPs”), and Internet content providers (“ICPs”). The declaration that I filed in May 1998 on behalf of the Antitrust Division of the DOJ summarized my economic analysis.1 Appendix A contains a copy of my curriculum vitae. 3. I have been asked by the DOJ to review the terms of its proposed settlement with Microsoft and to provide an opinion as an independent economist as to whether the antitrust remedy embodied in the settlement is in the “public interest.” It is my understanding that key components of the public interest standard of the Tunney Act are satisfied when the antitrust remedy is sufficient to (1) stop the offending conduct, (2) prevent its reoccurrence, and (3) restore competitive conditions.2 4. In conducting this analysis, I examined the following documents: (1) the Revised Proposed Final Judgment,3 the Second Revised Proposed Final Judgment, including the accompanying memorandum regarding modifications,4 and the Competitive 1 Declaration of David S. Sibley, United States v. Microsoft Corp., Civ. Action No. 981232 (D.D.C. May 18, 1998) (hereinafter “May 1998 Sibley Decl.”). See also David S. Sibley, Michael J. Doane, and Ashish Nayyar (2001), “Economic Issues in U.S. v. Microsoft,” UWLA LAW REVIEW, Symposium: Cyber Rights, Protection, and Markets, 103-136. 2 My declaration does not address the compliance and enforcement procedures contained in the proposed remedy. 3 Revised Proposed Final Judgment, United States v. Microsoft Corp., Civ. Action No. 98-1232 (CKK) (D.D.C. Nov. 6, 2001). 4 Second Revised Proposed Final Judgment, United States v. Microsoft Corp., Civ. Action No. 98-1232 (CKK) (D.D.C. to be filed Feb. 27, 2002) (hereinafter “SRPFJ”); United States’ Memorandum Regarding Modifications Contained in Second Revised Proposed Final Judgment, United States v. Microsoft Corp., Civ. Action No. 98-1232 (CKK) (D.D.C. to be filed Feb. 27, 2002). 2 Impact Statement of the DOJ;5 (2) the Findings of Fact and Conclusions of Law issued by Judge Jackson;6 (3) the decision issued by the U.S. Court of Appeals for the D.C. Circuit in June of 2001;7 (4) the record from the U.S. Senate Judiciary Committee’s December 12, 2001, hearing regarding the proposed settlement, including the responses to follow-up questions posed to Assistant Attorney General Charles James;8 (5) the DOJ’s written response to questions regarding the proposed settlement raised by Senator Orrin Hatch;9 (6) the Litigating States Proposed Final Judgment; (7) comments on the settlement filed by third parties, including declarations submitted by other economists; and (8) public documents and websites containing relevant information. 5. My conclusions are summarized as follows. • Any economic analysis of the SRPFJ must have as its starting point a clear delineation of the conduct found to be unlawful. The remedy presently under consideration must therefore focus attention on and fully resolve the appellate court finding that Microsoft engaged in specific anticompetitive acts to maintain its operating system monopoly. • In developing this remedy, it is necessary to balance two broad factors: (1) the need to impose constraints on Microsoft’s current and future behavior so that the unlawful acts stop and do not recur, and competitive conditions 5 Competitive Impact Statement, United States v. Microsoft Corp., Civ. Action No. 981232 (CKK) (D.D.C. Nov. 15, 2001) (hereinafter “CIS”). 6 See Findings of Fact, United States v. Microsoft Corp., 84 F. Supp.2d 9 (D.D.C. Nov. 5, 1999); Conclusions of Law, United States v. Microsoft Corp., 87 F. Supp.2d 30 (D.D.C. Apr. 3, 2000). 7 United States v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. June 28, 2001). 8 See United States Senate, Senate Committee on the Judiciary Documents for the December 12 Hearing on “The Microsoft Settlement: A Look to the Future”; Office of the Assistant Attorney General, United States Department of Justice, Response to written follow-up questions posed to Assistant Attorney General Charles James (Jan. 24, 2002). 9 See Office of the Assistant Attorney General, United States Department of Justice, Response to Senator Hatch’s letter of November 29, 2001 (Dec. 11, 2001). 3 are restored; and (2) the requirement that these constraints not be so intrusive and complex that they themselves distort market outcomes. • The SRPFJ achieves the right balance. Broadly defined provisions banning exclusivity, discrimination, and retaliation fundamentally alter the way Microsoft does business, and eliminate the artificial entry barriers erected by Microsoft that are the source of competitive concern. At the same time, the SRPFJ does not create market distortions, such as overextensive regulation of Microsoft that may invite inefficient rent-seeking by Microsoft’s competitors, and make Microsoft a less efficient competitor. • Microsoft erected artificial entry barriers to slow or halt the natural tendency of the marketplace to provide certain alternative technologies (known as “middleware”) that have the potential to erode Microsoft’s operating system monopoly. The proposed decree aims to restore and enhance competitive conditions by removing technical barriers between Microsoft and rival middleware suppliers. This is the appropriate conduct to be remedied, not the existence of the monopoly itself, or barriers which arise naturally in software markets. • The proposals of other commentators fail to strike the right balance. In an attempt to eliminate all theoretical ways in which Microsoft could harm competition, they propose a complex regulatory program that is likely to be slow-moving, litigious, and vulnerable to manipulation by Microsoft’s competitors, to say nothing of Microsoft itself. • In analyzing the SRPFJ, I have had the benefit of reviewing a number of thoughtful and probing comments on the proposed decree. I found that most of the potential problems raised by the various commentators are, in fact, not problems at all, but are met by the SRPFJ upon careful analysis. My review of their criticisms reveals the potential loopholes that are theoretical possibilities are either unimportant, or rely on strategies that Microsoft would not have the incentive to undertake. • In light of the above, in my opinion, the SRPFJ is in the public interest. 6. I have organized my declaration as follows: In Section II, I discuss the specific anticompetitive acts that are the focus of this inquiry and provide an overview of the proposed remedy embodied in the SRPFJ. This section also reviews the characteristics of software markets that are relevant to an economic analysis of the 4 proposed decree. Section III presents my analysis of the SRPFJ and discusses why, in my opinion, the proposed decree meets the public interest requirement of the Tunney Act. Section IV addresses the main suggestions for additional remedy provisions discussed by various commentators. My conclusions are presented in Section V. II. Microsoft’s Unlawful Conduct and Proposed Remedy in the SRPFJ 7. Any economic analysis of the SRPFJ must have as its starting point a clear delineation of the conduct found to be unlawful. To be in the “public interest,” an antitrust remedy must stop the offending conduct, prevent its recurrence, and restore competitive conditions. The remedy presently under consideration must therefore focus attention on and fully resolve the appellate court finding that Microsoft engaged in specific anticompetitive acts to maintain its monopoly position in the market for operating systems designed to run on Intel-compatible personal computers (“PCs”). 8. To assess the remedial effectiveness of the SRPFJ, it is useful for two reasons to review the characteristics of software markets that gave rise to the Microsoft operating system (“OS”) monopoly. First, as discussed below, certain economic forces can lead naturally to dominance by a single firm, even apart from anticompetitive conduct. It was alleged, and both the District Court and the Court of Appeals agreed, that Microsoft’s conduct erected artificial entry barriers on top of those that occur naturally in software markets. These artificial entry barriers were added to slow or halt the adoption of alternative technologies (known as “middleware”) that have the potential to erode Microsoft’s OS monopoly. This is the conduct to be remedied, not the existence of the monopoly itself. 5 9. Second, there is widespread agreement that the middleware threat to the Microsoft operating system posed by the Netscape Web browser (i.e., Navigator) and the Java programming technology was a “nascent” one.10 While there is no question that Microsoft’s conduct was aimed at eliminating that threat, there is significant uncertainty regarding when Microsoft’s OS monopoly would have been substantially eroded (if at all). Thus, the appropriate remedy in this case is to restore the potential threat that middleware provides, not to eliminate natural entry barriers that are not in themselves a cause for competitive concern. This point has been overlooked by those critical of the proposed decree who argue the appropriate antitrust remedy in this case calls for the elimination of the applications barrier to entry. A. Characteristics of Software Markets 10. In many software markets, including OS markets, there are fundamental forces that may lead to one firm being dominant at a given time and that tend to create barriers to entry. These forces have been widely discussed in the economics and computing literature. The first is the presence of scale economies. For complex software such as an OS, the initial or “first-copy” costs to writing software are often very large, whereas the incremental cost of producing additional copies is small. Hence, average cost declines as the scale of output rises. The second is increasing returns in consumption. The larger the market share of a particular OS, the more independent software vendors (“ISVs”) will tend to write applications for that OS. The more this happens, the more attractive will customers find that OS, further increasing its market share, which leads to the development of more new software applications, and so forth. 10 United States v. Microsoft Corp., 253 F.3d 34, 79 (D.C. Cir. June 28, 2001). 6 Thus, increasing returns in consumption induce a series of feedback effects, which tend to make a dominant OS more dominant over time.11 11. Economies of scale and increasing returns to consumption give rise to a phenomenon that lies at the heart of antitrust analysis of network industries: monopoly tipping.12 If a large set of users adopts a new network technology, then that technology becomes more attractive to everyone else as a result of increasing returns in consumption. As more users join, the technology becomes still more attractive until it becomes dominant; in economic terminology, the market has “tipped” to the new technology. Because users invest time and money in learning to use a given technology proficiently, for a newer technology to succeed, it would have to offer a substantial improvement in performance – i.e., enough of an improvement at least to overcome the switching costs associated with the change. In the normal course of markets and competition, such improvements do in fact occur. One example is the displacement of slide rules by pocket calculators. 12. The economic theory of network effects describes well the performance of the OS market. As an operating system gains popularity, the incentive to develop 11 Increasing returns to consumption is often discussed as an important consequence of network effects. First formalized by Rohlfs, there is a network effect whenever the value to existing users of a network increases as the network expands with new users. See Jeffrey H. Rohlfs (1974), “A Theory of Interdependent Demands for Communications Service,” 5 BELL JOURNAL OF ECONOMICS AND MANAGEMENT SCIENCE 16-37. See also Michael Katz and Carl Shapiro (1985), “Network Externalities, Competition and Compatibility,” 75 AMERICAN ECONOMIC REVIEW 424-440; Michael Katz and Carl Shapiro (1986), “Technology Adoption in the Presence of Network Externalities,” 94 JOURNAL OF POLITICAL ECONOMY 822-841. 12 See, e.g., Joseph Farrell and Garth Saloner (1986), “Installed Base and Compatibility: Innovation, Product Differentiation, and Predation,” 76 AMERICAN ECONOMIC REVIEW 940-955; Joseph Farrell and Garth Saloner (1985), “Standardization, Compatibility, and Innovation,” 16 RAND JOURNAL OF ECONOMICS 70-83. 7 software for that operating system grows since the number of potential customers for the application developer is larger. This, in turn, increases the value of the operating system to end users (and likely its market share), which is determined by the quality and variety of software applications written for it. As the OS gains market share, software developers find it even more advantageous to produce additional applications for that system. This feedback effect explains why the number of complementary software applications and the installed base of these applications serve as natural barriers to entry, and also why alternative operating systems already in the market at a small scale are not effective competitors. This feature of software markets has become known as the applications barrier to entry.13 13. Microsoft’s dominant market share was a predictable consequence of the applications barrier to entry. At trial, it was documented that Microsoft’s market share in each period from 1991 to 1997 held consistently at about ninety percent. Further, it was documented that Microsoft’s OS dominance was stable, that it had hardly fluctuated in the face of determined attempts at entry by rival operating systems, and that it was forecast to remain stable in the future.14 B. The Middleware Threat to the Microsoft OS 14. The above discussion suggests that, to enter with a product consumers would want installed on their PCs, OS vendors would have to create or induce others to 13 In my May 1998 Declaration, I argued that the application barrier to entry occurs naturally in certain software markets and is not, by itself, a source of antitrust concern. By contrast, I stated “[t]he bundling and other contractual browser restrictions that Microsoft insists upon in its agreements with OEMs, IAPs, and ICPs add artificial entry barriers to those that occur naturally, and are therefore a source of competitive concern.” See May 1998 Sibley Decl. at ¶19. 14 Government Exhibit No. 1. 8 create an extensive set of software applications to go with it. Alternatively, the product would have to emulate the Windows applications programming interfaces (“APIs”) needed to run existing Windows applications. APIs permit software applications running on an OS to access the basic computing functions performed by that operating system, such as opening a file, executing a print command, drawing a box, etc. The Netscape Web browser was a new class of software – called middleware – that itself exposed a broad range of APIs to which software developers could write applications. This middleware product threatened Microsoft’s OS dominance because the browser could serve as a software applications platform independent of the underlying OS.15 Thus, a new entrant in the OS market would not have to create an installed base of software applications for its OS comparable in size and use to those of Microsoft in order to succeed. Instead, applications written to the browser platform (perhaps using the Java programming technology of Sun Microsystems, Inc. (“Sun”)) would be accessible to a user using any OS supporting that browser. Application developers would have the incentive to write to these browser APIs because their applications would then run on Windows plus the operating systems that were previously unprofitable for these ISVs to write applications. This would ultimately make it less important for users to which operating systems were installed on their computers. As Bill Gates stated: “[t]hey [Netscape] are pursuing a multi-platform strategy where they move the key [APIs] into the client [browser] to commoditize the underlying operating system.”16 15 See May 1998 Sibley Decl. at ¶¶ 18-19, 30, and 49-50. 16 Government Exhibit No. 20, Email from Bill Gates to the Microsoft Executive Staff and Direct Reports (May 26, 1995). 9 15. As the evidence in this case demonstrates, Microsoft engaged in specific anticompetitive actions intended to displace the Netscape browser with its own Web browser, Internet Explorer (“IE”). In particular, the commingling and contractual browser restrictions that Microsoft insisted upon in its agreements with OEMs, IAPs, ICPs, and Independent Software Vendors (“ISVs”) impeded the growth of the Netscape Web browser by adding artificial entry barriers to those that occur naturally. Such restrictions are therefore a source of competitive concern. 16. In challenging Microsoft’s commingling and contractual practices, the plaintiffs’ antitrust complaint alleged the following: (1) Microsoft engaged in a series of anticompetitive acts to maintain its OS monopoly; (2) Microsoft attempted to monopolize the Web browser market; (3) Microsoft illegally tied IE to its operating system; and (4) Microsoft entered into unlawful exclusive dealing arrangements. The District Court sustained claims (1) through (3). The appellate court, however, sustained only the monopoly maintenance claim, and with fewer anticompetitive actions than the District Court had found.17 Thus, the focus of the SRPFJ is on remedying the twelve specific anticompetitive actions the appellate court found Microsoft to have taken to maintain its OS monopoly. (See Table One.) In addition, the SRPFJ includes measures designed to enhance the ability of rival middleware vendors to interoperate with the Microsoft OS. As addressed in Sections III and IV below, many critics of the proposed decree appear to have ignored the fact that the government’s case had been significantly narrowed. 17 The appellate court reversed both the attempted monopolization and tying claims (remanding the tying claim for further hearing under the rule of reason standard) and vacated the Final Judgment that called for a structural remedy and interim conduct remedies. 10 TABLE ONE SUMMARY OF FINDINGS OF ANTICOMPETITIVE ACTS Anticompetitive Findings of District Court Appellate Court Agreement? Agreements with OEMs 1. Prohibition on OEM removing desktop icons, folders, or Start Menu entries Yes 2. Prohibition on OEM altering initial boot sequence Yes 3. Prohibition on OEM allowing alternative user interface to launch automatically No 4. Prohibition on OEM adding icons or folders in different size or shape Yes 5. Prohibition on OEM using Active Desktop to promote others’ products Yes Binding of IE to Windows 6. Excluding IE from the “Add/Remove” utility Yes 7. Designing Windows to override users’ choice of default browser other than IE No 8. Commingling code to eliminate OEM choice of removal of IE from Windows Yes Agreements with IAPs 9. Licensing IE for free No 10. Payment for use of IE with IAP service signup No 11. Developing IE Access Kits and offering them for free No 12. Placement of IAP’s product on desktop in return for IE exclusivity (or limit to Navigator shipments) Yes Agreements with ICPs, ISVs, and Apple 13. Exclusive agreements with ICPs No 14. Agreements with ISVs to make IE the default hypertext interface Yes 15. Threat to end support of Office on MAC platform as “a club” to coerce Apple to use IE as default browser with MAC OS Yes Efforts to Contain and Subvert Java 16. Design of Java Virtual Machine (“JVM”) that was incompatible with Sun’s product No 17. Exclusive agreements to promote Microsoft’s JVM Yes 18. Deceived Java developers about Windows-specific nature in Microsoft Java Yes 19. Coerced Intel to stop aiding Sun by threats to support Advanced Micro Devices, Inc. (“AMD”) Yes Course of Conduct 20. Apart from specific acts, Microsoft’s general course of conduct violated Section 2 of the Sherman Act 11 No C. Summary of SRPFJ Provisions 17. Given the appellate court findings, the SRPFJ focus is appropriately on middleware. Each of the twelve anticompetitive acts were directed toward eliminating the middleware threat to the Microsoft OS. However, by its nature, the proposed decree must be forward looking, and this requirement imposes challenges as to how middleware should be defined. As the appellate court noted, “[s]ix years has passed since Microsoft engaged in the first conduct plaintiffs alleged to be anticompetitive. And as the record in this case indicates, six years seems like an eternity in the computer industry.”18 The anticompetitive actions taken by Microsoft targeted the middleware threat posed by the Netscape Web browser and Java.19 However, there is general agreement that Microsoft has won the “browser war.” Relief focusing only on this threat is thus likely to be ineffective. Moreover, the characteristics of middleware products today focus not on access to the Internet but on the range of offerings that access to the Internet can provide. Thus, middleware is properly defined in the proposed decree to encompass present and future middleware threats. In particular, middleware is broadly defined in the SRPFJ to capture almost any software that exposes a range of APIs. For example, as defined, middleware captures Internet browsers, email client software, networked audio/video client software, and instant messaging software. 18. As shown in Table Two, to stop the unlawful conduct found by the appellate court, the SRPFJ targets Microsoft’s business practices by broadly banning exclusive dealing, providing OEMs more control of the desktop and initial boot 18 United States v. Microsoft Corp., 253 F.3d 34, 6 (D.C. Cir. June 28, 2001). 19 See, e.g., May 1998 Sibley Decl. at ¶¶ 18-19. 12 sequences, and prohibiting retaliatory conduct by Microsoft. The remedy for preventing recurrence of that conduct consists of provisions for non-discrimination and nonretaliation. With regard to lost competition, the SRPFJ seeks to restore the potential middleware threat. This is to be accomplished primarily through provisions requiring API disclosure and the licensing of communication protocols embedded in the OS. This will enable independent software developers to more effectively interoperate with Windows and thus compete with the middleware functionality offered by Microsoft. Middleware developers are also aided by (1) the requirement that Microsoft create and preserve default settings when Windows launches or invokes rival middleware in certain cases, and (2) the requirement that Microsoft create “add/delete” functionality that makes it easier for OEMs and users to replace end-user access to Microsoft Middleware functionality with rival middleware. 13 TABLE TWO SUMMARY OF SRPFJ PROVISIONS Provision Section in SRPFJ Remedy to Stop Offending Conduct Prohibits retaliatory conduct III.A.1-3 III.F.1 Broadly bans exclusive dealing II.F.2 III.G.1-2 Provides OEMs more control of desktop and initial boot sequence III.C.1-6 Remedy to Prevent Recurrence III.A.1-3, III.B.1-3 III.F.1 Non-discrimination and non-retaliation provisions Remedy to Restore Competitive Conditions If Microsoft middleware products rely on an API, then that API must be disclosed. Microsoft required to create and preserve default settings, such that certain of Microsoft’s integrated middleware functions will not be able to over-ride the selection of third-party middleware products. Microsoft required to create add/delete functionality that makes it easier for OEMs and users to replace Microsoft middleware functionality with independently developed middleware. Microsoft required to license communications protocols embedded in the OS, but the company’s ability to deploy proprietary technology provided separately is preserved. 19. III.D III.I III.H.2 III.H.1 III.E III.I III.J.1-2 The difficult task is to create a balanced remedy that constrains anticompetitive behavior by Microsoft without limiting competition on the merits. Thus, in developing an antitrust remedy in this case, it is necessary to balance two broad factors: (1) the need to impose constraints on Microsoft’s current and future behavior so that the unlawful business practices stop and do not recur, and competitive conditions are restored and (2) the requirement that these constraints not be so intrusive and complex that they themselves distort market outcomes. 20. By focusing on Microsoft’s anticompetitive business practices, the provisions in the SRPFJ eliminate the artificial barriers to entry erected by Microsoft that are the source of competitive concern. The provisions in the proposed decree aim to 14 deter conduct that (1) seeks exclusivity or (2) is backed by retaliatory threats. The SRPFJ also aims to restore and enhance competitive conditions by removing technical barriers to competition between Microsoft and rival middleware suppliers. As discussed above, from an economic standpoint, middleware is important because it can expose APIs and has the potential to become an applications platform distinct from the Windows OS. 21. At the same time, the SRPFJ does not attempt to preordain market outcomes or to weaken Microsoft as a legitimate competitor. Overly broad remedies can create socially wasteful costs by eliminating efficiencies, and remedies designed to “manage” the competitive process can indirectly reduce consumer welfare. In particular, over-extensive government regulation of Microsoft may result in inefficient rent-seeking by Microsoft’s competitors,20 and make Microsoft a less efficient competitor. As discussed below, in my opinion, the SRPFJ achieves the right balance. III. Economic Analysis of the SRPFJ in Light of the Tunney Act Requirements 22. It is my understanding that key components of the public interest standard of the Tunney Act are satisfied when the antitrust remedy is sufficient to (1) stop the offending conduct, (2) prevent its recurrence, and (3) restore competitive conditions. In this section, I examine the extent to which the SRPFJ satisfies this three-part test. In so doing, I respond to many of the thoughtful comments on the proposed decree that were submitted during the public comment period recently concluded. 20 Rent seeking involves the use of real resources to obtain favorable treatment or rules. 15 A. Does the SRPFJ Stop the Offending Conduct? 23. To answer this question it is first necessary to review both the specific acts of Microsoft that were held to be anticompetitive and the linkage between those acts and the provisions in the SRPFJ. Table Three identifies the twenty specific acts related to the monopoly maintenance claim that were found to be anticompetitive by the District Court and the twelve claims upheld by the appellate court. The right-hand column of Table Three presents the provisions in the SRPFJ that I believe likely would effectively prevent those acts from occurring. I begin my analysis by examining the acts of Microsoft found to be unlawful by the appellate court. 24. Prohibition on OEM removing desktop icons, shortcuts, or Start Menu entries. If the SRPFJ had been in effect when Microsoft imposed this requirement on OEMs, Microsoft would have been in violation of Section III.H.1.a of the proposed decree. This section of the SRPFJ specifically allows either end users or OEMs to enable or remove access to each Middleware Product by displaying or removing icons, shortcuts, or menu entries anywhere in a Windows Operating System Product that a list of icons, shortcuts, or menu entries is normally displayed. According to the SRPFJ, the mechanism that accomplishes this task must be readily accessible from the desktop or the Start Menu entries, and it must be available to OEMs using standard pre-installation kits. 16 TABLE THREE PROVISIONS IN SRPFJ THAT ADDRESS ANTICOMPETITIVE ACTS Appellate Court Agreement? Addressed in SRPFJ Section 1. Prohibition on OEM removing desktop icons, folders, or Start Menu entries. Yes III.H.1 2. Prohibition on OEM altering initial boot sequence. Yes III.C.3-5 Anticompetitive Findings of District Court Agreements with OEMs 3. Prohibition on OEM allowing alternative user interface to launch automatically. 4. Prohibition on OEM adding icons or folders in different size or shape. 5. Prohibition on OEM using Active Desktop to promote others’ products. No Yes III.C.1-2 III.H.3 Yes III.C.1-2 Yes III.H.1 No III.H.2 Yes III.C.1 III.H.1 Binding of IE to Windows 6. Excluding IE from the “Add/Remove” utility 7. Designing Windows to override users’ choice of default browser other than IE. 8. Commingling code to eliminate OEM choice of removal of IE from Windows Agreements with IAPs 9. Licensing IE for free No 10. Payment for use of IE with IAP service signup No 11. Developing IE Access Kits and offering them for free No 12. Placement of IAP’s product on desktop in return for IE Exclusivity (or limit to Navigator shipments) Yes III.G.1-2 No III.G.1-2 Yes III.F.2 III.G.1 Yes III.F.1-2 III.G.1 Agreements with ICPs, ISVs, and Apple 13. Exclusive agreements with ICPs 14. Agreements with ISVs to make IE the default hypertext user interface 15. Threat to end support of Office on MAC platform as “a club” to coerce Apple to use IE as default browser with MAC OS Efforts to Contain and Subvert Java 16. Design of Java Virtual Machine (“JVM”) that was incompatible with Sun’s product. No 17. Exclusive agreements to promote Microsoft’s JVM Yes III.F.2 III.G.1 18. Deceived Java developers about Windows-specific nature in Microsoft Java tools Yes III.D 19. Coerced Intel to stop aiding Sun by threats to support AMD Yes Course of Conduct 20. Apart from specific acts, Microsoft’s general course of conduct violated Section 2 of the Sherman Act 17 No III.F.1-2 25. Prohibition on OEM altering the initial boot sequence. This Microsoft prohibition would have violated Sections III.C.3-5 of the proposed decree. These sections require that OEMs be allowed to alter the initial boot sequence in certain ways to promote rival middleware. Section III.C.3 allows OEMs to launch rival middleware in place of a Microsoft Middleware Product at the end of the initial boot sequence. Section III.C.4 allows OEMs to offer machines that dual boot to two different operating systems. Section III.C.5 allows OEMs to present Internet access offers which may promote rival software. 26. Prohibition on OEM adding icons or folders in different size or shape. Microsoft began to impose this restriction, which was intended to prevent OEMs from pre-installing Netscape Navigator, in its first Windows 95 contracts. Under the proposed decree, the only restrictions that Microsoft would now be able to place on the icons, shortcuts, and menu entries placed by an OEM are those described in Section III.C.1-2. These sections state that Microsoft can restrict the OEM from placing such icons, shortcuts, and menu entries in any list in Windows that is described in the Windows documentation as being for particular types of functions. These provisions would, however, apply also to Microsoft’s own placement of icons, menu entries, and shortcuts and do not restrict the OEM from choosing the size and shape of its shortcuts.21 27. I note that Section III.H.3 of the SRPFJ is also relevant with regard to Microsoft’s prohibition against the addition of OEM-specified icons, shortcuts, and menu entries. This section states that Microsoft cannot alter an OEM’s desktop configuration 21 The size and shape of an icon is fixed and cannot be changed by the OEM or Microsoft. Section III.C.2 prohibits Microsoft from restricting the OEM’s selection of the size and shape of shortcuts, including shortcuts placed on the desktop. 18 of icons, etc. without end-user actions, and, in any case, it cannot even ask the user to undertake such action for fourteen days after the initial boot. Based on my reading of the Competitive Impact Statement (which serves as an explanation of SRPFJ provisions) and on conversations with personnel from the DOJ, the only existing Microsoft technology to which this section refers is the Desktop Cleanup Wizard, which currently exists only on Windows XP. The Desktop Cleanup Wizard simply asks the end user if he or she wants to retain infrequently-used icons on the desktop, whether or not these icons refer to rival software. The SRPFJ requires that it treat Microsoft and Non-Microsoft icons in an unbiased manner. 28. Prohibition on OEMs using Active Desktop to promote others’ products. It is my understanding that this prohibition is no longer a relevant concern because the Active Desktop is no longer significantly in use. Indeed, I note that the Microsoft preinstallation kit for Windows XP instructs the OEM not to activate the Active Desktop. However, should features similar to the Active Desktop exist in the future, Sections III.C.1-2 would prevent similar types of restrictions by providing OEMs more control and flexibility over the desktop. 29. Exclusion of Internet Explorer from the “Add/Remove” utility. This violation would clearly have been prevented by Section III.H.1 of the proposed decree. Section III.H.1 requires Microsoft to allow the removal of the means of access to Microsoft Middleware Products. 30. Commingling of code to eliminate OEM choice of removal of IE from Windows. This offense is addressed by Sections III.H.1 and III.C.1 of the proposed decree. Section III.H.1 requires Microsoft to allow the removal of the means of end-user 19 access to Microsoft Middleware Products, which would include IE. Section III.C.1 allows the OEM to install and display icons, shortcuts, and menu entries that facilitate easy end-user access to middleware offered by Microsoft rivals. From the standpoint of most end-users, a software product, such as a browser, has been removed and is not present if there are no visible means to access it. Accordingly, Section III.C.1 and III.H.1 together enable the OEM or end user to select another browser as the default browser, without IE being visible to the end user. I do not interpret the appellate court decision as requiring that code internal to Windows be removed without regard to the competitive significance of its removal merely because it is also used in Web browsing. The appellate court stated that such removal of code would be needed if such removal was required to permit OEMs to remove the means of access to Microsoft products, since their inability to do so resulted in the exclusion of rival products. Thus, because the SRPFJ requires Microsoft to make it possible for OEMs effectively to remove Microsoft Middleware Products by removing access to them and to install rival products, the actual removal of code is not necessary. 31. Placement of an IAP’s product on the desktop in return for IE exclusivity (or limit to Navigator shipments). This offense would have been prevented by Sections III.G.1 and III.G.2 of the proposed decree. With one exception, these sections prevent Microsoft from entering into an agreement with any IAP, ICP, ISV, independent hardware vendor (“IHV”), or OEM requiring either exclusivity for a Microsoft Middleware product or that such software be distributed in a fixed percentage, irrespective of consumer choice. The exception is that fixed percentage agreements that provide Microsoft preferential status are permitted under the SRPFJ as long as it is 20 commercially feasible for the OEM, IAP, etc. to give equivalent treatment to rival middleware. When preferential status for Microsoft necessarily excludes rival middleware, Section III.G.1 implies that preferential status from Microsoft cannot extend to more than fifty percent of the shipments of the OEM, IAP, etc. Also, Microsoft cannot grant an IAP or ICP placement on the desktop or any other favored place in Windows in return for the IAP or ICP refraining from distributing, promoting, or using any software that competes with Microsoft Middleware. 32. Agreements with ISVs to make IE the default hypertext user interface. Such exclusive agreements are ruled out by Sections III.F.2, and III.G.1. Section III.F.2 prevents Microsoft from rewarding ISVs for refraining from developing, promoting, or using software that competes with Microsoft middleware and operating systems. Provision III.G.1 prohibits Microsoft from entering into agreements which give Microsoft preferential status (e.g., fixed percentage agreements) when an ISV or IHV is unable to offer an equivalent status to a rival product. Fixed percentage agreements are permissible, however, when it is commercially feasible for the other party to the agreement to provide at least the same level of promotion to the rival middleware. 33. Threat to end support of Office on MAC platform as “a club” to coerce Apple to use IE as default browser with MAC OS. For the purpose of the SRPFJ, Apple is considered an ISV. One of the historical incidents involving Microsoft and Apple was that Microsoft threatened to end the support of Office on the MAC platform if Apple continued to promote Netscape’s Web browser. Section III.F.1 forbids retaliation of the kind Microsoft threatened. This restriction would have rendered the threat itself ineffective. Microsoft also signed an agreement with Apple which ported Office to the 21 MAC and made IE the default browser and relegated Netscape’s browser to a folder. This agreement would have violated Section III.F.2 because it represented consideration in return for Apple’s refraining from promoting the Netscape browser. Finally, because Apple could not have made both IE and Navigator the default browser on the MAC, the agreement would have violated Section III.G.1. 34. Exclusive agreements to promote Microsoft’s JVM. These agreements between Microsoft and ISVs gave those ISVs advance information on new Microsoft APIs in return for writing to the Microsoft version of the Java Virtual Machine (“JVM”). Section III.F.2 would have prevented Microsoft from offering the ISV consideration, in the form of advance information, in return for promoting the Microsoft JVM over the Sun JVM. Section III.G.1 would also block such a transaction since the ISVs were being asked to promote the Microsoft JVM exclusively. 35. Deception of Java developers regarding the Windows-specific nature of Microsoft Java. To the extent that such deceit on the part of Microsoft involved the disclosure of additional APIs developed by Microsoft for its JVM that worked only on Windows, this behavior would have been blocked by the API disclosure requirement of Section III.D. However, I see nothing in the SRPFJ that speaks directly to the issue of deceit. 36. Coerced Intel to stop aiding Sun by threats of support to AMD. Microsoft’s interaction with Intel in this regard contained a threat. Section III.F.1 forbids retaliation against an IHV, so that had the SRPFJ been available at the time, the threat of retaliation would have been without force. Section III.F.2 would have been invoked by the Microsoft offer of consideration, which essentially took the form of increased support 22 for Intel’s microprocessors. Thus, this conduct would have been prevented by the SRPFJ. 37. In addition to likely preventing the anticompetitive acts upheld as illegal by the appellate court, the SRPFJ also provides at least partial protection with regard to two Microsoft behaviors found to be unlawful by the District Court but not upheld as such on appeal. (See Table One, items 7, and 13.) In this regard, the SRPFJ addresses actions that go beyond the violations upheld by the appellate court. 38. Designing Windows to override a user’s choice of default browser other than IE. Section III.H provides partial protection against this act. To restore this access would take positive action by the end user and could not be initiated and completed by Microsoft otherwise. Section III.H.2 allows end users and OEMs to select a Non- Microsoft Middleware Product to be launched automatically whenever the Microsoft Middleware would have been launched in a Top-Level Window and have displayed either all of the user interface elements or the trademark of the Microsoft Middleware Product.22 This requirement forces Microsoft to have default in some circumstances and provides a “bright line” rule in a situation where previously Microsoft had complete discretion. 39. Exclusive agreements with ICPs. Although the appellate court did not find these agreements to be unlawful, Section III.G.1 of the proposed settlement prevents exclusive and “fixed percentage” agreements for Microsoft Middleware products with ICPs. In addition, Section III.G.2 outlaws an exchange of placement of the ICP’s icon on 22 The term “Non-Microsoft Middleware Product” is used only in Section III.H of the SRPFJ, and my use of the term applies only in reference to that section of the proposed decree. Elsewhere, I use the term “rival middleware.” 23 the desktop for the ICP refraining from using, distributing, or promoting middleware offered by Microsoft’s rivals. 40. Based on the above analysis, I conclude that the SRPFJ is likely to stop effectively the Microsoft conduct found to be unlawful by the appellate court. The proposed decree also is likely to address two areas that were originally found to be unlawful by the District Court but reversed on appeal. B. Does the SRPFJ Prevent Recurrence of the Offending Conduct? 41. In addition to preventing the recurrence of acts similar to those that occurred in the past, the SRPFJ contains provisions to guard against future acts that differ substantially from those listed in Table Three but would also be anticompetitive. The SRPFJ identifies non-Microsoft products whose distribution and usage cannot be impeded by Microsoft’s actions. Covered products, such as Microsoft Middleware Products, are described in terms of their general functionalities and not just with reference to specific products now commercially available. 42. In particular, “Microsoft Middleware Product” is broadly defined in the decree to cover the functionality provided by Internet Explorer, Microsoft’s Java Virtual Machine, Windows Media Player, Windows Messenger, Outlook Express, as well as their successors. In addition, new and yet-undreamed-of products in the general categories of Internet browsers, email client software, networked client audio/video client software, and instant messaging software are also covered. The SRPFJ also covers any new Microsoft Middleware distributed separately from a Windows Operating System Product that is similar to the functionality of a rival middleware product and is either trademarked or distributed by Microsoft as a major version of a Microsoft Middleware 24 Product. In this last category, the new Microsoft Middleware Product need not even be something currently recognized as middleware. This definition is not perfectly general, and it is possible to imagine future Microsoft products that would not fall under this definition but nevertheless would still compete with rival middleware. However, the middleware definition does appear broad enough to capture the types of middleware threats most likely to emerge during the term of the proposed decree. Similarly, provisions in the proposed decree regarding non-discrimination and non-retaliation (i.e., Sections III.A, III.B, and III.F) are broad and go beyond the specific acts found to be unlawful by the appellate court. 43. During the effective period of the decree, the Technical Committee and other compliance and enforcement measures set out in the SRPFJ should work to prevent a recurrence of the offending acts. However, before reaching a conclusion about the SRPFJ’s compliance with this part of the Tunney Act’s requirements, there remains the issue of possible “loopholes” and “overly-broad exclusions,” which was commented upon in many thoughtful submissions provided during the public comment period just concluded. I will discuss below those comments pertaining to provisions in the SRPFJ that are intended to prevent recurrence of acts such as those described at trial, in the general areas of retaliation and exclusive dealing. (Potential loopholes in the general area of disclosure of APIs and other technical interfaces are discussed in Section III.C of this document.) 44. Claimed Loopholes. The SRPFJ contains various provisions (Sections III.A and III.F) that protect parties from retaliation by Microsoft in those cases involving a middleware product that competes with a Microsoft Middleware Product and operating 25 system. These provisions do not address explicitly the possibility that Microsoft may have a competitive concern involving rival middleware that has no counterpart at present among Microsoft’s suite of middleware products. In this situation, Microsoft might retaliate against an OEM, ISV, or IHV that supported the product in question, perhaps to prevent it from ever becoming a serious threat to its OS monopoly. However, there are several reasons why this is unlikely to occur. 45. First, this action would be blocked by Section III.A.1, which forbids Microsoft from retaliating against an OEM supporting, or contemplating supporting, any rival software that competes with Microsoft Platform Software whether or not Microsoft has a counterpart to the rival software. Section III.F.1 contains similar protection for ISVs and IHVs. While it is not possible at first glance to rule out the occurrence of such an event, further analysis suggests that such an event is unlikely to occur. This is because as discussed in Section II above, Microsoft’s strength is derived from having an operating system that runs many applications, and, in the past, Microsoft has consistently supported applications that do not compete with its own applications. The Microsoft Software Developer’s Network and the many developer seminars that Microsoft sponsors are evidence in support of this position. Second, if Microsoft were to adopt this strategy, the strategy itself would impose a cost on Microsoft in that the company would have to refrain from developing its own version of the threatening software. This would encourage other, non-Microsoft developers to produce another version of the competing product and end-users to use the non-Microsoft middleware product. Also, there remains the issue of exactly how Microsoft would retaliate and against whom. 26 46. Previously, Microsoft has retaliated against OEMs by charging uncooperative OEMs a higher price for Windows. However, this form of retaliation is ruled out by Section III.B, which requires that OEMs pay royalties pursuant to uniform license agreements that can be viewed by other OEMs and by the plaintiffs for monitoring purposes. If retaliation were to take the form of manipulation of other types of consideration (e.g., MDA discounts), such action would make it impossible for Microsoft to comply with Section III.B.3.a of the proposed decree, which states that such discounts must be offered to all covered OEMs, including OEMs that cooperate with Microsoft. 47. Based on Microsoft’s past practices, Microsoft might withhold APIs, documentation, or access to communications and security protocols. Such behavior is likely to be an ineffective means of retaliation or control. There are thousands of published APIs, and the very existence of a Non-Microsoft Middleware Product that prompts retaliation implies such a product was built around published APIs and technologies, in addition to whatever its developer may have invented and embodied in the product. Attempting to manipulate these APIs would invariably harm products that are complementary to the Microsoft OS and enhance its value. For all these reasons, I believe that Microsoft’s incentives would be not to retaliate against an ISV regarding a product without a Microsoft counterpart. In my opinion, reliance on incentives will be superior, in this instance, to detailed regulation. 48. A second possible loophole is that Microsoft could provide special treatment or discriminatory prices on other (non-middleware) products as rewards or retaliation, presumably for a third party’s favoring or impeding a Non-Microsoft 27 Middleware product. (See Declaration of Joseph Stiglitz and Jason Furman, hereafter “Stiglitz and Furman Decl.” at 31, and Declaration of Kenneth J. Arrow, hereinafter “Arrow Decl.,” at ¶ 41.) Regarding special treatment, I note that if such treatment refers to non-monetary consideration of some kind, this behavior would be ruled out by Section III.A.1 of the proposed decree. This section of the SRPFJ prohibits Microsoft from retaliating against or withholding newly developed forms of non-monetary compensation from an OEM because the OEM is developing, promoting, or using software that competes with Microsoft Platform Software. 49. I also consider the possibility that special treatment might take the form of monetary discounts on other Microsoft products, such as Microsoft Office. I will assume that the alleged discrimination takes the form of requiring the OEM to establish the Microsoft Middleware Product as the default on all of its computers. This action violates Section III.A.1 and III.A.3 because linking the price of Office to an OEM’s promotion of rival middleware would represent an alteration in Microsoft’s commercial relationship with that OEM in connection with that OEM’s promotion of rival middleware, and the withholding of such a discount would occur because it was known to Microsoft that the OEM was exercising options provided for by Section III.H (e.g., making rival middleware the default). Furthermore, this would be a case of preferential treatment within the meaning of Section III.G. Since only one middleware product in a given category can by definition be the default on a given computer, the OEM could not represent that it was commercially feasible for it to give greater or equal distribution to the Non-Microsoft Middleware Product. 28 50. The third loophole cited in the comments pertains to Section III.A and the process that governs how Microsoft must proceed if it wants to terminate dealings with an OEM. In the past, Microsoft has had the ability to cancel an OEM’s Windows license without prior notice. The SRPFJ adds constraints to Microsoft’s ability to terminate an OEM. The SRPFJ requires that Microsoft provide any one of the top twenty OEMs (defined by volume) written notice of its intent to cancel, in which it must specify the deficiency prompting the cancellation, as well as a 30-day opportunity to cure the deficiency. Because Microsoft must provide a reason in the written notice and an opportunity for a cure, it obviously cannot terminate an OEM for conduct authorized under the SRPFJ. Again, Microsoft does not have to do this currently. Because Microsoft cannot terminate an OEM’s license for conduct consistent with the SRPFJ, the presumption is that, if an OEM is terminated, the cause must be related to a normal commercial dispute. Viewed in this light, I do not agree with Stiglitz and Furman when they allege that Section III.A provides Microsoft “substantial leverage” to force an OEM to distort its choice among competing middleware products. (See Stiglitz and Furman Decl. at 31-32.) I do not believe that detailed regulation would achieve a better outcome. 51. This discussion has summarized the major comments on the SRPFJ Sections III.A, III.B, and III.F as they relate to retaliation and discrimination. On balance, I conclude that these provisions are likely to fulfill the Tunney Act requirement that the SRPFJ prevent a recurrence of the offending conduct. C. Will the SRPFJ Restore Competitive Conditions? 52. As discussed above, the SRPFJ’s focus is on restoring the competitive threat provided by middleware (see Table Two). This is accomplished by providing 29 middleware developers the means to create competitive products through: (1) provisions for API disclosure; (2) provisions that require Microsoft to create and preserve default settings, such that Microsoft’s integrated middleware functions will not be able to override the selection of third-party middleware; (3) the creation of “add/delete” functionality that make it easier for OEMs and end-users to replace Microsoft middleware functionality with independently developed middleware; and (4) requirements for Microsoft to license communications protocols embedded in the OS while maintaining Microsoft’s ability to deploy proprietary technology provided separately. These provisions are discussed more fully below. 53. The SRPFJ requires Microsoft to release certain types of technical information to rival middleware suppliers. This information is to be provided in order to enable rival software developers to configure their products so that they are able to use the same Windows capabilities that Microsoft Middleware uses. To better evaluate these provisions, recall from above that Microsoft has published thousands of APIs, which are used by software developers to allow their products to run on Windows. Microsoft rivals (e.g., RealNetworks) use those APIs to build products to run on Windows and compete with Microsoft products. Microsoft has many more APIs that it does not publish or otherwise make available to ISVs. Potentially, some of these unpublished APIs give Microsoft products capabilities or features that rival products cannot easily duplicate. When these APIs are used by Microsoft Middleware Products, the SRPFJ obliges Microsoft to disclose them to ISVs, IHVs, IAPs, ICPs, and OEMs meeting certain requirements. The same obligation applies to certain types of communications protocols and security features developed by Microsoft that are used in connection with its Window 30 Operating System products. The sections of the SRPFJ dealing with technical disclosure are III.D, III.E, III.I, and III.J. 54. The API disclosure provisions of the SRPFJ have attracted perhaps more comments than any others in the proposed decree. Criticisms of these provisions generally follow two lines of argument: (1) the proposed decree provides too much latitude, enabling Microsoft to delay the release of APIs until a Microsoft product has a decisive first-mover advantage over the competition; and (2) Microsoft could evade the intent of the proposed decree and avoid releasing this information at all. I will first describe the relevant sections of the SRPFJ dealing with the API disclosure provisions and then evaluate their likely effectiveness. 1. 55. API Disclosure and Communications Protocol Provisions Section III.D of the proposed decree specifies the main process for releasing the APIs and the documentation used by Microsoft Middleware to interoperate with Windows. Starting with the release of Service Pack 1 for Windows XP or twelve months after the submission of the SRPFJ to the Court (whichever is earlier), Microsoft must disclose APIs and documentation used in association with Microsoft Middleware. Going forward, there are to be disclosures occurring in a “Timely Manner” whenever there is a new version of a Windows operating system product or a new major version of Microsoft Middleware.23 56. Section III.E pertains to the use of Microsoft’s client-server communications protocols. It does not apply to the use of communications protocols 23 The term “Timely Manner,” which governs the release date of APIs pursuant to Section III.D, means the time Microsoft first releases a beta version of a Windows Operating System Product, either through the MSDN or with a distribution of 150,000 or more copies. 31 between other types of Microsoft products. The basis for the client-server focus is that there is now a growing number of applications that run on servers, rather than on the desktop. I discussed this factor in my May 1998 Declaration.24 It represents a strong source of competition to Microsoft in the business computing segment and may yet make a serious attack on the applications barrier to entry in the desktop PC market. Therefore, it is important that rival middleware be able to operate with Microsoft server operating systems. It is equally important that a non-Microsoft server be able to operate with Windows as efficiently as would a Microsoft server. Communications protocols are essential for that purpose and are just as necessary to rival middleware developers as is access to Windows APIs. By contrast, I have not yet seen an argument that clearly articulates why the applications barrier to entry would be threatened by the disclosure by Microsoft of communications between other types of Microsoft software. 57. Under Section III.E, starting nine months after the submission of the SRPFJ to the Court, Microsoft shall make available to qualifying third parties any communications protocol implemented in a Windows Operating System Product (on or after the date of SRPFJ submission), installed on a client and used to interoperate or communicate with a Microsoft server operating system product. This will have both of the effects discussed above. It will enable rival middleware to communicate with a Microsoft server and also will allow a non-Microsoft server operating system to communicate effectively with a Windows operating system. To protect Microsoft intellectual property rights, Microsoft may charge for the use of these protocols as long as it does so on “reasonable and non-discriminatory terms.” (See SRPFJ at Section III.E.) 24 See May 1998 Sibley Decl. at ¶ 19. 32 Section III.E also references Section III.I, which says that Microsoft must offer to license any intellectual property that it owns and that is needed to allow ISVs, IHVs, IAPs, ICPs, or OEMs to exercise their rights under the SRPFJ. The SRPFJ also states that all terms governing payment must be reasonable and non-discriminatory. 58. Section III.J can be viewed as “carving out” exceptions to Section III.D and III.E. Section III.J.1 states that Microsoft cannot be required to disclose portions of APIs, documentation, or portions of communications protocols if disclosure would “compromise the security of a particular installation or group of installations” in the general areas of anti-piracy, anti-virus, software licensing, digital rights, encryption, or authentication systems, “including, without limitation, keys, authorization tokens or enforcement criteria.” (See SRPFJ at Section III.J.1.) Section III.J.2 similarly allows Microsoft to condition the licensing of any API, documentation, or communications protocol relating to anti-piracy, anti-virus, license enforcement mechanisms, authentication/authorization security, or third party IP protection. Microsoft may require that a licensee: (a) have no history of software piracy, counterfeiting, etc.; (b) have a “reasonable business need” for the API, documentation, or communications protocol for a planned or shipped product; (c) meets “reasonable, objective standards” established by Microsoft for certifying the authenticity and viability of its business; and (d) agrees to have a third party verify that its product complies with the technical specifications for whatever Microsoft APIs or interfaces it may use. 59. Before evaluating these sections of the SRPFJ, one observation is in order. The API disclosure required under Section III.D is triggered by the existence of Microsoft Middleware, meaning that a version of a Microsoft Middleware Product is 33 distributed apart from the operating system. Thus, if Microsoft bundles a piece of middleware with the operating system and does not distribute this middleware in some other way (e.g., by download), then Microsoft need not disclose the APIs used by that piece of middleware. There is a current example of this situation: Windows Media Player version 8.0 is available only with Windows XP. Therefore, Microsoft under the SRPFJ does not have to disclose the APIs applicable to Windows Media Player version 8.0. However, as discussed below, it would be impractical for Microsoft to affect competition in this way. 2. Comments Regarding API Disclosure and Communications Protocol Provisions 60. This group of decree provisions attracted a large number of thoughtful comments. Rather than address all of the commentators, I will discuss the major comments which tend to recur in the various submissions. As noted above, a potential loophole in the SRPFJ is that Microsoft’s disclosure obligations only begin when it distributes a piece of middleware separately from the operating system. If Microsoft chooses to bundle this product and does not create a redistributable version, the APIs used by that product need not be disclosed. (See Stiglitz and Furman Decl. at 29-30, and Comment of Rebecca M. Henderson (hereinafter “Henderson Comment”) at 5-6, and 9, and Comments of Software Information Industry Association at 26.) In theory, this feature of the SRPFJ could allow Microsoft to avoid disclosing APIs on new products and major new versions of current products. 61. In my opinion, this concern has little practical significance. If Microsoft were to follow such a strategy as a matter of broad policy to deter competition, it would come at a high price. First, none of the installed base of Windows users would have the 34 new product, which alone would impose a large cost on Microsoft, if the product’s use were at all competitively significant, as was the case in 1995 with the browser. Second, since competing providers would continue to innovate, as RealNetworks has done, at some point Microsoft would face the danger (since most users tend not to replace their operating system readily) that the Windows user’s best option becomes obtaining the relevant piece of middleware from Microsoft’s competition. Had Microsoft refrained from any separate distribution of IE in 1995, the effect would have been to solidify Netscape’s hold on the browser market. Third, this problem is substantive only if the bundled Microsoft product uses an API that is not published. Even then, there are thousands of published APIs to which competing ISVs can and do write. RealNetworks, for example, has always written to these publicly available APIs, unless it could persuade Microsoft to produce or reveal a particular proprietary API. Based on the comments submitted by RealNetworks in this proceeding, its main API concern is not over unpublished APIs that only Windows Media Player 8.0 may use (if any), but about the Secure Audio Path API, sometimes called SAP. This API is used by a previous version of Windows Media Player that was distributed separately from the operating system, so Microsoft will have to disclose SAP under the SRPFJ. For these reasons, I do not believe that the ability of Microsoft to withhold API disclosure by a bundling-only strategy is likely to lead to significant competitive harm. 62. The definition of “Non-Microsoft Middleware Product” has also been criticized because of the requirement that the middleware product have had at least one million copies distributed in the previous year. For example, RealNetworks objected to this as “a huge number of copies . . . that will take a great deal of time, money and 35 resources for most middleware companies to reach.” (See Comments of RealNetworks, at 13, and Comments of SBC at 40-41.) The comments of RealNetworks also note that the above definition of “Non-Microsoft Middleware Product” does not state whether new versions are to be counted separately. My understanding is that the word “product” refers for this purpose to an aggregation of versions. Thus, if in the course of a single year, version 1 of a product had 200,000 copies distributed, version 2 had 300,000 copies distributed, and version 3 had 500,000 copies distributed, it is my understanding that the product would qualify. Furthermore, the term “distributed” should not be confused with “sold.” Under my reading of the proposed decree, mass mailings of CDs (i.e., so-called “carpet-bombing”) would constitute distribution for this purpose, as would “downloads.” While one million distributed copies might have been significant in the early stages of the Internet, the recent explosive growth in the Internet and its use suggests that this requirement can be easily met by most, if not all, middleware vendors.25 63. It has been argued that the requirement that the million copy threshold must have been reached in the previous year is a further impediment, leading to the result that the “entrepreneur will begin to gain some of the settlement rights only a year after the widespread distribution of her product. She will be entitled to information about how this new product can interact with Windows only after Microsoft has imitated the innovation.”26 However, based on my reading of the SRPFJ, this concern is misplaced. 25 It is worth noting that, even in 1995, within one year of the introduction of the Mosaic browser (the first browser with a graphical user interface) there were some two million users. See Gina Smith, “Inside Silicon Valley: A High Tech Top 10 Computers & Technology,” San Francisco Chronicle (Jan. 1, 1995). 26 See Timothy F. Bresnahan, “A Remedy that Falls Short of Restoring Competition,” ANTITRUST, at 69 (Fall 2001) (hereinafter “Bresnahan Article”). 36 The million copy requirement only comes into play in Section III.H, which is the only section in which the term “Non-Microsoft Middleware Product” is used. This section is solely concerned with the ability of the end user or OEM to have a Non-Microsoft Middleware Product launch automatically or be featured on the desktop. That is, it has nothing to do with the API disclosure requirement. Furthermore, it is my understanding that, once a particular Non-Microsoft Middleware Product meets the million copy requirement and Microsoft has created a default setting, an OEM will be able to set as the default a competing product by another vendor, even if that competing product has not yet met the one million copy requirement. Thus, when RealNetworks asks, “Must [middleware distributors] accumulate one million distributions . . . before they are protected?”, it betrays a misunderstanding of this section of the proposed decree.27 64. The proposed release schedule for APIs and documentation has also attracted criticism. (See, e.g., Bresnahan Article at 69; and Stiglitz and Furman Decl. at 30.) The requirement in Section III.D is that, once the initial disclosure for Windows XP has taken place, Microsoft must disclose new APIs no later than the date of the last major beta release, if the disclosures are triggered by new Microsoft middleware, or in a “Timely Manner,” if the disclosure is triggered by a new Windows operating system product.28 Whether this is too long a period of time or not appears to depend on the case at hand. For an API to be published by Microsoft, it must first be “hardened,” which means that it must undergo an extensive testing procedure to make sure that it works in different programming environments and in the hands of developers who may not use it 27 28 See Comments of RealNetworks at 14. See definition VI.R in the SRPFJ. 37 in the same way that Microsoft does. If an API has been developed for a Microsoft Middleware Product and has not been hardened, it may well take some period of time before it can usefully be disclosed to ISVs and others. On the other hand, if that Microsoft Middleware Product uses APIs that have been published or that have been hardened, then the process would likely be much shorter. Thus, the appropriate disclosure period would depend on the case at hand, and my own expertise as an economist does not qualify me to opine further. I note, however, that alternatives to the SRPFJ on this matter do not appear to represent a clear improvement. For example, one alternative would be for Microsoft to disclose APIs tentatively at an earlier stage, subject to the understanding that further testing might cause Microsoft to change them. In this case, a software developer, OEM or other party that uses Microsoft APIs may have earlier access to them but may well feel reluctant to make extensive use of a very preliminary list of APIs, knowing that Microsoft may make changes at a later date. From Microsoft’s standpoint, to release APIs that are only preliminary could pose legitimate risks. If Microsoft were to release a tentative new API at the alpha testing stage and were to change the API at a later date, even a Microsoft disclaimer could leave Microsoft open to charges that it was changing APIs throughout the testing process in order to deceive and manipulate. Indeed, the disclaimer would almost indemnify Microsoft for such manipulation. Its precise reasons for changing the API would then lead to litigation. For these reasons, it is unclear that preliminary, earlier disclosure is an obvious improvement to the provisions currently embodied in the SRPFJ. Indeed, it would probably extend regulation into the testing process, which seems likely to reduce and distort innovation in APIs. 38 65. Other features of the proposed API disclosure process that have drawn comment include the limitations contained in Section III.J. For example, Professor Bresnahan states that the settlement “overbroadly exempts the most competitively important protocols such as security, authentication and identity protocols.” (Bresnahan Article at 68.) The same concern is expressed by Stiglitz and Furman. (See Stiglitz and Furman Decl. at 30.) These fears are unfounded, based on my understanding of the SRPFJ. In particular, I observe that Section III.J.1 exempts from disclosure portions or layers of APIs, documentation, and protocols that, if disclosed, would compromise the security of a particular actual installation. The exemption, as described in the CIS, “is limited to specific end-user implementations of security items such as keys, authorization tokens or enforcement criteria.” (See CIS at 51.) That is, the SRPFJ only limits disclosure of specific end-user implementation of security features. For example, Microsoft would not have to disclose the actual key used by an actual customer. It would not need to disclose an API written especially for an actual customer, and no other. These limits appear reasonable. APIs relating to general Microsoft technologies for security, etc. must be disclosed. 66. Apart from the disclosure of APIs, there is also the issue of the disclosure of the communications protocols between Windows installed on a client and a Microsoft server. Several commentators are of the opinion that this provision is very limiting and excludes, for example, communications between hand-held computers and servers.29 As discussed above, it is not clear how including such communications (e.g., in Section III.E) would reduce Microsoft’s monopoly power. I do not see a need to extend Section 29 See, e.g., Bresnahan Article at 68; and Henderson Comment at 3 and 5-6. 39 III.E to cover non-desktop products, as proposed by the litigating states. The Microsoft operating system monopoly has always been centered on the desktop. This is why Section III.E focuses on facilitating server-based applications, which provide indirect competition to Microsoft. There is no evidence that Microsoft has monopoly power in operating systems for handheld computers, set-top boxes, etc. Indeed, the operating system sold for use in these areas, Windows CE, has been characterized by poor performance since its inception and has been out-performed by Palm OS, Blackberry, and other such competing operating systems. Similarly, Microsoft is not dominant in the server market, and it currently faces competition from servers by Linux and others. I present data confirming these claims in Section IV below. For these reasons, I am convinced that Section III.E provides the right focus. To extend Section III.E to cover additional areas would, as I have discussed, certainly increase antitrust regulation with no clear rationale or benefit. 67. There does remain the issue of how Microsoft will decide what “reasonable and non-discriminatory” charges it will set for access to these communications protocols. This is a reasonable concern that has been raised by several commentators.30 The basis for such license fees is apparently limited to intellectual property that Microsoft may have embedded in these protocols, as set out in Section III.I. Some guidance offered for what “reasonable and non-discriminatory” might mean is in the CIS, where it says that the “overarching goal of this Section is to ensure that Microsoft cannot use its intellectual property rights in such a way that undermines the competitive value of its disclosure obligations, while at the same time permitting 30 See, e.g., Bresnahan Article at 69. 40 Microsoft to take legitimate steps to prevent unauthorized use of its intellectual property.” (CIS at 49.) Presumably, any charging mechanism that excluded substantial numbers of ISVs, IAPs, ICPs, or OEMs would violate this requirement. It is my understanding that previous DOJ antitrust consent decrees imply that the term “reasonable and non-discriminatory” is likely to be interpreted as not significantly excluding competitors. On this assumption, the lack of specific rate-setting guidance in Section III.I is not likely to be a severe problem. 68. Because Section III.B does not constrain the structure or levels of the royalty schedule beyond the uniformity requirement, some commentators have expressed the concern that Microsoft might be able to stay within the confines of this provision but still price in such a way as to be anticompetitive. For example, RealNetworks opines that Microsoft could “establish the price of versions of Windows without its middleware set as the default at some artificially high price and the actual price Microsoft wanted to receive as a cash incentive to carry Microsoft’s middleware as the default application.” (See RealNetworks Comments at 27.) 69. Contrary to RealNetwork’s hypothetical, Section III.B.3.c states that Microsoft cannot discount the price of Windows based on any requirement that is inconsistent with the proposed decree. This means that Microsoft cannot offer discounts on Windows that are tied to OEMs foregoing such options as installing non-Microsoft icons pursuant to Section III.C, or setting defaults, or removing Microsoft Middleware Products pursuant to Section III.H. For instance, Microsoft cannot set the price of Windows at $500 but offer a cash discount of $450 if an OEM sets some Microsoft Middleware Product as the default. Alternatively, should Microsoft offer a direct 41 payment based on the level of support for the Microsoft Middleware Product, this would be a case of preferential treatment within the meaning of Section III.G, so that the OEM could not give Microsoft preferential status more than fifty percent of the OEM shipments. IV. Issues Not Addressed by the Proposed Decree 70. Many of the parties publicly commenting about asserted loopholes in the proposed decree also have been critical of claimed limitations to the remedy achieved by the settlement.31 In this section, I address the main suggestions for additional remedies discussed by these commentators. A. Unbundling of Microsoft Middleware from the OS. 71. An issue raised in this case is that, if Microsoft proceeds to bundle application software with the OS, an available “stripped down” version of the OS without the application in question should also be released.32 Alternatively, when Microsoft releases a new operating system, it should continue to offer the previous version at the original price. 72. This is a potentially important issue. If the OEM has to pay a positive price for a rival middleware product and pays a marginal price of zero for the same functionality bundled in the operating system, then the competitive battle is stacked against the competitor (see Arrow Decl. at ¶ 27). The critics also suggest that OEMs will 31 See generally Stiglitz and Furman Decl.; Comment of Robert E. Litan, Roger D. Noll, and William D. Nordhaus on the Revised Proposed Final Judgment (hereinafter “Litan et al.”); Arrow Decl.; and Bresnahan Article. 32 See, e.g., Arrow Decl. at ¶ 26. 42 not want to support more than one product with such functionality, even if icons were removed for the Microsoft Middleware version as permitted under the SRPFJ. With the underlying Microsoft Middleware code embedded in the system, the critics suggest that end users will still find this functionality being invoked and thus will have support concerns and needs, lessening the OEM interest in carrying the rival middleware. Further, the critics claim the availability of the commingled Microsoft Middleware code will further encourage ISVs to write applications to Microsoft products rather than to Non-Microsoft Middleware.33 Thus, these commenting economists have urged the DOJ to require the unbundling of Microsoft Middleware from Windows Operating System Products. 73. However, on closer inspection, the requirement to have an unbundled operating system is highly regulatory and is likely to lead to more litigation. For example, to determine the appropriate discount for the unbundled operating system, the general approach would necessarily involve some estimate of the costs of the Microsoft Middleware Products that are to be removed from the bundled version. Such estimates, however, are likely to be arbitrary and complex to calculate. This is because software development efforts involve substantial shared costs between projects and benefit from common overhead expenditures. For example, suppose that a given server is used for ten development projects, both middleware and non-middleware; the cost of this server 33 Arrow asserts that permitting OEMs to remove Microsoft Middleware icons but not the underlying code would further undermine OEM incentives to carry Non-Microsoft Middleware. (See Arrow Decl. at ¶ 37.) Litan et al. at 44 claim that permitted commingling of code will be fatal to the proposed decree by ensuring universal distribution of Microsoft Middleware code, which when compared to partial distribution of Non-Microsoft Middleware code will encourage continued enhancement of the applications barrier to entry. 43 would have to be allocated between projects. But such cost allocation rules are inherently arbitrary.34 Should corporate overhead be allocated between development projects for the purpose of pricing the unbundled operating system? If so, on which of the many accounting bases should it be done? How should the cost of a computer used by one individual on three different projects be allocated between them? To answer questions such as these, regulatory agencies (e.g., the Federal Communications Commission (“FCC”) and the Federal Energy Regulatory Commission (“FERC”)) evolved highly complex case law over a period of decades. Speaking as a regulatory economist with nearly three decades of experience, I can assert with confidence that such pricing of the unbundled operating system would be a regulatory quagmire at least equal in complexity to those that have kept regulatory bodies such as the FCC busy for years. 74. In its comments intended to support the notion of an unbundled operating system, SBC unintentionally discredits this proposal. In referring to the problem of pricing an unbundled version of Windows, SBC states: Several such mechanisms are possible. The Final Judgment provided that pricing be guided based on bytes of code. . . . SBC believes that it would be preferable to allocate costs between the operating system and the removed middleware based on measurement of “function point code.” . . . Alternatively, SBC supports the use of a pricing mechanism based on the fully allocated product development costs for the operating system product and middleware products in questions. (See Comments of SBC at 143). 34 See, e.g., William J. Baumol, Michael F. Koehn, and Robert D. Willing (1987), “How Arbitrary is ‘Arbitrary’? – or Toward the Deserved Demise of Full Cost Allocation,” 120 PUBLIC UTILITIES FORTNIGHTLY 16-21. 44 In this revealing passage, SBC makes it clear that because of the numerous and subtle common costs incurred in software development, each interested party would have wide scope to select and litigate for the (arbitrary) pricing mechanism that favored it the most. 75. In any case, it appears to be true that many applications on the desktop are not paid for by the OEM or (initially) by the end user. Indeed, all three of the current major Instant Messaging products are available without charge. I am aware of several instances in which third-party software applications are included by OEMs in their PC offerings, even though similar functionality is bundled by Microsoft in Windows XP. For example, Dell Computer offers photo imaging and CD “burning” software with Microsoft XP Home Edition-based PCs even though XP Home includes similar capabilities.35 Dell includes Sierra Imaging’s Image Expert 2000 software on some systems, pre-installing a premium version that is available to the end user for 60 days (an additional fee applies to retain premium features after this time limit).36 Clearly, 35 Dell systems shipped with CD-RW capability come with Roxio Easy CD Creator, a CD burner software product. A recent article in Computer Shopper addresses Windows XP’s CD mastering capabilities. See COMPUTER SHOPPER, Feb. 2002, at 131. Another article – “Windows XP Tip: My Pictures Folder,” TECHTV, Oct. 26, 2001 – reviews the photo managing capabilities Microsoft has bundled into XP. Microsoft also has a separate product, Microsoft Picture It 2002, that provides special effect and other enhanced photo management capabilities. 36 Perhaps a more significant example is RealNetworks’ RealOne media player product, comprising RealPlayer and RealJukebox, currently packaged by the OEM Sony in a Windows XP Home Edition Vaio Notebook system sold in the retail channel. In December 2001, it was also announced that Compaq will begin shipping these RealNetworks products as default media players in Presario desktop and notebook models designed for consumers. By mid-2002, Compaq will be offering the newest RealOne Player, with a RealOne icon on the desktop and memberships to the RealOne subscription services. See EDP’S WEEKLY IT MONITOR, Dec. 24, 2001. As discussed elsewhere, Windows XP bundles a similar media player product (Windows Media Player) in the operating system, and yet these OEMs provide the Non-Microsoft Middleware product as well. 45 Microsoft’s bundling does not eliminate the OEM’s incentive to use such alternative applications when they are offered under desirable arrangements. Generally in such cases, the business model of an ISV is to provide the software to the OEM for free with hope for future fees from Web services (or other services) provided to end users through the software or from potential upgrade revenue when end users desire premium versions of the product. For example, RealNetworks is pursuing such a strategy and by August or September 2001 was enjoying usage rates approximately twice that of Windows Media Player.37 RealNetworks’ momentum has continued despite the fact that a version of Windows Media Player has been bundled with every version of Windows since Windows 95. RealNetworks appears to have competed well with products produced by Microsoft and bundled in Windows.38 B. Protections Concerning Microsoft Office Practices 76. Several commentators suggest it is necessary to require Microsoft to “port” Office to other operating systems, such as Apple MAC OS and Linux. For example, Stiglitz and Furman stated a concern that the proposed decree “does not address any issues relating to the pricing, distribution, or porting of Microsoft Office.” (Stiglitz and Furman Decl. at 38.) Stiglitz and Furman and Litan et al. argue that the “porting” of Office is likely to reduce the applications barrier to entry (or at least reduce Microsoft’s ability to raise them deliberately). (See Stiglitz and Furman Decl. at 42 and Litan et al. Comment at 71-72.) I agree that this remedy would be a more direct attack on the 37 The Wall Street Journal reported (on Sep. 24, 2001) August 2001 usage figures: “28.8 million users accessed multimedia files on the Web in the RealNetworks format and 13 million did the same in Microsoft's format” (based on Internet measurement firm Netratings Inc. figures). 38 Ibid. 46 applications barrier to entry. However, Office has never been a significant part of the case brought against Microsoft. Where Office has been an issue, it relates to Microsoft’s efforts to control middleware, such as the “club” used against Apple to harm Netscape, found to be anticompetitive by the District Court and upheld by the Court of Appeals. (See Opinion at 72-74.) The SRPFJ remedies directed at ensuring that rival middleware opportunities exist and can be freely pursued should be sufficient in this regard.39 C. Network Server, Handheld Computer and Web Services Issues 77. Some commentators would prefer the antitrust remedy to extend beyond middleware and the PC environment to cover such emerging product areas as servers, handheld devices, and Web services to insure Microsoft does not extend its monopoly to dominate additional markets and erect new barriers to entry. (See Stiglitz and Furman Decl. at 38-39; Comments of SBC Communications Inc. (“SBC”) at 42-43; and Arrow Decl. at ¶¶ 55, 68-70.) Arrow, for instance, suggests that end users will access the Internet with server and handheld devices, and he concludes that the remedy should protect competing server operating systems and web services. Given Microsoft’s anticompetitive practices, he concludes it is reasonable to require parity in access to APIs, protocols, and documentation for interoperability across product areas. (See Arrow Decl at ¶¶ 55, 68-70). These remedies go well beyond the scope of the case brought against Microsoft (as well as the findings upheld by the appellate court) and also well beyond the desktop, where Microsoft has its proven monopoly. Hence, regulatory intervention is not called for in these areas, as is further addressed in the following 39 In light of the findings in this case overall and of the Court of Appeal’s condemnation of Microsoft’s conduct toward Apple regarding Office in particular, it is hard to imagine Microsoft attempting the use of the “club” again, let alone a party that would permit it without threats of litigation and complaints to regulators. 47 assessment of certain specific issues raised relating to corresponding Litigating States proposals in these product areas. 1. 78. Servers Litan et al. point to the increasing importance of client-server networks and server-based computing and conclude that a new platform entrant must not only overcome the application advantages that Microsoft illegally obtained in the desk top OS, but must also provide compatibility with “servers which are increasingly relying on Microsoft’s server operating systems” (see Litan et al. at 30.) This suggestion is at variance with the focus of the present antitrust case, which involves Microsoft’s desktop monopoly, not the server market. In addition, there is no clear monopoly issue in the server market. Microsoft’s share of server operating systems has grown from approximately 27 percent in 1996 to 41 percent in 2000. This gain has apparently come at the expense of other PC compatible network software providers (such as Novell), but not at the expense of competitors likely to be the more relevant factors in the future.40 For example, according to a 1999 estimate issued by the International Data Corporation (“IDC”), Linux’s server share more than doubled in 1998 to reach 17.2 percent.41 More recently, IDC has reported that Linux’s worldwide market share in 2000 of new and upgraded operating systems for servers had climbed to 27 percent, ranking it second 40 See Stephen Shankland, Linux Growth Underscores Threat to Microsoft, CNET NEWS.COM (Feb. 28, 2001); INFORMATIONWEEK, p. 86 (Apr. 21, 1997) (citing 1996 shares as reported by International Data Corp.). 41 Steven Brody, IDC Says Linux Likely to Lead OS Growth, SUNWORLD (Mar. 31, 1999), reproduced at http://www.linuxworld.com/linuxworld/lw-1999-03/lw-03-idc.html. 48 behind Microsoft’s share of 41 percent.42 Litan et al. acknowledge that “the Linux OS has made significant inroads into the server market,”43 while IDC confirms that, excepting Microsoft and Linux, “market share declined for other server systems, including Unix” over the past year.44 For these reasons, I do not believe the server market by itself raises any monopoly power issues. 2. 79. Handheld Computers and Web Services Similarly, some commentators are concerned that Microsoft practices will lead to dominance in operating systems for handheld devices, removing a partial threat to at least some Windows-based personal computers. This leads them to assert that the proposed decree improperly ignores this segment of the computer industry. Again, this remedy seeks a penalty outside the scope of the case. No findings were found or upheld relating to Microsoft conduct directed at handheld devices or handheld competitors. Further, the Microsoft Windows CE operating system has not been gaining systematically on competing systems over the last several years, and there is little reason to divert the focus of the SRPFJ to this area.45 42 See Elise Ackerman, Despite a Tough Road, Linux Has Never Been More Popular, SAN JOSE MERCURY NEWS (Nov. 25, 2001); Peter Galli, Battle Brews Over Linux Server Share, EWEEK (June 10, 2001), reproduced at http://zdnet.com.com/2102-11503810.html (citing also Gartner Dataquest estimates of Linux as having a share of server shipments of 6 to 8.6 percent share in third quarter 2000). 43 Litan et al. at 25. 44 COMPUTERWORLD (Feb. 26, 2001). See also Stephen Shankland, Linux Sales Surge Past Competitors, CNET NEWS.COM (Feb. 9, 2000), 45 According to Gartner figures, worldwide market share for Windows CE has been between 20 percent and 25 percent over the last four years, with no significant trend. See Final 1998 Handheld Computer Market Results, GARTNER DATAQUEST (May 17, 1999); Gartner Dataquest’s Worldwide PDA Forecast, GARTNER DATAQUEST (Dec. 11, 2000); and Handheld Computer Shipments Rebound in 4Q01, GARTNER DATAQUEST ALERT 49 D. Restoring Java as a Competitive Threat 80. Some commentators have suggested that the proposed decree should require mandatory distribution of a Sun-compatible Java runtime environment with each copy of Windows (and IE) shipped by Microsoft. Critics of the proposed decree have suggested this provision is appropriate to attempt to compensate for Sun’s lost position and lost momentum as Microsoft deceived developers and discouraged distribution and use of Sun-compliant Java. (See, e.g., Litan et al. at 25 and 71.) Stiglitz and Furman believe this would decrease the applications barrier to entry. (See Stiglitz and Furman Decl. at 42.) There is no question that the cross platform potential of Java was real, but there exists significant uncertainty as to the timing and impact that Java would have had absent Microsoft’s unlawful conduct, as discussed in the Findings of Fact. Furthermore, if there is consumer demand for PCs that come with JVMs installed, the OEMs are free to meet that demand and are protected from retaliation by Microsoft under the SRPFJ if they do so. Therefore, in my opinion, this “must carry” provision is disproportionate and will improperly preordain market outcomes. Furthermore, other platforms or products, aided by the SRPFJ, will have an opportunity to serve as a carrier for Java distribution or otherwise provide alternative middleware platforms for future application developers. E. Publishing IE Source Code 81. Similarly, critics have suggested that the proposed decree should force the open-source licensing of IE in order to reduce the applications barrier to entry and deny Microsoft one of the fruits (i.e., the dominant position of IE) of its anticompetitive (Feb. 15, 2002.) While Microsoft is expected to improve this position subsequent to the introduction of Pocket PC 2002 in October 2001, Gartner continues to project Windows CE share at no more than 30 percent for 2002. See Microsoft Aims to Dominate With Pocket PC 2002, GARTNER DATAQUEST (Sep. 10, 2001). 50 conduct. (See Stiglitz and Furman at 41-42, and Litan et al. at 71.) Litan et al. claim that third parties will then “transform IE into a true independent middleware platform,” ensuring that alternative middleware will be ubiquitous even if the SRPFJ anti-retaliatory and disclosure provisions are not enough to foster such an alternative. 82. This claim may well be true, but open-source licensing of IE will inflict economic harm on Microsoft by expropriating its intellectual property. This appears to be either an effort to collect damages from Microsoft or an exercise in competition policy well outside the confines of an antitrust case. If it is an attempt to collect damages from Microsoft, then it should be linked to an estimate of the damages caused by Microsoft’s acts. I am not aware that such an estimate exists. Moreover, Microsoft is clearly subject to other punishment outside this case, as Netscape has recently filed suit seeking treble damages for losses associated with Microsoft’s anticompetitive conduct aimed at eliminating Netscape’s browser as a competitive threat. F. Continued Licensing of the Predecessor Version of an Operating System 83. One proposal made by Litan et al. is that, whenever Microsoft makes a major release of a Windows Operating System Product, it must continue to license the predecessor version of the new product at its original price. Possibly, the objective is to limit Microsoft’s ability to have customers upgrade to the new operating system by increasing the price of the predecessor version. Of course, there is nothing inherently anticompetitive about inducing customers to upgrade to a new major release of an operating system. However, based on my understanding of submission of Litan et al., this proposal is designed to correct a perceived loophole in the proposed decree. Litan et al. state: 51 In the absence of this provision, Microsoft could frequently offer new, slightly modified versions of the OS that render the middleware based on the predecessor APIs unworkable with the new version. Middleware developers would be discouraged if they knew that Microsoft could raise their costs simply by slightly revising the operating system code in such a way that requires the middleware to be significantly modified. (Litan et al. at 72.) 84. It is not possible to assert that the SRPFJ prevents this from occurring, but it seems unlikely that Microsoft would find such a strategy profitable. First, it would appear to be difficult for Microsoft to limit the damage thus created to threatening middleware products. By changing APIs in the manner suggested by Litan et al., Microsoft would be requiring both ISVs and its own developers to rewrite their code substantially. Moreover, such a strategy would be counterproductive for Microsoft because it would serve to reduce the applications barrier to entry, since the new version of the OS would run fewer applications than its predecessor. This necessarily implies that Microsoft and its ISVs would have to rewrite, at least in part, the thousands of applications available prior to release and would have to coordinate the development schedule of these rewrites with each new release of the operating system. Microsoft’s own spotty record in meeting and coordinating the release schedules for even one or two major products makes this outcome an unlikely event. 85. It may be that Microsoft would attempt a less extreme version of the Litan et al. scenario, in which only some of the APIs are changed between versions of Windows. However, there would still exist the problem of limiting the damage to only the middleware that Microsoft regards as threatening. Even moderate changes in APIs would likely lead to large failures of backward compatibility in Windows applications. Thus, to make this strategy work, Microsoft would need to reduce the number of 52 published APIs by a significant amount each year. This action would certainly “discourage” software developers, as Litan et al. suggest, but at the same time it would also discourage ISVs from writing programs for the Windows desktop. IV. Conclusions 86. The antitrust remedy in this case must focus attention on and fully resolve the appellate court finding that Microsoft engaged in specific anticompetitive acts to maintain its operating system monopoly. In developing this remedy, it is necessary to balance two broad factors. First, the remedy must place constraints on Microsoft’s current and future behavior so that the unlawful acts stop and do not recur, and competitive conditions are restored. However, these constraints should not be so intrusive and complex that they themselves distort market outcomes. This potential distortion can take many forms, but two of the most important are (1) over-extensive government regulation of Microsoft that may result in inefficient rent-seeking by Microsoft’s competitors, or (2) requirements that make Microsoft a less efficient competitor. Thus, the difficult task is to create a balanced remedy that constrains anticompetitive behavior by Microsoft without limiting competition on the merits. 87. In my opinion, the SRPFJ achieves the right balance. By focusing on Microsoft’s anticompetitive business practices, its provisions eliminate the artificial barriers to entry erected by Microsoft that are the source of competitive concern. The provisions in the proposed decree are likely to deter conduct that (1) seeks exclusivity or (2) is backed by retaliatory threats. The SRPFJ also aims to restore and enhance competitive conditions by removing technical barriers to fair competition between 53 Microsoft and rival middleware suppliers. From an economic standpoint, middleware is important because it can expose APIs and has the potential to become an applications platform distinct from the Windows OS. The SRPFJ does not attempt to preordain market outcomes or to weaken Microsoft as a legitimate competitor. 88. I have considered other proposals carefully, including that of the Litigating States. However, in my view, these proposals fail to achieve the right balance. In an attempt to erase all theoretical ways in which Microsoft could harm competition, these alternative proposals tend to require a complex regulatory program that is certain to be slow-moving, litigious, and vulnerable to manipulation by Microsoft’s competitors. For example, the provision for how to price the proposed unbundled operating system invites arguments over cost allocations, and other ratemaking issues, that have the potential to slow down the competitive process. 89. Finally, in analyzing the SRPFJ, I have had the benefit of reviewing a number of thoughtful and probing comments on the proposed decree. As the discussion in Section III demonstrates, most of the potential problems raised by the various commentators are, in fact, not problems at all, but are met by the SRPFJ. However, at first glance there does appear to exist potential ways in which Microsoft could engage in behavior that reduces competition while claiming nonetheless that it satisfied the provisions of the SRPFJ. For example, some commentators have alleged Microsoft could (1) sell middleware only as bundled with the operating system, (2) set prices for access to its client-server communications protocols so high that they exclude competition, and (3) change large numbers of APIs frequently through numerous releases of new operating systems. Although these strategies may be theoretical possibilities, my analysis shows 54 either that these acts would be unimportant or that Microsoft would lack the incentive to undertake such actions. 90. In sum, in my opinion, the SRPFJ focuses attention on and fully resolves the appellate court finding that Microsoft engaged in a series of anticompetitive acts to maintain its OS monopoly. The SRPFJ contains provisions that will stop the offending conduct, prevent its recurrence, and restore competitive conditions. In my opinion, in light of the above, the SRPFJ is in the public interest. 55 *** I declare under penalty of perjury that the foregoing is true and accurate. Executed on February 27, 2002 in Austin, Texas. ________________________ David S. Sibley APPENDIX A CURRICULUM VITAE OF PROFESSOR DAVID S. SIBLEY DAVID S. SIBLEY Department of Economics University of Texas at Austin Austin, TX 78712 Phone: (512) 475-8545 Fax: (512) 471-8899 Education: 1973 1969 Ph.D. in Economics, Yale University B. A. in Economics, Stanford University Teaching Fields: Industrial Organization, Economics of Information Research Fields: Economics of asymmetric information, telecommunications policy, public utility pricing, models of firm’s internal organization. Professional Experience: March, 1992 - Present: John Michael Stuart Centennial Professor of Economics, University of Texas at Austin. August, 1991- March, 1992: Edward Everett Hale Centennial Professor of Economics, University of Texas at Austin. September, 1983 - August, 1991: Research Manager, Bell Communications Research, Morristown, NJ. Head of Economics Research Group. September 1981- September 1983: Murray Hill, NJ. Member of Technical Staff, Bell Laboratories, September 1980 - September 1981: Adviser to the Chairman of the Civil Aeronautics Board. January 1980 - September 1980: Consultant, Civil Aeronautics Board, Washington, D.C. September 1978 - January 1980: Senior Staff Economist, Council of Economic Advisers, Executive Office of the President, Washington, D.C. October 1973 - September 1978: Holmdel, NJ. Member of Technical Staff, Bell Laboratories, Teaching: September 1991 - Present: Introductory Microeconomics, undergraduate and graduate Industrial Organization. Fall 1989: Visiting Lecturer, Woodrow Wilson School of Public and International Affairs, Princeton University. Graduate course in regulation and public choice. September 1983 - December 1983: Adjunct Lecturer in Economics, University of Pennsylvania. Graduate course on regulation. Publications: A. Journal Articles: “Pricing Access to a Monopoly Input,” (with M. J. Doane, M. A. Williams, and S. Tsai), Journal of Public Economic Theory, 2001 (forthcoming). “Exclusionary Restrictions in U.S. vs. Microsoft,” (with M.J. Doane and A. Nayyar), UWLA Law Review, 2001. “Raising Rivals’ Costs: The Entry of a Upstream Monopolist into Downstream Markets,” (with D. L. Weisman), Information, Economics and Policy 10:451-470. “Having Your Cake – How to Preserve Universal-Service Cross Subsidies While Facilitating Competitive Entry,” (with M. J. Doane and M. A. Williams), Yale Journal on Regulation, Summer 1999. “The Competitive Incentives of Vertically-Integrated Local Exchange Carriers: An Economic and Policy Analysis,” (with D. L. Weisman), Journal of Policy Analysis and Management, Winter 1998. “Multiproduct Nonlinear Prices with Multiple Taste Characteristics,” (with P. Srinagesh), Rand Journal of Economics, Winter 1997. “Optional Two-Part Tariffs: Toward More Effective Price Discounting,” (with R. Rudkin) in Public Utilities Fortnightly, July 1, 1997. “A Bertrand Model of Pricing and Entry,” (with W. W. Sharkey), Economics Letters, 1993. “Regulatory Incentive Policies and Abuse,” (with D. M. Sappington), Journal of Regulatory Economics, June 1993. “Optimal Non-linear Pricing With Regulatory Preference over Customer Types,” (with W. W. Sharkery), Journal of Public Economics, February 1993. “Ex Ante vs. Post Pricing: Optional Calling Plans vs. Tapered Tariffs,” (with K. Clay and P. Srinagesh), Journal of Regulatory Economics, 1992. “Thoughts on Nonlinear Pricing Under Price Cap Regulation,” (with D. M. Sappington), Rand Journal of Economics, Spring 1992. “Compensation and Transfer Pricing in a Principal-Agent Model,” (with D. E. Besanko), International Economic Review, February 1991. “Regulating Without Cost Information: Some Further Thoughts,” (with D. M. Sappington), International Economic Review, November 1990. “Asymmetric Information, Incentives and Price Cap Regulation,” Rand Journal of Economics, Fall 1989. “Optimal Two Part Tariffs for Inputs,” (with J. C. Panzar), Journal of Public Economics, November 1989. “Regulating Without Cost Information: The Incremental Surplus Subsidy Scheme,” (with D. M. Sappington), International Economic Review, May 1989. “Optimal Consumption, the Interest Rate and Wage Uncertainty,” (with D. Levhari), Economics Letters, 1986. “Reply to Lipman and Further Results,” International Economic Review, June 1985. “Public Utility Pricing Under Risk: A Generalization,” Economics Letters, June 1985. “Optimal Non-Uniform Pricing,” (with M. B. Goldman and H. E. Leland), Review of Economic Studies, April 1984. “Efficiency and Competition in the Airline Industry,” (with D. R. Graham and D. P. Kaplan), Bell Journal of Economics, Spring 1983. “Optimal Nonlinear Pricing for Multiproduct Monopolies,” (with L. J. Mirman), Bell Journal of Economics, Autumn 1980. “A Dynamic Model of the Firm with Stochastic Regulatory Review,” (with V. S. Bawa), International Economic Review, October 1980. “Public Utility Pricing Under Risk: The Case of Self-Rationing,” (with J. C. Panzar), American Economic Review, December 1978. “Regulatory Commission Behavior: Myopic vs. Forward-Looking,” (with E. E. Bailey), Economic Inquiry, June 1978. “Optimal Decisions with Estimation Risk,” (with L. C. Rafsky, R. W. Klein and R. D. Willig), Econometrica, November 1977. “The Demand for Labor in a Dynamic Model of the Firm,” Journal of Economic Theory, October 1977. “Optimal Foreign Borrowing with Export Revenue Uncertainty,” (with J. L. McCabe), International Economic Review, October 1976. “Permanent and Transitory Income Effects in a Model of Optimal Consumption with Wage Income Uncertainty,” Journal of Economic Theory, August 1975. “A Note on the Concavity of the Mean-Variance Problem,” Review of Economic Studies, July 1975. B. Reports and Articles in Conference Volumes, and Other Publications “U.S. v. Microsoft: Were the Exclusionary Practices Anticompetitive” (with Michael J. Doane), Computer Industry Newsletter, American Bar Association, Spring 2000, Vol. 5., No. 1. “Optional Tariffs for Access in the FCC’s Price Cap Proposal,” (with D. P. Heyman and W. E. Taylor), in M. Einhorn (ed.), Price Caps and Incentive Regulation in the Telecommunications Industry, Kluwer, 1990. Report to the Governor, The Task Force on Market-Based Pricing of Electricity. Coauthored with D. M. Sappington, Appendix III. “An Analysis of Tapered Access Charges for End Users,” (with W. E. Taylor, D. P. Heyman and J. M. Lazorchak), published in the Proceedings of the Eighteenth Annual Williamsburg Conference on Regulation, H. Treeing (ed.), Michigan State, 1987. “Deregulation and the Economic Theory of Regulation,” (with W. W. Sharkey), in Proceedings of the Eleventh Annual Telecommunications Policy Research Conference, 1983. “Antitrust Policy in the Airline Industry,” (with S. B. Jollie), Civil Aeronautics Board, October 1982. Transmitted by the CAB to Congress as part of proposed sunset legislation. “Optimal Non-Uniform Pricing for Electricity: Some Illustrative Examples,” (with R. W. Koenker), in Sichel (ed.) Public Utility Ratemaking in an Energy-Conscious Environment, Praeger, 1979. “The Dynamics of Price Adjustment in Regulated Industries,” (with E. E. Bailey), in Proceedings of IEEE Conference on Systems Control, 1974. C. Books: Co-editor of Telecommunications Demand Analysis: An Integrated View, North-Holland, 1989. The Theory of Public Utility Pricing, (with S. J. Brown), Cambridge University Press, 1986. Second printing 1986. Third printing 1989. Revised edition planned. Current Research Areas: Telecommunications policy, especially access pricing and optional tariff design; Design of incentive mechanisms; Organizational slack/informational asymmetries. Other Professional Activities: Associate Editor of the Journal of Regulatory Economics. Consultant to the Governor of New Jersey’s Task Force on Market-Based Pricing of Electricity. Referee for National Science Foundation and numerous professional journals. Consulting for Bell operating companies on a variety of pricing and public policy issues. Memberships: American Economic Association; listed in Who’s Who in the East 1990.

Some case metadata and case summaries were written with the help of AI, which can produce inaccuracies. You should read the full case before relying on it for legal research purposes.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.