An important provision in each of the final judgments in the government's Microsoft antitrust case requires Microsoft "make available" to software developers the communications protocols that Windows client operating systems use to interoperate "natively" (that is, without adding software) with Microsoft server operating systems in corporate networks or over the Internet. The short-term goal of the provision is to allow licensees of the protocols to write applications for non-Microsoft server operating systems that can interoperate as well with Windows client computers as can applications written for Microsoft servers. The long-term goal is to preserve, in the network context, the "middleware threat" to the Windows monopoly - the possibility that middleware applications running on servers might become a platform that could erode the "applications barrier to entry" as Netscape and Java had threatened to do. The district court singled out this provision as the "most forward-looking" in the final judgments, and as the key to assuring that the other provisions do not become "prematurely obsolete." The provision has, however, proven to be by far the most difficult to implement. We argue that it has not accomplished its purpose and that courts can draw some hard lessons from the experience. In 2003, almost a year after Microsoft first disclosed the protocols, only four firms had taken licenses. At the court's urging, both the plaintiffs and Microsoft have undertaken enormous efforts to promote the protocol program to developers, to make the license terms more attractive, to provide technical support, and especially to improve the technical documentation. The efforts have included several ambitious software development projects aimed at testing the adequacy of the documentation. Despite these efforts, as of March 2007, there were only 27 licensees producing 14 products, none of which had apparent platform potential. These results suggest that the program has failed in its primary goal. We argue that the real reason for the dearth of the licensees is that firms developing software applications to run on non-Microsoft servers generally do not need Microsoft's proprietary protocols to interoperate with Windows. They can achieve interoperability by using standard protocols supported in Windows, by adding other protocols, or by developing their own Windows client application. We draw two primary lessons for courts in future cases. First, court should only impose injunctive relief in response to a proven need. The clearest need is to stop illegal conduct that impedes normal market processes. The protocol licensing requirement, however, did not respond to a proven violation and did not address technologies that were the focus of the liability phase of the case. Nor was there an independent showing of need for a forward-looking provision - evidence taken during the remedial phase of the case did not support compulsory licensing of protocols. Second, the court should avoid regulatory decrees, especially in high-technology markets. The protocol licensing program has become highly regulatory. The plaintiffs have directly supervised the price of the licenses and other terms of dealing. More important, they have regulated the quality of the product through complex testing. If these characteristics appear in future monopolization cases, they should be treated as warning signs
