IN THE UNITED STATES DISTRICT COURT FOR THE DISTRICT OF COLUMBIA STATE OF NEW YORK ex. rel. Attorney General ELIOT SPITZER, et al., Plaintiffs, Civil Action No. 98-1233 (CKK) v. MICROSOFT CORPORATION, Defendant. DIRECT TESTIMONY OF BILL GATES DEFENDANT'S EXHIBIT 1507 SUMMARY TABLE OF CONTENTS I. MICROSOFT'S ROLE IN FOSTERING INNOVATION ....................................4 A. Microsoft's Development of a Standard Computing Platform ....................5 B. New Technology Initiatives.......................................................................14 II. KEY ASPECTS OF MICROSOFT'S BUSINESS THAT ARE IMPERILED BY THE NSPR ......................................................................................................18 A. The Platform Value Provided by Windows ...............................................18 B. Microsoft's Promotion of Interoperability.................................................32 C. Intellectual Property Rights .......................................................................41 III. THE NSPR.............................................................................................................44 A. Overarching Problems ...............................................................................45 B. Section by Section Analysis.......................................................................61 TABLE OF CONTENTS I. MICROSOFT'S ROLE IN FOSTERING INNOVATION .....................................4 A. Microsoft's Development of a Standard Computing Platform ....................5 B. New Technology Initiatives.......................................................................14 1. .NET.............................................................................................. 15 2. Trustworthy Computing................................................................ 17 II. KEY ASPECTS OF MICROSOFT'S BUSINESS THAT ARE IMPERILED BY THE NSPR ......................................................................................................18 A. The Platform Value Provided by Windows ...............................................18 1. The Integrity of the Windows Platform........................................ 22 2. Innovation in Windows................................................................. 24 3. Testing to Assure Product Quality................................................ 28 B. Microsoft's Promotion of Interoperability.................................................32 1. Development of APIs and Protocols............................................. 34 2. Disclosure of Technical Information ............................................ 35 3. Microsoft's Open Review Process................................................ 39 4. Testing Interoperability................................................................. 40 C. Intellectual Property Rights .......................................................................41 III. THE NSPR.............................................................................................................44 A. Overarching Problems ...............................................................................45 1. Breadth of Regulated Product Categories..................................... 45 a. "Any Microsoft Product".................................................. 46 b. Middleware Definitions .................................................... 47 2. Vagueness and Ambiguity ............................................................ 52 a. Internal Inconsistencies..................................................... 53 b. Middleware Definitions .................................................... 54 c. Ordinary Business Practices ............................................. 60 3. Feasibility...................................................................................... 60 B. Section by Section Analysis.......................................................................61 1. Section 1........................................................................................ 61 ii a. Feasibility of Code Removal ............................................ 62 b. Non-Settling States' Explanations of Code Removal....... 69 c. Consequences of Code Removal ...................................... 77 d. Pricing............................................................................... 79 2. Section 2........................................................................................ 84 a. Section 2.a......................................................................... 85 b. Section 2.b......................................................................... 88 c. Section 2.c......................................................................... 90 3. Section 3........................................................................................ 94 a. Proliferation of Windows Variations ................................ 95 b. Consumer Confusion ........................................................ 96 c. Slowed Growth of the PC Ecosystem............................... 96 d. Security and Patents.......................................................... 97 4. Section 4........................................................................................ 97 a. Asset Expropriation to Enable Cloning ............................ 99 b. Ambiguity and Feasibility............................................... 106 c. Consumer Harm .............................................................. 110 5. Section 5...................................................................................... 112 6. Section 6...................................................................................... 115 a. Section 6.a....................................................................... 116 b. Section 6.b....................................................................... 117 c. Section 6.c....................................................................... 118 d. Section 6.d....................................................................... 119 e. Section 6.e....................................................................... 120 7. Section 7...................................................................................... 120 8. Section 8...................................................................................... 121 a. Acts Promoting Microsoft Software ............................... 121 b. Joint Ventures and other Cooperative Efforts................. 123 c. Intellectual Property Transfers........................................ 124 9. Section 9...................................................................................... 125 10. Section 10.................................................................................... 125 11. Section 11.................................................................................... 129 12. Section 12.................................................................................... 131 iii a. Ambiguity of "Browser" Definition ............................... 131 b. Windows Fragmentation and Quality ............................. 132 c. Reduced Innovation and Competition ............................ 133 13. Section 13.................................................................................... 135 14. Section 14.................................................................................... 139 a. Why Microsoft Built Office............................................ 140 b. Reduced Innovation ........................................................ 142 c. Consumer Harm .............................................................. 145 d. Office for Apple Macintosh............................................ 145 15. Section 15.................................................................................... 148 16. Section 16.................................................................................... 150 17. Section 20.................................................................................... 154 18. Section 21.b................................................................................. 155 iv DIRECT TESTIMONY OF BILL GATES 1. My name is William H. Gates III. I am the Chairman of the Board and Chief Software Architect of Microsoft Corporation. I am a co-founder of Microsoft and was its Chief Executive Officer from 1986, when the company went public, until January 2000. I made the decision to relinquish my duties as CEO so that I could spend more time working with the product groups at Microsoft to develop new technologies that will be necessary to enable the next generation of computing. 2. My work at Microsoft has encompassed nearly every aspect of the software business. I have written code and architected software products. In my positions at Microsoft I have met regularly with the leaders of small and large companies in the personal computer industry and in related businesses, including companies Microsoft works with to develop and distribute products, as well as with customers in the business world, in academia and in government. I closely track trends that might affect Microsoft's business. 3. I am married and have two children. I have written two books, "The Road Ahead" (1995) and "Business@ the Speed of Thought" (1999), both of which deal with how innovative software technology can increase business productivity. 4. I am submitting this testimony to provide the Court with information concerning Microsoft's development of new platform technology and how that technology is used by computer manufacturers, software developers and others in building new products. I believe that Microsoft has made a significant contribution to the success of the computer industry through our development and broad licensing of our Windows family of operating systems and other software products. 5. In my testimony, I identify a number of key aspects of Microsoft's business and technology model that have been vitally important to the value that Windows provides to the marketplace and thus to its success. The non-settling States' proposed remedies ("NSPR") would imperil Microsoft's business and technology model, depriving the marketplace of the primary benefits that Windows provides and thereby greatly devaluing the product. 6. In fact, for reasons that I explain in this testimony, I believe that Microsoft would be unable to develop a version of Windows that would comply with Section 1 of the NSPR as written. I understand that if that were the case, Section 1 would ban Microsoft from continuing to offer Windows in the marketplace, unless the Court later agreed to modify the remedy. 7. Section I of my testimony describes Microsoft's formation and our early development of operating system products. I explain how Microsoft's creation and nurturing of a common platform that ran across competing brands of personal computers ("PCs") helped to unify a fragmented industry by providing consumers with the benefits of broad interoperability across PCs from many computer manufacturers ("OEMs") and applications from many independent software developers ("ISVs"). In so doing, Microsoft helped to bring about a revolution in computing. I also briefly describe Microsoft's efforts via its .NET and Trustworthy Computing initiatives to develop breakthrough technologies that, if successful, should spark a new round of investment and excitement in computing, providing business opportunities for thousands of companies and benefits for millions of consumers. 2 8. Section II addresses three key aspects of Microsoft's business that have been vitally important to its success and the success of all those who build products that take advantage of the Windows platform. Those elements are: (i) the stability, consistency and quality of Windows and Microsoft's commitment to developing innovative new releases of the operating system that provide ISVs and consumers with new capabilities; (ii) the interoperability across a wide range of hardware and software provided by Windows and associated tools and documentation; and (iii) the incentive to innovate provided by the promise of intellectual property protection. The NSRP would undermine all three elements of Microsoft's success, causing great damage to Microsoft, other companies that build upon Microsoft's products, and the businesses and consumers that use PC software. 9. Section III provides a section by section analysis of the problems inherent in the NSPR, covering all the substantive provisions of the proposed remedy. The NSPR would deprive Microsoft of much of the economic value of its two most important products, Windows and Office, effecting a massive transfer of Microsoft's intellectual property rights in both products to its competitors. With free access to Microsoft's technology, competitors could build a clone of Windows (a product that mimics the key features of the operating system) and their own version of Office without bearing any significant part of the R&D expenses that Microsoft incurred to build the technology. As I understand it, providing Microsoft's technology to its competitors so they can build "functional equivalents" of our products now, and match all our future innovations for ten years, is in fact one of the central objectives of the NSPR. 3 10. As explained in Section III, the NSPR would undermine the Windows platform, to the detriment of all who benefit from it, in many different ways. In fact, the NSPR would hobble Microsoft as a competitor and innovator across many product categories because many of its provisions are broadly worded to apply to any Microsoft product, service, feature or technology. 11. Aside from these concerns, it would be extremely difficult, if not impossible in some cases, for Microsoft to comply with the NSPR. Many key aspects of the NSPR, particularly its definitions relating to "middleware," are vague and ambiguous, providing Microsoft with no clear statement of its obligations. Other aspects of the NSPR simply could not be feasibly implemented. Many provisions of the NSPR lead to extreme results, but Microsoft would not have the freedom to construe the NSPR in ways that we find less extreme. Microsoft is committed to complying fully with Court orders, including any remedy that may be ordered in this case. We can do that only if the remedy is clear as written and its terms feasible. I. MICROSOFT'S ROLE IN FOSTERING INNOVATION 12. For more than 25 years, Microsoft has been at the forefront of the development of the PC industry. Microsoft has played an important role by creating software--MS-DOS and later Windows--that created substantial business opportunities for other companies, which in turn made our operating systems more valuable. Today Microsoft is investing in a next generation computing platform, XML Web Services, that holds the potential to unleash new waves of productivity gains in the economy. 4 A. MICROSOFT'S DEVELOPMENT OF A STANDARD COMPUTING PLATFORM 13. In the 1960s and 1970s, IBM dominated computing. IBM made "mainframes," large computers such as the System 370 that performed data-intensive functions for large corporations. These systems were expensive to acquire (often $1,000,000 or more) and expensive to operate. Maintained by technicians in air conditioned rooms behind glass walls, few had access to the computing resources that mainframes provided. 14. Typically these mainframes were provided to corporate customers with all the software necessary to make the mainframe useful. Software was not considered to be a distinct line of business. In those days there was no such thing as a "software company." 15. Apart from IBM, mainframes were offered by competitors such as Data General, Sperry-Rand, Burroughs and others. There was little or no interoperability among mainframes from each company. A corporate customer would choose an "all IBM" solution or an all "Burroughs" solution, etc., for a particular computing need. 16. In the 1970s, Digital Equipment Corporation achieved considerable success with a line of less expensive computers (called minicomputers) that were particularly well suited to engineering and scientific tasks. Again, however, there was little or no interoperability between DEC minicomputers and mainframes offered by IBM and others. And these computers were still far too expensive to be within the reach of most consumers or small businesses. The largely "vertical" nature of the industry at this time is depicted below. 5 Computer Industry 1983 Consulting Applications Tools OS IBM HP ICL Networking Peripherals Computers Processors 17. In 1975, my friend Paul Allen and I saw an article in a magazine called Popular Electronics describing a new computing device called the MITS Altair 8800. This device was a far cry from what people think of today as a personal computer. Ordered through the mail, the Altair arrived as a box of parts with some instructions on how to assemble it. As such, the Altair was strictly for computer hobbyists. When assembled, the Altair was a breadbox-sized machine with rows of switches and a few lights that, with the addition of some software, could be made to blink. 18. Although the Altair did not do much, Paul and I recognized that it was the start of a trend that had the potential to revolutionize the computer world. The Altair was made possible by a new invention: a computer on a single integrated circuit (or "microprocessor"). The microprocessor integrated circuits enabling thousands (and today, many millions) of functions. The advent of the microprocessor carried with it the possibility of making computing power far more affordable and thus widely available. 6 19. We recognized that to make the Altair and other microprocessor- based devices useful, they were going to need software. I left college, and Paul and I founded a company to develop great microprocessor software, which we called Microsoft. It was not much of a business in its early years, just Paul, me and a small group of developers we hired banging out code day and night in spartan offices in Albuquerque, New Mexico. But it was a labor of love. 20. Our primary product, Microsoft Basic, was a programming language, the first for this new breed of computing device. During our first five years in business, our products were directed almost entirely at helping software developers create applications for this device. From the start, we recognized that the potential of microprocessor-based computers (or microcomputers, as they became known) would not be realized unless a broad array of useful software products were written to run on them. Although the market at the time was tiny, we aimed to fill the need for programming languages and software tools to make it easy to develop microcomputer software. We knew that our vision could not be achieved without the creativity and innovation of many developers, including developers working for other companies. So we began Microsoft with a unique focus: building tools to enable thousands of software developers to create the vast range of applications that would ultimately make computers useful for consumers and businesses of all sizes. 21. By 1980, a number of companies were offering microcomputers that were the precursors to today's personal computer. Unfortunately, however, the personal computer industry was developing along the lines of mainframe computing: the offerings of various computer manufacturers were separate islands in the sea of computing. Early 7 PCs such as the Tandy TRS-80, the Apple II, the Commodore PET, the Atari 800 and others each ran their own, distinct operating systems. That meant that software applications written for one line of computer would not run on any other line. End users thus could not easily share information among computers and they had to learn a different set of skills to operate each one. In other words, the fledgling PC industry was fragmented. 22. In mid-1980, IBM approached Microsoft with its plans to introduce an IBM "personal computer" (a term that IBM coined). We were very enthusiastic about this development. We hoped that the resources, expertise and cachet of IBM would help people to recognize that the PC could be much more than a "toy," as many then regarded it to be. 23. IBM was on a fast-track to develop its PC, and asked if Microsoft (by then based near Seattle) would license our BASIC language product in order to make their PC more accessible to software developers, which we did. They also asked that we supply operating system software for the device. We agreed to do so. We quickly acquired rights to a small operating system program (called Q-DOS, for Quick and Dirty Operating System) and hired its developer, Tim Paterson, to work with us to develop an operating system that would meet IBM's needs. Within nine months we produced an operating system that met IBM's specifications. Since that small beginning, Microsoft has invested more than $6 billion in developing its operating system products (and billions more in creating development tools and applications that enhance the value of the platform). 24. When released in 1981, the IBM PC was available with a choice of three operating systems: CP/M-86, UCSD-P System and MS-DOS from Microsoft. Over time Microsoft's operating system became the most popular because we worked 8 relentlessly to improve it, adding new features and other innovations to the platform, we widely licensed it at attractive prices as a consistent software platform that would promote interoperability among a wide range of hardware and software products, and we helped developers to build applications for the operating system. 25. Early on, we recognized that consumers would benefit greatly if a wide range of hardware and software products could interoperate with one another. Among other things, (i) the products would be more useful if information could be exchanged among them, and (ii) development costs would fall and a broader array of products would become available if they could be developed for larger customer segments without the need to rewrite software to target narrow platforms. As more products became available and more information could be exchanged, more consumers would be attracted to the platform, which would in turn attract more investment in product development for the platform. Economists call this a "network effect," but at the time we called it the "positive feedback loop." 26. Given these benefits, we expected that the market would attach great value to any product that enabled such broad interoperability. As I explain more fully below in Section II.B, Microsoft committed itself to providing compatibility among a wide range of products, as we believed the market would demand. There were three key and closely-interrelated elements to our strategy, a strategy that is unchanged to this day. 27. First, we worked hard to develop MS-DOS (and later Microsoft Windows) as a useful platform for software developers. We built capabilities into MS-DOS which developers could draw upon in building their own applications, freeing them from the need to recreate these capabilities on their own. With each succeeding release of MS- 9 DOS, we added new capabilities (all of which consumers take for granted today), thereby facilitating the efficient development of innovative new applications. Then, as now, these capabilities are "exposed" to developers via application programming interfaces or "APIs." As we added new APIs, we also went to great lengths to continue to support existing APIs so that older applications would run well on newer versions of MS-DOS and Windows. We thus preserved the integrity and utility of our operating systems even as we drove the platform forward with new technologies such as the graphical user interface in the late 1980s and Internet technologies such as HTML in the mid-1990s. 28. Second, we broadly licensed MS-DOS at low prices to any OEM that was interested. This freed developers from the need to create entirely separate applications for each line of PC. With very minor exceptions not relevant here, MS-DOS was the same on each line of PC from different OEMs, masking differences in the underlying hardware platform. As a result, developers knew that they could create an application to run on MS- DOS and that it would run not only on the IBM PC, but also on any other PC that used MS- DOS as its operating system. OEMs, in turn, knew that they could build a PC based on MS-DOS without bearing the substantial costs of designing, developing and testing an operating system themselves, and that their PC then would run the growing body of applications written to MS-DOS, making their PCs more valuable to consumers. 29. Third, we actively assisted software developers in making use of the APIs exposed by MS-DOS, providing them with software development tools and technical information concerning the operating system, and instructions. We called the employees who spread the word of the platform benefits of MS-DOS "evangelists," reflecting the passion and commitment with which they went about their jobs. Today Microsoft invests 10 many hundreds of millions of dollars annually in developing tools, information and other resources to facilitate the development of products that interoperate with our operating system. Our Developer and Platform Evangelism Division, some 2,500 employees strong, is dedicated to this work. Hundreds of evangelists are stationed around the world to assist developers in building products that interoperate with Windows. 30. Microsoft's development and evangelization of MS-DOS (and later Windows) was critical to the creation of the PC industry. At first dozens, later hundreds, and eventually thousands of OEMs came into existence and built PCs based on the R&D work of Intel, AMD and others on compatible microprocessors and Microsoft on successive versions of MS-DOS. Similarly, thousands of ISVs were formed to build software applications that took advantage of the ever-growing range of capabilities provided by MS- DOS, which in turn was made possible by exponential growth in the underlying processing capability of microprocessors. 31. With the success of MS-DOS and the products built to work well with it, the PC industry was organized along a "horizontal" model, quite unlike the model that prevailed in the days of mainframe computing or even in the early days of the PC industry. Under this model, shown below, a wide variety of companies provide hardware and software products and services that are broadly compatible with one another. 11 become much easier to use and more useful, sparking new rounds of productivity gains and empowering users. 34. Many of Microsoft's most important competitors have chosen alternative business and technology strategies, often focused more on selling relatively expensive hardware than on facilitating broad interoperability. For example, Apple has historically chosen not to license its Apple Macintosh operating system products to other OEMs, preferring to obtain the competitive advantage it perceives from being the only OEM to offer PCs that feature the Mac OS. While offering Apple certain advantages (such as the ability to ensure that its hardware and software are optimized to work very well together), that strategy provides consumers with much less choice in software and hardware that work with the Mac OS. 35. In mid-1985, I urged Apple to license its Macintosh operating system software to other OEMs, and I offered to help Apple do so. (My July 8, 1985 letter to John Sculley, and an accompanying memorandum dated June 25, 1985 setting out my views more fully, is in evidence as DX 2245 and is submitted here as DX 1558. A follow-up memorandum that I sent to Mr. Sculley on July 29, 1985 is in evidence as DX 2246 and is submitted here as DX 1559.) Among other things, I explained to Apple that I was enthusiastic about the benefits of licensing Mac technology to other OEMs because "[t]he IBM [PC] architecture, when compared to the Macintosh, probably has more than 100 times the engineering resources applied to it when investment of compatible manufacturers is included." DX 1558. (The term "IBM architecture" referred generally to PCs that were built in accordance with IBM's original decision to use an Intel chip and Microsoft operating system.) Microsoft was interested in promoting the development of the Apple 13 Macintosh platform because Microsoft was the leading ISV for Apple and enthusiastic about the capabilities of the Apple platform. 36. Today one of Microsoft's most important competitors is Sun Microsystems. Sun is primarily focused on selling network server hardware. Like Apple, Sun's software efforts are primarily directed at promoting its hardware business. Sun also offers its own, proprietary version of UNIX called "Solaris." Solaris is mostly used to run on hardware offered by Sun itself. UNIX applications must be customized, at considerable expense, to take full advantage of the Solaris operating system. 37. I believe that Sun is feeling considerable competitive pressure from OEMs such as Compaq, Dell and Hewlett-Packard that are building server hardware that use server versions of Windows operating systems. In its server operating system business, Microsoft is following the same high volume/low cost strategy that has been so successful on the desktop. By making its server operating systems widely available to OEMs at attractive prices, Microsoft enables OEMs to build server hardware that is substantially less expensive than Sun's offerings. B. NEW TECHNOLOGY INITIATIVES 38. Microsoft is not content to rest on the extent to which software presently helps people as they go about their daily lives. While PCs are used by nearly every knowledge worker and in more than half of American homes (a success rate that seemed barely imaginable twenty years ago), we believe that breakthrough technologies now under development can make software vastly more useful, easier to use and more reliable. Our strategic direction in technology development is called ".NET." .NET 14 includes our work on Trustworthy Computing, an initiative to help bring about computers that are far more available, reliable and secure than they are today. 1. .NET 39. The broad connectivity among computers provided by the Internet provides an infrastructure that software developers can use to build new products that will greatly promote interoperability among computers running any operating system, from mainframes to PCs to small, handheld devices. Microsoft is at the forefront of industry efforts to define new technical standards, promulgated by standards bodies such as the World Wide Web Consortium, that will facilitate the exchange of information and functionality across widely disparate computing platforms. 40. These emerging standards collectively define technology known within the industry as "XML Web Services." XML Web Services can be thought of as software programs that provide functionality to other programs, located on the same computer or other computers (around the corner or around the world), through a defined set of industry-standard interfaces. Of particular note here, the interoperating computer programs can be run on any operating system. Early examples of XML Web Services are already up and running on Windows and various UNIX operating systems. 41. Microsoft was an early pioneer in defining and standardizing XML and associated technologies. Today Microsoft is working closely with IBM and others to define and enhance standards relating to XML Web services, working through the World Wide Web Consortium, the new Web Services Interoperability Organization, and other standards bodies. 15 42. Microsoft's implementation of XML Web Services standards is an important part of our .NET efforts. Our goal is to deliver the best implementation of a platform for building XML Web Services. As a result, we will strive to provide the best price/performance, the best scalability across multiple computers and the best development tools to take advantage of the platform. We believe that we are well situated to deliver on our .NET platform vision because of our deep experience in developing and evangelizing platforms that have a proven track record of meeting industry needs. 43. Our key developer tool for building next-generation software, Visual Studio.NET, was released earlier this year following more than three years of development work. It has been very well received by the developer community. Using Visual Studio.NET, developers can create software products in any of approximately 30 programming languages, including Java, that will run on Microsoft's .NET platform software. (Most programs written for Sun's Java platform are written in a single programming language, Sun's own Java language.) 44. Microsoft also developed a brand new programming language, called C# (pronounced "C-sharp"), that is tuned to the needs of developing XML Web Services. Microsoft submitted the specifications for C# to the European Computer Manufacturers' Association (ECMA) so that the language could become an industry standard, and ECMA adopted C# as a standard in December 2001. (By contrast, Sun has touted Java as an industry standard, but withdrew it from the ECMA standard setting process and maintains proprietary control over the language.) 45. Software products written using Visual Studio.NET will interoperate with products that adhere to the relevant industry standards for XML Web Services whether 16 or not those programs are running on any Microsoft operating system or other Microsoft platform software. That is the beauty of XML Web Services--they enable access to data and functionality any time, on any device, running any software. 46. Realization of our .NET vision will take many years and many billions of dollars of R&D investment by Microsoft and partners who share our vision. If successful, however, we believe that .NET will bring about growth in economic productivity that will exceed the productivity benefits to date from the development and broad adoption of PC technology. 2. Trustworthy Computing 47. To make computing more pervasive, the industry needs to build systems that excel in availability, reliability and security, which I call "Trustworthy Computing." Today the PC ecosystem falls short in all three respects. Internet connections may fail, software programs may crash, and viruses may infect any computer that interacts with any other. Even when working as designed, computers remain too hard to use. Absent sustained effort to attack these engineering challenges, the problem is likely to get worse, not better, as the computing environment becomes ever more complex with greater interoperation of a broad range of devices via the Internet and other networks. 48. I have committed Microsoft to developing software that will promote Trustworthy Computing. Our Visual Studio.NET development tool is an important step in this direction. Visual Studio.NET is the first multi-language development tool that is optimized for the creation of secure code. Advanced programming techniques embodied in Visual Studio.NET will also enable developers to write "managed" code--code that is less prone to a wide variety of programming errors. 17 II. KEY ASPECTS OF MICROSOFT'S BUSINESS THAT ARE IMPERILED BY THE NSPR 49. Three overarching aspects of Microsoft's business and technology model are imperiled by the NSPR: (i) the considerable benefits provided by Microsoft's ongoing development of successive versions of Windows as consistent, well-tested, well- supported platforms for software development; (ii) Microsoft's efforts to promote the development of a broad range of hardware and software products that interoperate well with one another; and (iii) the central role played by intellectual property protection in providing an incentive for Microsoft to invest capital, time and energy in software development. I discuss each of these in turn. A. THE PLATFORM VALUE PROVIDED BY WINDOWS 50. The primary value that Windows provides to the economy is that it is a full-featured platform for software development that promotes compatibility across a broad range of hardware and software products. I believe that many provisions of the NSPR would prevent Windows from continuing to provide that value. 51. In the discussion that follows in this subsection, I explain why it is highly efficient for software programs to be built on high-quality software platforms. I then identify three aspects of Microsoft's development of Windows that are essential to the success of that product, all of which are imperiled by the NSPR's vision of a world in which OEMs and third parties could remove important software code from Windows as well as by other provisions of the NSPR. 52. A "platform" is software that provides capabilities that can be used by ISVs in creating their own software programs. Modern computer operating systems usually serve as platforms. 18 53. Developers are free to use as few or as many of the capabilities in an underlying platform as they like. Developers are always free to create their own programs to provide any capability provided by Windows (and to draw upon other Windows capabilities in doing so). 54. Capabilities provided by operating systems are often referred to as "system services." A software program can make use of a system service by making a "call" to an API. When an application "calls" an API, the operating system performs the function associated with that API by causing the underlying microprocessor to perform a specified set of instructions. For example, an ISV can call upon Windows to cause a set of user interface controls, such as toolbars, menus, or back and forward buttons, to appear in the ISV's application. 55. A simple example of an API is the ChooseFont API. By calling this Windows API, an ISV is able to display the following dialog box in its software program. 19 By calling a set of Windows APIs that relate to fonts, an ISV can create a software program that easily enables users to create documents using a wide variety of fonts provided by Windows. 56. Windows exposes a very rich set of capabilities for ISVs to use today through more than 6,000 APIs (in very round numbers). These APIs are generally referred to in the industry as the "Win32 API set" because the APIs were introduced in connection with Microsoft's 32-bit operating systems. We have added to and improved upon these APIs as our operating system technology has evolved. 57. The availability of a consistent, high quality software platform frees ISVs from the need to repeatedly "reinvent the wheel." Rather than expend resources to develop technology already developed by others, ISVs can simply call on the underlying operating system, often with just a few keystrokes. That frees ISVs to focus on building the unique features of their own products and very substantially reduces development time and costs. 58. The availability of consistent, high quality platform software also promotes compatibility among software programs from a wide range of developers, which in turn makes software programs easier to develop and use. For example, the Internet Explorer system services in Windows provide an implementation of HTTP, a key industry- standard protocol for transmitting information (such as Web pages) over the Internet. By calling on the HTTP support in Windows, any ISV can develop an application that can upload and download information to and from other programs in a compatible way (even if those programs are running on a UNIX operating system, as they often are on the Web), 20 avoiding various problems that may arise if each ISV developed its own implementation of HTTP. 59. Another example of a system service in Windows that promotes interoperability is Microsoft's Component Object Model or "COM." COM provides a set of methods, exposed via Windows APIs, for ISVs to exchange information and functionality among software programs. When you embed an Excel spreadsheet in a Word document, for example, you are using COM services provided by the underlying Windows operating system. Thousands of software applications take advantage of the COM technologies in Windows. 60. The availability of a stable, consistent set of system services in Windows also enables ISVs to create programs that adhere to common user interface elements, promoting compatibility among programs. For example, consumers who become familiar with the "ChooseFont" dialog box shown above when working with one program will feel comfortable when presented with the same or a similar dialog box in other Windows-based programs that call upon it. Similarly, Windows exposes APIs that make it easy to create the "toolbars" that often appear at the top of applications. End users, who learn how to use icons, drop down menus and the like in one application written for Windows, will likely have an easier time learning how to use similar features in other Windows-based applications, particularly if the ISV elects to conform to user interface conventions established by Microsoft to promote such ease of use. (ISVs who wish to develop their own font controls or toolbars are of course free to do that.) 61. I believe that through years of effort and billions of dollars in R&D, Microsoft has done a better job than any other company at providing ISVs and the PC 21 industry generally with the benefits of a platform for software development. Three key aspects of our work in Windows, however, are imperiled by the NSPR. These three aspects are discussed below. 1. The Integrity of the Windows Platform 62. The NSPR would undermine the utility of Windows as a development platform by requiring Microsoft to enable anyone who offers to license 10,000 copies to remove blocks of software code from Windows before providing it to consumers. (Sections 1, 2(c), 7 and 22.x.) If software code is removed, the Windows APIs provided by that code will no longer function. That means that applications that call upon those APIs will fail to function properly or may not run at all (depending upon which APIs are rendered inoperable). 63. If OEMs and others remove software code from Windows, as the NSPR would authorize them to do, then the Windows platform would "fragment." Once fragmented, Windows no longer would provide ISVs with a well-defined set of APIs on which they can rely to provide useful functionality. Under the NSPR, one OEM might ship software marketed as "Windows" without its Web browsing software, another OEM might ship software marketed as "Windows" without its media creation, delivery and playback software, while a third OEM might ship software marketed as "Windows" without its instant messaging software, all categories of software that provide useful APIs to ISVs. Other OEMs might remove smaller parts of Windows, such as its HTML rendering engine (a part of the Web browsing software in Windows) or even subsets of that. 64. Sections 1 and 22.x.i of the NSRP identify categories of software that Microsoft must make optionally removable within six months of entry of the NSPR, ten of 22 which cover software in existing versions of Windows. Additional software in other unspecified categories also must be made optionally removable under Section 22.x.ii by an unspecified date. Assuming that just ten blocks of code were made optionally removable under the NSRP, however, there would be more than 1,000 variations of Windows that OEMs and others could create from each release of Windows. 65. If OEMs installed idiosyncratic variations of Windows on new PCs, ISVs seeking out to build new applications could no longer rely on Windows to provide useful functionality. On any given installation of Windows, useful system services might be available, or they might not, depending on which software code the OEM elected to remove. ISVs are less likely to call on services provided by Windows APIs if their customers may be running variations of Windows from which APIs have been removed. ISVs would then be required to develop and test customized versions of their applications for each major variation of Windows. 66. Customers would soon be faced with the prospect of finding and distinguishing among, for example, Corel WordPerfect for Compaq Windows, Corel WordPerfect for Dell Windows and Corel WordPerfect for Gateway Windows (and for Sun Windows and AOL Windows), each with varying capabilities reflecting the underlying capabilities of the version of Windows to which they were written. Software innovation would slow as ISVs devoted greater resources to (i) duplicating functionality that Windows might otherwise provide and (ii) testing many variations of their products to reflect variations in the underlying operating systems. 67. Once multiple versions of popular applications were created to run on specific versions of Windows, OEMs could no longer provide Windows-based PCs to 23 customers with the value proposition that customers could run any of thousands of Windows applications on their PCs. Far from providing any assurance of quality, the Windows brand would mean whatever anyone who offers to license 10,000 copies wanted it to mean (or whatever their sub-licensees wanted it to mean). 68. Consumers expect to know how to use their home PC after learning how to use a PC at work or at school, and vice versa. Once various idiosyncratic versions of Windows are created, however, consumers would lose the ability to easily transfer their learning from one PC to another. 69. In short, if the Windows platform were to fragment, the primary value it provides--the ability to provide compatibility across a wide range of software and hardware--would be lost. Windows would no longer offer an efficient platform to ISVs because Windows would not consist of any single platform on which ISVs could rely in developing applications. (See Demonstrative Exhibit 1.) 70. As software programs became more costly to develop and offered fewer new innovations, consumers would have less incentive to buy new PCs. The same "positive feedback loop" that propelled the PC industry to years' of steady growth would work in reverse, causing the industry to stagnate as products became more expensive to develop even as they provided fewer benefits and less interoperability. 2. Innovation in Windows 71. One of the reasons Microsoft's operating system has been successful is that ISVs and OEMs know that Microsoft is committed to working tirelessly to improve the Windows platform by providing new capabilities made possible by more powerful microprocessors. As famously stated in "Moore's Law," microprocessor power has grown 24 exponentially, doubling roughly every 18 to 24 months. Today's microprocessors provide more computing power than an IBM mainframe of a generation ago. Rapid growth in microprocessor power makes possible major new innovations in the next layer of the computing architecture ­ operating systems. New capabilities in operating systems, in turn, enable ISVs to provide new innovations in their applications. The availability of new applications spurs sales of new PCs. 72. Absent steady advances in operating systems and applications, consumers have little reason to buy new software products since software never wears out. That is why it is especially important in the software industry that new product releases provide consumers with new capabilities. The point is well-illustrated by Microsoft's development of Windows 95, an operating system that provided the industry with a wide range of advances, sparking years of very strong growth in PC hardware and software sales. 73. Microsoft's large and rapidly growing investments in operating system R&D reflect our belief that improving Windows, in part by adding new capabilities, is vitally important. As Chart 1 Chart 1: Operating System R&D Expense $1,400 shows, we are committing ever $1,200 $1,000 greater resources to improving $800 our operating system products $600 $ Million (both client and server), which $400 $200 provides direct benefits to $0 consumers. FY82 FY83 FY84 FY85 FY86 FY87 FY88 FY89 FY90 FY91 FY92 FY93 FY94 FY95 FY96 FY97 FY98 FY99 FY00 FY01 74. By providing OEMs and others with the right to remove software code in at least ten categories from Windows, the NSPR would essentially "draw a line 25 around Windows," as competitors once urged the DOJ to do. If OEMs and others were free to remove software code from the ten or more so-called "middleware" categories from Windows, all that ISVs could rely upon in developing new products would be the relatively small and ill-defined subset of Windows that remained. I believe that some of the witnesses for the non-settling States have referred to this as the "core Windows operating system," although the NSPR provides no statement as to what would constitute the "core." 75. Similarly, it appears that Windows itself could not rely upon any software code that fell into any of the ten or more "middleware" categories. This point is unclear because Section 1 of the NSPR provides no clear guidance and the testimony of the non-settling States' witnesses are in conflict with one another. That means that Section 1 would expose Microsoft to contempt liability for engaging in the basic engineering practice of pursuing an integrated design, i.e., a design whereby one part of Windows would rely on capabilities provided by another part of Windows. 76. For example, Microsoft developed a new "Help" system in the mid- 1990s that presented information about how to use Windows in the HTML format, thereby enabling a richer presentation of data, use of Back and Forward buttons and hyperlinks (as used in a Web browser), and other advantages. As is Microsoft's usual practice, we also exposed the capabilities of our new HTML-based Help system to ISVs through published APIs. These APIs enabled ISVs quickly and easily to create HTML-based Help systems for their own applications. The Help systems in future versions of Windows will provide Help through short video clips with audio, which many people find easier to follow than text. Some of our applications already do so today. 26 77. The NSPR may prevent Microsoft from providing these new capabilities in Windows. Our software for displaying information in the HTML format is provided by the Web browsing software in Windows, a category of software that Microsoft must enable OEMs and others to remove. Section 1 states that despite the removal of such software code, the operating system must "perform effectively and without degradation (other than the elimination of the functionalities of any removed Microsoft Middleware Product)." Section 2(c) states flatly that any OEM and others can "remove the code for Microsoft Middleware Products." 78. I cannot tell from these sections and the associated definitions what software files (or routines within files) Microsoft must find a way to make "removable" from Windows and what features must still "perform[ ] effectively and without degradation." For instance, I understand that the non-settling States' Rule 30(b)(6) witness, California Assistant Attorney General Tom Greene, testified that it would be permissible if the removal of "middleware" broke "audio" Help, but not text-based Help. As I understand it, Mr. Greene testified that text-based Help is a "basic" operating system function, and thus should remain no matter what software code is removed, but that "audio" Help is not. (Deposition of Tom Greene, March 12, 2002 at 66-67.) 79. As a matter of principle, there is no distinction between Help information presented in one format (text) as opposed to another (audio or even multimedia). Consumers will take multimedia Help for granted in the near future. Nothing in the NSPR draws a distinction between Help information presented one way rather than another. Faced with that kind of uncertainty, Section 1 would require Microsoft to attempt to design and develop new operating systems so that no part of the operating system relied 27 on any other part that might be considered middleware and thus, might be removable under Section 1. Here again, the resulting operating system--bloated and slowed with the duplicate code needed to eliminate cross-dependencies--would have only a small subset of the functions of Windows today, a subset that could be designed so that none of the pieces necessary to its proper operation can be removed before it reaches customers. 80. Going forward, nearly any new feature that Microsoft might contemplate providing in a new version of Windows would likely be regarded as "middleware" under the extremely broad definition of "Microsoft Middleware Product" provided in Section 22.x.ii. That is true because for any platform feature that Microsoft might add to Windows, there is likely to be at least one other firm in the industry that provides some similar software that exposes at least a few APIs, thereby turning the Windows feature into a removable "Microsoft Middleware Product" under Section 22.x.ii. Section 1 thus could prevent Microsoft from adding significant new features to future versions of Windows in a way that would ensure that those features reach consumers and can be relied on by software developers. 81. By reducing Windows to some undefined "core operating system," the NSPR would turn back the clock on Windows development by about ten years and effectively freeze it there. While operating system and platform competitors continue to add new cutting-edge features to their products, Windows would be stuck until 2012 (the term of the NSPR) in circa 1992-era functionality. 3. Testing to Assure Product Quality 82. A third key aspect of Microsoft's successful development and promotion of its Windows operating system products that is imperiled by the NSPR is the 28 work Microsoft does to test thoroughly each operating system product it releases. Our testing work is not glamorous, but it is essential to the success of Windows in the marketplace. 83. Modern operating systems such as Windows are enormously complex products. Windows XP, for example, contains literally tens of millions of lines of software code, developed over the course of many years by thousands of engineers at Microsoft. In the course of creating any complex software product, bugs and other problems always arise. The only way to find these problems is to test thoroughly the product, trying out all its capabilities in a rigorous, organized way under various scenarios. 84. The process of testing Windows is greatly complicated by the fact that Windows must work with hardware and software from thousands of other companies. Focusing just on PC components, Windows must work well with various microprocessors, motherboards, video cards, audio cards, graphics cards, hard drives, floppy drives, CD and DVD drives, modems, and so forth. Windows must also work well with a wide range of peripherals, including printers, monitors, keyboards, pointing devices, joysticks, cameras, scanners, camcorders, digital music players, handheld devices, memory card readers, security devices and more. 85. We must test to ensure that Windows correctly performs the functions that those products expect from it. We must also test to ensure that the interaction of those products with Windows and with each other does not cause problems. For example, an application may make changes to a PC that inadvertently causes another application to malfunction. 29 86. To release a quality product, we test Windows against various combinations of the wide range of hardware and software products. Our testing effort is massive. In fact, to create a new version of Windows, we generally put more testers than developers on the project. Put differently, at least half of the work we do to produce a new version of Windows involves testing the product, not writing the software. In the case of Windows XP, about 1,900 testers were involved in testing Windows XP for about 20 months. In round numbers, we subjected Windows XP to more than 5,000,000 hours of testing at a cost of roughly $500 million. 87. We also subject each new release of Windows to an exhaustive external testing process, subjecting it to use in the field and collecting feedback from customers both on features and performance. Microsoft distributed nearly 500,000 copies of beta versions of Windows XP for testing. This "beta testing" process also reveals bugs, typically tens of thousands of them. The final months of the development process for a new release of Windows are devoted almost entirely to identifying bugs through internal and external testing and fixing them. 88. The testing burden does not end even after a new version of Windows is released. Upon release, customers inevitably find still more bugs in the product, some that may be quite obscure yet important to particular customers. Microsoft undertakes to fix many of these for specific customers by issuing code updates in the form of QFEs, which stands for "Quick Fix Engineering." In the case of Windows 2000, for example, we provided customers with approximately 1,600 QFEs within the first year of its release. 30 89. In Windows XP we introduced an innovation that enables Microsoft and ISVs to draw upon real-world data in order to discover and fix problems in the interoperation of Windows, applications, third party drivers and other software installed on a PC and hardware. When a problem occurs, the operating system will in most cases display a message inviting the user to send an anonymous "error report" to Microsoft containing details on the nature of the problem. (The report is transmitted over the Internet using the HTTP support we built into the operating system.) We get a massive volume of error reports, enabling Microsoft to see which problems come up most frequently and dedicate resources to fixing them. We are working on improvements to Windows that will enable us to fix problems that users report without any further action by them, completing an excellent feedback loop between Microsoft and its customers. In addition, we recently created a portal where ISVs and IHVs may access the error data that pertains to their products, enabling them to identify and fix problems as well. 90. As I explain more fully in Section III, it would be utterly impractical for Microsoft to undertake the level of testing and problem solving described above if the NSPR were in place. As it stands today, Microsoft typically conducts testing against two primary versions of a new Windows desktop operating system, one of which (the "professional" version) is a superset of the other (the "home" version). Microsoft could not assure the level of quality that it provides today if we were required to test Windows on the assumption that OEMs or others might run Windows in any of 1,000 or more variations, with entire blocks of interdependent code removed altogether. Nor could we effectively diagnose and fix problems that arise when PCs are actually in use. 31 B. MICROSOFT'S PROMOTION OF INTEROPERABILITY 91. Over the years, Microsoft has worked to ensure that products from a variety of companies work well together. Indeed, I believe that Microsoft has done more to promote interoperability among computer products than any other company in history. 92. Literally tens of thousands of hardware and software products interoperate very well with Windows today. Such interoperability extends not only to products in the PC ecosystem, but also to products in the larger computing ecosystem, such as servers that run UNIX operating systems and other computing devices that do not run Windows. The vast majority of large organizations in the world run heterogeneous computing systems, consisting of various combinations of (i) mainframes, (ii) servers running a variety of Microsoft and non-Microsoft operating systems and hosting powerful database software from Oracle and others, and (iii) PCs running Windows. These systems work well today, and they contribute powerfully to economic productivity. 93. Interoperability across disparate computing products does not happen by accident. Interoperability is a two-way street, requiring a lot of hard work between companies that want to build interoperable products. As discussed below, Microsoft devotes enormous efforts to promoting interoperability between a wide variety of products and Windows. These efforts include our development and broad licensing of the Windows platform (described above) and our disclosure of vast amounts of technical information about Windows--information that we provide to our direct competitors, such as Sun. 94. We work to enable interoperability because the market demands it. Proof of our success is provided by the large number of products that interoperate with Windows today, including server software from Sun and Novell and, of course, tens of 32 thousands of Web sites that run on various versions of UNIX and are accessible from Windows-based PCs. 95. Given the complexity of modern computing technology, the speed with which it changes, and the large number of products that interoperate with Windows, issues will always arise concerning the precise manner in which one product interoperates with another. Typically, interoperability among disparate products may be achieved multiple ways, and we attempt to work through these issues and provide the marketplace with the interoperability it values one way or another. 96. As in any area of technology, room for improvement always exists, and Microsoft is working hard to continue to enhance interoperability in a wide variety of ways. Among other things, we are continuing to build support for industry-standard protocols and other industry-standard technologies into Windows, thereby enhancing interoperability between Windows and non-Windows operating systems. For this and other reasons, Windows XP provides greater opportunities for interoperability than did Windows 2000, and Windows 2000 provided greater opportunities for interoperability than its predecessor, Windows NT 4.0. The NSPR would frustrate our efforts in this regard by authorizing OEMs and others to remove technologies, including support for basic Internet standards like HTML and HTTP, from Windows that are essential to broad interoperability. 97. Microsoft's .NET initiative is directed at enabling broad interoperability across wired and wireless networks, regardless of operating system, device or programming language. I believe that no other company in the industry shares as broad a vision or is devoting as many resources as Microsoft is to making such interoperability a reality. 33 98. In the discussion below, I briefly identify four important ways in which Microsoft promotes interoperability today. The NSPR threatens all of them. As I will explain in Section III, many provisions of the NSPR would hinder, rather than promote, interoperability. 1. Development of APIs and Protocols 99. One of the primary ways in which Microsoft promotes interoperability is through the development of technology in Windows that supports various APIs and protocols. Using APIs exposed by Windows, ISVs can create software programs that work very well with the operating system. Literally millions of individual software developers create programs that run on Windows. The vast majority do so without any direct interaction with Microsoft, drawing on the enormous volume of technical information made available by Microsoft and on high-quality development tools offered by Microsoft and others, such as Rational Software and Borland. 100. In addition, the rich set of APIs provided by Windows can be used to create software programs that act as bridges between Windows and non-Windows operating systems. For example, Novell's technology model for its flagship NetWare operating system products entails installation of client software on Windows and non-Windows PCs to facilitate interoperation between PCs and servers running NetWare. 101. A protocol is a method of communicating information across a network. Morse Code, a series of dots and dashes that represent letters of the alphabet, is an example of a very simple protocol outside the context of computing. 102. Using protocols supported in Windows, or other protocols that developers can add to Windows, information can be exchanged between Windows-based 34 PCs and computers running other operating systems. For example, as I briefly alluded to above, the Web browsing software in Windows includes a system service known as WININET that enables any developer to create programs that interoperate with Windows using the industry-standard HTTP protocol. To take one example, personal finance software such as Intuit's Quicken and Microsoft Money use the HTTP support built into Windows to transmit financial information, such as account balances and stock prices, to and from computers at banks and brokerages (computers that often run a version of UNIX). 103. As shown in Appendix A, Microsoft has steadily increased the number of protocols supported in Windows that it makes available to developers, enhancing interoperability with each new release. We will continue to do so in the future. 104. I understand that the non-settling States believe the Court should enter a disclosure remedy in this matter directed at "permit[ting] rival software to achieve interoperability with Microsoft software . . . ." (Plaintiff Litigating States' First Amended Proposed Remedy, March 4, 2002 at 12.) Section 4 of the NSRP would mandate an extraordinarily broad disclosure of technical information concerning Windows interfaces and protocols. Yet, all the disclosure imaginable will do little to promote interoperability if, as Sections 1, 2 and 7 provide, OEMs and others are free to remove the software that supports the disclosed interfaces and protocols from Windows. If software code is removed, the APIs and protocols supported by that code are removed as well. 2. Disclosure of Technical Information 105. I believe that Microsoft discloses more technical information about its products than any other software company. In fact, Microsoft actively "evangelizes" Windows by providing developers with technical information about it and encouraging 35 them both to use Windows and to provide feedback to Microsoft. Microsoft's documentation and evangelization of technical information concerning Windows are key reasons why Windows is successful. 106. Detailed information concerning the Win32 API set and other technical aspects of Windows are widely available in bookstores. Developers writing programs to work with Windows can choose from among development tools offered by Microsoft or others. These tools usually include relevant portions of Microsoft's Windows Platform Software Development Kit (or "SDK"). The Windows Platform SDK is a set of tools and documentation that Microsoft broadly licenses to software developers (at little or no cost) to assist in creating software that runs on Windows. 107. An important method by which Microsoft disseminates technical information directly to the developer community is through the Microsoft Developer Network ("MSDN"). (The MSDN Web site is at http://msdn.microsoft.com/default.asp.) MSDN contains an enormous body of technical information about Windows and other Microsoft products. A great deal of information is available free of charge on MSDN, and additional information useful to professional developers is available with the purchase of low-cost subscriptions to the service. Access to MSDN is available to any developer, including Microsoft's direct competitors. For example, Sun Microsystems has more than 100 subscriptions to MSDN. 108. Through the free MSDN Web site, any software developer can receive extensive documentation about Windows APIs. MSDN also includes other forms of technical information and resources for developers, such as SDKs for Windows and other products, Device Driver Kits (which assist in writing software that interfaces with 36 hardware devices), royalty-free sample applications (demonstrating techniques for software development using Microsoft technologies), and access to the Microsoft Developer Knowledge Base (a database of tens of thousands of articles containing bug reports and "workarounds" relating to Microsoft development products). MSDN is also where developers go to obtain full copies of shipping products and beta code for products that are still under development. 109. MSDN materials also are distributed to developers on CD-ROMs and DVDs. Subscribers to MSDN receive hundreds of disks worth of software and information, each year, all fully indexed and searchable. 110. MSDN is very popular with developers. More than 4 million developers use the Web site each month. Last year, developers generated nearly a half billion page views (one developer viewing one page) on MSDN. 111. Another important way in which Microsoft distributes technical information about its products is through various conferences, which are open to all and designed to meet the needs of various constituencies in the software developer community. About once every twelve to eighteen months, for example, Microsoft holds a large Professional Developers Conference (PDC). Microsoft's PDCs are multi-day events featuring a wide variety of seminars (about 200 this year) designed to educate developers about the latest technologies under development at Microsoft and provide them with insight into Microsoft's future platform plans. 112. Our most recent PDC was held in October 2001, and nearly 7,000 developers attended. I give the keynote speech nearly every year, focusing on important technology trends that we believe developers should start taking advantage of in their 37 products. This year we focused on Web services and Microsoft's .NET platform for building such services. 113. Other important developer events hosted by Microsoft include Developer Days and Tech·Ed. Typically held annually, Developer Days consists of regional presentations concerning technical aspects of Windows and other Microsoft technologies. Microsoft's most recent Developer Days events were held in 32 cities in the United States in early November 2001. Dozens more were held overseas. 114. Tech·Ed is another multi-day conference, aimed at a broader base of software developers, that provides extensive technical information about Microsoft products. Our most recent Tech·Ed was held April 9-13 in New Orleans, and featured more than 200 sessions on how to build products that take advantage of a wide range of Microsoft products, including Windows. 115. Microsoft's PDCs, Developer Days and Tech·Ed events are open to all developers, including Microsoft's competitors. 116. For the reasons set forth in Section III, the utility of Microsoft's disclosures of technical information described above would be greatly reduced if the NSPR were in effect. Among other things, Microsoft would be obligated to devote massive resources to documenting thousands of internal interfaces within Windows that are neither intended nor tested for use by external developers rather than focusing upon delivering documentation that developers actually need to make products that work well with Windows. Even more fundamentally, the NSPR would greatly reduce Microsoft's incentive to invest in innovation, so that there would be fewer innovative technologies in the future that would be of any interest to developers. 38 3. Microsoft's Open Review Process 117. Another important way in which Microsoft discloses technical information about its products--and receives valuable feedback--is Microsoft's Open Review Process. Through this process, Microsoft provides alpha and beta code to developers interested in particular technologies and obtains extensive feedback concerning how the technology should be developed to best meet their needs. 118. The Open Review Process begins even before Microsoft starts developing many new technologies. The first step is Microsoft's presentation of a technical proposal for a new initiative to a group of a few dozen developers who are likely to be interested in using the technology. After collecting their feedback, Microsoft conducts a "design preview," which is a more in-depth look at the technology plans, to a somewhat larger group of developers. The next step is a "design review," which provides still more detail about the project under development and will usually include actual code built to the specifications under discussion. Developers are invited to use the code and provide additional feedback both as to design and as to Microsoft's implementation of the design. Finally, Microsoft prepares a final specification, which typically will be posted to MSDN and made available to the developer community at large via SDKs and the like. 119. Our development of innovative new directory and management services in Windows 2000 provides a useful case study of the Open Review Process. In August 1995 and February 1996, four years before Windows 2000 was released, we conducted Design Previews of early specifications for our planned directory and management services in the new operating system for about 80 to 120 developers. The next month, we provided updated specifications to about 300 developers who attended the relevant seminar at our Internet Professional Developers Conference. In July 1996, we 39 provided early beta code and updated specifications to about 90 developers, and in November, we provided about 3,000 developers with a preview (pre-beta) version of Windows NT 5.0 (as Windows 2000 was then known) that included our directory and management services. We held another Design Preview in May 1997 (for about 180 developers), released Beta 1 of Windows NT 5.0 to 6,000 developers at our Windows NT 5.0 PDC in September 1997, and conducted yet another Design Review for 65 developers in November 1997. By the time it was released commercially, Microsoft had distributed hundreds of thousands of beta test copies of Windows NT 5.0 worldwide. 120. By the time Windows 2000 was released in February 2000, the process of reviewing, testing and providing feedback on its directory and management services that began with a few dozen developers 4½ years earlier had grown to thousands of developers outside of Microsoft. 121. Microsoft would be prohibited from providing information and obtaining feedback via the Open Review Process if the NSPR were in effect. Section 4, read in conjunction with the definition of Timely Manner (Section 22.pp), appears to require that Microsoft disclose technical information to the industry generally (ISVs, IHVs, etc.) at the same time that information is "disclosed to any third party." It is not practical to disclose information concerning a new technology to the industry at large before specifications for the new technology have even been prepared, much less before significant development work has been undertaken. 4. Testing Interoperability 122. Testing is essential to ensuring that products interoperate with each other. No other software company engages in product testing that approaches the scope and 40 complexity of Windows testing because no other product seeks to provide compatibility with as many third-party hardware and software products as Windows. A very substantial portion of all the testing we do on Windows is directed toward testing the interoperation of Windows with other software and hardware products, including non-Microsoft server operating systems, such as UNIX. Even in a theoretical world of perfect information flow between developers working on two products, testing would be essential to find bugs or other problems in their implementation (the code they actually wrote) as the two products interact with one another. 123. As I described above, it would not be feasible to test all the many variations of Windows that OEMs and others might elect to ship under the NSPR. Absent such testing, bugs will not be found, quality will inevitably decline and interoperability will suffer. C. INTELLECTUAL PROPERTY RIGHTS 124. Microsoft is an intellectual property (IP) company. We have no factories of any consequence or natural resources. Indeed, we have no physical assets of any kind that are important to the success of the company. Our products instead consist almost entirely of information we create--primarily instructions to microprocessors on how to perform various functions. Those instructions are reflected in source code (written by Microsoft software developers) and object code (a machine-readable form of the code written by developers, created by running that source code through a "compiler" program). The source code, object code and related information are protected to varying extents by copyright, patent and trade secret law. 41 125. Some of Microsoft's most valuable intellectual property is the trade secrets that may be learned by reviewing the source code to our products. Unlike patent and copyright rights, which survive any disclosure, trade secrets are forever lost once revealed. 126. Absent intellectual property protection, there would be little reason to invest in developing software. Software can be copied and distributed quickly and at near- zero marginal cost. The very low marginal cost of copying software means that if two firms have rights to the same piece of software, the price of that software quickly tends to be competed down to zero. 127. Even absent literal copying of software code, software innovations developed by one firm can be implemented by competitors writing their own code. The more information one firm has about a competitor's product, the easier it is to copy the key features and other innovations of the product. In the software industry, some information about competitors' products is available, and other information is protected by IP laws. If Microsoft's competitors were permitted to implement many of Microsoft's innovations in their own products without regard to Microsoft IP rights, Microsoft would have little it could uniquely offer the marketplace. No firm can do unique R&D in the software industry absent significant IP protection for its work. 128. As I will detail on a provision by provision basis in Section III, the NSPR would strip Microsoft of a broad range of very valuable IP rights-- IP rights that, together with our employees, constitute Microsoft's most important assets and thus underpin the company's market capitalization of approximately $300 billion. The NSPR directly targets the two most important products at Microsoft, Windows and Office. These 42 two products collectively account for approximately two-thirds of our revenue. Very briefly, the NSPR would: · Transfer important IP rights in Windows from Microsoft to anyone who wishes to license 10,000 copies, allowing them to remove important parts of Windows before delivering it to the marketplace and to modify it in many other important ways while still marketing the resulting operating system to consumers under the "Windows" trademark; · Impose price controls on Windows that would effectively penalize Microsoft for investing in improvements to Windows and reward third parties who impaired the product by removing functionality; · Grant equal rights to everyone in the industry to some of the most innovative work Microsoft has ever done, i.e., the development of Microsoft's industry- leading Web browsing software, in which we have invested more than $750 million; · Grant three companies full licenses to Microsoft's Office technology--as it exists today and all improvements we may make for ten years--and the right to use that technology to offer Microsoft's Office technology on various platforms, including clones of Windows, on the basis of an "auction" that would greatly devalue Office by vesting four companies with rights to the same technology; and · Require Microsoft to provide the industry at large with rights to a vast range of IP concerning the inner workings of Windows and Office, including access to actual source code, that would be useful to competitors seeking to emulate Microsoft's innovations in Windows. With the exception of the Office "auction," the NSPR would provide all of this IP to Microsoft's competitors entirely free of charge. In fact, Section 4 is so sweeping (especially when read in conjunction with the defined terms) that nearly anyone in the industry could demand that Microsoft provide it with royalty-free access to nearly any 43 important Microsoft platform technology under a claim that access to that technology was necessary to enable interoperability. 129. Microsoft is investing $4.5 billion in R&D this year. If the NSPR were in effect, it would not be sensible for Microsoft to invest nearly so heavily in Windows and Office innovation. There would be little reason to invest in R&D under the NSPR because Microsoft would become simply a technology provider to its competitors, receiving little economic return for our past work or for new work on Windows or Office for the next ten years. III. THE NSPR 130. I believe that the NSPR would greatly reduce Microsoft's incentive and ability to develop and deliver new technologies to the marketplace. The consequences would be three-fold. First, all those who build upon or otherwise benefit from Microsoft's heavy investment in developing new technologies--OEMs, ISVs and the businesses and consumers who use our software--would be harmed. With the loss of the positive feedback benefits provided by Windows, the marketplace would experience higher prices and less innovation. 131. Second, Microsoft would be greatly devalued as a company. Microsoft's market capitalization is based on the market's well-founded belief that Microsoft is on a path to deliver a wide range of breakthrough technologies that will generate new sources of revenue. 132. Third, competition would be reduced not only in operating systems, but also in key product categories where Microsoft is the strongest challenger to incumbent leaders, such as online services (where AOL Time Warner leads), handheld devices (where 44 Palm leads) and game consoles (where Sony leads). Indeed, in the important area of server computing--both hardware and software--the strongest competitive challenge to incumbent, high-price UNIX vendors such as Sun is the PC model of multiple, competing OEMs building upon a standard, widely licensed and attractively priced operating system, such as Windows 2000 Server. 133. This section of my testimony describes the NSPR on a provision by provision basis, explaining why the remedies proposed by the non-settling States would reduce Microsoft's development and delivery of new technologies. I begin in Section III.A by identifying three overarching problems that run throughout the NSPR. Section III.B then discusses each substantive provision of the proposed remedy. A. OVERARCHING PROBLEMS 134. There are three key aspects of the NSPR--the breadth of the covered product categories, the vagueness and ambiguity of many of its most important provisions, and the feasibility of complying with various of its requirements--that are especially alarming to me. I believe that these aspects of the NSPR would make it extremely difficult for Microsoft to understand the requirements of the NSPR, to comply fully with the requirements it does understand, and to continue to deliver new technologies to the marketplace. In short, the practical effect of the NSPR would be to cripple Microsoft as a technology company. 1. Breadth of Regulated Product Categories 135. I understand that this lawsuit concerns competition in operating systems for PCs. The NSPR, however, imposes sweeping restrictions on Microsoft without regard to the product category at issue in this lawsuit. I provide several examples below. 45 a. "Any Microsoft Product" 136. Section 6.c provides that Microsoft may not enter into any agreement in which any third party agrees to distribute, promote or use any Microsoft product, service, feature or technology exclusively or in a fixed percentage. Yet such agreements are common throughout the economy and are often vitally important to creating economic value. For example, game console vendors compete in part by attracting ISVs to offer popular games exclusively for their game console. Many games are available only on the leading Sony PlayStation, not on Microsoft's new Xbox or Nintendo game systems, and Sony promotes the PlayStation on that basis. Microsoft needs the ability to promote Xbox on that basis as well if we are to compete in the game console business. 137. Similarly, simple advertising deals often entail a third party's commitment to "promote" the advertised product exclusively or in a fixed percentage. For example, MSN might enter into an arrangement to be the "exclusive sponsor" of an event presented on the Internet, such as the release of a new album from a music artist, or another Web site might agree to run MSN advertising on some percentage of its Web pages for a specified period of time. In either case the third party would be promoting MSN exclusively or in a fixed percentage. Such routine business transactions would be prohibited by Section 6 of the NSPR. 138. Similarly, Section 8 prohibits Microsoft from taking any action that directly or indirectly adversely affects a third party based on its use, distribution, promotion, support or development of any non-Microsoft product, service, feature or technology. Section 8 is very broadly worded: it appears to prohibit Microsoft from competing in any product category because nearly any act of competition could be said to directly or indirectly adversely affect a competitor. 46 b. Middleware Definitions 139. The "Middleware" definitions in Sections 22.w and 22.x are at once extremely broad and, as discussed below, vague and ambiguous. Since the meaning and effect of many provisions of the NSPR turn on the various definitions of "middleware," the scope of these terms is critical. 140. I understand that the trial primarily concerned Microsoft's efforts to compete with Web browsing software from Netscape and, to a lesser extent, with various aspects of Sun's Java. Plaintiffs alleged that Netscape Navigator and Java had the potential to develop into software development platforms that would run on multiple PC operating systems. If a sufficient number of ISVs wrote applications that drew on capabilities provided by these platforms, Plaintiffs argued, consumers would have less interest in running Windows and might use non-Microsoft operating systems under their Web browsing (or Java) software layer. As Plaintiffs noted, I expressed concern in my 1995 memorandum on the rise of the Internet that Netscape was "mov[ing] the key API[s] into the client to commoditize the underlying operating system." (In evidence as GX 20 and offered here as DX 1487.) 141. My understanding is that the Court of Appeals' liability determination turned largely on Netscape's ability to distribute Navigator (and with it, Java, according to plaintiffs) in two channels of distribution: the OEM channel and the IAP channel. 142. The potential competitive significance of Netscape Navigator and Sun's Java turned on two key attributes of those programs, neither of which is shared by the many software categories deemed to be middleware under the NSPR. 47 143. First, Navigator and Java supposedly had the potential to become general-purpose software development platforms. In other words, under plaintiffs' theory, Navigator and Java had the potential to provide a full set of system services, via APIs, so that developers could write applications such as word processing software, spreadsheets and personal finance software to them as platforms. If the platforms were good (a big "if" because developing good platform software is hard), ISVs might well write applications to run on Navigator or Java rather than Windows. 144. At the time, we were struck by the statement of Marc Andreesen, a co-founder of Netscape, that Navigator would reduce Windows to little more than a "poorly debugged set of device drivers." That statement meant that Navigator would strive to compete directly with Windows, providing the key APIs to developers and leaving Windows simply to handle PC interaction with peripheral devices such as monitors and printers. With the benefit of hindsight, we now know that Netscape never did the hard work needed to become a PC applications platform, but it could have and AOL certainly has the resources to pursue this strategy today. Similarly, Sun provided a quite broad set of system services (through its Java class libraries) to enable the development of a broad range of applications on the Java platform. For example, Corel produced a beta version of its office productivity suite, complete with word processor, database, presentations software and so forth, to run on the Java platform. Corel's Java-based office productivity suite did not succeed due to various shortcomings in the client-side Java platform. 145. Second, Navigator and Java both ran on Windows and other PC operating systems and thereby competed with similar system services in Windows to the extent they provided APIs to developers building PC applications. 48 146. The NSPR does not reflect either of the attributes of Navigator and Java that were so important to the competitive challenge they potentially posed to Windows. The elements that define "Middleware" in Section 22.w are listed below. None of them significantly bounds the types of software that would fit the NSPR's definition of middleware. To be "Middleware," software must be: a) "provided in the form of files installed on a computer or in the form of Web- Based Software" All software consists of files installed on a computer (whether that is a client or server computer), so this is no limitation at all. b) "operates directly or through other software . . . by offering services via APIs or Communications Interfaces." Nearly any software that runs on a computer can offer services via APIs or Communications Interfaces. c) "and could, if ported . . . . enable software products written for that Middleware to be run on multiple Operating System Products." Many software programs "could" be ported to multiple operating systems and thereby enable any services it provides to be available cross-platform. It is just a matter of doing the necessary work. (Section 22.w.) 147. In short, the definition of "Middleware" in the NSPR appears to be very close to "any software that exposes a few APIs." (In fact, the non-settling States technical expert, Professor Appel, and their Rule 30(b)(6) witness, Mr. Greene, both testified that the presence of a single API can be enough to make a piece of software "Middleware." (Deposition of Andrew Appel, February 2, 2002 at 77; Deposition of Thomas Greene, March 12, 2002 at 61.) Given that nearly any software can expose a few APIs, that definition is just one step short of "all software." But not all software that exposes a few APIs presents any real competitive challenge to a desktop operating system such as Windows. Rather, only software that runs on desktop versions of Windows and 49 other operating systems and competes with Windows by serving as a general purpose development platform (or that reasonably could become such a platform) presents a real competitive challenge. 148. Section 22.w of the NSPR includes as "Middleware" many categories of software that do not serve as general purpose development platforms and thus do not present any significant competitive challenge to Windows. For example, "Handheld Computing Device synchronization software" is just that--a relatively simple program that enables a handheld device such as a Palm Pilot or a Pocket PC to synchronize information such as schedules and email with scheduling and email software on a PC. That is a highly specialized function, not a development platform for building software applications. The same holds true for "calendaring systems." If calendaring software exposes any APIs, those APIs are likely to be useful for a single, specialized purpose: to provide calendaring functionality in another software program. 149. Other than Internet browsers, network operating systems and the Java virtual machine, none of the categories of software listed as "examples" of Middleware in Section 22.w reasonably could become a general purpose development platform. None provides a set of key APIs that could commoditize Windows. Instead, each is directed at specialized functionality that provides at most a very small subset of the functionality of a general purpose platform. 150. Section 22.w is also very broad because it is not limited to software platforms that run on a PC and thus can provide a substitute for PC operating system functionality. For example, Section 22.w states that a "network operating system" is an example of middleware, but such products run, by definition, on servers, not on PCs. 50 (Novell is the only company I know of that markets what it calls a "network operating system.") For many years to come, however, the thousands of applications that run directly on Windows-based PCs today will continue to run on PCs. For that reason, server operating systems, set top box software, and other software that doesn't run on PCs will not commoditize Microsoft's PC operating system software. 151. The definition of Microsoft software that would constitute "Middleware" under the NSPR is similarly unbound. Under Section 22.x, a "Microsoft Middleware Product" is simply any software offered by Microsoft that provides functionality similar to "Middleware." Given the breadth of Section 22.w's definition of "Middleware," that could mean nearly any Microsoft software. Indeed, it is a safe bet that for nearly any Microsoft software that exposes APIs (including any feature of Windows), there will be programs from other software vendors that could be said to provide similar functionality. 152. Section 22.x is not limited to software included in desktop versions of Window, even though the case primarily concerned Microsoft's decision to integrate Web browsing software into its PC operating systems. To the contrary, Section 22.x.ii(1) defines as a "Microsoft Middleware Product" any "Middleware" that Microsoft has distributed separately from an Operating System Product in the past three years (without regard to whether that software is also distributed as part of Windows). Nearly all Microsoft software is distributed separately from an Operating System Product. (Section 22.x.ii(2) then picks up all software within Windows as well.) 153. Section 22.x.i calls out Microsoft Office as an example of middleware. Microsoft Office is the most important application that Microsoft offers. It is 51 not part of Windows. Furthermore, neither Microsoft Office nor the programs with which it competes, such as Corel WordPerfect or Sun StarOffice, are general-purpose development platforms. Microsoft has put a lot of effort into exposing Office functionality to developers via APIs, but that functionality relates solely to business productivity, such as customized word processing or specialized financial reports, not to operating system platform functionality. Office does not provide operating system functionality; it calls into Windows for such functionality. 154. With respect to software in Windows, Section 22.x seems to sweep within its ambit nearly any part of Windows that exposes functionality through one or more APIs--which is to say, most of the product. 155. Another key term exacerbating the breadth of the NSPR is the definition of "Microsoft Platform Software" set out in Section 22.y. The term is not a proxy for "desktop versions of Windows." The term also encompasses any "Microsoft Middleware Product," which includes server versions of Windows, Microsoft Office, the Exchange email server, and any other software offered by Microsoft, running on any kind of computing device, that provides functionality similar to "Middleware" offered by a competitor. As shown above, that could be almost anything under the broad definition of "Middleware." 2. Vagueness and Ambiguity 156. The problems that would result from the extremely broad scope of the NSPR are compounded by the fact that many key provisions are vague and ambiguous. That is of particular concern to me because I want to be certain that Microsoft understands 52 what its obligations are when this lawsuit is concluded so that we can comply fully with the final judgment. 157. Clarity is especially important because so much of the NSPR pertains to engineering decisions. If the final judgment is not clear, we will not know how to build new products that comply with the judgment. 158. In addition, any decisions we make about the meaning of ambiguous provisions will undoubtedly be scrutinized by Microsoft's competitors, leading to one controversy after another, some of which may come before this Court. Absent clarity, the Court will lack any clear basis for adjudicating such controversies. From Microsoft's perspective, on-going controversy would be a very bad outcome. Our objective in trying to settle the case, and our objective now, is to arrive at a set of understandable rules that will govern our operating system business so that we can better avoid protracted and contentious legal confrontations and focus on building great software. a. Internal Inconsistencies 159. Several provisions of the NSPR appear to be inconsistent with one another, either in their command to Microsoft or in their intended purpose. I am concerned that this will lead to difficult questions of interpretation, particularly when the NSPR is read in view of its direction that "[a]ll of the provisions of the Final Judgment . . . will be interpreted broadly consistent with its remedies purpose . . . ." (Section 21.c.) 160. For example, Section 4 imposes broad obligations on Microsoft to disclose a wide range of technical information concerning interfaces in Windows for the stated purpose of promoting interoperability with Windows. Yet Sections 1 and 2 authorize third parties to remove large portions of Windows, including software that supports the 53 interfaces that must be disclosed under Section 4. If OEMs remove software that supports APIs, disclosure concerning those APIs is not going to promote interoperability. The APIs will not work if the software is removed and developers will be much less likely to use them if that is a possibility. 161. Similarly, Section 16 establishes circumstances under which Microsoft is obligated to comply "fully" with certain industry standards in Windows (and other products). Once again, Microsoft would be unable to provide any assurance that its operating systems actually comply with industry standards (so that developers writing applications for Windows could rely upon those standards) if third parties were free to remove the software that implements the standards. If an OEM exercises its right under Sections 1 and 2 to remove Microsoft's Web browsing software, for example, Windows will no longer comply with the HTTP standard (and other Internet-related standards), in apparent violation of Section 16. b. Middleware Definitions 162. Many of the key terms in the NSPR are defined far more broadly than how the terms are ordinarily used in the computer industry, potentially leading to ambiguity when attempting to apply the terms to our business. Even the term "Microsoft" has been given a special definition that seems to sweep within it nearly any company. ("Microsoft" means Microsoft's "assigns," including "any transferee or assignee of any . . . ability to license the Intellectual Property referred to in this Final Judgment." Many sections of the NSRP grant third parties the right both to (i) take licenses to Microsoft's Intellectual Property and (ii) further grant licenses to that Intellectual Property to others.) 54 163. An important example of vagueness and ambiguity is the NSPR's definitions relating to middleware. There is nothing in Section 22.w that provides any technical or legal distinction between the examples of things that are "Middleware" (such as synchronization software) and those that are not, namely, disk compression and memory management software. 164. Even more troubling is the definition of "Microsoft Middleware Product" in Section 22.x. The NSPR would impose a number of very significant design and disclosure obligations upon Microsoft relating to software--labeled as "Microsoft Middleware Products"--in Windows. However, the NSPR provides no rule for determining which code within Windows constitutes the various "Microsoft Middleware Products" identified by NSPR (much less a rule for determining what code will constitute other "Microsoft Middleware Products" under Section 22.x.ii). That is a serious omission because Microsoft's obligations under Sections 1, 2 and 4 depend entirely on knowing which software code is and is not included within specified middleware categories. If we do not know what code constitutes the various "Microsoft Middleware Products" we will not know how to build operating systems that comply with Sections 1 and 2 or how to make the required disclosures under Section 4. 165. The problem is compounded by the fact that the NSPR appears to define "Middleware" at a very granular level: if even a single API can render a program "Middleware," then small programs or even individual files or parts of files within Windows might well be regarded as "Microsoft Middleware Products" under the NSPR. 166. This is a major problem because the degree of "granularity" (size of modules) that will be applied in defining what software constitutes "Microsoft Middleware 55 Products" is determined by design decisions made by third party software developers (because a "Microsoft Middleware Product" is defined to be software similar to whatever "Middleware" a Microsoft competitor may create). Functionality that Microsoft might well regard to be a feature of Internet Explorer, for example, might well be offered as a standalone product by a third party, rendering portions of Internet Explorer "Microsoft Middleware Products" in their own right. 167. Of course, when designing new operating systems, Microsoft will not have complete knowledge of all the software programs available in the world that may be deemed "Middleware," much less software programs that may be released after Microsoft makes key design decisions, committing itself to a particular development path based on decisions concerning where the "Microsoft Middleware Products" lines would be drawn. 168. The central problem is that the NSPR--and much of the testimony of the non-settling States' witnesses--proceeds on a faulty premise. The NSPR and the non- settling States' witnesses speak of Windows as if it consisted of a small, self-contained and fully functional operating system (which they sometimes refer to as the "kernel" or the "core operating system") and a collection of readily identifiable, add-on middleware products that might just as easily be distributed separately from the operating system. In fact, each version of Windows is designed as a single, integrated product that provides a broad range of functionality. Various parts of the operating system provide functionality to other parts of the operating system (through interfaces that may or not be documented for external use) as well as to developers (through documented APIs). Given the interdependencies among parts of Windows, and the complexity of the product, there is no 56 clear dividing line between where a particular block of "middleware" ends and the rest of the operating system begins. 169. Such integration--an important aspect of product innovation and competition--is essentially the process of breaking down boundaries between formerly disparate technologies. In the past, consumers purchased and installed a separate "spellchecker" application, and ran it when the time came to "spell check" a document. Today, spell checking is just another feature of a word processor that we take for granted. Rather than launch a separate spelling application, word processing software such as Microsoft Word recognizes spelling errors as they occur and corrects many of them automatically with no user intervention. As a result, the "boundary" between the "word processor" and the "spell checker" has largely disappeared. 170. The significance of the NSPR's failure to define the boundary between "Middleware" in Windows and the rest of the operating system is well illustrated by the record of this case. Microsoft repeatedly pressed Plaintiffs to identify which software in Windows they believed constituted Internet Explorer. We never got an answer. Does Internet Explorer include the software that enables Web pages (or any other software) to display information formatted in HTML? Does it include software that supports the HTTP protocol? We think the answer to both questions is plainly "yes," yet at trial Plaintiffs appear to argue that these important files were part of Windows not Internet Explorer. (See Plaintiffs' Revised Proposed Findings of Fact at ¶¶ 161.2.2, 154.3.2.) 171. Although the parties devoted considerable resources to litigating the question of what software actually constitutes Internet Explorer, Judge Jackson never resolved the matter (perhaps because Plaintiffs focused upon removing end user access to 57 Web browsing, rather than Web browsing code itself). The testimony put on by the non- settling States in this proceeding continues to be unclear on this point. For example, Professor Appel testified that when "unbinding" Internet Explorer from Windows, HTTP support should be removed, but FTP support (another protocol for transferring files) should not. Yet both are just protocols for transferring information between two computers and both are supported in every Web browser. What distinguishes them for purposes of determining Microsoft's engineering obligations under Sections 1 and 2(c)? Professor Appel deemed the date they first became popular to be significant, but there is no such test in the NSPR, and in any event Professor Appel did not suggest that a "date" test would apply in determining what other Windows code was part of other "Microsoft Middleware Products." (Trial Transcript, April 10, 2002 at 3091-93.) 172. A clear rule for determining what code in Windows constitutes the various "Microsoft Middleware Products" is essential to application of Sections 1, 2 and 4. To attempt to comply with Sections 1 and 2, we would need to know what software code must be made optionally removable without degrading the rest of the operating system. For example, does removing Internet Explorer entail removing the HTML rendering software in Windows? That is an important question because many parts of the user interface of Windows, including its Help system, rely on that HTML rendering software. If we design an "unbound" operating system that leaves the HTML software in place when an OEM "removes" Internet Explorer, competitors may claim that we have not really enabled the removal of Internet Explorer because HTML software is integral to Web browsing. Yet if we design an "unbound" operating system in which HTML software is removed when 58 Internet Explorer is removed, then others may claim that other parts of the operating system that rely on that HTML software have been degraded (and they would be). 173. In other words, Section 1's instruction to redesign Windows to enable "binary code" to be removed without causing any "degradation" of the product would put Microsoft on the horns of a dilemma as to each middleware removal decision: remove too little code, and be charged not removing the "Microsoft Middleware Product," or remove too much code, and be charged with "degrading" the operating system. 174. The problem of not knowing what software code to make "removable" is compounded by the fact that there are many categories of "Microsoft Middleware Products" in Windows and as to each program falling into one of those categories our engineers would face multiple line drawing questions. 175. Absent a rule delineating the boundaries of "Microsoft Middleware Products," Microsoft also would not know what it would be required to do to comply with Section 4. Section 4.a.ii would obligate Microsoft to disclose the interfaces between "Microsoft Middleware Products" and the rest of the operating system. Obviously our engineers would need to know where the line is between each "Microsoft Middleware Product" and the rest of the operating system in order to disclose the interfaces between them. Furthermore, under the definitions of the NSPR, the disclosure of new interfaces can lead to additional parts of the operating system being deemed a "Microsoft Middleware Product" (see Section III.B.4.b), leading to ever larger number of line drawing problems-- problems with no answer in the language of the NSPR. 59 c. Ordinary Business Practices 176. Section 8 provides another important example of ambiguity in the NSPR, made worse by the very broad scope of the provision. Do the non-settling States reall