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 only
purpose. Thus: “without the link serving any purpose”; “nothing
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
BULLETIN115 &
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-
ASSUMING
CONTROL
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
purposes of antitrust tying law, first assuming the standards of Jefferson Parishapply directly to software
products, and second assuming those standards require some elaboration.
WHAT IS A SOFTWARE PRODUCT?
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
[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.”
H. HOVENKAMP, 1999 SUPPLEMENT TO
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 … .
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.”).
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
Enterprises 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.,
AREEDA
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
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
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,
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.
ARE
WINDOWS
IE BROWSER FUNCTIONALITY A “SINGLE PRODUCT”?
APPLYING
JEFFERSON PARISHDIRECTLY
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.
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
(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
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
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,”
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,
SOURCES—VOICES
OPEN
SOURCE
REVOLUTION101 (Chris DiBona et al. eds.,
1999) (discussing importance of modularity); CARLISS
Y. BALDWIN, KIM
B. CLARK, DESIGN
RULES:
POWER OF
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
[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]](imgs/goclick.gif)
