This comment is on the proposed settlement in U.S. vs. Microsoft, and on the Remedial Proposals by State of New York et al vs. Microsoft.
THE OPEN SOURCE SOFTWARE INTEREST
My interest in the outcome of this case is a consequence of my participation in the open source software community. I'm a long-time user and advocate of the Linux/GNU family of operating systems and related open source applications; also, I'm a stockholder in Red Hat, Inc., a commercial distributor of open source software.
Antitrust legislation and litigation concerns not only the direct parties in the case, but the public interest as well.
Obviously, the interests of the open source community form a subset of the public interest, because that community is part of the public. However, open source software and its development are related to the interests of the general public in a much closer way. Open source programming is fundamentally about freedom. This body of software is developed largely by end users, for the benefit of end users. Most open source projects encourage anyone to contribute improvements. Also, anyone is at liberty to start a new project and build on the existing body of open software. The most common licenses encourage wide distribution of the fruits of this open-ended collaboration.
The nature of the open source community makes it a powerful force against monopolism. It is possibly the only body today able to offer the public serious alternatives to Microsoft operating systems and office productivity applications, and thus effectively counteract Microsoft's unrelenting campaign to preserve and extend its monopoly. In certain parts of the world a growing user base has already begun to abandon Microsoft products in favor of open source replacements.
Because of the diversity of this community, it can have no single representative able to speak for all. It is not a business, though it includes businesses. It's not a private club, though it includes a great number of local users' groups. Its most productive components, the "projects", usually don't have even that amount of organization; they're geographically dispersed teams of volunteer programmers sharing source code over the internet, who prefer to give their attention to the programs they have a need for, rather than and unwanted apparatus of officers and treasuries. University research programs and undergraduate programming classes are involved, and many of the customs and practices derive from the open traditions of academic research. A great deal has been accomplished by unaffiliated individuals. Thus, different members of this community will contribute different perspectives to this public issue.
DEFECTS OF THE PROPOSED SETTLEMENT AND REMEDIAL PROPOSALS
The remedies in the proposed settlement are written around "ISVs, IHVs, IAPs, ICPs, and OEMs" -- all business entities (section I). Developers and suppliers of open source software are neither mentioned nor contemplated. Indeed, section J paragraph 2 speaks of "reasonable business needs" and "authenticity and viability of its business".
"ISV" is counter-intuitively defined to be a supplier of a software product that runs on a Windows Operating System product -- thereby excluding a supplier of a software product that runs on a non-Microsoft operating system, or a supplier of a non-Microsoft operating system.
The information to be disclosed to non-Microsoft entities includes APIs, protocols, and documentation for middleware (section D). It does not include user data file formats used by applications. The language of section I could reasonably be interpreted to assert intellectual property rights to any information which is not specifically required to be disclosed; that could be used to restrict the analysis and documentation by outsiders of an application's external behavior, or the use of information they have already compiled by behavioral analysis. That would have profound implications; in effect, it would manipulate the Court into restoring and strengthening an application monopoly which the open source community has already broken.
These are not accidental oversights. These provisions are carefully crafted to exclude open source software developers from access to the technical information necessary to make their creations interoperable with Microsoft systems and application software.
Several open source operating systems have fully demonstrated their readiness for the most demanding commercial service. Open source office productivity applications have matured to a point where their relative merits compared to Microsoft equivalents are as much a matter of opinion and taste as objective fact. Star Office / Open Office, in particular, has achieved a high degree of interoperability with Microsoft Office file formats.
Now the struggle between Microsoft and the open source community is converging on offering end users the freedom to migrate their existing document and data files from proprietary Microsoft formats to next-generation open-standard replacements. This migration process relies heavily on "filters", which are utility programs that convert one file format to another. Historically, open source projects have analyzed sample document files to deduce their formatting, so that filters can be written. Once these filters exist, end users can migrate to a different application package at will without losing their investment in their data. Equally, users of non-Microsoft applications can put their work into formats that Microsoft applications can read and edit. Microsoft's most important weapon to obstruct end-user defection and prevent the emergence of a level playing field is the obscurity of the file formats used by its office applications. If they can continually change their file formats to break compatibility, then deny access to the revised format information by a combination of secrecy and legal measures, they can erect high barriers against migration to non-Microsoft applications, or exchanging document files with users of non-Microsoft applications and operating systems. This is a powerful anticompetitive tactic.
Why agree to share information with certain businesses, but not with open source developers? Because Microsoft has a long history of success in buying out or smothering commercial suppliers of any product that endangers its monopoly position -- it has every reason to be confident of its ability to continue the same proven strategy.
Those methods don't work against open source developers. These developers aren't carrying the weight of a business, so they don't need revenue -- therefore there's no way to cut off their resources. Legal harassment is impractical, because they're scattered through hundreds of jurisdictions with radically different legal systems, some of which are promoting open source software as a matter of national security policy. Their code is released under licenses that make monopolization virtually impossible. Their distribution costs are negligible. Their archives are duplicated and backed up all around the world. And because anybody with a computer and a modem can participate at will, their numbers, productivity, and code quality are far beyond any business's ability to match.
Section B applies only to "Covered OEMs", which are defined to be only the 20 largest-volume OEMs. This leaves Microsoft considerable room to impose discriminatory terms and rates on all its other customers, and thus penalize any behavior it wants to discourage. Smaller OEMs are the ones most likely to respond to end users' requirements and preferences -- such as offering customers a choice of Microsoft, non-Microsoft, dual-boot, or no pre-installed software.
Section C says nothing about adjusting royalties when Microsoft middleware is replaced by non-Microsoft middleware, or simply deleted.
New York et al's Remedial Proposals offer important improvements. Their section B paragraph 2-ii contains the important phrase "actual volume of total shipments of the licensed products", meaning that Microsoft is paid only for Microsoft products shipped, and not the total number of computers shipped by the OEM including those on which Microsoft products are not installed. This is a critical issue to the open source community, since it removes an economic barrier to offering a choice of software to the OEM's customers -- and to offering machines without software to those who prefer to do their own installations or boot from the local network.
They do not, however, propose to provide open source developers with the same external interface information as business entities, nor do they include application file formats among the information to be disclosed except indirectly by interpretation of a definition (section C paragraph 4). Also, in their provisions for interoperability, they discuss middleware but not applications; this effectively protects only suppliers of software that runs on Microsoft operating systems.
They do propose to force Microsoft to open-source Internet Explorer. Other open source users and developers may disagree with me about this, but I don't believe that would be useful at this late date. Open source versions of Netscape and its successor Mozilla are already the dominant browsers on open source operating systems. Nearly four years of work have been invested in bringing the original commercial source code up to the standards of open source projects, so that substantive progress can now be made. Most of the commercially-produced Netscape code had to be discarded and rewritten from scratch. It's unlikely that a development team could be assembled that would be willing to undertake similar remedial work on Internet Explorer. In general, open source developers would have little interest in looking at Microsoft source code. It's the external behavior that's important for interoperability, not the internal design.
They propose to make the porting of Microsoft Office to some non-Microsoft operating systems mandatory. This is interesting, in that it could become a stepping stone for Microsoft users to abandon Windows first and Office later, rather than attempting both changes at once. Several years ago most of the open source community would have been interested in porting Office, but the work on replacements is far advanced now. It's of interest that the latest version of the only non-Microsoft OS which runs Office now is Mac-OS X, which is actually a commercial Unix operating system underneath the Macintosh user interface. Thus, this version of Office uses Unix APIs. Most non-Microsoft operating systems with any significant popularity today are derived from Unix (FreeBSD, OpenBSD, Solaris, HP-UX, AIX, Linux, GNU Hurd, SCO Unix); thus, it would be relatively easy to write the Mac-OS source code according to recognized Unix portability standards, so that it would compile on any Unix platform. However, the language of the proposal is so vague on what the target operating systems would be, that Microsoft could choose BeOS, OS/2, and Plan 9, thus frustrating the intent.
Section L of the Remedial Proposals is of great importance to open source software. Open source software achieves much of the interoperability among its components and applications by adherence to published formal standards. Interoperability between Microsoft and non-Microsoft systems and applications is essential to creating a level playing field. Thus, requiring Microsoft to be truthful in its claims to standards compliance promotes competition and user choice. It is also important that definitions of "standard" and "de facto standard" are provided, since Microsoft has a history of misusing these terms for deceptive marketing purposes.
1. In section D, "shall disclose to..." should be changed to "shall publish". This would place all software developers on an equal footing, and make crucial interoperability information available to open-source developers working without the financial support of a business. In the same section "APIs and related Documentation" should read "APIs, file formats, communication protocols, and related Documentation"; and "or Microsoft applications to store and communicate user data" should added following "Microsoft Middleware to interoperate with a Windoww Operating Systems Product". This makes explicit the requirement to publish application file formats and network protocols. From the viewpoint of the open source community, enforcing these two requirements is the central issue of the whole case, and the key to breaking the monopoly once and for all. The requirement to disclose application file formats is implied in the Remedial Proposals' definition of "API", but leaving it less than airtight invites tactical litigation and delay. The burden of any such litigation would probably fall on the State Attorneys-General, because nobody in the open source community has the financial resources to take on Microsoft in court.
2. The Remedial Proposals forbid Microsoft from using agreements or retaliation to discourage OEMs from installing non-Microsoft operating systems alongside Windows and allowing the user to control which system is booted. Microsoft should also be prohibited from taking technical measures against multi-booting. It wouldn't be difficult to modify Windows to malfunction in the presence of a non-Microsoft boot loader, intentionally corrupt or overwrite the boot loader, or fail after partition re-sizing.
On the history and nature of open source software: "The Cathedral and the Bazaar" by Eric S. Raymond, http://www.tuxedo.org/~esr/writings/cathedral-bazaar
On the licensing of free and open source software: the General Public License ("GPL") by Richard M. Stallman, http://www.fsf.org/licenses/licenses.html#TOCGPL
On the place of business within the open source community, "Under the Radar" by Robert Young and Wendy Rohm, http://www.redhat.com/radar.html
John A. Carroll