Section 2 defendants often interpret the holdings of the United States Court of Appeals for the District of Columbia in U.S. v Microsoft Corp to declare non-liability for any products that demonstrate technological improvements. Joshua Gray writes that this is an incorrect reading of Microsoft and that plausible product improvements do not exempt the product from Section 2 analysis.
In 1998, the Department of Justice and 20 states sued Microsoft for illegally shielding its monopoly Windows Operating System (OS) from new competition by rivals’ innovative middleware technology. The case hinged on one type of middleware in particular, a cross-platform Java programming language first developed by Sun Microsystems. At the time, Herbert Hovenkamp explained the theory of harm at the heart of Microsoft as follows: Sun’s Java was “the ‘switch’ that would connect multiple operating systems, thus destroying Microsoft’s significant network advantage over rival systems and permitting people to base their purchasing decisions on factors such as price or quality.” Microsoft reacted to Java with a course of conduct “to keep this switch from being deployed, and thus to preserve the inability of the different systems to become interconnected.”
The district court ruled in favor of the government on April 3, 2000, finding Microsoft liable for its redesign, licensing, and distribution of Java. However, in June 2001, the U.S. Court of Appeals for the District of Columbia Circuit (“D.C. Circuit”) in an elusive and consequential series of holdings refused to affirm liability for Microsoft’s “creation and promotion” of its custom— or, borrowing a word from an internal communication, “polluted”—version of Java. The D.C Circuit otherwise broadly condemned Microsoft’s actions with respect to Java. These Java holdings were central to the Microsoft case and remain central to the modern construction of Section Two of the Sherman Act, now several decades into the digital era. The unsettled question of what to make of these holdings takes on new urgency in light of the pending summary judgment motion in the Antitrust Division’s Google search monopoly maintenance case.
The D.C. Circuit pointed to an unspecified increase in speed and concluded that Microsoft’s version of Java “does allow applications to run more swiftly and does not itself have any anticompetitive effect.” Section Two defendants in subsequent cases would construe this particular Java holding to establish a categorical rule of non-liability for anything that can be objectively described as a technological improvement. As defendants would have it, any ordinal improvement in speed—or anything else measurable—stops the analysis. Accordingly, there is no room for consideration of alternatives to the product design and evidence of anticompetitive intent is not relevant. This in turn, in their view, would establish that product improvements are privileged conduct not subject to the ordinary principles of Section Two analysis.
For example, Google’s summary judgment motion briefing in the search monopoly maintenance case asserts this view of the Java holdings arguing that “[i]t was of no moment that Microsoft’s [version of Java] would have been improved even more if it allowed for the creation of applications with both Microsoft’s and Sun’s [Java] or that Microsoft could have achieved that result at little to no cost. Instead, the question was simple: was the Microsoft [Java] a genuine product improvement?”
It is incorrect, however, that the D.C. Circuit’s analysis ignored plausibly anticompetitive design choices because of increased speed. A better interpretation of the Java holdings is that the D.C. Circuit concluded only that Microsoft’s changes to Java were not a sham. Objectively viewed, Microsoft’s design changes also had the capacity to be used to cause anticompetitive harms, so more analysis was needed. It follows necessarily that plausible product improvements are not presumptively lawful, much less exempted from a “normal” Section Two analysis.
The D.C. Circuit turned its attention to the marketplace context of Microsoft’s redesign of Java and distribution of its new product. It discussed evidence that Microsoft coerced its trading partners so as to force them to adopt its new product. Because Microsoft engaged in acts that prevented the marketplace from reaching a determination on the technical and commercial merits of a new product that has the capacity to maintain or extend monopoly power, it properly could be held liable for monopoly maintenance.
The D.C. Circuit’s analysis of Microsoft’s redesign of Java and its distribution is best viewed as a method of balancing harms and benefits that is grounded in marketplace evidence. The D.C. Circuit might have written that “we do not have to decide whether Polluted Java was an improvement because Microsoft did not permit the marketplace to make that judgment on the merits.” It did not. From the perspective of binding precedent, it matters less what the D.C. Circuit wrote, because that is what the court actually did, making it the ratio decidendi of the case.
As described by the district court, the record offers little to no evidence that Microsoft’s redesign of Java was likely to win the competitive race on the merits, especially in the long run. According to the lower court’s findings of fact, during the crucial 1995-1997 period, Java was a bold experiment with an uncertain future. To mature, Java needed more extensive libraries (resources used for programming, such as pre-written code or message templates) that could replicate the functions of a full OS without making calls to native APIs (software interfaces that allows computer programs to communicate) and, possibly, greater speed. Building out the libraries was a monumental undertaking by three main protagonists: Sun, Intel, and Microsoft. The initial innovator Sun may have had insufficient resources to finish the project alone. Intel was the one partner with the capability to help Sun realize its cross-platform aspirations for Java. Intel had the capacity to write code to complete the Java libraries. And uniquely, Intel could adapt its CPUs so that Java matched the speed and efficiency of native calls to Windows. Finally, Microsoft controlled the native environment for Windows and had unmatched capability to code.
When Netscape licensed Java in May 1995 for its popular Navigator internet browser, it became the most likely vehicle for broadly distributing Java to most Windows users. Before April 1996, Intel had developed a high-performance version of Java designed to run well on Intel based systems while complying with Sun’s cross-platform standards. Microsoft reacted with a course of conduct that prevented the marketplace from making a decision on the merits concerning Sun’s and Intel’s new technology.
First, using carrots and sticks, Microsoft convinced Intel not to permit Sun to distribute Intel’s new high performance version of Java and eventually to stop work building out the Java libraries.
Second, in March 1996, Microsoft entered into a license with Sun for use of Java. Microsoft then started its own development of Polluted Java with no cross-platform capability. Similar to Intel’s Java, Microsoft’s version was high-performance because it prioritized ease of use for developers and speed.
A representative example of the changes Microsoft made is the addition of “extensions” to overcome Java’s inherently cross-platform construction. Specifically, Microsoft “developed methods for enabling ‘calls’ to ‘native’ Windows code that made porting more difficult than the method Sun was striving to make standard.” Although “Microsoft easily could have implemented Sun’s native method along with its own in its developer tools and its [version of Java]… it elected instead to implement only the Microsoft methods.” Microsoft implemented this design because it denied developers a choice “between speed and portability.” And, “Microsoft encouraged developers to use these extensions by shipping its developer tools with the extensions enabled by default and by failing to warn developers” that the tools in their default mode would produce applications that run only on Windows and Microsoft’s version of Java.
Third, starting in 1997, Microsoft entered First Wave Agreements with large developers granting them early access to beta versions of Windows in exchange for their promise “to use Microsoft’s version of [Java] as the ‘default.’” According to the District Court, “Microsoft and the [developers] all read this requirement to obligate the [developers] to ensure that their Java applications were compatible with Microsoft’s version of [Java]. The only effective way to ensure compatibility with Microsoft’s [Java] was to use Microsoft’s Java developer tools which, in turn,” defaulted to the incompatible Java “extensions.”
Affirming liability, the D.C. Circuit characterized Microsoft’s actions as “deceptive” and the First Wave agreements as “exclusive.” Courts interpreting the Java holdings should not allow the D.C. Circuit’s characterizations to obscure the mechanics of what Microsoft actually did or lose sight of how many underlying facts implicated Microsoft’s design choices. Here, it may be necessary to read the D.C. Circuit’s opinion next to the district court’s findings of fact.
The Java holdings did not concern simple misrepresentation. Microsoft was not the typical deception case against a monopolist who ran an advertising campaign fraudulently misrepresenting a product from a non-monopolist rival. It was far stronger. Microsoft’s misrepresentations concerned the nature of its own product. What Microsoft failed to disclose, or affirmatively covered up when answering questions from the press, was its product design choices. More specifically, it hid the anticompetitive nature of the changes it made to Java to prevent others, especially developers, from making informed choices on the competitive merits.
Likewise, the Java holdings did not condemn formally exclusive agreements. With only one exception, the First Wave Agreements were exclusive in the technical sense that developers promised to create and distribute applications that defaulted to Polluted Java using tools that Microsoft had designed to default to its Java extensions. The one agreement that was exclusive in the formal sense of including an express term that prohibited the use or distribution of any version of Java other than Microsoft’s was Microsoft’s license to RealNetworks, the most popular application for streaming multimedia content in the late 1990s.
Notably, the D.C. Circuit never mentions the license with RealNetworks. To the contrary, it condemned a group of First Wave Agreements in which important developers promised to use Microsoft Java as a default, but did not prohibit either use or distribution of other, compliant versions of Java. Further, according to the district court, a principal reason why the group of agreements was similar to an exclusive in practical effect was that the developers believed that it required them to use Microsoft tools that defaulted to Microsoft’s extensions. It would be an error to read these Java holdings to concern formal contractual exclusivity rather than exclusivity as an attribute of product design including two different defaults.
The D.C. Circuit’s analysis also considered a broad range of marketplace evidence to reach conclusions about net competitive effect. If software developers, PC users, and all the other businesses that used Windows valued incremental additional speed, then Microsoft would not have had to deceive developers or restrict their choice of tools to win market acceptance. But that’s exactly what Microsoft did. To the extent slower speed was an obstacle to the spread of Java in 1996, according to the District Court, Intel was working to overcome it. If Intel was successful, it could have nullified any commercial value of Microsoft’s “improvement” to Java.
Defendants support their proposed rule of immunity for design improvements with their belief that the merits of design changes are not a justiciable issue, because courts lack the skills to measure or weigh the technical merits of design changes, or to reach reliable conclusions as to net competitive effects. At the same time, Defendants have no trouble advancing a robust view that the D.C. Circuit held that Polluted Java was an “improvement” of conclusive significance for antitrust analysis. If the latter were true, there would be an unresolved contradiction between those two views of the capabilities of our courts.
By shifting the focus to marketplace context, the D.C. Circuit’s method of analysis does not burden courts with a definitive decision on the issue in either direction based solely on the new product itself. This interpretation of the Java holdings, therefore, offers a more faithful construction of the crucial, but elusive, sentence in the D.C. Circuit’s opinion quoted in part above. Here is that sentence again in full: “[Microsoft’s version of Java] does allow applications to run more swiftly and does not itself have any anticompetitive effect” (emphasis mine). It describes Polluted Java as a new product with at least one plausible advantage and narrowly concludes that its existence does not result in a harmful effect. To state the point clearly, this is a narrow conclusion on an issue so circumscribed that its practical significance is almost nil.
So interpreted, the D.C. Circuit’s Java holdings align with the law in the Second Circuit. An early and influential high tech monopoly maintenance case, Berkey Photo, Inc. v. Eastman Kodak Co., held lawful Kodak’s introduction of “a remarkable new film” because its “success was not based on any form of coercion.” And Schneiderman v. Actavis PLC (hereinafter “Namenda”) followed that principle to hold that “[w]ell-established case law makes clear that product redesign is anticompetitive when it coerces consumers and impedes competition.” In an especially apt footnote, the Namenda panel explained that the question whether the new product at issue “is superior … is not significant in this case. When there is coercion, the technical desirability of the product change … bear[s] on the question of monopolistic intent, rather than the permissibility of the defendant’s conduct” (cleaned up).
Because of the enduring importance of the Java holdings, it is unfortunate that some of the D.C. Circuit’s language can be misinterpreted to privilege product design changes to a greater extent than an interpretation grounded in what the en banc court actually decided in its landmark opinion. Reading Microsoft together with Berkey and Namenda, the standard is roughly similar in the Second and D.C. Circuits and the relevant legal question is whether the monopolist acted to coerce its trading partners so as to force them to use or distribute its plausibly anticompetitive new product thereby harming competition. If it has engaged in acts that materially disrupted the normal competitive processes of acceptance and implementation of new products, then the monopolist can be held liable for monopoly maintenance. In cases involving digital technologies, these will typically be fact-bound issues that cannot be resolved on summary judgment. Especially for products that are related to standards in network industries, this test demands careful application as the D.C. Circuit itself demonstrated.
Disclaimer: Joshua Gray has counseled some companies about potential antitrust claims against several global technology companies. Joshua has counseled clients about Google’s business practices, but this work is not reflected in any past or current litigation.
Articles represent the opinions of their writers, not necessarily those of the University of Chicago, the Booth School of Business, or its faculty.
