But in my view, it would be appropriate for this Court to go further. A great deal of energy and
social resources have been committed to this case. This Court has had the benefit of an extraordinary
clarity and completeness in presentation by the attorneys on both sides. Both sides are too quick, however,
to minimize the difficulty of this question of how tying law properly applies to software products. Making
the case seem easy is their proper role. But this is not an easy question, and the legal system would benefit
greatly from this Court’s experience if the Court would, as an alternative, craft a standard that makes
sense of the values in antitrust law and of the peculiar facts about software.
In my view, that experience does suggest an approach that avoids invasive antitrust review, and
yet does protect against threats to the competitive process. The approach is drawn from the methodology
of the Areeda Treatise, though it modifies one aspect of the Areeda test. In the balance of this section,
my aim is to sketch this alternative, and its relationship to the findings this Court has made in this case.
C
ONSIDERATIONS IN
APPLYING
JEFFERSON PARISHTO
SOFTWARE
TIES
My analysis is guided by three considerations that I believe should inform the articulation of any
rule governing the tying of software products.
(1) Risk: I do not believe software is more benign as a technique for strategic bundling than con-
tract, or “technology” (such as physical products), is. Indeed, as the evidence in this case suggests, software
can be a more effective technique for strategic bundling than contract or “technology.” This is for two
reasons. First, as the Court of Appeals noted, software by its nature is plastic. This means that it is easier
to mold software into the form a designer wants than say bridges, or hard disk drives. It also means soft-
ware is more like “contract” than like “technology” — like lawyers drafting a contract, software designers
have great freedom to package software as they wish. ¶¶162, 163. That freedom is less with physical
technology. While a designer of a software application could choose to put the functionality of a spread-
sheet program into a flight simulator, the designer of an automobile cannot choose to put the functional-
ity of the drive train into a radio.
Second, software is less transparent than other technologies in the bindings that it might effect.
Because of the complexity of modern software products, it is often easy to hide the actual functioning of a
software routine. Thus, to the extent there is an incentive for strategic behavior, it is easier to hide that
behavior in code than it is in either contract or technology.17Contracts (since interpreted by humans) and
technology (since largely observable) don’t keep secrets well. Code — at least code that is not “open
source” code — keeps secrets well.
The consequence of both features of software is that the risk that software will be used to effect
strategic bundling is greater than the risk that technology generally will be used to effect strategic bun-
dling. Antitrust law therefore does not have less reason to be concerned about strategic ties with software;
indeed, these considerations suggest that the law has more reason to be concerned.
(2) Neutrality: The test for tying should not itself influence the design of software products.18To
the extent that software manufacturers seek to bundle software products, or software functionality, they
can achieve that bundle either through contract or through the design of the software itself — in short,
through code. If the bundle itself is not anticompetitive, then the law should not tilt this design decision
in one way or the other. The test for tying should be neutral between contract-based and code-based re-
strictions on bundling two products.
The reason for this consideration should be obvious. If two software products could be bundled
together either through a contract that requires them both to be present if one is, or through software that
essentially makes it impossible for one to exist without the other, then there is no evidence in this case,
and no argument that I know of, to show why the law should prefer one mode of bundling to the other.
While antitrust law is generally encouraging of technology-based tying efficiencies, and skeptical of claims
of contract-based tying efficiencies,19the bolting achieved through software has no necessary relationship
to efficiency. As the Court’s findings make clear, code that makes it hard to separate two sets of function-
17 As the Court of Appeals commented when dismissing the hypothetical bundle of a mouse with an operating sys-
tem, “[p]roblems seem unlikely to arise with peripherals, because their physical existence makes it easier to identify
the act of combination.” 147 F.3d, 948 n.11.
18 This point is analogous to the observation by Meese that hostility to post-transaction tying efficiencies forces in-
efficient “forward integration.” Alan Meese, Antitrust Balancing in a (Near) Coasean World, 95 MICH. L. REV. 111,
114 (1996). Page & Lopatka, supra note 9, at 1274, make a similar point.
alities need not produce any efficiency. The same “integration” could occur without bolting two products
with locked bolts. Or in the terms I outlined in the section on Relevant Findings, there is no strong rea-
son to believe that the move from phase two bundling to phase three bolting produces any increase in effi-
But if the law is especially forgiving of one method of bundling over another — if it, for example,
scrutinizes bundles achieved through contract more strictly that it scrutinizes bundles achieved through
code — then the effect of this rule may be to tilt the architecture of software towards software bundling
rather than contract bundling. Unless the law has an independent reason for preferring that technology of
bundling, the law of tying has no reason to induce it.
(3) Screening: The test for one or two “software products” should avoid, if possible, extensive and
direct examination of the efficiencies or benefits of one design over the other. While the government is
certainly correct that courts have in other contexts considered the efficiency of various technical and de-
sign issues, Pl. CL., at 57 n.11, it is also clear that the objective of the Jefferson Parishtest is to minimize
the factual burden necessary to make the “two product” determination. As Professor Areeda observed,
“[t]he separate products requirement is not an invitation to examine the general reasonableness of the
would thwart the main purpose of the separate products element: screen-
ing legal inquiries, allowing them to go forward only when the benefits of
further inquiry … exceed the costs resulting from the inquiry itself.
AREEDA
TREATISE, at 180, 183. The aim instead is to look to readily observable facts about the products
and the markets, so as to filter tying cases to avoid extensive judicial inquiry where it is unlikely that an
alleged tie does any competitive harm, or where it seems unlikely that judicial inquiry would be socially
desirable. Thus tests that require courts to weigh the benefits of a particular software design against the
competitive harm are less preferable to those that allow the “two product” inquiry to be made without ex-
tensive examination of the nature of a software design.
JEFFERSON PARISHTO
SOFTWARE
TIES
While few commentators or courts have examined tying law as it applies to software products,20
many have tried to draw from Jefferson Parisha useable set of tests to apply to a broad range of products.
The Areeda Treatise is a prominent example. Its aim is to articulate the Supreme Court’s “separate prod-
uct” test, in a way that is consistent with its case law, and with as much of the case law from lower courts
The Treatise organizes the inquiry into two steps. In the first, the plaintiff has the burden of
showing “(1) that somecustomers actually want the items separated and (2) that separating them is physi-
cally and economically possible.” It seems plain from the Court’s findings that the government has met
this burden. ¶¶150-54. See also AREEDA
TREATISE, at 192.
In the second step, the burden of production shifts to the defendant to establish that at least one
of six “single product” rationales applies to the facts in the particular case. If any of these tests yield the
conclusion that two items ought to be considered a “single product,” then the result of the inquiry gener-
ally is that these two items be considered a “single product.”
Of the tests, or “rationales,” that the Areeda Treatise describes, three are directly relevant to the
facts of this case.21These are (1) the “Competitive Market Practices” rationale, (2) the “New Product”
rationale, and (3) the “Same Product” rationale. As will be clear, the focus of the Court’s analysis needs to
be upon the “New Product” rationale, but the insight that guides that analysis will be found in the “Same
Competitive Market Practices [CMP]
The core of the Areeda analysis is the “Competitive Market Practices” test. AREEDA
¶1744. The aim of this test is to determine whether competitive firms, operating in a competitive envi-
20 See, e.g., De Vries, supra note 9; Rachel V. Leiterman, Comment: Smart Companies, Foolish Choices? Product De-
signs that Harm Competitors, 15 SANTA CLARA COMPUTER & HIGH TECH. L.J. 159 (1999) (collecting and exam-
ining related cases).
21The others are the “Finished Product Rationale,” ¶1748, the “Intellectual Property and Other Government-
Encouraged Bundling,” ¶1749, and the “Phantom Separate Product” rationale, ¶1750.
ronment, bundle products in the way that the defendant does. The answer to this question provides good
indirect evidence of whether it is efficient to provide the two items as two products. If firms with no mar-
ket power, operating in a competitive environment, similarly bundle the two items, then a court has good
reason to believe that these two items cannot be efficiently offered separately. If they could, then the
competitive market would provide them separately. The actual market practices of firms without market
power is therefore a good indicator of whether two items can be offered separately efficiently.
To apply the CMP test, however, a court must first determine what the relevant “bundle” is.
While it is true that other competitors “bundled” browsers with their operating system, for purposes of
the CMP test, I don’t believe that practice should count. Including free and easily removable software
with an operating system or with any software package is not the kind of “tying behavior” at issue in a
Section 1 case. So long as the consumer, or OEM, can easily remove the allegedly “tied” product, there
can be no “forcing” for purposes of Jefferson Parish.
The only relevant alleged tying behavior would be a case where a manufacturer bundled a browser
which the consumer or manufacturer could not easily remove. So conceived, as this Court has found,
¶153, no operating system manufacturer except Microsoft bundles products in this way. Only Microsoft,
this Court has found, hampers that choice. It interferes with that choice both by overriding a default se-
lected by the user, ¶171, and by forbidding OEMs from removing the obvious access to the IE technol-
ogy. ¶158. There is therefore no competitive market practice that would suggest that Microsoft’s two
products should be considered a “single product” for purposes of antitrust tying law.22
It might seem odd to conceive of a tie as constituted by the failure to permit the removal of soft-
ware product. This oddness, however, is a function of the nature of software. When a computer is sold, its
hard disk is an underutilized shipping container. To the extent it is empty, it represents software that
could have been offered to consumers. Many software producers distribute software on this “container,”
requiring the purchaser to register for a key after a short time, or otherwise charging for the software later.
The relevant forcing in a market such as this is the refusal to allow the consumer the option to decline the
The second relevant test for determining whether this Court should consider the two items a
“single product” for purposes of antitrust tying law is the “New Product Rationale.” See AREEDA
TREATISE, at ¶1746. This test is used to determine whether two products, bundled together in a new
way, ought to be treated as a “single product.” If the test is satisfied, then two items will be considered
“one product” and not subject to tying scrutiny.
upon by the Supreme Court in Jefferson Parish, the bulk of the authority relied upon by the Areeda
authors are cases decided prior to Jefferson Parish and, in particular, prior to the Supreme Court’s rejection
of the “functional integration” test for one or two products.23No case since Jefferson Parishhas relied upon
draws its continued validity into some doubt.25Thus one might well question whether the rule survives
22 The evidence about the BeOS is not to the contrary. While the Court has not made direct findings on this issue,
the evidence appears to be that the BeOS simply requires a HTML reader to render its help files; it does not require
any particular reader. Pl. Findings ¶116.2.5.2.
23 The treatise cites Telex Corp. v. IBM, 367 F. Supp. 258, 347 (N.D. Okla. 1973); ILC Peripherals Leasing Corp. v.
IBM Corp., 448 F. Supp. 228, 230-32 (N.D. Cal. 1978) (disk drive unit and head/disk assembly); Innovation Data
Processing v. IBM Corp., 585 F. Supp. 1470, 1476 (D. N.J. 1984) (software); Information Resources, Inc., v. A.C. Niel-
sen Co., 615 F. Supp. 125, 129-30 (N.D. I. 1984) (Optical scanning data integrated with manual data), finding one
product, and Anderson Foreign Motors v. New England Toyota Distributors, 475 F. Supp. 973, 983 (D. Mass. 1979),
Data General Corp. Antitrust Litigation, 490 F. Supp. 1089, 1108-09 (N.D. Cal. 1980), and Multistate Legal Studies
v. Harcourt Brace, 63 F.3d 1540, 1551 n.10 (10th Cir. 1995), finding two products. The treatise cites Montgomery
County Assoc. of Realtors. v. Realty Photo Master Corp., 783 F. Supp. 952 (D. Md. 1992), which did find a single
product for a software product that tied pictures to descriptions, but the Court reached this conclusion under the
“separate demand” test of Jefferson Parish. The IBM peripheral cases coming from the 9th Circuit were influenced by
that circuit’s “function of the aggregation” test for determining whether there was one product or two. See ILC, su-
pra, at 230. But the Supreme Court in Jefferson Parish expressly overruled this “function” test.
24See Innovation Data Processing, supra.
25See Multistate, 63 F.3d, at 1551 n.10.
Jefferson Parish at all, or at least question the weight the rationale gives to the “new product” conclusion in
light of the Supreme Court’s rejection of the “functional integration” test.
Nonetheless, the motivation for the rule does make sense, especially in the context of software
products. As Microsoft rightly argues, Df. CL., at 5, MS Findings, at ¶529, innovation in software often
involves the bundling of functionality into a product that was not included in the product before. If the
defendant is the first to bundle this new functionality, then there would be no historical practice against
which to compare the bundle. And if there were no historical practice, then the CMP test would no
longer be a useful proxy for determining whether it was efficient to provide the two items separately.
How this test should be applied in the context of software products, however, is uncertain — in-
deed, how this test should be applied in the context of the software products at issue in this case in par-
ticular is uncertain. While the Court of Appeals, using the rationale, concluded the text meant that Wi n-
dows 95 and IE were likely “integrated,” the 1998 edition of the treatise, applying the same test, agreed
with this Court that they should likely be considered “separate products,” HERBERT
LAW, ¶1746b, at 467-69 (1998), and the 1999
edition of the treatise, applying the same test again, agreed with the Court of Appeals, though for differ-
ent reasons, that they should be considered “integrated.” 1999 SUPPLEMENT, ¶1746.1b, at 494.
These different conclusions reflect a genuine uncertainty about how to apply the “New Product
Rationale,” and the cases underlying it, to software products.26And combined with the considerations
that I began with above — both the observation that the opportunity for strategic bundling is greater with
software than with “technology” and the objective that the test not bias incentives in the design process —
they raise a difficult question about whether the test should survive at all. But rather than reject the test
completely, the experience of this Court suggests a relatively simple modification to the “New Product
Rationale” that would adjust it to the “unique problem” that “computer software poses.” 1999
SUPPLEMENT, ¶1746.1b, at 491. To see this, however, will require a more extensive explication of the
The “New Product Rationale” is two tests bundled into one. As the Areeda Treatise puts it,
courts should treat two products as one for purposes of antitrust tying law if:
(1) no relevant analogue of bundling or unbundling exists because the
defendant’s bundle causes the items to operate together in a way that had
not been tried before or (2) the items were previously sold unbundled and
operated together but the newly bundled items operate better when bun-
dled by the defendant than if bundled by the end user.
AREEDA
TREATISE, ¶1746, at 224. The Court of Appeals applied the second disjunct to interpret the
term “integrated” for purposes of the consent decree. 147 F.3d, at 949. But the motivation for the test is
notion that “functional integration” affects the “separate product” test.28Instead, the core of ¶1746 turns
on whether there is a special reason why, though products are presumptively “separate” under ¶1743, the
defendant should, nonetheless, be permitted to bundle them.
Two types of “special reason” are accounted for by the treatise. In the second, the issue is whether
it is necessaryfor the defendant to bundle the two items for the functionality of the two items operating
together to be realized. The answer to this question turns not on how well the bundle functions relative to
26Or at least a conflict among the authors. The 1998 and 1999 Supplements are authored by Professor Hovenkamp.
27 The term “integrated” had a life of its own at the trial. Some spoke of “deep integration,” “deeper integration,”
“light integration,” “close integration,” “tight integration,” “technical integration,” “seamless form of integration,”
“technical seamless integration” and “the tight welding of code.” One might order the different senses of integration
conceptually as follows: At one extreme, a program could be said to be “integrated” with an operating system if it
would run on that operating system. Professor Fisher referred to this sense to reject it as a true sense of “integration.”
January 12, 1999, P.M. Session, 1999 WL 11492, at *1. A stronger sense of “integration” describes two programs
that allow seamless transfer of data between them — for example, Microsoft Word and Excel, “work well together,”
as Professor Felton described them. June 10, 1999, A.M. Session, 1999 WL 380890, at *11. A stronger sense again
would be two programs that shared code. This is the phase two integration that I described in the relevant facts, and
it is what Professor Schmalensee referred to as tighter integration, where the degree of “tightness” was a function of
the amount of shared code. January 19, 1999, P.M. Session, 1999 WL 20651, at *11. Microsoft’s Allchin referred to
this sense of integration as well, focusing on the efficiency that results from “reduc[ing] the amount of code.” Febru-
ary 2, 1999, P.M. Session, 1999 WL 47198, at *9. And finally, there was “integration” in the sense of programs
written to share code, and which could not be separated without disabling the other. This is phase three integration,
which Professor Fisher called the “tight welding of code.” January 7, 1999, A.M. Session, 1999 WL 6529, at *9.
28 This understanding was confirmed by the 10th Circuit in Multistate, supra, 63 F.3d, at 1547. Microsoft distin-
guishes this express rejection of the “integration” test by saying the Court was not considering “integrated products”
but instead was considering a “functionally integrated package of services.” Df. CL., at 4. But the “products” at stake
in Jefferson Parish were “services”; the alleged tie was between the service of surgery and the service of anesthesiology.
So unless there is some principled reason not to consider “integration” in the context of alleged ties of services, but
to consider integration in the context of alleged ties of software products, the Court’s rejection of an “integration”
defense would seem dispositive.
other bundles,29but on whether it is necessary for the defendant to bundle the products for whatever efficiency
there is to be achieved. AREEDA
TREATISE, ¶1746, at 227. As the section describes with a hypothetical
that matches some of the facts this Court has found:
[C]onsider the bundling into one software package of previously unbun-
dled operating systems and applications software. Is the seller of such a
software package immune from tying inquiry on grounds that it reflects
new product design? The answer is no if he can show only that his brands of
software operate better in conjunction with each other than with other soft-
ware. To find a new product, the items of software must operate better
when bundled together by the seller than they would if they were distrib-
uted on different diskettes and installed by the buyer.
AREEDA
TREATISE, ¶1746b, at 229 (emphasis added). As the government argued, Pl. Findings, at
¶¶159.4.1, 159.4.2, however, and as this Court has found, ¶190, applying that test in the context of the
this case would entail that Windows 98, for example, was not a “new product,” since essentially the same
functionality could have been achieved by the consumer whether the consumer purchased Windows 98
from Microsoft, or purchased Windows 95 and installed IE 5.0. No difference in the functionality of IE,
in other words, would have existed had Microsoft allowed consumers the choice. Thus, at least for some
versions of IE, the “New Product Rationale” would provide no reason to find that the two items were a
“single product” for purposes of antitrust tying law.
The latest edition of the Areeda Treatise, however, is skeptical about the application of that sta n-
dard to software products. 1999 SUPPLEMENT, ¶1746.1, at 487. Its skepticism derives again from the
nature of software. Animating this second disjunct of the rationale is the view that “generally, two items
will operate better when bundled by the defendant because the bundling requires some physical or tech-
nological interlinkage that the customer cannot perform.” AREEDA
TREATISE, ¶1746b, at 227. This may
well be true for physical products,30and certainly for many intangible products. But, subject to a qualifi-
cation that I raise below, it not true in the same sense with software products. With software products,
whether two items will operate better when bundled by the defendant than when bundled by the cus-
29Not relative to a competitor’s product, as the Court of Appeals indicated in Microsoft II, assuming again that opin-
ion is to be read to interpret antitrust tying law. 147 F.3d, at 950.
30It explains, for example, the IBM peripheral litigation cases. See cases cited supra, note 21.
tomer is simply a matter of software design. If there is a difference in the functionality of the resulting
bundle if installed by the consumer, this is because the designer chose to make it that way. 1999
SUPPLEMENT, at 493-94. And as God can’t plead the laws of nature as a defense, it would be odd to
build an immunity based on an impossibility that the defendant itself created.
Physical or technological products are different. 1999 SUPPLEMENT, ¶1746.1b, at 493. If a car
manufacturer bundles a bumper with the car, or an automatic transmission with the car, this is a bundle
better bundled by the manufacturer because bumpers and transmissions are heavy and large objects to
handle — not because the manufacturer has made them that way, but because nature has made them that
way. Likewise, installing them properly requires training. There is no “code” that could provide the
training separately. Thus there is no similar ability of the defendant with non-software products to as eas-
ily architect the bundle so as to satisfy the rule of ¶1746b. (“One could not so readily design an automo-
bile whose pistons could be installed by the end user as easily as by the factory assembler.”) 1999
SUPPLEMENT, ¶1746.1, at 488-89.
One response to this feature of software would be to interpret this part of the “New Product Ra-
tionale” to ask not whether two products can becombined by the consumer as successfully as by the de-
fendant, but whether they could bedesigned to be combined by the consumer as successfully as by the de-
fendant. This seems to be the meaning of ¶1743 of the Areeda Treatise, but the latest version of the trea-
tise rejects that interpretation. Citing the plasticity of software, the author of the 1999 Supplement con-
cludes “[t]he problem with such a test is that … incremental software would neverqualify as part of the
same product but must be considered separate.” 1999 SUPPLEMENT, ¶1746.1b, at 494. “[V]irtually all
improvements to software would have to be regarded as ‘separate products.’” Id., at 489.
The latter conclusion does not necessarily follow on the Areeda analysis,31but even if it does,
there is a different problem raised by interpreting the test to ask not whether two products as designed can
31 The reason is that two products, though “separate products” for purposes of the “New Product Rationale,” could
still be “single products” for purposes of the “Competitive Market Practices” test, or any of the other rationales. So
for example, the 1999 edition of the Areeda Treatise suggests that if the two software products were considered “two
products” because they could be offered separately and then combined, this would mean that Windows 95 itself was
![[made with GoClick]](imgs/goclick.gif)
