On the States' Remedial Proposals in New York vs. Microsoft

In the remedy phase of their antitrust lawsuit against Microsoft, the States have proposed a set of remedies as an alternative to those negotiated by Microsoft and the U.S. Department of Justice.

As a software engineer with 20 years' experience developing software for Unix, Windows, Macintosh, and Linux, I'd like to comment on the States' proposals. In general, the States' proposals appear to be a great improvement, closing many loopholes. However, in my opinion, they are too burdensome in some places, and ineffectual in others. In the follow sections I propose amendments to their Remedial Proposals to address these concerns.

Please note that this document is still evolving, thanks to thoughtful feedback from many readers.

Remedial Proposal C: Mandatory Disclosure to Ensure Interoperability

This proposal is good, but it fails to explicitly include a crucially important Independent Software Vendor, the Open Source community. The Open Source community serves the public interest by providing high quality free software which competes directly with software from Microsoft, but with little penetration into the desktop market as yet. The importance of taking the Open Source community into account in the settlement has been noted by many commentators, including Ralph Nader and Robert Cringely.

Three Open Source projects merit particular mention here:

Wine is an open source, independent reimplementation of the Windows APIs. It's important because it lets operating systems such as Linux, FreeBSD, and Solaris run Windows programs without Windows. It currently only supports a few Windows programs, but is making good progress at supporting more. It still has difficulty with Microsoft Office, which uses many undocumented Windows APIs.

Kerberos is an open source authentication protocol. Microsoft has benefitted greatly from Kerberos, and has incorporated it into Windows 2000 and Microsoft Passport, with some propietary extensions. In May 2000, Microsoft threatened legal action against people who published technical information about these extensions. This may have hampered the development of products which can interoperate with Windows.

Samba is an award-winning, open source, fully compatible replacement for Windows network file servers. Samba actually outperforms Windows. The Samba team has expressed concern that the settlement negotiated by the DOJ specifically exempts Microsoft from providing any information that would aid the Samba project, and thus prevent Samba from maintaining interoperability with Windows.

Projects like Wine, Kerberos, and Samba need access to interoperability information just like any other software vendor. Unlike commercial vendors, however, open source products are neccessarily available for free, and any demand for secrecy or royalties would effectively prevent Open Source products from using the information. Thus provision 4a should be amended to read (new text in bold italics ):

"Microsoft shall disclose and license to ISVs, IHVs, IAPs, ICPs, OEMs and Third-Party Licensees, on an ongoing, basis and in a Timely Manner, in whatever media Microsoft customarily disseminates such information to its own personnel, all APIs, Technical Information and Communications Interfaces that Microsoft employs to enable:..."

and a new subsection d should be added:

The aforementioned license shall grant a royalty-free, non-exclusive perpetual right on a non-discriminatory basis to use this information to create independent implementions of the APIs so disclosed.

Similarly, Section 22r should be amended to read

"ISV" means any entity (including without limitation the Open Source community) other than Microsoft...

Essentially, this says "It should no longer be a secret how to interoperate with Windows, and any Windows APIs used by Microsoft applications such as Office must be well documented."

Remedial Proposal H: Internet Browser Open-Source Licensing

Part of section 12 would require Microsoft to give away the source code to their web browser. This is a highly invasive demand, much more burdensome than requiring interfaces to be documented.

In my opinion, nationalizing the source code for Internet Explorer is problematic for many reasons:

it would be difficult, as it is commingled with the source code for Windows itself
it would not provide the benefits intended, as Microsoft could simply shift all innovation away from the Browser to other products
it would be resisted strenuously by Microsoft
it is not neccesary, as the desired benefits can be obtained by other means

An alternative and less burdensome approach would be to require Microsoft to define a way to plug in new browsers into Windows, and make sure that Microsoft products such as Office and Visual Studio that previously accessed Internet Explorer directly do so using the plugin interface instead. This should be easy, as Microsoft has helpfully devised an API by which all applications access the services of Internet Explorer; all that needs to be done is to allow other browsers to provide that API. Furthermore, Microsoft should be required to publicly disclose and license this API to any ISV (including, for example, the Mozilla project) wishing to plug their browser into Windows as a replacement for Microsoft's browser.

On the other hand, the part of Section 12 that requires Microsoft to disclose and license all APIs related to the browser is a good one; it does not require the disclosure of any browser source code, only browser and operating system interfaces. Thus this part of Section 12 should be retained.

I recommend amending Section 12 to read

~~Internet Browser Open-Source License~~
Open Internet Browser Plugin API
Beginning three months after the date of entry of this Final Judgement, Microsoft shall disclose and license all source code for all Browser products and Browser functionality. In addition, during the remaining term of this Final Judgement, Microsoft shall be required to disclose and make available for license, both at the time of and subsequent to the first beta release (and in no event later than one hundred eighty (180) days prior to its commercian distribution of any Browser product or Browser functionality embedded in another product), all source code for Browser products and Browser functionality. an Open Internet Browser Plugin API to all interested ISVs, shall update Windows so that all Microsoft products which invoke Internet Browser functionality do so via the Browser Plugin API rather than invoking Internet Explorer directly, shall modify all Microsoft products that use Internet Browser functionality to work properly regardless of whether the Internet Browser functionality is provided by a Microsoft browser or by a third party's browser, and shall no longer require that any Microsoft Browser be installed. As part of this disclosure, Microsoft shall identify, provide reasonable explanation of, and disseminate publicly a complete specification of all APIs, Communications Interfaces and Technical Information relating to the Interoperation of Microsoft Internet Browser products and / or functionality and each Microsoft Platform Software product. The aforementioned license shall grant ~~a royalty-free, non-exclusive perpetual right on a non-discriminatory basis to make, use, modify, and distribute without limitation products implementing or derived from Microsoft's source code, and~~ a royalty-free, non-exclusive perpetual right on a non-discriminatory basis to use any Microsoft APIs, Communications Interfaces and Technical Information used or called by Microsoft's Browser products or Browser functionality not otherwise covered by this paragraph.

Remedial Proposal J: Cross-Platform Porting of Office

This proposal aims to "erode the applications barrier to entry for new operating systems", and thereby begin "to pry open to competition a market that has been closed by defendant's illegal restraints". One way it tries to achieve this is to require Office to be available for other platforms in a timely manner. Timeliness is important because if, say, the Macintosh version of a vital program lags behind the Windows version for more than a few months, users may switch to Windows to get the newer version.

Macintosh

The states' proposal requires Office to be available for the Macintosh within 60 days of its release for Windows. This is a heavy burden, as it might require changing the very nature of Microsoft Office. Office for Macintosh has always been a loose cousin of Office for Windows. Office for Macintosh contains a major application (Microsoft Entourage) not available on Windows; this is but one indication that the source code for the Windows and the Macintosh versions of Office differ significantly. Typically Microsoft alternates between Windows and Macintosh versions, releasing Office 2000 for Windows, and Office 2001 for the Mac. Because the Windows and Macintosh versions of Office are not built from the same sources, reducing the lag between their releases from one year to two months would be a major undertaking.

It's not clear how short the lag need be to avoid disadvantaging the Macintosh. Four months would be a much easier target for Microsoft to meet. Absent compelling evidence that a four month lag would be much worse for the Macintosh than a two month lag, I recommend that Section 14a be amended to read

Continued Porting of Office to Macintosh.
Microsoft shall port each new major release of Office to the Macintosh Operating System within ~~60 days~~ 120 days ...

Other operating systems

The states' proposal requires Microsoft to auction off the right to port Office to other operating systems. Such a porting process would be long, and could yield a delay of well over a year between the release of Office on Windows to the release of Office on the new platform.

There is a way to ensure that Office can run on many alternative operating systems within weeks of its release on Windows: require that Office work properly when installed and run under Wine for Intel-based systems. This would as a side effect enable many other Windows applications (for instance, Quicken) to also run on Wine within weeks of their release on Windows, thus greatly increasing the number of applications available on Linux, FreeBSD, and Solaris for Intel.

Because each new release of Office requires more Windows APIs, Microsoft should be required to ensure that each new release of Office installs and runs properly under the open source version of Wine no later than 30 days after Office is released. To do this, it should be compelled to engage an outside consulting house such as Codeweavers, Macadamian, or Transgaming to make the needed improvements to Wine. This will provide an excellent test of whether Microsoft has sufficiently documented the Windows APIs used by Office. The cost of enhancing Wine to support Office 2000 was estimated recently by a Wine developer at approximately US $2 million, approximately one ten thousandth of Microsoft's annual revenues.

Thus, I recommend that subsections 14b and 14c be struck, and replaced with a new subsection reading

Contracting with a Third Party to Enhance Wine to Support Microsoft Office.
"Within 60 days of entry of this Final Judgement, Microsoft must contract with one or more outside firms to enhance the Open Source Windows Emulator WINE to be able to install and run Office 2000 under Linux. The work shall continue, with new releases of Wine occurring every 30 days, until completed, or until the expenses incurred by the outside firms reach 1 percent of the total development and marketing costs of Office 2000. The resulting enhancements to Wine shall be released under the same license used by Wine itself.
Furthermore, as soon as practicable, but in no case later than 60 days prior to the date each new version of Office becomes commercially available for use with a Windows Operating System Product, Microsoft shall again contract with one or more outside firms to enhance the Open Source Windows Emulator WINE to be able to install and run the new version of Office under Linux. The work shall continue, with new releases of Wine occurring every 30 days, until completed, or until the expenses incurred by the outside firms reach 1 percent of the total development and marketing costs of the new version of Office. The resulting enhancements to Wine shall be released under the same license used by Wine itself.
Furthermore, the license agreement for Microsoft Office and all other Microsoft products sold separately from a Microsoft Operating System shall not require the user to own any other Microsoft Software or Microsoft Operating System.

Summary

The amendments I propose above should increase competition in the desktop operating system market by enabling the development of competing non-Windows software that integrates well into previously all-Windows environments, and by increasing the ability of non-Microsoft operating systems to run Windows software.

Dan Kegel
dank@kegel.com
10 December 2001 Return to "On the Remedy Phase of the Microsoft Antitrust Trial"