question is not whether there is any bad in the design. The Court of Appeals’ test is whether there is

“some good.” The Court’s findings indicate that there is some good, even if the Court believes that on

balance, the net is not good.

Nor does the “bolting” qualification that the Court of Appeals articulated change this conclusion.

In describing a kind of linking that would fail the test for “integrated products,” the Court excepted cases

where the designer links products “without the link serving any purpose but an anticompetitive one.” 147

F.3d, at 949. But every time the Court articulated this exception, it used language indicating that the an-

ticompetitive purpose must be the onlypurpose. Thus: “without the link serving any purpose”; “nothing

more than… metaphorically ‘bolt’”; if the product is not superior “in some respect.” 147 F.3d, at 949 (em-

phasis added). The exception for bolting is not an invitation to balance the anticompetitive purpose

against other purposes. Rather, in my view, the test requires this Court to accept the bad with the good.

To conclude that the “bolting” that this Court has found was the only effect of Microsoft’s de-

sign, the Court would have to conclude that the other purported benefits in fact did “no good.” But in fact

this Court has found some good. ¶¶186, 193 (indirectly recognizing platform value of exposed browser

functionality APIs). And while the Court’s findings do not address it, it does not seem contested that the

modularized design of IE 3.0 and later enabled independent software vendors to write to the APIs ex-

posed by the IE components. Compare ¶44. Nor was it contested — indeed, the government’s own wit-

nesses asserted — that this feature provided “some benefit.” MS Findings ¶526. Thus under the Court’s

test, understood as an interpretation of Jefferson Parishas applied to software, even if part of Microsoft’s

motivation were anticompetitive, so long as part of what it produced was beneficial the government’s Sec-

tion 1 tying claim would fail.

It might be argued that at a different level of particularity, Microsoft’s design would fail the Court

of Appeals’ test. While phase two in the three phases of IE’s development certainly presents benefits, the

government might argue that this Court has found that phase three provided no such benefits. That while

there was good reason to expose APIs, and to make browsing technology more available, there was no

Meese, Monopoly Bundling in Cyberspace: How Many Products Does Microsoft Sell, ANTITRUST



good reason to hold the operating system hostage to browsing technology by making it impossible to re-

move browsing technology without also “breaking” Windows. This, the government might argue, was the

relevant “bolting.” Microsoft has argued that phase three provides other benefits; for example, it assures

IE technologies are on all Windows machines, and thereby relieves third-party software vendors of the

design and support burden of distributing upgrades to Microsoft’s operating system technology. But the

Court has not found this to be significant. ¶¶173, 174.

While I do believe that the Court has found that there was no good in moving to phase three of

Windows 95/98 design, I do not believe that this approach is consistent with the Court of Appeals’

opinion. The Court of Appeals was trying to avoid a situation where courts were “embark[ing] on product

design assessment[s].” 147 F.3d, at 949. It would be inconsistent with this objective to imagine courts

engaging in lengthy trials about the nature of software design before determining whether at some level of

particularity there was “some good.” Rather, the Court’s language and purpose seem to aim at removing

district courts from design evaluations. Thus, in my view, the proper level of generality must be the pack-

age of functionality taken as a whole. At this level, under the Court of Appeals test, Microsoft must pre-







If the reasoning of Microsoft IIdoes not govern the standards applicable to an alleged tie of soft-

ware products, then the question is how this Court should apply the standards of Jefferson Parishto the

facts in this case. In examining that question, I will draw upon the Supreme Court’s authority, as well as

the understanding of that authority outlined in the treatise begun by the late Professor Philip Areeda. As

both parties in this case, as well as the Court of Appeals and Supreme Court, have made extensive use of

that treatise,14I take it to be relatively neutral in this dispute.

My analysis is in three parts. I first address the question, “What is a software product?” I then ask

whether Windows 95/98 and the browser functionality of IE should be considered “two products” for

IMAGE abd9.doc07.gif

n.168 (Spring 1999).


purposes of antitrust tying law, first assuming the standards of Jefferson Parishapply directly to software

products, and second assuming those standards require some elaboration.



The essence of a tying claim is that the defendant has improperly linked “two products.” A single

product cannot be tied to itself; a tie always involves two. But though an alleged tie must always allege the

“two products” said to be tied, the conclusion of the tying inquiry may well be that “two products” (or as

the Areeda Treatise sometimes calls them, two “items”) should be considered a “single product” for pur-

poses of antitrust tying.

But that very formulation raises a question often left implicit in a tying inquiry — what is a


This question is ordinarily implicit because the answer with physical products is self-evident: with

tangible items, a “product” is a physical object that can be sold independently of another “product.” As the

Areeda Treatise puts it,

[I]f a car manufacturer insists on selling cars with their tires, we might
debate whether cars and tires are a single product. But there would very
likely be little dispute about which part of the total contrivance consti-
tutes the “car” and which part constitutes the “tire.”




LAW493 (1999)

[1999 SUPPLEMENT]. The same is generally true for intangible products as well. There is no ambiguity

when we refer to the “service contract” that was allegedly tied to the sale of Kodak parts in Eastman Ko-

dak. The “product” refers to the set of services that would be provided over the term of a contract to sup-

port a particular copier. It plainly doesn’t refer, for example, to the particular technicians who would serv-

ice the machines (even though without these technicians, there would be no service). Nor does it refer to

the tools or supplies that would be used in servicing those machines (even though without these, there

would be no service). Instead, it refers, abstractly, to the functions performed by the technicians, tools and

supplies in maintaining the Kodak copiers.

14See, e.g., Eastman Kodak Co.v. Image Tech Servs., Inc., 504 U.S. 451, 469, 470 n.15, 474, 476, 499, 491, 493, 497,


But as the history of this case reveals, there is a contest about what a “product” is when speaking

of a software product. Microsoft insists that because the government cannot point to the “code” that co n-

stitutes IE, it cannot identify a “product.” MS Findings ¶¶361, 364 (“software products consist of soft-

ware code and nothing else…”). The government does not point to any particular code that might con-

stitute the product “IE,” but it does believe that there is a set of functionalities that count as the relevant

“product.” Pl. CL., at 59. Without resolving the question, the Court of Appeals appeared skeptical of

treating a set of functionalities as a “product,” 147 F.3d, at 947, though it expressly indicated that it “did

not mean to suggest that [functionality] is never an appropriate criterion of identity.” Id.As it went on:

In some contexts it may be appropriate to treat as equivalent two prod-
ucts that supply the same functionality, if they meet the same demand.
Computer programs written for different operating systems, however, do
not seem to meet the same demand … .

147 F.3d, at 947 n.9.

As this passage indicates, what a “product” is should not turn upon questions of metaphysics.

Rather, the definition of a product should depend upon the economic purpose of the inquiry.15That pur-

pose, in a tying case, is to identify the product over which the law might seek to assure consumer sover-

eignty. As the Supreme Court has explained, the aim of antitrust tying doctrine is to assure “that the pub-

lic, acting through the market’s impersonal judgment, shall allocate the Nation’s resources and thus direct

the course its economic development will take.” Times-Picayune Publishing Co.v. United States, 345 U.S.

594, 605 (1953). This suggests that the perspective from which this Court should identify a software

product is the perspective of the consumer in the market. If it is the purpose of tying doctrine to preserve

consumer choice, it would make most sense to view a “product” as the consumer would. ¶149 (“Consum-

ers determine their software requirements by identifying the functionalities they desire.”).

IMAGE abd9.doc07.gif

502 (1992); Microsoft II, 147 F.3d, at 948 n.11, 949, 950, 951, 962; Df. CL., passim; Pl. CL., passim.

15 As the Supreme Court said of the scope of tying law generally, quoting Professor Kenneth Dam, Dam, Fortner
v. United States Steel: “Neither a Borrower Nor a Lender Be”, 1969 SUP.CT.REV. 1, 19, “the definitional
question is hard to separate from the question when tie-ins are harmful. … To treat the definitional question as an
abstract inquiry into whether one or two products are involved is thus to compound the weakness of the per se ap-
proach.” Jefferson Parish, 466 U.S., at 21 n.33.


It is for this reason that I believe the government is correct to identify “software products” by their

functionality. On this view, a “software product” should be viewed as “functionality separately valued by

consumers.” This definition focuses on the perspective of the consumer. It is also objective — when de-

fined from this perspective, no party on its own can alter what a “product” is. And while the definition of

any “product” will change, the legal test for determining whether two “products” should be considered a

“single product” for purposes of antitrust tying law has other ways of accounting for this change. See, e.g.,


TREATISE, ¶1746.

This test is also consistent with the principle articulated by the Court of Appeals. As the Court

said, “in some contexts,” two “products” would be the same if they met the same demand. 147 F.3d, at

947 n.9. Without the benefit of a factual record, the Court of Appeals assumed that software written for

different operating systems could not satisfy the same demand. But in light of the findings that this Court

has made, it is plain that computer programs written for different platforms could meet the same demand.

The drive to build versions of Internet Explorer for different platforms came from Microsoft’s recognition

of a significant demand for common “browser functionality.” ¶153 (discussing demand). Corporations

wanted to standardize on a single browser technology, to minimize the costs of training. ¶151. The aim

of Microsoft was to develop versions of Internet Explorer for different platforms that would provide, as

much as was possible, the same functionality. This is the same demand even though the programs run on

different platforms.

To view “software products” as the code, rather than functionality, not only would not reflect

consumer understanding of software, but would create many potential paradoxes of identity. These stem

from the nature of software code. There is no necessary relationship between a given set of functionalities

and a particular design of code. The same functionalities could be instantiated in very different software.

But because the underlying code is invisible to the consumer (at least so long as it is not open source

code), these “differences” would be invisible. The consumer doesn’t care, for example, whether the same

IE functionality is provided by one file or fifty. It would therefore be meaningless to speak of preserving

consumer choice over a particular “product” if the product were the “code.” To say one had a choice over


such invisible differences would be like wrapping products in gift wrap, and then giving consumers the

“choice” of products.

The Court of Appeals hesitated before embracing the notion of a product being identified with

its functionality because it found it odd to think about separating or removing a product merely by

“hid[ing]” its code. 147 F.3d, at 948 n.11. But if there is any oddness here, it rests in the nature of com-

puters, not in the nature of the government’s test for products. It is well known, for example, that when a

user “deletes” or “erases” a file, the ordinary technique of operating systems is simply to remove the file

from the drive’s file listing. The actual contents of the file still remain on the disk, “hidden” from the user,

or from the ordinary ways a user gets access to a file, at least until that file is written over by another pro-

gram. But no one would therefore argue that a user has not complied with an obligation (imposed, say, by

a contract) to “remove a file after X days,” simply because the user invoked the “delete” function and

merely “hid” the contents of the file. The ordinary meaning of “deleting” or “erasing” a file is simply to

make it inaccessible; and a file is “deleted” even if a recovery program can reconstruct the file directory

entry. Thus while it might be odd to say someone has removed a book from a library simply by removing

its card from the card catalog — though many librarians would consider a book “lost” if it is mis-shelved

— this is a perfectly ordinary way of speaking about software on a computer. The relevant feature for a

consumer is the functionality, not the code, just as “[y]ou don’t go out and buy a Frank Sinatra record be-

cause you want another piece of plastic in your house. The product is the music.” Transcript of Telecon-

ference, United States v. Microsoft, No. 94-1564, January 16, 1998, page 16 (counsel for defendant).

Microsoft resists this understanding of “product” because it says that means that any time func-

tionality is added to its operating system, a tying question is raised. Df. CL., at 5. If indeed that were a

consequence of understanding a “software product” as a set of functionalities, then that would be a good

reason to resist this understanding of “software product.” Operating systems, like applications, have his-

torically folded separate functionalities into a primary product. At one time, no operating system supplied

TCP/IP support; separate products did; now all major operating systems support TCP/IP. Cf. MS

Findings, at ¶531. At one time, most word processors had no spell check or grammar check inside; now


many do. MS Findings, at ¶147. This addition of functionality is an ordinary part of the evolution of

software. And clearly, every such addition should not raise a federal tying claim.

But this is to confuse the initial question of how one defines a “software product” with the ulti-

mate question of whether, for purposes of antitrust tying law, two “items” should be considered a “single

product.” There is nothing problematic about saying about a physical product that a “car” is a product,

and a “radio” is a product, but then concluding that for purposes of antitrust law, a car bundled with a

radio should be considered a “single product.” The “separate product” or “single product” designation is

the conclusion of a legal analysis, not an instance of ordinary language. Like “malice” in defamation law,

which has little relation to “malice” in ordinary language, Massonv. New Yorker Magazine, 501 U.S. 496,

510 (1991), this may be confusing to the ordinary reader. But courts and commentators have little trouble

understanding the difference between a description of “two products” going into a tying inquiry, and the

conclusion that these two products are a “single product” for purposes of antitrust tying law.

Thus in my view, this Court should define a “software product” as a set of functionalities sepa-

rately valued by consumers, and identify particular “software products” by looking to the market’s ordinary

understanding of particular products. See, e.g., ¶150 (defining “web browser”). This would both avoid

forcing courts to examine code to understand what a product is, and permit the test to track what is the

obvious character of software to most consumers — what it does.




95/98 AND





To say that two “software products” have been bundled into the same software package is not yet

to conclude that they should be considered “two products” for purposes of antitrust tying law. That con-

clusion is the result of a legal analysis that itself is based upon a number of considerations.

The core of the inquiry is whether it is “efficient,” as Jefferson Parishand Eastman Kodakput it, to

provide the products separately. Jefferson Parish, 466 U.S., at 22; Eastman Kodak, 504 U.S., at 462. “Effi-

ciency” is determined indirectly. Jefferson Parishdoes not instruct courts to evaluate the costs and benefits


of separating two products. Rather, the aim is to identify proxies for efficiency that are sufficient to indi-

cate that a defendant should be forced to offer two products separately.

The proxy that Jefferson Parishfixes on is “separate demand.” The essential question is whether

“two separate product markets have been linked.” 466 U.S., at 21. The evidence Jefferson Parish used to

find “sufficient demand for the purchase of anesthesiological services separate from hospital services,” id.,

included (1) that the two services could be provided separately; (2) that they were billed for separately; and

(3) that doctors or patients often requested specific anesthesiologists, particularly in the specialty at issue

in the case. Id.at 22-23. These together indicated that “consumers differentiate between anesthesiological

services and the other hospital services provided by petitioners.” Id.at 23.

These factors were not exclusive. The Court pointed, for example, to the opinion of Judge Van

Dusen in United Statesv. Jerrold Electronics Corp., 187 F. Supp. 545 (E.D. Pa. 1960), aff’d, 365 U.S. 567

(1961), as an indication of the other considerations that might be relevant to the “separate product” in-

quiry. But these additional factors are simply other ways to answer the same question — whether there is

“separate demand.” They are not “other factors” in the sense of other considerations that might be bal-

anced against the “separate demand” test. (The Supreme Court, for example, expressly rejected the argu-

ment that “functional[] integrat[ion]” should matter to the inquiry. Jefferson Parish, 466 U.S., at 19.)

These other factors are just other ways to identify whether “two separate product markets have been


This, in my view, is the crucial fact about Jefferson Parish. If the Supreme Court really means the

“separate demand” test to be the only proxy for whether there is “one product” or “two” for purposes of

antitrust tying, and if it really means that the very same test should be applied regardless of the “industry,”

id., at 26 n.42, then in my view, on the facts that this Court has found, the government has prevailed on

the “separate product” question.

The Court has found that browsers can be supplied separately from operating systems; obviously

they have and can be billed for separately from operating systems; and this Court has found that many

people make specific requests for browsers, independently from the default selected by an operating sys-


tem. ¶¶ 150, 151, 153, 154. Consistent with the approach in Jerrold, other competitive firms treat the

products as separate; none bind the consumer’s choice as Microsoft does. These factors are unequivocal to

the conclusion that there is “separate demand” for browser technology and operating systems. If Jefferson

Parishalone is the test, then the government should prevail on the “separate product” question.

But Microsoft argues that a more extensive analysis of the “separate product” test is called for

when the products are “software products.” I believe that Microsoft is correct. As the 1999 Supplement to

the Areeda Treatise notes, “[i]t bears … emphasis that tying law’s ‘separate product’ requirement was not

developed with a product such as computer software in mind.” 1999 SUPPLEMENT, at 490. Other courts

have found it necessary to extend the analysis of Jefferson Parishin the context of software products, Cal-

dera, supra, as have antitrust commentators.16The view of these skeptics is that something is missed in an

analysis of software products that focuses on “separate demand” alone.

The concern is over-inclusiveness — that the “separate demand” test in the context of software

will condemn far too many bundles, especially if the rule is a “per se” rule. As Microsoft argues, the evo-

lution of software is constantly a process of bundling new functionality into old products. As the govern-

ment acknowledged in the 1994 Tunney Act proceedings, often this bundling involves adding function-

ality to an operating system that results in the lessening of demand for some software product. 59 FED

REG59426, 59428 (1994). Yet the “separate demand” test places a constant pressure on this bundling.

Because the evolution that Microsoft describes is a process where existing products are folded into other

products, it will always appear “feasible” to provide the products separately. Yet because software, as the

Court of Appeals observed, is “by its nature [] susceptible to division and combination in a way that

physical products are not,” 147 F.3d, at 951, it is (practically) always true that software could bedesigned

to permit these separate products to interact seamlessly. ¶¶162, 163. But if this were the only test, then

“virtually all improvements to software would have to be regarded as separate products,” 1999

SUPPLEMENT, ¶1746.1 at 489, and the bundling that Microsoft describes would then be perpetually

regulated by the courts.

IMAGE abd9.doc02.gif

16See supra note 9.


Some software projects aspire to this “separability.” The Open Source or Free Software Move-

ments, both as a matter of programming aesthetic and as a matter of express policy, favor architectures

that are modular, and hence easily modifiable. See, e.g., Microsoft “Halloween Document,”

< http://users.andara.com/~sdinn/halloween.html> (“Linux uses commodity PC hardware and, due to OS

modularity, can be run on smaller systems than NT”); Sandra Loosemore, with Richard M. Stallman,

Roland McGrath, Andrew Oram, and Ulrich Drepper, The GNU C Library Reference Manual,

< http://www.gnu.org/manual/glibc-2.0.6/html_chapter/libc_1.html>; Linus Torvalds, The Linux Edge, in







REVOLUTION101 (Chris DiBona et al. eds.,

1999) (discussing importance of modularity); CARLISS






MODULARITY(1999) (discussing open source movement). But while as a policy matter,

one might favor such a design architecture, the antitrust laws have not compelled it. There are many bu n-

dles that are benign from the standpoint of consumer welfare, and that antitrust law should therefore

permit, even if they are bundles that, under a different design principle, need not have been “bundles.”

It is this realization that has led the author of the latest edition of the Areeda Treatise to embrace

a very lenient rule for software ties — at least those that bundle software in a new way. As the supplement

now suggests,

[A] single product conclusion seems to be the correct one in all cases in
which the code for the two programs is interspersed such that the pur-
chaser cannot readily separate them. The disadvantage of such a rule is
that any software producer can comply with it by interspersing code. But
the disadvantage of an alternative rule forcing separation is that most of
the advantages of integration will have been lost.

1999 SUPPLEMENT, ¶1746.1b, at 494. Needless to say, if this were the rule, then Microsoft would prevail

on the “separate product” question.

As a District Court, you must decide this case under existing law. And therefore, if the Court be-

lieves that Microsoft IIdoes not control, or that, properly read, it was simply an interpretation of the term

“integrated products” in the consent decree, then the Court should conclude under the per se analysis of

Jefferson Parishthat the “separate demand” test has been met.

[made with GoClick]