Skip to main content

Microsoft Tunney Act Comment : Jeffrey E. Harris

This document is available in two formats: this web page (for browsing content) and PDF (comparable to original document formatting). To view the PDF you will need Acrobat Reader, which may be downloaded from the Adobe site. For an official copy, please contact the Antitrust Documents Group.


My name is Jeffrey Harris. I currently work as a network administrator and software developer for a company that provides computer services to both government and industry. The company I work for has established a number of partnerships, the most significant ones being a Microsoft (MS) Solutions Partner and a Lotus/IBM Business Partner. I hold Microsoft Certified System Engineer and Microsoft Certified Systems Administrator certifications on the Windows 2000 Operating System, and the Windows NT operating systems, and I have worked with all versions of Microsoft Windows (both server and desktop versions where applicable) from Windows Version 2 to Windows XP in both a professional and personal capacity. I also hold certifications from Lotus Development on their Groupware Applications (Lotus Notes/Domino). I believe that my qualifications, as well as over 10 years experience working with computers and computer networks, including MS and non-MS products, make me well qualified to comment on the proposed MS settlement. Please note that I speak as both a computer professional, and as a consumer.

Also note that nothing in this message reflects the opinions or position of the company I work for, and I am acting ONLY in my own personal capacity in submitting these comments.

I ask that my comments be entered into the Federal Record, and considered by the presiding judge in determining the Court's final decision. I also ask that the Department of Justice acknowledge receipt of my comments.

My comments are based on a review of the original government complaint, the proposed settlement, and the Justice Department's Competitive Impact Statement (CIS), as published on the US Department of Justice's (USDOJ) website, and the Appeals Court's ruling as published on the Appeal Court's website.

Executive Summary: I STRONGLY oppose the MS Settlement in its current form. In my opinion, the agreed-to settlement will do little, if anything, to restrict MS' abusive and illegal monopolist practices, and will mainly serve to prevent the government from documenting and presenting any future abuses for legal sanctions. I cannot see how the settlement that is proposed even pretends to remedy the antitrust violations for which MS has been found culpable, and how it will meet the required standard of remedying anti-competitive practices that have harmed consumers. The company has been found in violation of Federal Anti-Trust Law, and this is the penalty phase of the case, but the settlement contains no penalties and actually advances MS' operating system monopoly in a number of ways, as I discuss below. I recommend that the Court either reject the proposed settlement outright, or modify the settlement to close the numerous loopholes identified below. I have provided some additional remedies for the Court's consideration, which are not part of the proposed settlement, but which, in my opinion, will further the public interest, if adopted by the Court.

Background: The United States and several of the states filed suit against MS claiming violation of various provisions of the Sherman Anti-Trust Act. After a trial, and appeal, a ruling was made and upheld that MS monopolized the PC Operating Systems market in violation of Section 2 of the Sherman Act. The US Court of Appeals remanded the case back to District Court, for, among other things, a new determination of penalties for this violation. The Court asked the plaintiffs and MS to attempt to reach a settlement acceptable to both sides that would address the practices that MS was found guilty of. An agreement (which was subsequently revised) was reached by both parties, and the revised agreement presented to the Court for approval. The US Department of Justice, in accordance with Federal Law, has solicited public comment on the proposed settlement.

Comments on the proposed agreement:

General Comments: This agreement focuses too much on middleware and middleware products (as defined in the proposed agreement); for my discussion in this section, I refer to them both as simply "Middleware". The original complaint against MS does not mention Middleware at all (I did a word search for "Middleware"). However, the provisions of the settlement, with few exceptions, focus on Middleware. The USDOJ in the CIS (page 2) states that the Appeals Court upheld the conclusion that MS acted to protect its operating system monopoly from the threat of Middleware. Yet, the Appeals Court's decision only mentions Middleware 39 times in a 43304 word opinion, and while the decision did address MS' objections to the District Court's decision, some of which were based on the exclusion of Middleware as a mitigating factor in MS' favor, the Appeals Court decision looks beyond that. Both the original Trial Court, and the Court of Appeals noted in their rulings that Middleware, in and of itself, does not provide enough incentive for users that it would end MS' illegal monopolistic practices. Therefore, in my opinion, the proposed agreement wrongly focuses on remedying MS' illegal actions by trying to promote competition in Middleware.

Furthermore, the ultimate goal of any settlement from this anti-trust action should be the promotion of competition that allows users a choice in the selection of operating systems. USDOJ (on page 25 of the CIS) reminds us that "Appropriate injunctive relief in an antitrust case should: (1) end the unlawful conduct; (2) 'avoid a recurrence of the violation' and others like it; and (3) undo its anti-competitive consequences." The Appeals Court Decision stated "From a century of case law on monopolization under s 2, however, several principles do emerge. First, to be condemned as exclusionary, a monopolist's act must have an 'anti-competitive effect.' That is, it must harm the competitive process and thereby harm consumers. In contrast, harm to one or more competitors will not suffice. 'The [Sherman Act] directs itself not against conduct which is competitive, even severely so, but against conduct which unfairly tends to destroy competition itself.' Spectrum Sports, Inc. v. McQuillan, 506 U.S. 447, 458 (1993); see also Brooke Group Ltd. v. Brown & Williamson Tobacco Corp., 509 U.S. 209, 225 (1993) ('Even an act of pure malice by one business competitor against another does not, without more, state a claim under the federal antitrust laws....')."

I do not really see where the proposed agreement meets any of the criteria the USDOJ lists, nor is there any substantiation by USDOJ in the CIS of how the proposed agreement will definitively benefit consumers. From my reading of the document, the proposed agreement does not directly provide any benefits to the consumer; the benefits accrue to OEMs, ISVs, IAPs, and ICPs, with the expectation that the benefits may flow through to consumers. For example, allowing OEMs to provide dual operating systems on PCs for consumers does consumers no good if the OEMs choose not to provide a choice of operating systems, and similarly for middleware. For this reason alone, the Court should reject the proposed agreement as being inadequate.

Specific comments: Paragraph III A. purports to restrict any retaliatory behavior against any OEM (i.e., computer manufacturer) for exercising its rights under the proposed agreement, or for various activities related to non-Microsoft software. However, nothing in this paragraph discusses the right of an OEM to ship a computer system without an operating system at all. Although most new computer systems have a version of a Windows operating system installed, it is virtually impossible to buy a PC from any major OEM without a MS operating system, let alone a non-MS operating system, and the price of that operating system is passed along as part of the cost of the system, whether the consumer wants it or not.

USDOJ (on page 27 of the CIS) states that MS can only base consideration on the absolute level or amount of the OEMs support for the MS product or service, rather than on any relative level or amount. What does "absolute" mean, and how can this be enforced?

Also, the USDOJ discusses (on page 28 of the CIS) that OEMs are protected against sudden loss of Windows licenses. However, MS can still cancel licenses AFTER the 30 day opportunity to cure, which could still result in continued anti-competitive behavior by MS.

This provision also does not prohibit MS from retaliating against an OEM that makes a good-faith complaint against MS alleging a violation of the proposed agreement, which is either not brought forward to the Court for action, or is ruled as not being a violation of the settlement. In essence, an OEM would have to consider whether or not the harm it believes it may be suffering from MS as a result of a purported violation of the proposed agreement is worth additional penalties it may suffer from MS if the Court does not agree with the purposed violation (or no action is taken by the Plaintiffs), and does not redress them. Paragraph III B addresses the requirement for MS to license its software using uniform royalties, and to make available to the covered OEMs and Plaintiffs information on the royalty schedule. The proposed agreement does not provide for public access to this information.

Paragraphs III B2 and B3 allows MS to specify "reasonable" volume discounts based upon the volume of licenses. What is considered "reasonable"? Who will decide if MS is specifying "reasonable" discounts? The lack of definition of "reasonable" is one reason to make the royalty schedule public, so that if the public believes that MS is not being reasonable, it can ask its government representatives in the USDOJ and the various states to take action. Furthermore, when discounts are based on volume of licenses, it provides incentive for MS to continue to push for the installation of a MS product on EVERY system that an OEM ships, since the more that are installed, the bigger the discount for the OEM. This flatly contradicts the purpose of the proposed agreement to curb MS' monopolistic practices.

USDOJ (on page 29 of the CIS) defends this provision, noting that it is based on "verifiable criteria", which is "uniformly applied". Yet, this "verifiable criteria" could still be biased in favor of MS - for example, a requirement that a browser provide an integrated Windows logon capability. Most browsers, including Internet Explorer, provide a capability to allow users to access remote servers that restrict access based on user accounts. Internet Explorer also has a capability to "pass through" a user's credentials in a way that no other mass-market browser has (unlike other browsers, there is no need for a user to enter a username and password). Therefore, MS could include this as a "verifiable criteria", which would be heavily biased in favor of Internet Explorer.

Also the USDOJ (on the same page of the CIS) defends the selection of the 20 largest OEM for protection. However, no data is provided for what percentage of all Windows licenses those 20 largest distribute compared to the total universe of OEMs, and compared to all Windows licenses distributed from all sources. Furthermore, there is no protections for end users who buy retail copies of MS products, instead of obtaining them through the purchase of OEM systems. Since consumers MUST be the ultimate beneficiaries of any anti-trust action, there needs to be relief for these purchasers as well.

Paragraph III C4 prohibits MS from restricting "dual booting", but again, if the OEM chooses not to provide this option, or chooses not to provide an option to purchase a pre-installed non-MS operating system, nothing will change for consumers. Therefore, focusing this relief on OEMs is misplaced.

Clarification for Paragraph III C5: Does "initial boot sequence" refer to setup of the program, or the initialization of the operating system after the operating system is installed and the user starts, or restarts, the computer? Please add this term to the list of definitions in the proposed agreement.

Paragraph III D requires two different release dates for operating system documentation and APIs; one is tied to the earlier of the release of Windows XP Service Pack (SP) 1, or 12 months; the other is tied to a "Timely Manner" as defined in the proposed agreement, and purportedly applies to operating systems released after Windows XP. Note that Windows XP is the client side operating system for the latest release of a MS Windows Operating System. The corresponding server version is now called ".net server", and is still in Beta test. Therefore, if MS releases the last beta of .net server prior to the release point based on Windows XP SP1 or 12 months, which requirement applies? Also, what is considered "a new version"? For example, MS released Windows 98 Second Edition (SE) as a "new" version of the Windows 98 operating system, yet many people (myself included) feel that Windows 98 Second Edition was really just an upgrade or SP release to Windows 98, and yet MS implicitly recognized that by providing a special "step up" installation version of Windows 98 SE that could only be used by owners of the original Windows 98 version.

Paragraph III E requires disclosure of communications protocols. However, MS could sidestep the requirement in this provision by not including the protocol in the operating system distribution itself, but instead require an add-on product to provide the capability; the add-on would be distributed either by automatic download to clients, or other means of distribution to client systems other than including it in the operating system distribution. For example, Windows 95, Windows 98, Windows ME, and Windows NT 4.0 machines require an "add-in" package (an "Active Directory Services Client") to interoperate in certain ways with Windows 2000 servers. This software is not included with those operating systems, but is available for download from MS, or from the appropriate Windows 2000 server installation CDs. The USDOJ (on page 39 of the CIS) explicitly acknowledges this limitation of the proposed agreement.

Paragraph III F discusses retaliation by MS against companies that exercise options under this proposed agreement. However, Paragraph III F1, similar to what was noted above for Paragraph III A, does not prohibit MS from retaliating against an ISV or IHV that makes a good-faith complaint against MS alleging a violation of the settlement, which is either not brought forward to the Court for action, or is ruled not a violation of the proposed agreement. In essence, an ISV or IHV would have to consider whether or not the harm it believes it may be suffering from MS as a result of a purported violation of this agreement is worth additional penalties it may suffer from MS if the Court does not agree with the purposed violation (or no action is taken by the Plaintiffs), and does not redress them.

Paragraph III F 2 grandfathers any current restrictions between ISVs or IHVs and MS under the proposed agreement, but goes on to allow MS to craft partnership agreements that would prohibit these companies, such as the one I work for, from entering into other partnership agreements with companies that compete with MS (i.e., Lotus/IBM since their e-mail system competes with MS'). This one provision could nullify the entire benefit the USDOJ is trying to achieve for the ISV/IHV community, and could actually serve to STRENGTHEN MS' anti-monopolistic practices.

Paragraph III G discusses MS agreements with independent companies such as ISVs and OEMs. MS could avoid the restrictions in this paragraph by establishing joint development efforts that bind the other party - in essence, by providing substantial consideration to induce companies to establish such efforts. In addition, MS could avoid the restrictions in this paragraph by licensing intellectual property (IP) for its exclusive use - thereby making such IP unavailable for non-MS products, either for direct incorporation into those products, or for indirectly use as middleware to achieve interoperability with Windows operating systems. Again, this provision could nullify the entire benefit the USDOJ is trying to achieve for the ISV/IHV etc., community, and could further serve to STRENGTHEN MS' anti-monopolistic practices. For example, in the CIS, USDOJ discusses (bottom of Page 14) how MS coerced Apple to adopt Internet Explorer in exchange for continued development of MS Office for Apple systems. Such behavior would still be legal if it is part of a joint development effort or investment in Apple by MS.

MS could also establish fixed percentages for distribution of MS products. Using the example cited by USDOJ (on page 44 of the CIS), an IAP could agree to ship Windows Media Player on 70% of its software distribution if it can show it is commercially feasible for it to ship 70% of its software distribution with a non-MS media player. While it may be commercially feasible, that is not the same as being competitively advantageous for it to ship the non-MS media player, particularly if MS is paying it substantially more to ship Windows Media Player. Such action could ultimately result in the loss of competing products as a result of MS' deep pockets and marketing muscle with IAPs.

I note that III G 2 prohibits MS from offering IAPs placement on the desktop in exchange for IAPs agreeing to refrain from using competing non-MS Middleware Products, yet nothing prohibits MS from offering a quid pro quo for an IAP - placement on the desktop (which need not be a formal part of any agreement) and a percent placement in the IAPs distribution packages (as discussed in my previous paragraph) in exchange for significant payments by MS.

Paragraph III H discusses requirements for MS to allow removal of Middleware and Middleware products by end users. MS could avoid the requirements of III H 1 by separating Middleware Products (as defined in the proposed agreement) from the operating system as add-ons, and enabling automatic download to clients (or perhaps by requiring OEMs to install them separately from the basic operating system on their systems, but nevertheless pre-installing those components as well). Such "Middleware Products" (in quotes because software as discussed in this scenario does not meet the definition in the proposed agreement) may be required for full functionality of the operating system, yet, because they do not meet the formal definition of Middleware Products in the proposed agreement, would not require the uninstall capability.

Paragraph III H also could invoke a "poison pill" response by requiring the enablement of either all MS Middleware Products or all Non-MS Middleware products as a group; for example, a user may be forced to pick Windows Media Player and Internet Explorer over a non-MS browser and media player because he dislikes Internet Explorer, and would prefer a non-MS browser, but feels he needs to have Windows Media Player. While there is still an element of choice in this scenario, the available options are not necessarily desirable to users, and implicitly may favor MS, because users may stick to products they know, rather than ones they do not.

There are also a number of important additional exceptions to the applicability of Paragraph III H. First, MS can avoid the provisions of this paragraph by carefully crafting Middleware Products to require the type of functionally which excludes it from this provision. Second, a significant number of systems with Windows operating systems do not connect to a server outside the Internet, yet those systems can be bound by the restrictions that apply for systems that DO connect to servers. Since most systems that do not connect to servers outside the Internet are those purchased and used by consumers, this exclusion will have the biggest impact on them. Third, the provisions apply essentially to existing technology as of the previous operating system. Therefore, when MS releases a new operating system, it is not bound to the provisions of this paragraph for any new Middleware products until and unless it carries the product forward to the next succeeding Windows operating system, or it releases that Middleware less than seven months prior to the last beta test version of that new operating system.

Also, what is "a server maintained by Microsoft"? Is that an Internet accessible server operated by MS or a subsidiary to provide specialized services, such as Hotmail or Passport? Or is it a computer running a Windows server operating system? Please clarify. If it is the former, why should consumers be locked into accepting a Microsoft Middleware Product, particularly if they do not intend to ever use the MS servers?

Paragraph III I discusses requirements for MS to license its IP. However the restrictions of this paragraph, particularly Paragraph III I 3, may unduly restrict the development of non-Microsoft middleware or other rights contemplated by this agreement. For example, if Sun Microsystems wants to obtain MS IP for the purposes of making its Java Virtual Machine interoperate with Windows XP, MS could restrict the ability of Sun to distribute the Virtual Machine to other ISVs for the purposes of building software applications that run on that Virtual Machine, undermining the intent of this provision.

Furthermore, Paragraph III I 5 requires that any company that seeks to assert its rights under the proposed agreement may have to license its IP to MS. The USDOJ's discussion in the CIS not withstanding, I do not understand why a company would need to submit to MS ITS IP to assert its rights under the proposed agreement; this requirement could serve as a mechanism to restrict companies' reliance on the proposed agreement, since companies may have to consider whether it is in their best interest to license their IP to MS, and they may decide that they should forgo protection under the proposed agreement, rather than share sensitive IP information with MS, which is NOT the intent behind the proposed agreement. Companies should not have to make such an onerous choice.

Paragraph III J discusses restrictions and rights MS has in licensing documentation and API information, and in my opinion, this paragraph provides the best means for MS to avoid compliance with many other provisions of the proposed agreement. First, in Paragraph III J 1, MS is permitted to not disclose API and other information related to anti-piracy, anti-virus, software licensing, digital rights management, encryption or authentication systems. The USDOJ's description of this exclusion as "narrow", and comments in the CIS (page 53) notwithstanding, such exclusions serve to only undermine the intent of the proposed agreement, and limit the benefits to anyone outside MS. For example, MS is developing a new strategy ("Dot-NET") that provides for distributed application and transaction processing across a network of servers, and is incorporating the capability for doing this in its soon-to-be-released .NET server software. Any distributed application processing MUST provide capabilities for securing transactions, and yet, under this exclusion, MS would not be required to release necessary APIs or documentation to allow non-MS Middleware and applications to compete equally with MS software. Similarly, MS would not have to release salient potions of APIs for Windows Media Player (which incorporates Digital Rights Management APIs) or APIs that non-MS anti-virus software manufacturers could use to improve the performance of their products (for example, obtaining information about how scripts that are run using MS' native Javascript or Visual Basic scripting engines, since this could touch upon how MS incorporates anti-virus measures into the engines to protect against certain types of virus-infected scripts).

USDOJ also states this provision is necessary for MS to comply with "lawful orders" of federal agencies to not disclose certain information on security grounds. To my knowledge, no such "lawful orders" currently exist, and even if they do, or will so in the future, the wording of this paragraph could have been tailored to say exactly that - no more and no less. As the wording stands, it goes well beyond being able to comply with such "lawful orders".

Second, Paragraph III J 2 allows MS to place restrictions on licensing APIs, communications protocol and documentation relating to the functions discussed in my previous paragraph. An API, or a communications protocol, and their associated documentation generally provide the means for calling a function from the operating system (for example, accessing a file on a computer) without explaining all the details of how the underlying mechanism operates (for example, the file format of a "token" necessary to verify that the user is authorized to access that file). In many cases, communication protocols themselves are publicly defined and available on the Internet for review, particularly those that relate to the Internet. Therefore, I do not understand how restrictions on the release of such information harm MS; however, I do see harm to consumers and independent software writers (i.e., individuals who author and market their own software, generally as "freeware" or "shareware" via the Internet) since the necessary information that software writers need to write software that competes with MS Middleware Products may be unavailable, and therefore their products will be unavailable for consumers to select in place of an equivalent MS product.

Paragraph IV A 3 restricts the ability of Plaintiffs to release information provided by MS except as it may relate to an enforcement action, and under certain other conditions. Such restrictions limit the availability of information that may be useful in private litigation against MS that relates to the proposed agreement, but which the states and the USDOJ, for whatever reason, do not use to bring enforcement actions against MS. In essence, short of an enforcement action, this provision makes it difficult for the public to know if MS has breached the proposed agreement, and more difficult for others to prove that they did so.

Paragraph IV B 2 discusses requirements for individuals to serve on the Technical Committee (TC). The requirement for individuals to be "experts in software design and programming" unduly disqualifies a large class of individuals who are experts in administering computers, but who do not write software. TC members also need to know how to administer systems, since software design alone may not reveal obvious restrictions (i.e., a vulnerability due to a specific operating system configurations that falls outside the scope of the software design itself or Middleware Products that require a specific hardware configuration in operational systems that again is outside the software design itself).

Paragraph IV B 2 a specifies that a TC member shall not have been employed by a competitor, unless agreed to by both parties. How is a competitor defined? Since MS makes a large range of software and hardware products, and provides a range of services, including Internet access, does this mean that any employee in any company that makes software or hardware for systems that utilize MS software or hardware or provides services in markets that MS competes, such as Internet access, would be prohibited from serving on the TC without approval from both sides? I believe that the term should be defined explicitly and narrowly in the proposed agreement from its possibly broad usage (i.e., competitors are the 20 largest ISVs, and the 20 largest IHVs based on license revenue to MS, the 20 largest IAPs, and the 20 largest service providers for support on MS software and hardware, based on annual revenue).

Paragraphs IV B 9 and 10 place restrictions on members of the TC and their staff, including requirements to treat all information as confidential, and prohibitions on public statements. Such restrictions limit the ability of the public - who are supposed to be the ultimate beneficiaries of this agreement - from being informed on substantial or even individual issues with regard to MS' compliance with this proposed agreement (the TC is allowed to keep complainants informed on the status of complaints made to the TC, but only to the extent it does not breach their restrictions in this paragraph). Again, should the Plaintiffs not make an enforcement action against MS as a result of TC action (an issue that I will discuss further in my next paragraph), purported violations of this agreement may never be made public.

Paragraph IV D 4 d prohibits any work product, finding, or recommendation by the TC from being admitted in an enforcement action against MS for violation of this proposed agreement. This provision, in my opinion, will fatally cripple the ability of the Plaintiffs to pursue an enforcement action. Even if this provision only applies to voluntary dispute resolution activity (and it is not clear to me that such a limitation applies, even though it is in the section for voluntary dispute resolution), it is highly likely that prior to an enforcement action, the Plaintiffs would pursuit voluntary dispute resolution with MS, thus prohibiting, in this scenario, the admission of any TC work in a subsequent enforcement proceeding.

The Plaintiffs may also wait to see a pattern of behavior, and then act. Many individuals or small company make use of the dispute resolution process to seek redress against violations of this agreement by MS. If the Plaintiffs then decided to seek an enforcement action based on a compilation of those complaints, no further use of information that the TC produced could be used in the subsequent enforcement action.

I also believe that the restrictions of this paragraph may go well beyond the literal bar on enforcement actions. Although USDOJ, in the CIS (page 59), has stated that this restriction would not bar subsequent enforcement actions based on derivative use, nowhere in the proposed agreement is this explicitly stated. Therefore, MS may have a viable argument - based on precedent for limited immunity in criminal cases - that any evidence compiled by the Plaintiffs that relies on, or is derived from, TC materials may be inadmissible because it was only available as a result of, or knowledge of, TC work, and therefore is indirectly admitting TC work. Whether or not such a defense would succeed would not be known until, and unless, the Plaintiffs bring an enforcement action, and the courts rule on such a motion and any appeals. Therefore, I believe that this provision should be stricken from the proposed agreement to prevent any bars on future enforcement actions.

Section V discusses termination of the proposed agreement. While I offer no opinion as to whether or not five years is an appropriate and equitable period for the proposed agreement to last, I highly question the benefits of possibly extending the proposed agreement for another two years, should MS engage in a pattern of willful and systematic violations (a charge that may be difficult, if impossible, to prove, based on my previous comments). Why should the same prohibitions for another two years cause any change in MS' behavior, if the previous five have not? I remind the Court that this is the THIRD enforcement action against MS in the last 10 years.

Definition J is for "Middleware". I see several problems with this definition. First, Middleware must be trademarked. Should MS want to evade the provisions of this proposed agreement, it merely has to not trademark any Middleware. While MS may lose some legal rights should it not trademark a given Middleware, it may still hold "branding" rights with regard to the Middleware (i.e., the name "Topaz" may not be trademarked for a future version of an e-mail client, but everyone associates Topaz as its relates to e-mail with MS), and it may be to MS' advantage in any given case to NOT trademark a specific piece of Middleware.

Second, the definition requires that the Middleware in question must update the appropriate Middleware Product to the next major version number, as that term is defined in the paragraph. However, MS can avoid the invocation of this definition by changing the way it versions products. Instead of a release changing a Middle product to version 6.1 from 6.0, for example, the Middleware changes the version to 6.01 or 6.0, Service Pack 1. Both of these latter nomenclatures are ones that MS uses today. With such nomenclature, a "Middleware" release may NEVER trigger the definition, and the restrictions accorded such a release under the terms of the proposed agreement. Third, the Middleware in question must contain user interface elements. Although USDOJ (on page 18) tries to defend this requirement, I believe it only serves to undermine their intent. User Interface can apply to either the Middleware Product itself, or the interface of the Middleware installer (the redistributable file which installs the Middleware for the user). If USDOJ is referring to the Middleware installer, then I concur with this part of the definition. If they are referring to the Middleware Product itself, then any Middleware that provides updates without changing the user interface is not covered. For example, MS releases service packs for software, which fix bugs in the operation of the software (for example, how a program utilities memory) but do not change the user interface. Therefore it this interpretation applies, then Middleware that does not include updates to the user interface would not meet the definition. At a minimum, I recommend the definition of "user interface" be clarified", and also that this particular part of the definition of Middleware be revised, should "user interface" apply to the Middleware Product itself.

The forgoing discussion on Definition J concerning trademarking also holds for Definition K. However, note that Middleware Products must also be considered part of a "Windows Operating System Product". As that term is defined in the proposed agreement (see discussion of Definition U below), software that would otherwise be considered Middleware Products may not be if 1) it was NEVER distributed separately from the operating system or 2) MS defines the operating system product as not including that software.

Definition N, and the requirement for distributing one million copies of a software product in the last year for the definition to apply, in my opinion, prevents smaller ISVs and individuals from receiving the protections contemplated by the proposed agreement. One of my primary concerns is that since individuals and companies cannot seek protection or redress under the proposed agreement unless their products meet the distribution requirement, MS can suppress competition from these products by the same methods it has in the past, and also prevent these products from reaching a critical distribution where they could become a direct threat to MS. For example, Opera is a web browser that competes with Internet Explorer. Unless Opera meets the distribution requirements, MS could prevent Opera developers from obtaining necessary information they require to provide the same capabilities - or better - that MS puts in Internet Explorer. Therefore, Opera could conceivably disappear from use, restricting consumer choice and competition. The USDOJ (on page 21 of the CIS) defends this provision, arguing that products that have not been demonstrated as being competitive and that may be unknown to MS do not deserve protection under the proposed agreement. However, as I stated, this provides incentive to MS to crush any possible competition before it can grow to be significant (which can occur very quickly), and I strongly doubt that MS would be unaware of any software that is rapidly being adopted by consumers. A much lower threshold, such as 1000 copies or 20,000 copies, make more sense to me, and would better achieve the same intent without unduly burdening MS.

Definition U is for "Windows Operating System Product". MS, and MS alone, defines what constitutes a Windows Operating System Product. Therefore, as discussed above, MS has the ability to control what is considered Middleware and Middleware Products, and thus the overall scope of the proposed agreement, by how it defines a Windows Operating System Product. There must be a more restricted definition, for example, core services that required for an application to function or everything that is included on an installation CD (although as previously discussed, that particular definition is subject to manipulation as well), rather than MS being allowed to define the term to its best advantage.

Recommendations: I recommend that the Court reject the proposed agreement as written. The proposed agreement fails to meet the basic requirement, articulated by the Appeals Court, that any agreement provide benefits and promote competition for consumers. Nothing in this agreement directly benefits consumers, and all the of indirect benefits depend on the willingness of independent companies to innovate in a way that will benefit consumers. If the proposed agreement is approved by the Court, the only beneficiaries of the proposed agreement may be the 20 largest OEMs, various IAPs and ICPs, and some ISVs and IHVs, but even that is not certain, based on MS' past practices, and the number of limitations in the proposed agreement as discussed above. Furthermore, a number of provisions will inhibit enforcement of this proposed agreement, should MS violate it. Therefore, it is very conceivable that the proposed agreement may only serve as a toothless tiger - ignored by MS, and unenforceable by the Plaintiffs.

If the Court wishes to use the proposed agreement as a framework for injunctive relief, I recommend any proposed agreement or injunction include the following changes:

1. MS should be prohibited from retaliating against any company that files a complaint alleging a violation of any proposed agreement or injunction, whether or not the complaint is pursued or upheld. However, MS would be allowed to seek restitution from a company that filed a complaint only if it could show bad faith or reckless disregard on the part of the company that filed the complaint.

2. MS would be allowed to cancel licenses for Windows software issued to any company that would be protected under any proposed agreement or injunction, but only after demonstrating to either a majority of the Plaintiffs or the Court it had a legitimate business interest in doing so.

3. Provide public access to royalty and licensing information for companies that would be covered under any agreement or injunction. Specific company identification need not be disclosed. Define what is reasonable in terms of volume licensing.

4. Specify that verifiable criteria, as used in the proposed agreement, must be approved by a majority of the Plaintiffs or the Court as being non-discriminatory; that is, MS must not be permitted to use criteria that it knows gives it an unfair advantage over other vendor's products.

5. Expand the coverage to protect more than just the 20 largest OEMs, and provide benefits to end-users and businesses who purchase Windows Operating System Products at the retail level, or through distributors in bulk.

6. Define "Initial Boot Sequence".

7. Clarify that for operating systems releases prior to the twelve month window or Windows XP Service Pack 1, the requirement for releasing operating system documentation and APIs is the same, and that the last beta requirement only applies to operating systems released after that milestone.

8. Clarify what is considered a new version and what is considered a major version. Any definition should not allow manipulation by MS.

9. Eliminate the loopholes on disclosure of communication protocols by eliminating the requirements that they be included in an operating system distribution.

10. Allow MS to withhold information on APIs and other information related to anti-piracy, anti-virus, software licensing, digital rights management, encryption or authentication systems ONLY when complying with a "lawful order" of a federal agency or any court.

11. Overturn current agreements between an ISV or IHV and MS that restrict the ability of independent companies to promote or develop software that competes with MS, unless MS can demonstrate to a majority of the Plaintiffs or the Court that any such agreement does not unduly stifle competition.

12. Prohibit MS from structuring joint development efforts with an ISV or OEM that prevent competition unless MS can demonstrate to a majority of the Plaintiffs or the Court that such restrictions serve a bona fide business purpose for a reasonable period of time.

13. Prohibit fixed percentage agreements with IAPs, regardless of the commercial feasibility of distributing rival products.

14. Close loopholes in the definition of Middleware and Middleware Products as they relate to "user interfaces" (at a minimum define what is meant by "user interface"), whether they are trademarked or not, whether they are part of the operating system product or not, and whether they are downloaded or included with operating system distributions.

15. Require MS to allow removal of Middleware and Middleware Products only on a product by product basis, and not on an "All MS" or "All Non-MS" basis.

16. Eliminate the exceptions that allow MS to invoke MS Middleware Products in the case of a server maintained by MS.

17. Eliminate the requirements that other companies must allow licensing of their IP to MS, or agree to restrictions on distribution of products that may be based on MS IP, unless MS can demonstrate to either a majority of the Plaintiffs or the Court a bona fide business purpose in imposing these requirements.

18. Eliminate restrictions on public release of information by the Plaintiffs which might otherwise only be released as it may relate to an enforcement action, and under certain other conditions. MS would be notified in advance and given an opportunity to appeal release of the information to the Court.

19. Include a requirement that at least one member of the TC must be an expert in software design and development, and at least one member an expert in computer system network operating system or network application administration.

20. Clarify the definition of "competitor" as it relates to TC employment.

21. Eliminate restrictions on public release of information or statements by the TC, similar to that for the Plaintiffs. The TC would still not be allowed to release information deemed confidential by MS without MS' approval, the approval of a majority of the Plaintiffs, or the Court. In a situation where release of such information is contemplated, MS would be afforded adequate opportunity to appeal a decision of the Plaintiffs to the Court. Note that the reason for allowing the release of confidential information in this manner is to prevent MS from arbitrarily considering all information confidential, and therefore not releasable at all, while still affording MS some protection for legitimately confidential information.

22. Eliminate provisions that prohibit admission of any work product, finding, or recommendation by the TC in an enforcement action against MS for violation of any proposed agreement or injunction.

23. Provide for, in the event that MS engages in a pattern of willful and systematic violations, a more meaningful set of penalties. For example, MS may have to rebate to consumers, based upon proper proof of purchase, a flat amount for any operating system purchased over the period of the agreement, whether the purchase was made at retail or via purchase of an OEM system with the operating system pre-installed.

24. Reduce the distribution requirement in the definition of Non-MS Middleware Product to 1,000 or 20,000 copies.

25. Change the definition of "Windows Operating System Product", so MS cannot decide what constitutes a Windows Operating System Product.

I also recommend consideration of possible some alternative provisions, which were not part of the proposed agreement; however, some of these are being pushed by the states that demurred on the proposed agreement:

1. A requirement that MS bundle Non-MS Middleware Products with its operating system products. This would primarily benefit those consumers that purchase retail versions of MS operating systems, and those who buy systems from OEMs who choose not to integrate non-MS Middleware Products. MS would be allowed to charge a reasonable fee to ISVs whose products they incorporate to defray the costs of integrating such Middleware products into its operating system distribution packages.

2. A requirement that MS structure volume licenses with OEMs in such a way that OEMs must allow end-users to elect not to purchase a Windows operating system with their PCs at all.

3. A requirement that MS provide a "secure facility" for inspection of code. This facility could be used to keep producers of non-Microsoft middleware up to date on integration and interoperability issues with MS operating systems.

4. A requirement that MS make Internet Explorer "open sourced" - that is, MS would be required to disclose and license all source code for all Browser products and Browser functionality.

5. A requirement that MS distribute with all of its operating systems a version of the Java Virtual Machine (or runtime environment) that conforms to Sun Microsystems' Java specification. MS distributed a non-compatible version with previous operating systems, and stopped distributing it with Windows XP, although it does have the same non-compatible Java Virtual Machine available for download. The reason that MS cited for not including it in Windows XP is that it was prohibited by Sun from doing so (which is true), although Sun has long expressed willingness to allow MS to distribute a Java Virtual Machine as long as it conforms to the Java standard. Since MS has refused to do so, MS is technically prohibited from distributing the Java Virtual Machine it has.

6. A requirement that MS only incorporate standard communications protocols in its products. A standard communications protocol is one that has been ratified by either the International Standards Organization, or the Internet Engineering Task Force. MS would be required to adhere to the strict requirements of the ratified standard, although it could at any time propose new standards or modifications to existing standards for adoption by either body.

7. A requirement that MS make its consumer operating systems "open sourced" - that is, MS would be required to disclose and license all source code for its consumer operating systems. Of all the proposals, this is the one that would most benefit consumers, because it is the only option that truly promotes innovation and competition at the operating system level, and would give users a real choice in operating systems, a choice, that most likely, will not require them to give up applications they have chosen to use, or lock them out of potential future applications.

Summary: I believe we are all in agreement that the resolution of this case is of great importance, not just now, but for many years to come. This suggests a careful and deliberate penalty is far more important to the health of the nation than is a hasty one.

Any agreement, or any injunction, must ultimately answer the question - "How do consumers benefit from this?". The USDOJ has not satisfactorily answered this question in their CIS; they have focused on the benefits for companies. As written, the proposed agreement only indirectly, at best, benefits consumers.

In addition, the proposed agreement focuses too much on Middleware and Middleware Products and not enough on operating systems. Both the District Court and the Court of Appeals have noted that a reliance on Middleware and Middleware Products is not a substitute for remedying an illegal monopoly on operating systems.

I believe that the Court has made a well-intended effort to speedily resolve this case by asking the parties to come to a proposed agreement. However, as I hope I have demonstrated, the proposed agreement falls far short of what is necessary to benefit consumers, and redress illegal monopolistic behavior. Therefore, the Court needs to look at alternatives and changes to the agreement that will ultimately benefit consumers by changing MS' illegal monopolistic practices. For the Court's benefit, I have provided a list of changes that I believe will benefit consumers.

Jeffrey Harris

Updated August 14, 2015