Last week, Microsoft and the European Commission each announced that Microsoft had  proposed certain concessions in response to a "Statement of Objections" sent to Microsoft by the EC on January 15 of this year relating to Microsoft's bundling of Internet Explorer with Windows.  If you've been reading the reams of articles that have been written since then, you may have noticed that the vast majority of the virtual ink spent on the story has been directed at the terms relating to browser choice.  Typically, and as an afterthought, most of these stories have added a brief mention that Microsoft also proposed commitments relating to "another" dispute, this one relating to interoperability.

While the browser question is certainly important, in many ways it is far less important than the interoperability issue.  After all - the primary benefit for consumers under the browser settlement is that they can choose their favorite browser when they first boot up their new computer, as compared to investing a few extra clicks to download it from the site of its developer - as they can already do now.  Interoperability, of course, goes far deeper.  There's no way that you can make one program work the way you really want it to with another unless it comes out of the box that way, or unless you have not only the ability, but also the proprietary information, to hack it yourself.  And if both programs don't support the same standards, well, good luck with that.

So what exactly did Microsoft promise to the EC, regarding interoperability?  Let's use ODF as a reference point and see.

Microsoft’s proposal relating to interoperability can be accessed by clicking the link provided in the Microsoft statement by its General Counsel, Brad Smith.  You can find that page here.  The document is 12 pages long (the annexed documents that relate to its implementation comprise another 25), and, as you would expect, it has been very carefully drafted.  While you should never regard anything you read in this blog as legal advice, that’s therefore a particularly apt point to make today, because I have not had the time to carefully consider the whole document, top to bottom.

As a result, what I will do below is to try to provide a general overview of what the proposal intends to accomplish as regards document format standards, and highlight some of the language and terms that I found to be particularly interesting in light of the history of the ODF – OOXML saga, without trying to provide a bottom line conclusion about how dramatically the proposal changes the competitive interoperability landscape.

The proposal package includes three Guiding Principles, followed by 5 General Terms, followed by 32 Specific Commitments.  The main document concludes with provisions relating to patent enforcement, implementation commitments, and definitions.  Four Annex documents, comprising a Warranty Agreement, Template Patent License, a document relating to standards in the context of only Outlook and Exchange, and an outward reference to additional versions of those applications complete the substantial package.  Given the breadth, depth, and intellectual property content of the whole, a dozen blog entries of scope comparable to this one could easily be written without exhausting the subject matter available here at the cost of a careful read.

That said, let’s start by looking at the Guiding Principles that appear towards the beginning of the Proposal.  By their terms, they self-impose an interpretive constraint on the language that follows, and would be relevant to setting the context in any future litigation or new investigation by the EC.  They read as follows: 

A. GUIDING PRINCIPLES  

(2)      Microsoft shall ensure that third-party software products can interoperate with Microsoft’s Relevant Software Products using the same Interoperability Information on an equal footing as other Microsoft Software Products. (“Interoperability Commitment”)
 

(3)    This Undertaking shall be interpreted in light of these Guiding Principles
 

(4)    Microsoft shall not circumvent or attempt to circumvent the commitments in this Undertaking, including the Guiding Principles.

 

That’s a helpful beginning.  The General Provisions that follow state that Microsoft will "support open, public standards," will make "Interoperability Information" available on "reasonable and non-discriminatory terms," without restrictions on how it can be used, except in the case of patent rights.  In that case, Microsoft retains the right to impose "field of use" restrictions that are "limited to restrictions of use for the purposes of interoperability" with the related Microsoft products.

 

Significantly the "reasonable and non-discriminatory obligation is further narrowed as follows:

 

Access to and use of the Interoperability Information shall be subject to no more than a nominal upfront fee and licensing terms which are compatible with Open Source Licenses.  

 

Interoperability Information is defined as follows:

 

"Interoperability Information" means, as applicable pursuant to Section II, either the complete and accurate specifications for all the Protocols implemented in a Microsoft software product that are used to exchange information with other Microsoft software products and mutually to use the information which has been exchanged, the complete and accurate specifications for the relevant Binary File Formats, or the complete and accurate information relating to Microsoft’s implementation of the Ecma 376 Specification, ODF and IS 25900 [this is the Ecma OOXML specification, in the form adopted by ISO]. [emphasis added by me]

 

The references to specific standards are significant – only ODF is mentioned above independent of a version number, and this will be relevant in the conditioning of the commitments that follow.

 

With this by way of background, let’s look at the commitments that relate specifically to standards, starting with General Rule (8), which reads as follows:

 

(8)      Open, public standards shall be supported and implemented by Microsoft in the following manner:

 

A.       Microsoft shall provide support for applicable standards by either (i) implementing the required portions of the applicable standard that relates to functionality of the implementing product, or (ii) completely and accurately documenting instances where required portions of the applicable standard are not implemented or are implemented with variations. Microsoft shall make this documentation publicly available in a Timely Manner.

 

B.       Microsoft shall completely and accurately and in a Timely Manner make documentation of the optional or informative portions of the standard it has chosen to implement publicly available.

 

C.       Microsoft shall completely and accurately and in a Timely Manner make documentation of any extensions it has made to the standard publicly available. Extensions include the format of the content types, relationships, elements and attributes that are not defined in the standard.

 

D.       Microsoft shall ensure that the open, public standards identified in Section B.II are supported, implemented and documented (including updates to such documentation) as outlined above and warrant to that effect as set forth in the warranty agreement in Annex A. The warranties shall be made available for no more than a nominal fee and be subject to effective private enforcement.

 

The emphasis, therefore, is on how transparently Microsoft implements standards when it chooses to do so, and how rapidly it must share that information with others, and on what terms, rather than restrictions on what standards Microsoft must support, and when (this is addressed later).

 

"Timely Manner," in turn:

 

…means as soon as Microsoft has developed the first sufficiently stable “beta” testing version of Microsoft’s Relevant Software Product (including Service Packs and Updates) and has made this implementation available to third parties for testing purposes for the first time.  “First sufficiently stable ‘beta’ testing versions” do not include pre-release versions of Microsoft’s Relevant Software Products that under standard industry understanding and past Microsoft practice would not constitute a sufficiently stable version to be labeled a “beta.”

 

Taken together, the Guiding Principles and General Rules are very helpful and appropriate.  Once one turns to the "Specific Commitments" as they apply to specific standards, however, more interesting language begins to pop up.  The first set of sections applicable to Office can be found in clauses (15) through (18), and reads in part as follows ("undertakings," as used in the proposal, refers to developers; highlighting below was once again added by me):

 

(15)    This paragraph describes how Microsoft shall implement paragraphs (16) to (18) and Section 2.2.  Microsoft shall make Interoperability Information available to interested undertakings relative to file formats used by Microsoft Office Word, PowerPoint and Excel that allows third-party Software Products to open, manipulate, save, exchange and share documents created by Microsoft’s PC Productivity Applications without a loss of container structure information or any instructions in the file that describe the document’s formatting characteristics. For these purposes, file formats are understood as containers …

(16)    Legacy Binary File Formats for Word, PowerPoint, and Excel. Microsoft shall make available to interested undertakings specifications of its Binary File Formats for Word, PowerPoint and Excel that meet the requirements of paragraph (15) above….

 

(17)    Office Open XML. The “.docx, .xlsx and .pptx” file formats used in the Office 2007 version of Microsoft’s Primary PC Productivity Applications shall implement the ECMA 376 Specification.  This commitment shall apply to successor versions of Microsoft’s Primary PC Productivity Applications with respect to IS 29500. 
 

(18)    Microsoft shall publicly document Additional Information for the ECMA 376 Specification that meets the requirements of paragraph (15) above.  This commitment shall apply to successor versions of Microsoft’s Primary PC Productivity Applications with respect to IS 29500….

 

In other words, Office 7 need not comply to the ISO version of OOXML, but later versions of Office must support the ISO version; this is old news, although it was not known whether the EC had taken any issue with this.  Note, however, that the language does not refer to future versions of the ISO standard.  The above commitments, and those quoted next below, are all effective October 30 of this year.

 

Sections 28 – 33 address other standards in general, and ODF in particular.  They read in part as follows (highlighting was again added by me): 

 

(28)    Support for Open Document Format (“ODF”). Microsoft commits to support ODF in Microsoft’s Primary PC Productivity Applications, as described below.

 

(29)    Microsoft shall implement ODF 1.1 support, and include ODF  in the “save as” drop down box, for Word 2007, Excel 2007 and PowerPoint 2007 in Office Service Pack 2 (“SP2”), and shall give customers who install SP2 the ability to set ODF 1.1 as their default format…

(30) – (31)  [These cover implementation details]

 

(32)    Microsoft’s Primary PC Productivity Applications shall support the ODF Standard in the following way. After SP2 for Office 2007 and for ten years from the effective date of this Undertaking, within 9 months of final publication by ISO of a new ODF Standard Microsoft shall support that version in the latest major version of Microsoft’s Primary PC Productivity Applications.…This provision is subject to the following pre-requisites for each version of the ODF Standard: (i) the version of the standard must be developed and available for implementation under substantially similar terms as ODF 1.0, including for a substantially similar purpose and under substantially similar (no less than reasonable and non-discriminatory) licensing terms covering all intellectual property rights in the standard;  (ii) the version of the standard is not substantially more difficult to implement technically than the previously supported version; and (iii) the standards development process for that version of the standard has not been manipulated or otherwise subject to misuse. Irrespective of the termination of this Undertaking Microsoft shall maintain the then existing level of ODF support over the commercial product lifetime of the then latest major version release of Microsoft’s Primary PC Productivity Applications….

(33)    In addition, Microsoft shall make available new APIs that allow adding the functionality to open and save a document in any other file format, coincident with the ODF software update and subsequent releases outlined in paragraphs (29) to (32) above. These APIs will enable translators for other file formats to be “plugged in” to Microsoft’s Primary PC Productivity Applications….

 

For those that have followed the ODF – OOXML competition from the beginning, this is extremely interesting.  Although OOXML was pushed as quickly as possible through Ecma and ISO, new versions of Office will be required to support only the current version of the ISO version of OOXML, presumably even if there is a new version available by the time Office 14 is released.

 

In contrast, Office will be required to support not the current ISO version of ODF, but ODF 1.1, a version of ODF released by OASIS that is more mature than the version approved by ISO.  However, Office will not be required to support ODF 1.2, which will be superior to 1.1.  Instead, it can wait for the next release of the ISO version of ODF, and then will be required to track the most current version of the ISO standard through the remainder of the ten year term of the settlement.

 

Looking at the first question: why is there no reference to future versions of OOXML/IS 29500?  Does this indicate that Microsoft intends to abandon its own XML formats?  Or that it wishes to have more implied control over the next ISO version, since it has no obligation to implement it under the proposed settlement?  At the moment, I can’t think of a third explanation, given that the EC apparently thought the question of OOXML support was important enough to require specific language covering OOXML support in the near term.

 

Turning to the second question: how strong is the commitment to implement ODF, and why should there be specific "outs" at all?  Irony aside (in light of the first approval round in ISO of OOXML), the game-playing condition is superficially not unreasonable, but who would make the judgment call over how much game-playing is too much, especially given that a certain level of game playing is rampant across so many strategic standard setting initiatives to begin with.  And, for the largest software company in the world, why should difficulty enter into the equation?  Note also that the next version of ODF could be more difficult to implement not only because ODF had changed, but because Office had changed as well.

 

Taken all together, this is a very complex set of documents, and one that is not to be summarized without careful study.  That is hardly surprising, given the very substantial financial stakes for Microsoft, on the one hand, and the regulatory goals of the EC on the other.

 

What is clear is that a fascinating game of cat and mouse may finally be nearing a conclusion in the EU.  Unlike the last contest between Microsoft and the EC, this one may end without endless litigation and billion dollar fines.  For now, though, the EC has simply stated that Microsoft’s "proposals require further investigation before the Commission reaches any conclusion as to the next steps."

 

It remains to be seen how many mice have in fact been caught, and by whom.  Until th EC has had time to evaluate Microsoft’s proposals and respond to them (presumably in private), we won’t know for sure.  While the EC has welcomed this latest overture from Redmond, for now, the European regulator is simply saying that, "The Commission has no further comment at this stage."  Stay tuned.

 

For further blog entries on ODF and OOXML, click here

sign up for a free subscription to Standards Today today!