U.S. Department
of Justice
Microsoft Tunney Act Comment : Steven Waldman
| |
| Steven Waldman
Thank you for the opportunity to comment upon the US v. Microsoft Proposed Final Judgement, published in The Proposed Final Judgement as written is not in the public interest. I urge the Department to pursue remedies substantially different from those proposed, whether via further negotiations with Microsoft, or through adversarial proceedings. If the settlement is presented to the District Court without substantial modification, I would urge Judge Kollar-Kotelly make a determination under the Tunney Act that the Proposed Final Judgement would not serve the public interest. The Proposed Final Judgement Would Do Positive Harm It may seem odd to suggest that an antitrust remedy could be positively harmful. After all, regardless of the remedy, a convicted monopolist cannot leave an antitrust proceeding with more rights than it had when it arrived, and usually leaves with fewer. However, a poor remedy can indeed leave the public in a situation worse than the status quo ante. The current Proposed Final Judgement does so, in two ways. First, the PFJ describes, permits, and envisions specific future conduct on the part of Microsoft that would itself be anticompetitive. By providing implicit government endorsement for this conduct, the PFJ would make it difficult for the Department, the States, or private third parties to bring proceedings against Microsoft to curb it at a later date. Second, the PFJ contains enforcement provisions whose primary practical effect would be to delay and reduce the likelihood of further action should the company continue to behave unlawfully. In other words, while the Proposed Final Judgement does place Microsoft under some new constraints, it places the DOJ and other potential litigants under even greater constraint. The net effect would be a diminishment rather than an increase in deterrence of Microsofts anticompetitive behavior. PFJ Explicitly Permits Continued Anticompetitive Practices The purpose of the Proposed Final Judgement is to remedy Microsofts unlawful conduct, specifically its unlawful maintenance of a monopoly in Intel-compatible PC operating systems. The reasoning behind the Court of Appeals upholding of the monopoly maintenance claim centered on the idea that there is an applications barrier to entry to operating systems markets, but that this barrier to entry could plausibly be chipped away at by a class of applications referred to as middleware. The Court held that Microsoft engaged in various practices to protect[] Microsofts monopoly from the competition that middleware might otherwise present, in violation of Section 2 of the Sherman Act. It is these practices that must be remedied. In particular, the Court held that by virtue of restrictive contracts with computer manufacturers (OEMs), internet providers (IAPs), software companies (ISVs) and by other means, Microsoft impeded the widespread distribution of middleware that might have threatened its monopoly. Section III.C.3 of the Proposed Final Judgement forces Microsoft to allow OEMs to automatically launch non- Microsoft middleware at the end of a PCs boot sequence, but only if a Microsoft Middleware Product that provides similar functionality would otherwise be launched automatically at that time. By this caveat, the PFJ endorses a restriction in an OEM licensing agreement that would otherwise constitute a violation of Section 2 of the Sherman Act under the Court of Appeals reasoning. The caveat is anticompetitive on two counts. First, it permits Microsoft to choose its battles: Microsoft need only face challenges from automatically launched middleware where the company feels its own offerings have an advantage. Should a competitor create an innovative middleware product that would threaten Microsofts applications barrier to entry, Microsoft can prevent its distribution as a default running service indefinitely, by simply not fielding an offering of its own or by quietly integrating but not trademarking its offering (see the definition of a Microsoft Middleware Product, PFJ, Section VI.K.2.b.iii). Secondly, the caveat necessarily permits competing middleware only if OEMs include Microsofts offering as well, since by definition (again, PFJ, Section VI.K.2) a Microsoft Middleware Product is a part of a Windows Operating System Product. The Appeals Court noted several reasons why OEMs are reluctant to include two products of the similar functionality in a default installation, including customer confusion; increased support and testing costs; and that it is a questionable use of the scarce and valuable space on a PCs hard drive. (the Appeals Court quoting the District Courts Findings of Fact) These considerations are cited by the Court in holding unlawful and exclusionary OEM contracts that forced a choice of including Microsoft middleware alone or Microsoft middleware plus a similar competitor. Additionally, even when competitive middleware is preinstalled alongside Microsofts offering, network effects would put any one of several nonubiquitous occasionally installed competitors at a serious disadvantage with respect to offering by Microsoft, even if inferior, that is guaranteed to be present on all installations. Should Microsoft force an ours or both decision with respect to competing middleware as a condition of OEM Windows licensing, it would most certainly be anticompetitive. However, it would also be explicitly sanctioned by the Proposed Final Judgement, and therefore difficult for the government or a third party to oppose. [1] To the degree that Section III.C might have any effect in allowing OEMs to integrate third party middleware with a Microsoft OS, Section III.H.3 largely eviscerates the hazard to the monopolist by foreseeing a mechanism by which the companys operating systems could ask end-users to confirm an alteration or undoing of OEM additions to the OS fourteen days after the consumer first turns on a PC. For example, under this section, an operating system would be permitted to present a dialog box stating, Windows has detected that this configuration has been modified from Microsoft-recommended defaults. This may lead to incompatibilities or system faults. [Correct Now?] [Cancel] Clicking Correct Now? would replace OEM-installed non-Microsoft middleware with Microsofts offering. If faced with the question, a court might determine that such a presentation (which Microsofts competitors would be unable to make) would constitute unlawful monopoly maintenance by Microsoft. But it would be difficult for the government or for a private litigator to make that case in the face of a Final Judgement that clearly endorses the conduct. The problems thus far mentioned are not unique. The Proposed Final Judgement is riddled with loopholes that not only make it a weak remedy, but that foresee and allow specific behavior by Microsoft that in the absence the Final Judgement would be actionable. By complicating potential future public or private antitrust enforcement against Microsoft, the Proposed Final Judgement would encourage misconduct and do positive harm to competition in the software industry. PFJ Specifically Discriminates Against Open Source Competition Over the past several years, a novel approach to software development known as open source has risen to prominence. Under the open source development model, many widely dispersed individuals, businesses, and other entities collaborate in the production of complex software products, contributing to what over time has become a rich commons of collectively authored software. Open source software is made available free of charge, under licenses that permit widespread redistribution and modification by users, sometimes with the restriction that any derived works must be made available to the public under the same terms. The business model that supports the continued development of open source software remains to be fully understood. The licensing terms of open source software prevent the exploitation by authors of any limited monopoly that would enable them to profitably sell software as traditional software vendors, such as Microsoft, have done. Nevertheless, a wide variety of actors including individual hobbyists, multinational companies, public and private universities, governments, and nongovernmental organizations have found sufficient incentive to invest substantial amounts of time and money into the production of open source software. In the face of Microsofts successful and unlawful monopoly maintenance, very few traditional software vendors still stand as competitors in the companys core market of Intel-compatible PC operating systems. Behemoths like IBM and scrappy upstarts like Be, Inc. have battled to gain a fingerhold, but failed to make any headway at all, and their products (IBMs OS/2, Bes BeOS) have all but faded from the computing landscape. The only non- Microsoft operating system that has managed to grow its share dramatically despite Microsofts well-established pattern of anticompetitive behavior is the open source operating system Linux. Other open source projects that have competed effectively with Microsoft include Samba (which provides Windows interoperable file and print services to computer networks) and Apache (the most popular web server on the Internet). It appears that the open source development model is somewhat resistant to the sort of anticompetitive behavior that has been effective for Microsoft in the past. One might even argue that the explosion of open source software over the past few years is a response by businesses, developers, and users to an artificially straitened traditional software landscape, and is perhaps attributable at least in part to Microsofts anticompetitive behavior. As traditional vendors have receded from whole categories of software under the self-fulfilling truism that competing with Microsoft is akin to suicide, many entities have for one reason or another decided that the cost of contributing a small portion to the development of alternatives is less than the direct costs (continual licensing fees) and indirect costs (the failings of software not adequately tailored to their needs; uncertainty and future costs created by vendor lock-in) associated with relying on Microsoft products. Regardless of the whys, open source software now stands as one of the few sources of effective competition against Microsoft. Indeed, while many of the battles that prompted the Justice Departments action against Microsoft are now past and prologue (e.g. the browser wars between Netscape and Microsoft), the struggles between open source Linux and Windows in the server space and between open source Apache and Microsofts IIS remains, among many others, remain active and fierce. [2] Any remedy to Microsofts anticompetitive behavior that diminishes the likelihood that open source projects can effectively interoperate with and compete against Microsofts offerings would harm competition in the software industry. Unfortunately, the Proposed Final Judgement in several places explicitly permits Microsoft to discriminate against open source competitors. Importantly for open source developers, Sections III.D and III.E of the Proposed Final Judgement would obligate Microsoft to disclose APIs, communication protocols, and documentation that might be required to interoperate with a Windows Operating System product. However, the caveats of Sections III.I and III.J restrict these earlier sections, and would allow Microsoft to essentially exclude open source competitors from access to or the use of this information. For the disclosure requirements of Sections III.D and III.E to have any effect, competitors must be able to use the information disclosed to develop and distribute competing and/or interoperating products. However, Section III.I foresees a regime under which the disclosed information must be licensed, as it continues to be the proprietary, intellectual property of Microsoft. Section III.I guarantees reasonable and non-discriminatory terms for such licensing, based on the payment of royalties or other payment of monetary consideration. However, reasonable and non-discriminatory commercial terms inherently discriminate against open source software, which by virtue of its licensing must be freely distributable and modifiable. Under ordinary circumstances, a company certainly should have the right to offer use of its proprietary technology only under commercial license, and this would legitimately prevent those who might wish to distribute open source applications based on that technology from doing so. But in the case of a company that has a monopoly over a substantial portion of the computing world and that has maintained that monopoly through unlawful anticompetitive conduct, allowing it to require competitors to pay even reasonable licensing fees in order to interoperate with its monopoly product provides the monopolist with unjustifiable reward for its misbehavior. In Microsofts case, permitting such licensing is particularly insidious, because even if it were to provide licensing of its putative IP on absurdly generous terms, for example if it were to levy a royalty of 1¢ per thousand copies, it would immediately exclude what in the present real world are currently its most tenacious competitors from any possibility of interoperating with its software. By permitting reasonable and non-discriminatory commercial licensing of technologies the use of which is required in order to compete against and interoperate with Microsoft technologies, the Proposed Final Judgement condones and foresees a practice that would exclude and discriminate against important open source competitors. Section III.J restricts the scope of the PFJ disclosure requirements where security technologies (anti-piracy, antivirus, software licensing, digital rights management, [and] encryption or authentication systems) are concerned. Unfortunately, in todays networked world, no software is untouched by security concerns, and any non-trivial internet application must make use of and interoperate with encryption and authentication systems. Further, non-disclosure of security-critical techniques and protocols is unnecessary: the professional computer security community is nearly unanimous in its disavowal of the notion of security through obscurity. A well-designed system should be secure even in the face of an attacker who fully understands the algorithms and protocols used to enforce the security. This is not as difficult as it sounds: the academic literature is filled with encryption algorithms and protocols that have never been broken despite massive peer-review, and even some that are provably secure. Historically, non-disclosure of security techniques in software has more often served to provide cover for shoddy work than to even arguably enhance security. Security by trade secret is invariably broken, because, invariably, secret techniques are not subjected to sufficient peer review, and weak secret techniques can be reverse-engineered and then compromised. (See the recent history of CSS, a once-secret, easily broken, scheme for protecting DVDs, for a topical case-in-point.) Microsoft has a particularly poor security record, with respect to both the inadequate security of its products, and its attempts to restrict disclosure in hopes of covering up embarrassing lapses. Open source software, in general, has a much better reputation for security, owing in large part to the fact that security algorithms in open source software are necessarily published, and are therefore subject to widespread review. Thus it is ironic that Section III.J.2 of the Proposed Final Judgement explicitly allows Microsoft to condition disclosure of security-sensitive technologies to those who meet[] reasonable, objective standards established by Microsoft for certifying the authenticity and viability of its business. Since most open source software projects are not developed or owned by any one business, and since the terms of open source licensing often require disclosure of source code, III.J.2 effectively excludes open source software from any access to protocols, APIs, and other information that might be required to interoperate with or compete against Microsoft products that include a security component. Any significant application now must have security designed into it, so Section III.J.2 could be used to effectively lock open source competitors out of the disclosure requirements of the Proposed Final Judgement. It would be difficult to oppose Microsoft in court for discriminating against its troublesome open source competitors when the discrimination is based on the language of a court-sanctioned Final Judgement. PFJ Enforcement Mechanisms Would Hinder Effective Enforcement The following portions of the Proposed Final Judgement would hinder effective enforcement of the agreement:
Let us be perfectly clear: At the end of the day, the Proposed Final Judgement provides the United States and each of the plaintiff States with a right to sue to enforce its terms. But lets also be honest: the choice by a State of whether or when to enter into complex antitrust litigation against a well-known and well-heeled opponent is politically fraught under the best of circumstances. Under the terms of the PFJ, an unsatisfied plaintiff would be faced with two bad options: 1) the plaintiff can expend resources on a dispute resolution mechanism (the TC) that the PFJ endorses, but that has no power, cannot be used at all as a basis for further proceedings, and will have no effect unless an amicable resolution is reached; or 2) eschew the dispute resolution mechanism endorsed by the settlement, thereby facing accusations of burdening Court resources unnecessarily, as well as a politically treacherous consulting process that would predictably lead to accusations of judicial overzealousness by reluctant former co-plaintiffs. A reasonable non-judicial enforcement mechanism would serve as a basis for judicial enforcement if required. Instead, the PFJ creates a middle path to nowhere, that increases the political difficulty of undertaking any binding action against the company. Under the PFJ, the real-world probability that misbehavior on Microsofts part would bring legal consequences would be less than without the proposed enforcement mechanisms. Thus, the Proposed Final Judgement does positive harm to the public. Complex, Vague, and Contradictory Language Hides New Anticompetitive Tools For Microsoft The ostensible purpose of Section III.I of the Proposed Final Judgement is to require that Microsoft license under reasonable and non-discriminatory terms intellectual property that software vendors and other parties might require in order to offer middleware products interoperable with Windows. If the wording were less vague (and if reasonable and non-discriminatory were changed to royalty free to include open source developers), this would be a serious and legitimate remedy: Having unlawfully restricted the development of competing middleware, it is fair that Microsoft be compelled to license, under generous terms, whatever intellectual property nascent competitors would find necessary to interoperate with Windows. However, the wording of this section is astonishingly vague. Microsoft may be compelled to license its IP to ISVs, IHVs, IAPs, ICPs, and OEMs only as required to exercise options and alternatives expressly provided to them under this Final Judgement. Exactly what options and alternatives are provided to these parties by the Proposed Final Judgement is not a matter of scientific clarity, even to the avid reader of the document. What is crystal clear, however, is that those to whom the PFJ purports to offer this relief the alphabet soup of third parties have absolutely no standing to enforce (and therefore to enlist a Courts aid in interpreting and clarifying) this or any other section of the Proposed Final Judgement (Section VIII of the PFJ, see above). Further, in an astonishing twist, Section III.I.5 exacts the remedy of compulsory licensing not only of the convicted monopolist, but of innocent competitors seeking relief. Section III.I.5 insists that a software vendor who wishes to provide a middleware product for a Microsoft operating system, if they require access to Microsoft IP to interoperate, must license to Microsoft its own intellectual property. The following language is no doubt intended to soothe competitors: [T]he scope of such license shall be no broader than is necessary to insure that Microsoft can provide such options or alternatives (Sec III.I.5). However, nowhere in the PFJ have I been able to discern any options and alternatives that Microsoft must provide to any third parties that would require a license on its part. Microsoft must merely permit practices that it has heretofore managed to prevent, in part by refusing to license its own IP, and it must disclose some of what it has heretofore kept secret. The requirements of Section III.I.5 unnecessarily and specifically envision a situation where a competitor, attempting to interoperate with Windows in ways that arguably would require some license of IP from Microsoft, could be asked to license its own IP to Microsoft, or else to cease and desist. If Microsoft and the putative competitor were to disagree about what no broader than necessary means, a competitor could not enlist any court to resolve the dispute and compel licensing under the PFJ. Thus, the PFJ sets up a situation where Microsoft could leverage an interoperability requirement by a competitor or ISV in order to acquire access to the attractive IP of its competitors. In the absence of the PFJ, a court might look at a well show you ours only if you show us yours requirement as anticompetitive, given that Windows Operating Systems are a de jure monopoly with which many third parties must interoperate or die. However, the Proposed Final Judgement gives cover to the practice by explicitly foreseeing and sanctioning a cross-licensing requirement, diminishing the likelihood of a successful outcome and increasing the burden in litigation for companies that may find themselves in the crosshairs of Microsofts IP lawyers. Again, the public is positively harmed by the PFJ, because it diminishes the likelihood of legal consequences should Microsoft engage in foreseeable anticompetitive behavior. Conclusion A District Court found, and a Federal Court of Appeals, affirmed, that Microsoft engaged over a period of years in multiple unlawful and sometimes deceptive practices in order to maintain its monopoly on PC-compatable operating systems. The fruits of this illegally maintained monopoly have been and continue to be huge for the company and its principals. The Proposed Final Judgement fails to provide any strong remedy for this conduct, and instead shelters the monopolist from potential consequences of past and future misconduct. The Proposed Final Judgment, by providing court sanction to practices a court might well find to be anticompetitive absent the proposed settlement, leaves consumers, competitors, open source software developers, and other interested parties in a worse position than they would be in if Microsoft were simply left to face private litigation as a de jure monopolist without any specific remedy being imposed in the present case. The Proposed Final Judgement would therefore be harmful to the public interest, and, unless it is very substantially modified, it should be rejected. Notes [signed Steven Waldman] |