U.S. Department
of Justice
Testimony Of David J. Farber
| This document is available in two formats: this web page (for browsing content) and PDF (comparable to original document formatting). To view the PDF you will need Acrobat Reader, which may be downloaded from the Adobe site. For an official signed copy, please contact the Antitrust Documents Group. |
|
IN THE UNITED STATES DISTRICT COURT
EXPERT TESTIMONY OF PROFESSOR DAVID J. FARBER MY PERSONAL BACKGROUND 1. I am The Alfred Fitler Moore Professor of Telecommunication Systems at the Moore School of Engineering of the University of Pennnsylvania in Philadelphia, Pennsylvania. I have held that endowed chair since 1994. From 1988 to 1994 I was a Professor of Computer Science and Electrical Engineering at the University of Pennsylvania. From 1977 to 1988, I was a Professor of Electrical Engineering and Computer Science at the University of Delaware. From 1970 to 1977, I was an Associate Professor of Information and Computer Sciences and Electrical Engineering at the University of California at Irvine. A copy of my curriculum vitae is attached as Exhibit A to this testimony. 2. As you will see from my curriculum vitae, I have since 1988 been Director of the Distributed Systems Laboratory at the University of Pennsylvania. That Laboratory is the center for research activities in the general systems area for both computer sciences and electrical engineering at the University. In that capacity I am involved in high speed network research with emphasis on its impact on hardware and operating systems. Over the last ten years my research has generally focused on the areas of high speed networking and the implications of that networking on interconnections, protocols and computer hardware and software architecture. During that period, I have also taught graduate and undergraduate courses in the computer science field, including course work concerning software development. 3. From 1987 to 1988, I was Director of the Center for Networking Technology and Applications at the University of Delaware. As Director I was instrumental in the definition and implementation of the early stages of commercialization of the Internet. During the period I was at the University of Delaware, my research work was principally in the area of distributed systems with a focus on the hardware and software necessary to implement such systems. I also led the creation of the University's own computer network and directed University-wide research in distributed systems. 4. In my years at the University of California at Irvine, I created and led what was then one of the largest computer research activity funded by the National Science Foundation -- the Distributed Computer Research Project. That Project created much of the software concepts for future distributed systems activities. 5. During my career, as detailed in my curriculum vitae, I have been Principal Investigator on a number of research projects (funded by government and private sources) related to computer software design and methodology. I have also been awarded two patents. I have published numerous articles in the computer science field and have lectured regularly in this country and around the world at various university and industry seminars. 6. I also have been regularly involved in activities in the business side of computers. I was a founder and Vice President of Caine, Farber and Gordon, Inc. ("CFG"), a private firm which is involved in program design methodology. CFG was an early creator of advanced software and compilers for microsystems and much of the Intel software support for the 8080 (the first pc-family microchip). 7. I have been on the technical staffs of Xerox Data Systems, the RAND Corporation and Bell Laboratories. I am currently on the technical advisory boards of a number of major corporations in the computer field, including Earthlink, Covad and Com21. 8. I have not testified in deposition or at trial as an expert witness in the last ten years, although I have consulted for parties in litigation in the past. I am being paid $300 per hour for my work for the government in this case. THE SUBJECT MATTER OF MY TESTIMONY ON BEHALF OF THE UNITED STATES 9. I have been asked by the Department of Justice to provide my expert opinions on software designed to function as a computer operating system and software applications that browse the World Wide Web via the Internet. The latter software is commonly referred to as an Internet or web browser (which I describe further below). In particular, I will discuss:
These subjects will be addressed from the viewpoints of software developers, original equipment manufacturers ("OEMs") and retail end users. 10. My testimony is based entirely on my lifetime of experience in the field of computer science. The matters about which I testify here concern commonly understood and accepted principles and practices in the field of computer science which are applicable to all software, whether developed by Microsoft or any other company. For that reason, I have done not, and do not believe it is necessary for me to do, extensive analytical work on the details of Windows 98 software (such as Professor Felten has done) in preparation for this testimony. My preparatory work (apart from preparing my report, this testimony and being deposed by Microsoft counsel) has been limited to a meeting with Professor Felten, review of certain memoranda filed by the parties with the Court, this Court's opinion denying summary judgment in this case and the Court of Appeals' decision of June 1998 concerning the Consent Decree entered against Microsoft. TERMINOLOGY USED IN MY TESTIMONY11. I and, I expect, other witnesses will use several technical terms for which I think it is useful to provide my definition for the Court. These definitions include the following:
12. The process of designing, writing, modifying, and testing software is one which is the subject of academic analysis and writing. Modern software is developed in small modules (i.e., routines, subroutines, methods, functions, procedures, etc.) which are aggregated into larger modules (i.e., files), which are in turn aggregated into software products. 13. The nature of the software development process, motivated in part by human limitations in managing design complexity and in part by a motivation of functional reusability, imposes a modular structure on software. A module is the computer software equivalent of a paragraph, in which, via one or more routines, one reasonably-sized function is accomplished. Each routine is a sequence of instructions (i.e. lines of code -- often in one of a number of high level programming languages). An instruction is a call on a lower level routine requesting that the function of the lower level routine be performed using data provided by the higher level routine. For example, if a computer is asked to calculate the hypotenuse of a triangle, it will have to call a lower level routine which computes the sine or cosine of the angle. At the lowest levels, an instruction is directly interpreted by the processor after possible translation by a compiler.One example would be a command to add two integers together. Routines typically contain a few tens to a few hundreds of lines of code each. 14. These software modules are then "knitted together" into unified programs. That is, each software product is built up from simple low level routines that are then called by routines at a higher level of composition. Routines at each level are called by yet higher level routines until the desired functionality of the end product is achieved. In this manner, all software is built up layer by layer through the use of often large numbers of routines, but each with limited complexity. 15. As a result of this layering, software has an inherently malleable and modular structure which gives software developers broad freedom in combining (i.e. bundling) different functions into software products. This malleability also gives a software developer two related types of design freedom: (1) to integrate two separate cd-roms because the functions on one particular cd-rom can be integrated by an OEM or retail end user with functions on another cd-rom and (2) to determine which functions to include within software sold as one product and which to separate and sell as a different product, whether produced by the same or a different software developer, for installation and use together by the a retail end user. Therefore, for example, software malleability provides a developer with the freedom to choose whether to incorporate a particular application (such as a Web browser) into a software product or sell that application separately for later combination by another software developer or retail end user with other software. 16. A common theme in software engineering and among software development methodologies is the advocacy for, and techniques in support of, the modular design and implementation of software. There are several efficiencies which result from development of software in this modular form. These include reduced errors in the development process, easier testing of products, reduced cost and complexity for maintenance and upgrades, and greater possible sharing of software modules among separate products. For example, the function of a computer which permits it to determine the sine of an angle should be modularized so that any application can call that function and, if there are any improvements or errors, the source can be more readily found and changed or corrected. 17. Applications may be large, often involving a very large number of routines. Examples of applications are Microsoft Word, Notepad and Speech Recorder -- as well as Internet Explorer. Software, including applications, must be stored in the form of files. The formation of these types of files (sometimes called dynamically linked libraries or DLLs in the Microsoft Windows world) should be dictated primarily by considerations of storage/loading efficiency (time to prepare the software to run), file reusability (the ability to use all or most of file in more than one application) and execution performance. The most technically efficient size for a file is generally larger than a single routine and smaller than an entire application. Thus, the aggregation of routines into products involves two processes: the routines of the product must be aggregated into files, which must then be aggregated into products, often with connecting code. 18. All the routines that are called directly or indirectly by a program should be available when the program is being used. But whether those routines originate from one particular software program or another is irrelevant to the performance of the functions, so long as the software is written and installed such that the programs work together. Moreover, a software developer is free (subject to minimal limitations of no relevance here) to change the partitioning of routines among files at any time without changing their function or correct operation when the files are combined during execution in an end user's computer. Thus, there is generally no technical reason why a particular routine must be included in the same file with another routine so long as the routines are appropriately compiled and linked in the end user's computer. 19. There are several software tools (i.e., software analogous to machine tools in the manufacturing world) that are used by software developers to accomplish this process of "knitting together" routines into files and, in turn, into programs. These tools include compilers, linkers and loaders. A compiler translates instructions (written in a language efficient for programmers) into the language understood by the computer hardware. A linker takes separately compiled program units (i.e., files or sets of routines) and combines them into a complete program. A loader loads programs, or parts of a program, into the memory of a computer in a form in which it can be executed. Programs are normally compiled only by the software developer and the resulting code files are delivered to the customer. Although the end user may not realize it, loading is typically done by the end user as part of his/her initiating execution of an application. Linking can be performed statically by the software developer or dynamically when needed for execution of an application. APPROPRIATE METHODS TO DEVELOP APPLICATIONS TO RUN ON 20. Developers of software, whether end user applications or OEM components, write their programs with the expectation that certain functions can and will be performed by the operating system of the computer on which the software will be used. The application invokes the operating system by calling routines supplied as part of the operating system. The interconnection is referred to as an application-programming interface (API). An API is the software convention that must be satisfied by a programmer when calling a function provided by the operating system. Access to and use of APIs allows: (1) an application developer to avoid what otherwise may be the expense of writing or purchasing all of the software necessary and (2) the application to run on a computer in conjunction with a specific operating system. 21. Developers of software applications depend on functions provided by the operating system. In that sense, application software developers and any operating system developer share a mutual dependency: applications developers rely on the presence of certain simple, general functions to which they interconnect their applications via APIs while an operating system developer must offer appropriate functions and APIs to which applications developers can write applications in sufficient quantity and quality that OEMs and end users will choose to buy both the operating system and applications. 22. From at least a technical viewpoint, the most efficient operating system is one that includes only those functions described in Paragraph 11(b) above which will be used by large numbers of application and component software development projects or are, by their unusual and peculiar nature, required to be at the operating system level. An example of the latter is security and protection of other operating system functions, which has become more critical as personal computers interconnect in networks which could otherwise invade and damage those computers' operating system functions. Moreover, only functions that are critical to the operating system itself or functions that the operating system makes available in the form of simple, general purpose APIs exist in a very efficient operating system. By way of example, network software that regulates the transfer of information to or from an ethernet card is normally part of an operating system while the file transfer client, which is further up the chain of routines, should not be in the operating system. This distinction is based on real time performance demands and security needs. 23. Inclusion of inappropriate functions at the level of what some software developers call an "operating system" is very likely to impose inefficiencies on application and other software developers, OEMs and retail end users. If the developers must use the particular functions, inappropriately placed in what I and others in the field refer to as "the operating system environment" (to distinguish it from what I consider to be an appropriate operating system), because of the manner in which that operating system environment is written or marketed, developers who need to write applications for that so-called "operating system" will, by definition, be forced to use that particular function regardless of whether that developer would prefer to use another software routine or develop a new one. Even if the structure and marketing of the operating system environment permits the addition of similar functions in addition to the functions provided by the operating system environment, the developer who wants or needs a different method of achieving a particular function must nevertheless write or buy often expensive, additional software. This duplication will likely: (1) increase storage requirements for different versions of software separately developed and included by the operating system vendor and application developer, (2) cause performance degradation from unused functions of the operating system and (3) increase risks of "bugs" (i.e., malfunctions) in software. THE NEGATIVE EFFECTS OF MICROSOFT'S BUNDLING 24. Microsoft claims in its memoranda filed with this Court that certain "efficiencies" result from its "integration" of some of the files (or DLLs) that are included in its Internet Explorer (IE) product as part of Windows 98 (which I refer to as an "operating system environment plus applications" to distinguish it from my definition of a true operating system and an operating system environment). The claims that efficiencies exist from this combination of functions are misleading. While the combination may offer certain efficiencies, these same efficiencies can be achieved without bundling of the Web browser software with what Microsoft calls its Windows operating system. This is because there are no technical barriers that prevent Microsoft from developing and selling its Windows operating system as a stand alone product separate from its browser software -- or other software functions beyond the appropriate operating system functions. Windows 98 (like all other software) necessarily consists of modules which are malleable and separable. There are no technical efficiencies for users achieved by combining Microsoft's browser software with the remainder of the software sold as Windows 98 that could not be achieved by writing two programs in a manner that later could be loaded and "integrated" either by the retail end user (i.e., just as end users install any other application that runs on Windows) or by an OEM. 25. One example of such a division of the existing Windows 98 would be that which I understand Professor Felten has developed with his team. The software which is necessary to accomplish Web browsing can be separated from the remainder of Windows 98 and sold on a separate disk (or some other distinct method). Yet, if an OEM or end user so desires, the operating system, operating system environment and browser application software can be installed by them to create the current version of Windows 98 (with the browser software labelled for commercial purposes as a Microsoft product called Internet Explorer); if that is not desired, an alternative Web browser can be installed with the Windows 98 operating system environment. Moreover, given the completely malleable nature of software and the apparently extensive number of files included in Windows 98, there are very likely to be alternative ways to separate Microsoft's web browsing software from those files which could and should be part of a Windows 98. THE NEGATIVE TECHNICAL CONSEQUENCES OF PERMITTING MICROSOFT 26. I understand that Microsoft claims that it should be permitted to include any software it chooses in its Windows product so long as some efficiency can be articulated as a result of the "integration" of that software into that product. But if that standard were adopted by this Court, then any application could be bundled into Microsoft's Windows product -- regardless of the ability, inherent in the nature of software described above, to achieve that efficiency without combining the applications into an ever larger bundle of software which includes not only operating system functions but operating environment functions and applications. Taken to its logical extreme, that standard would mean that Microsoft could bundle together all its existing and future applications with its current (already massive) product sold as Windows 98. Windows 98 (or whatever later version of Windows) could become the one and only universal software product, and only Microsoft could develop software for Intel-based personal computers. For example, Microsoft could next claim that, because there are some functions which overlap between Windows 98 and Microsoft's suite of applications called Office, now sold separately, those applications could be bundled into one product to achieve some "efficiency". But there is no such "efficiency" which cannot be achieved by the same separate distribution of those applications and their "integration" by an OEM or retail end user when the applications are installed (as is now the case). 27. In my view, any analysis of the propriety of such actions by Microsoft should take at least the three technical factors discussed above into account:
28. None of the above denies the possible convenience or preference of some users for "one stop shopping" for bundled products such as the current version of Windows 98 sold as one product by Microsoft. Those OEMs and retail end users who may find this convenience outweighs any technical inefficiencies described here can certainly still choose to buy Windows 98 in the form it now exists. But only the availability of an unbundled version of Windows 98 will cure the difficulties which arise for many OEMs, application developers and retail end users who may find too burdensome the problems arising from their inability to substitute different functions and applications (such as the Web browser) for use with only parts of what is now sold as Windows 98. The OEMs, developers and retail end users who do not want all the software that Microsoft sells as Windows 98 (including, for example, what Microsoft labels Internet Explorer) suffer the inefficiencies described above. Given the ease with which a properly structured browser application can be unbundled from Windows 98, I know of no technical reason why any OEMs, software developers or retail end users must suffer these negative consequences. I declare under penalty of perjury that the foregoing is true and correct.
Executed on October 8, 1998. Director of the Distributed Systems Laboratory, University of Pennsylvania (1988 -present) Founder and Vice President of Research and Planning for Caine, Farber and Gordon Inc. (1970 -) Principal Member of the Technical Staff, Xerox Data Systems (1969 -1970) Member of the Technical Staff, the RAND Corporation (1967 -1969) Supervisor; Systems Programming Department, Bell Telephone Laboratories (1965 -1966) Principal Investigator, Networking studies, AT&T Bell Labs 1990-1992 ($150,000) Director, Distributed Systems Laboratory, University of Pennsylvania (1988 -) Director. Center for Networking Technology and Applications, University of Delaware (1987-1988) Principal Investigator, Bitnet Modernization, National Science Foundation (1986-1988) [$100,000] Principal Investigator, Memnet, Northrop Corp. (1986 - 1988) [$200,000] Co-Director, Educational Technologies Laboratory, University of Delaware (1985 -1988) Principal Investigator; Internet Mail Relays, ARPA IPTO (1983-1984) Principal Investigator; CSNET Phonenet and CSNET Rjelay, National Science Foundation (1981-1985) [$700,000] Principal Investigator: Computer Message Services, U.S. Army DAKCOM (1979-1984) [$60,000] Principal Investigator; Audio Conferencing, The Institute for the Future (1974-1977) ($100,000) Actively involved in a multimedia experiment involving Fokus Germany and the Univ of Pennsylvania University of Pennsylvania MA (honorary), 1988 Stevens Institute of Technology BSEE, 1956 Stevens Institute of Technology, MS in Math, 1962 Bell Telephone Laboratories Communication Development Program, 1963 (Equivalent to MS in EE) Fellow of the Glocom Insitute of Japan Distinguished Visitor of the IEEE Distinguished Visitor of the IEEE Computer Society Appointed to the Philadelphia Academy of Sciences Program Committee INET 93 and 94 and DTPS 94 and 1CCC 95 Study Committee of the OECD on International Aspects of the HPCC Chairman of the Advisory Board - the First Internet Society Conference - INet '92 Member of the Board of Directors of the ISODE Corporation (1992 - 1993) Member of the Board of Directors of the Electric Frontier Foundation (1991 -) Chairman of the Selection Committee for the Kobayashi Award of the IEEE (1990) Member of the Board of Governors of the Academy of Sciences in Philadelphia (1989 -) Board on Computer Science and Telecommunications of the National Research Council (1991-1995) Board on Telecommunications & Computer Applications, National Research Council (1986-1990) Chairman; CSNET Executive Board, UCAR (1986 -1988) Editorial Board, Computer Networks (1980-1988) Editorial Board, IFIPS Compact Journal (1983-1988) Editor Series in Innovative Computing, Prentice-Hall (1987 -) Recent Invited Addresses (selected) (last three years) SELECTED PUBLICATIONS ( * - student co-author(s)) Realizing the Information Future, National Research Council, 1994. Toward a National Research Network, National Research Council, 1988 Transport Protocols for Department of Defense Data Networks, National Research Council. 1984. Report on the Evolution of a National Supercomputer Access Network - Sciencenet, National Science Foundation, 1984. SNOBOL 3, Co-authored with R-E. Griswold and I.P. Polonsky, Bell System Technical Journal, 1966. APAREL - A Parse Request Language. Co-authored with R. Balzer, Communications of the ACM, 1969. Farber, DJ. "A Survey of Computer Networks." Datamation 18, 4 (April 1972), 36-39. Mockatetris, P., Lyle, M. and Farber, D. "On the Design of Local Network Interfaces", IFIPS 1977 Farber, D. "An Overview of Distributed Processing Aims." 1974 COMPCON. Farber, D. "Software Considerations in Distributed Architecture." COMPUTER 1974 (March). Farber, D., Caine, S. "A Modular Office System", MICRODELCOM 1978 Von Glahn, P., Farber, D. and Walker, S. "The Trusted Office of the Future", Compeon '84 Many additional conference and symposium papers. "Reducing Host Load, Network Load, and Latency in a Distributed Shared" Advisory Boards of Metricom, Com21, AOL and RadioMail. Institute for Defense Analysis, Networks and Distributed processing (1991 - present) (continuing) Ballistic Missile Defense Advanced Technology Center, High availability distributed systems (1975) Bell Northern Research Laboratories (Canada), Office systems and high level protocols (1979) The Federal Communications Commission, Office systems (1980) ADDDITIONAL PUBLICATIONS OF DAVID J. FARBER Cover Feature A Secure and Reliable Bootstrap Architecture Persistent Object Systems: Principles and Practice Gigabit Object Network Proceedings of IEEE Military Communication Conference (MILCOM '92) Proceedings of International Networking Conference (INET '95) The Convergence of Computers and Communications - Part 2 ACM SIGCOMM Award Lecture Recoverability of Modular Systems A Note on Recoverability of Modular Systems AFIPS Conference Proc. of the Nat. Comp. Conference 1975 IEEE Trans. Comm. On the Recovery of Communication Protocols 1994 International Symposium on Robotics and Manufacturing High Performance Communications Cryptographic Support for a Gigabit Network Proceedings, INET '92 Traffic Characteristics of a Distributed Memory System Computer Networks and ISDN Systems The Trusted Office of the Future CapNet - An Alternative Approach to Ultra High Speed Networks Proceedings, International Communication Conference "90 Mirage: A Model for Ultra High-Speed Protocol Analysis and Design Proceedings, Workshop on Protocols for High-Speed Networks Proceedings, 10th International Conference on Distributed Computing Systems ACM Operating Systems Review Proceedings, SIGCOMM'88 Symposium The Distributed Computing System |