« Apple Stock Hits Record Hi on iPhone | Main | iPhone = a Big Deal »

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83452f49169e200d8350f2bef69e2

Listed below are links to weblogs that reference Analyzing the Microsoft Office Open XML License:

Comments

Benjamin

If there is any lesson that can be learned from observing Microsoft's behavior since its founding, it is to be very wary of their promises. Partners have been burned just as badly as competitors and customers when it comes to their dealings with this company!

The OOXML format has been revealed to be yet another trap. Anyone planning to use it is setting himself up for trouble. But this time, unlike falling into the trap of the old binary formats, we know in advance what MS will try to do if we (the world) becomes dependent on OOXML. We'll lose many opportunities for innovation, and a lot of our hard-earned money.

I am adopting ODF as my next-generation file format for its many advantages, and I hope the rest of the industry makes the same decision.

Marbux

There is a more serious "gotcha" in the Microsoft covenant not to sue, in the definition of "necessary claims." That construct bestows rights to implement only to those "claims of Microsoft-owned or Microsoft- controlled patents that are necessary to implement ..." The problem is that NO patents are necessary to implement a specification. Software is written in code, not in patent claims.

A patent claim is analogous to a description of real property in a deed. The claims describe the intellectual property that is owned; it is not the property owned, i.e., what is owned has a real house and a real tree on it; the property description in the deed does not. Just so, no description of intellectual property is "necessary" to implement a software specification.

So bottom line, the rights bestowed in the Microsoft covenant not to sue are a null set. No rights are granted whatsoever.

A virtually identical grammatical construct was used in the Microsoft Office 2003 XML Reference Schema patent license, a fact noted in my Groklaw article about that license. One might suspect that Microsoft is aware of that article, so one might suspect that the "gotcha" is deliberate. (I'll emphasize here that I have reviewed dozens of Microsoft IP documents over the years. The language employed is atypical not only for Microsoft but for the entire IP legal establishment.)

Courts will normally overlook such warts, recognizing the unfairness of misleading language and implying correct terms or recognizing a right by waiver or estoppel. But now take a look at the last sentence: "No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppel, or otherwise." Since the "rights" bestowed are a null set, there are no rights "expressly stated" in the promise. Therefore, the sentence forbids a court from recognizing any rights at all.

We must look somewhere other than the Microsoft covenant not to sue as a source of rights to implement the EOOXML specification. The irony is that a court might well find there are rights to so implement, but to do so would have to recognize a waiver or estoppel from Microsoft's public statements about the covenant not to sue, rather than from the covenant itself.

But as a legal foundation for building apps that can take thousands of person-hours, this covenant not to sue is legal quicksand of unknown depth.

There are many other warts in the Microsoft covenant not to sue. E.g., the covenant applies only to Ecma Office Open XML; it does not apply to any future version, including a version that might be approved by ISO or a variant that might be actually implemented by Microsoft in MS Office. So Microsoft makes no guarantee that it will not move the goal posts at any time. Compare that issue with Sun Microsystems' covenant for OpenDocument:

"Sun irrevocably covenants that … it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format for Office Applications (OpenDocument) v1.0 Specification, or of any subsequent version thereof ("OpenDocument Implementation") in which development Sun participates[.]"

Which covenant not to sue would you prefer your work to rest on, Microsoft's or Sun's? On quicksand or a solid foundation? On EOOXML or OpenDocument?

Zaine Ridling

The entire OSP smells from its vague, dismissive tone all the way to the solicited blurbs at the bottom of the QA section. Sam, you nail it when you note that you cannot fully implement the spec without getting your door knocked down by the Legal Club for Men — "It's a common practice to exclude 'enabling technologies' (— Microsoft). By building a complete and working implementation, you would have to replicate most of Microsoft's code — especially with regard to macros (Rob Wier at http://www.robweir.com/blog/2007/01/formats-of-excel-2007.html) in Excel:

"The 'Excel Macro-Enabled Workbook' option saves as an 'xlsxm' extension. It is OOXML plus proprietary Microsoft extensions. These extensions, in the form of binary blob called vbaProject.bin, represent the source code of the macros. This part of the format is not described in the OOXML specification."

Back to the drawing board. Microsoft is dipping one toe in the water and high-fiving itself as if it won the swim meet. Oy.

W^L+

I noticed when I read it that if an implementor were to add some extension (which is what the X in XML stands for, after all) or added functionality stored in the file format, there is no assurance that the covenant not to sue will still apply.

So, only Microsoft need apply.

Online Pharmacy

In 2000, Microsoft released an initial version of an XML-based format for Microsoft Excel, which was incorporated in Office XP. In 2002, a new file format for Microsoft Word followed.

The comments to this entry are closed.


Sam Hiser

Categories

OFF-WHITEPAPERS

ARTICLES


www.flickr.com
This is a Flickr badge showing public photos from swhiser. Make your own badge here.


Locations of visitors to this page


Google
Search PlexNex

  

View Sam Hiser's profile on LinkedIn

Powered by TypePad