This article is a part of the Section 2 Symposium symposium.
The DOJ’s Section 2 Report speaks in general terms about the costs and benefits of various remedies for monopolization. It prefers “prohibitory” remedies, but holds open the possibility of “additional relief,” including “affirmative-obligation remedies. The Report specifically mentions the protocol-licensing requirement of the Microsoft final judgments (§ III.E, entered in November 2002) as an example of a challenging and controversial affirmative-obligation remedy. In this post, I’d like to comment on the protocol-licensing program and its implementation. In doing so, I draw on my previous work with Jeff Childers, particularly Software Development as an Antitrust Remedy: Lessons from the Enforcement of the Microsoft Communications Protocol Licensing Requirement, and Measuring Compliance with Compulsory Licensing Remedies in the American Microsoft Case.
Section III.E requires Microsoft to “make available” to software developers the communications protocols that Windows client operating systems use to interoperate “natively” with Microsoft’s server operating systems in corporate networks or on the Internet. The short-term goal of the provision is to allow developers to write applications for non-Microsoft server operating systems that can interoperate as easily with Windows client computers as can software written for Microsoft’s server operating systems. The long-term goal is to preserve, in the network context, the “middleware threat” to the Windows monopoly. The idea is that middleware applications running on non-Microsoft servers might become a rival platform that could erode the “applications barrier to entry” as Netscape and Java had threatened to do.
Judge Kollar-Kotelly placed special emphasis on this provision as the “most forward-looking” one in the final judgments. It was, she believed, necessary to assure that the other provisions do not become “prematurely obsolete” as computing moves to corporate networks and the Internet. In practice, however, the provision has done little to advance the goals of the decree. Equally important, as I explain below, its implementation (by two sets of plaintiffs, with the aid of a Technical Committee and technical consultant) has been Kafkaesque. In 2006, when problems of implementation reached a crisis, the parties agreed to extend § III.E for 2 years beyond its scheduled expiration in November 2007. In January 2008, Judge Kollar-Kotelly held that the delays in implementation of § III.E required extension of the other provisions of the judgment for the same time. Just last month, at the plaintiffs’ insistence, Microsoft consented to an extension of the final judgments for an additional 18 months beyond November 2009 and an optional extension of § III.E for 18 months beyond that.
Section 2 remedies should aim to restore competitive conditions that would have existed but for illegal conduct. They should not try to achieve a competitive ideal or supervise market outcomes. Injunctions should normally be limited to preventing recurrence of proven wrongs. Regulatory decrees should be avoided, because, as the Supreme Court said in Trinko, courts are ill-suited “to act as central planners, identifying the proper price, quantity, and other terms of dealing.” Compulsory dealing is usually only appropriate where the defendant terminates a profitable course of dealing for no good reason. The Microsoft final judgments generally reflect these principles. Most of its provisions respond more or less directly to the liability holdings in the case that were affirmed by the DC Circuit in 2001—for example, prohibiting retaliation against computer manufacturers for promoting rival middleware; requiring uniform licensing terms; and giving computer manufacturers flexibility to remove visible means of access to Microsoft middleware products and install rivals’ products.
The protocol licensing provision, however, departs from these principles in several ways. First, it does not address a proven violation. There was no allegation that Microsoft exploited control over its interfaces to exclude rivals; indeed, the case held that making a product incompatible was usually legal. The idea for disclosure of interfaces was raised during settlement negotiations after the trial on liability. There was not even clear evidence that § III.E was needed for interoperability, which competitors could achieve in various other ways. Second, the provision involves detailed regulation of both price and quantity, raising complex technical issues that required a new bureaucracy in the form of the Technical Committee to implement. Finally, it imposes a duty of dealing, even though Microsoft had never licensed (or even documented) the protocols before.
As these red flags warned, the protocol licensing program has been a nightmare to implement. Microsoft has agreed to suspend royalties on its intellectual property, and has provided essentially unlimited tech support to its licensees. Nevertheless, the plaintiffs have consistently challenged the quality of the documentation that Microsoft has produced. The TC has tested this documentation by developing “prototype implementations” of them and reporting the problems its engineers encountered as bugs or “technical documentation issues” (TDIs), which Microsoft then tried to resolve. Over the years, despite multiple sets of specifications and a complete rewrite of the documentation, the TC has continued to generate thousands of new TDIs. In January 2008, Judge Kollar-Kotelly extended the judgments because of Microsoft’s failure to produce “certifiably complete accurate and usable documentation.” Although she recognized that Microsoft responded cooperatively to the plaintiffs’ concerns, and had committed enormous resources to the project, it had not done so early enough. Microsoft had, she found, failed to resolve the TDIs and to produce additional requested documentation illustrating the use of the protocols in “complex” scenarios. The plaintiffs have justified the recent additional multi-year extensions on the same grounds.
Jeff Childers and I suggest that the problems of enforcement of this provision of the judgment have less to do with Microsoft’s failure to commit adequate resources than with the intractability (and pointlessness) of the task and the unrealistic standard of compliance. Even assuming that a forward-looking, affirmative-obligation provision is warranted in this case, the plaintiffs and the court have applied an impractical standard of perfection with no meaningful time limit. Not surprisingly, dozens of engineers tasked with finding “issues” in over 25,000 pages of technical documentation have done so. In their most recent report, just last month, the plaintiffs suggest that, even though Microsoft’s documentation of the protocols will probably be “substantially complete” by the end of this year,
there will still be thousands of TDIs that need to be identified and ultimately resolved. The TC and its staff will also still have months of work to perform before they can be satisfied to a reasonable degree of certainty that the documents are of a sufficient quality (i.e., sufficiently complete, accurate, and usable) that Plaintiffs can have confidence that allowing the Final Judgments to expire is appropriate.
Thus, we face years more of this process without any discernable end-point, even though Microsoft has stated without contradiction that it is aware of no actual or potential licensee that can’t use the protocols because of flaws in the documentation. In other words, licensees may find flaws, but they can work around them, with the help of Microsoft’s tech support.
We suggest that the appropriate standard of compliance should be to ask: How would a competitive firm achieve § III.E’s goal of interoperability? That competitive firm would not apply a standard of perfection with no time limit. It would set out to find the practical needs of its actual and potential licensees, especially which features they want and are willing to pay for; it would establish a development program and testing mechanisms to meet those needs; and, most important, it would impose a firm ship date. Flaws in the documentation would be acceptable so long as they could be addressed in a reasonable maintenance program. Under these standards, Microsoft’s documentation and support effort are more than sufficient.
Ironically, in the European Microsoft case the monitoring trustee has reached essentially this result. He has concluded that “the interoperability information made available by Microsoft . . . appears to be complete and accurate [in] that a software development project can be based on it.” Therefore “Microsoft is now complying with its obligations under the 2004 Decision” so long as it responds to technical issues raised by licensees. It is too late to hope for a similar approach to § III.E, but perhaps the hard lessons of the Microsoft judgments will help shape future judgments and their implementation.
