Interoperating with Microsoft

Last week, with much fanfare, Microsoft announced a change in its practices in order to "expand interoperability". It is a rather sizable shift away from some of its previous inflammatory statements about free software—though it scrupulously avoids that term—but whether it is the harbinger of a more open Microsoft, or yet another empty pronouncement, is still unclear. It does contain things of interest to the community, in particular the patent enumeration, but there are pitfalls as well.

The largest chunk of what Microsoft promises is documentation for APIs and protocols used by some of their most popular products. They immediately released some 30,000 pages of Windows protocol specifications, much of which the Samba project had to pay to access last December. In addition, they will be releasing documentation suitable for developers wishing to interoperate with "Windows Vista (including the .NET Framework), Windows Server 2008, SQL Server 2008, Office 2007, Exchange Server 2007, and Office SharePoint Server 2007, and future versions of all these products."

Microsoft has also promised to list which of the documented protocols are covered by one of its patents or patent applications. We may finally start to get a handle on the infamous "235 patents" that Linux and free software supposedly infringe. These patents will be available for license on the standard "reasonable and non-discriminatory" (RAND) terms, with an interesting addition: "low royalty rates". The patent list is not yet available, but may be of use in ways that Microsoft does not intend; invalidating some of the patents with prior art for example.

As Microsoft is well aware, RAND terms are a non-starter for free software because they restrict redistribution of the code. The company has tried to soften that blow, perhaps, by rehashing its "covenant not to sue" developers that originated as part of the Novell interoperability agreement. The covenant may be a great public relations ploy, but does little to alleviate concerns that free software developers will have in implementing patented protocols. It is the rare developer who finds an itch to develop code to talk to Microsoft servers and who has no thought of using or distributing it commercially.

There are also provisions in the announcement for documentation of Microsoft implementations of industry standards. A cynic might wonder why additional information is needed, they are, after all, supposed to be standards. The unfortunate reality is that Microsoft does extend such standards for its own purposes in incompatible ways; having that kind of information can only help web browsers, directory services, and other multi-platform tools.

For a company as adamantly opposed to Open Document Format (ODF) as it claims to be, it is a bit surprising to see that they plan changes to Microsoft Office to "promote user choice among document formats". APIs for document format plug-ins along with the ability for users to make their own choice about the default save format will be added. How reasonable those APIs are and how faithfully they can encapsulate Office documents will be an interesting test of both Microsoft's sincerity and ODF's capabilities. It is also a pretty clear attempt to at least appear to be playing nicely with ODF while its competing OOXML format is being considered for an ISO standard.

There are also various platitudes about "opening dialogs" and "expanding outreach" with the community included in the announcement. It will be interesting to see how that actually plays out. It is, however, hard to imagine even a year ago seeing a posting on a Microsoft-sponsored site entitled "How open source has influenced Windows Server 2008". In less than seven years, we have moved from a "cancer" to influencing its flagship products.

One obvious conclusion that can be drawn from this and other Microsoft initiatives is that it is feeling a fair amount of pressure from customers, the European Union, standards groups, and free software. These kinds of changes, even if they don't go as far as the rhetoric would lead one to believe, are a pretty substantial shift in Microsoft culture and thinking. Unfortunately, they do also seem to be angling for the long-sought "Linux tax"—a payment, even just a small one, for each and every Linux deployment.

So far, Microsoft doesn't seem to have caught on to the idea that most Linux installations are free in both senses of the term. There is no per-installation, per-processor, per-core licensing stream to tap into. One of the headaches that free software users avoid is keeping track of all those licenses, enforced by the ever-present threat of a Business Software Alliance audit. It has, to a limited extent, already tapped into—and likely tapped out—that revenue from the deals with Novell and other distributors.

Overall, this seems like a positive step. It clearly acknowledges the role that free software (or open source if you prefer) is playing in both the commercial marketplace and the marketplace of ideas. The actual effects of this announcement for our community may be small, but it may also be indicative of Microsoft moving in a more cooperative direction. That would be a rather nice thing to see.