decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
The Way Forward -- Georg Greve Responds to Groklaw's Comments
Tuesday, December 12 2006 @ 04:53 AM EST

Georg Greve found your comments on his article, "Novell's Danaergeschenk" on Open XML intriguing enough that he has written a response, "OpenXML wrap-up after D12K", and I thought the best way to let you know about it would be to reproduce it here, which, thanks to his choosing a Creative Commons license, I can freely do. I also thought it would be useful because he addresses the "now what?" question. Novell gives no sign of changing course, so what should the community's response be? I believe this quotation is a helpful starting off point:
"I once preached peaceful coexistence with Windows. You may laugh at my expense -- I deserve it."
Jean-Louis Gassée, former CEO, BeOS

As you know, the now defunct BeOS was one of the nine examples used in the opening statement in the Iowa antitrust trial to illustrate Micorosoft's anticompetitive practices and how they affect the marketplace.

To my mind, the only answer that makes any sense is to insist that Microsoft support ODF, as it ought to do. It's an ISO standard. It works. There is support for it and demand for it. Pardon my simplicity, but why isn't Microsoft just supporting the ODF standard? Why should the world have to do things Microsoft's way, instead of Microsoft abiding by the standard everyone else was happy to agree on, a standard actually designed to make true interoperability achievable? I can't find anyone knowledgeable who thinks this Novell-Microsoft translator will work well. Steve Ballmer himself says it won't work 100 percent. So what exactly is the game?

An anonymous reader left this insightful comment earlier:

Recent discussion on ODF versus MS-OOXML has been based around the notion that these are two competing comparable formats. It is instructive however to look at what the actual objectives of the standards committees were.
ECMA TC45 - Office Open XML Formats
Programme of work:
To Produce a formal Standard for office productivity documents which is fully compatible with the Office Open XML Formats This includes:
  • Produce a standard which is fully compatible with the Office Open XML Formats, including full and comprehensive documentation of those formats in the style of an international standard, with particular attention given to enabling the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems.

  • Produce a comprehensive set of W3C XML Schemas for the Office Open XML Formats, with particular attention given to self documentation of the schemas and testing of the XSDs for validation using a wide variety of XSD tools of the market and cross platform.

  • To contribute the Ecma Office Open XML Formats standards to ISO/IEC JTC 1 for approval and adoption by ISO and IEC.

Note the key phrase "produce a standard which is fully compatible with the Office Open XML Formats" In other words, the objectives of the ECMA comity for Microsoft OOXML was simply to document the file format as used in Microsoft's new version of MS-Office.

By comparison, the objectives for ODF were:

OASIS Open Document Format for Office Applications (OpenDocument) TC.
Statement of Purpose
The purpose of this TC is to create an open, XML-based file format specification for office applications.
The resulting file format must meet the following requirements:
  • it must be suitable for office documents containing text, spreadsheets, charts, and graphical documents,

  • it must be compatible with the W3C Extensible Markup Language (XML) v1.0 and W3C Namespaces in XML v1.0 specifications,

  • it must retain high-level information suitable for editing the document,

  • it must be friendly to transformations using XSLT or similar XML-based languages or tools,

  • it should keep the document's content and layout information separate such that they can be processed independently of each other, and

  • it should 'borrow' from similar, existing standards wherever possible and permitted.

In other words, the objective of ODF was to create an open format tied to no particular vendor's product, which is usable by everyone, and which is designed to work with other standards.

I think what this shows is that ODF and MS-OOXML are not intended to be equivalent to each other. MS-OOXML is the proprietary file format for a product Microsoft happens to be shipping today (or soon at least) and Microsoft is just doing what people have been asking them to do all along - documenting their file formats. ODF however is intended to be something much broader and more permanent than MS-OOXML. Another way of looking at it is that ODF is a document standard while MS-OOXML is a product brochure.

When people talk about ODF versus MS-OOXML, we should be clear that they are not comparable in their scope or in their objectives. Getting ECMA to rubber stamp someone's product literature doesn't make it a genuine industry standard. We should always clearly make a distinction between a genuine standard and a product specification and not let someone's marketing department obscure the difference between the two.

Make no mistake: the choice isn't between being able to interoperate with Microsoft, thanks to Novell doing interoperability work for them, or being stuck in some ODF ghetto, unable to read Microsoft documents. Everyone wants to interoperate. The question is how. The problem is Microsoft. The solution lies with Microsoft. They need to get with the program and follow standards like everyone else, instead of insisting the world bend to their ways.

It's not normal or acceptable that we can't all freely share documents with one another, no matter what operating system we like to use. We can send each other email, even if you are on Windows and I'm on Linux. Why isn't that the norm for everything? It ought to be. The bottleneck is Microsoft. FOSS software is happy to interoperate with any other software. Why won't Microsoft?


OpenXML wrap-up after D12K
~ by Georg C. F. Greve, Free Software Foundation Europe

Publication of my article "Novells Danaergeschenk" on has spurred quite some interesting reactions, like this interview with the Futurezone of the ORF, Austria's national public-service broadcaster, titled "Streit ums Dateiformat der Zukunft" ("Controversy about the file format of the future" -- sorry, German only). But there was also a very lively discussion on Groklaw with some very interesting and good comments, some of which I'd like to pick up and/or reply to.

Additional information

Many of the comments were focussed on exploring all the angles of the problems caused by and related to OpenXML, such as:

Fidelity of implementation

This comment points out that the article could also have highlighted a very common practical problem: Even if the specification is commonly known, the dominant player can easily introduce small incompatibilities that will break interoperability for competitors, strengthening the "Incompatibility is always the fault of the competitor" mechanism that I outlined in the article.

This is indeed quite common, and Microsoft's treatment of Kerberos is good evidence that such a behaviour can be expected for OpenXML. As this comment points out, Microsoft appears to have reserved the right to take legal action against competitors that implement the actual instead of the published specification. But that may not be the only legal angle. Since the OpenXML format contains DRM "functionalities," this comment fears there might be ways to bring up TRIPS/DMCA/EUCD-like legislation against reverse engineering of the true format.

I did not examine these issues in depth for two reasons: I wanted to keep the article as short and simple as possible and to keep it as OpenXML specific as possible. That being said, there is significant economic gain for the dominant player in "not quite" adhering to any standard, and few sanctions for such behaviour. Precisely for this reason establishing and maintaining Open Standards is so difficult.

In my view, this experience makes a strong point for mandating Free Software reference implementation(s) as one of the criteria for Open Standards in software, as I have also explained in my article "Sovereign Software" for the first UN Internet Governance Forum (IGF):

    The only way to prevent this sort of thing seems to add one more criterion to the definitions above: ''The standard must have at least one Free Software implementation and all implementations that seek to be compliant with the Open Standard must be regularly tested against the Free Software implementation(s), which act as the common reference base.''
    Because Free Software is, inter alia, defined by the freedom to study its implementation, this allows all players in the market to study the common reference base not only in specification language, but also in language, and regular tests against that base can help curb deviations from the Open Standard.
    Free Software also provides the freedoms of use, modification and distribution, therefore most vendors can also simply include that implementation in their own software, further reducing interoperability barriers.

More examples for wanting only one standard

As Groklaw reader Toby Thain points out in his comment, the internet itself could also have served as an example for why having more than one standard for any given purpose is harmful. This is quite true and you might want to keep this in mind for debates. In the article I avoided it deliberately, though, as I sought to use an example that was closer to daily life for non-technical people.

Doing the math on OpenXML

This comment on points to a blog entry by Andrew Shebanow of Adobe, titled: Is Office Open XML A One-Way Standard? Ask Microsoft. Based on the article by Microsoft's Rick Schaut that explains why the Mac version of Microsoft Office will not support OpenXML until sometime next year, Andrew Shebanow does the math and comes to the conclusion that implementing OpenXML amounts to 150 work years.

In conclusion, Andrew Shebanow not only questions the economic viability, but also voices scepticism about the chances for a truly compatible implementation that maintains fidelity between the implementations of different vendors. So overall it seems that Rick Schaut has essentially confirmed the issues raised by IBM's Bob Sutor about OpenXML being a one-way standard for migration to Microsoft.

Principles of standardisation

Another insightful comment was this explanation by Diehl Martin about why Open Standards are important to break the vicious cycles of forced upgrades.

There were also some comments that are better described as related or follow-up articles, and very good ones at that. This anonymous article deals with standardisation on a more philosophical level, from the article:

    I don't, however, think that it's inappropriate to ask a vendor to change their software to comply with a standard. Do we seriously give MS Office the standing of a national language? The standing of English, or French, or Spanish, or Chinese, or Japanese? Do we really have no right, in the standards process, to ask Microsoft to change their software? Well, not so much change their software, but to implement the standard the other way around - for MS Office to implement the standard, not for the standard to implement MS Office, which is obviously why it's 4000+ pages, and getting bigger.

Difference to .doc import?

Related is also this comment that discusses how OpenXML (unlike ODF) has never been meant to be a universal document format. Putting OpenXML up against the Open Document Format is described as pure marketing spin, and referring to OpenXML only being incremental change to the old ".doc" and ".xls" formats.

The comment continues that importing an OpenXML file will be no different from importing ".doc" and ".xls" files into OpenOffice or some other program. In fact, I also received a few questions asking why I consider it a good thing for to support reading .doc files, while I disagree with the notion of adding OpenXML.

The answer is simple: The two questions have entirely different backgrounds and situations. Before there was an ISO standard universal document format, all applications had to try and support as many formats as possible, because this was the only way to achieve interoperability. And while there were some file formats that would have allowed better interoperability, e.g. the Rich-Text Format (RTF), they were not used by default by the dominating vendor. So writing import/export filters for was the only way to get a foot into the door, and has helped the technology field arrive at a truly universal Open Standard: Open Document Format (ODF).

Now an Open Standard exists, is ISO certified and supported by many different applications. It should be the only format used by governments and companies -- for all of the reasons outlined in the Groklaw article and this one. And while it is good to maintain support for legacy formats from the time when there was no standard, including ".doc," adding support for OpenXML only serves to help undercut the existing Open Standard by use of market power, technological tricks and political efforts.

Additional reading

Of course some comments also suggested additional reading, such as this comment, which references an article by Nicholas Petreley that is based on an Information Week article by Cory Doctorow, discussing the wider picture in which this debate is taking place.

Ways forward

Creating public discussion and awareness of a problem is often the first step in solving it, but it is not sufficient. In the comments there were several practical suggestions, which I'd like to support and encourage people to participate in.

Support Open Document Format (ODF)

As several people have pointed out, constructively supporting the use, spread, adoption and legislation for truly Open Standards, such as the Open Document Format (ODF), is one of the most useful things people can do. This includes using ODF yourself for cooperating online with others, as this comment proposes.

Funny enough, all of this brings to mind RMS' essay We Can Put an End to Word Attachments of 2002, only that it would need updating to recommend the Open Document Format, boiling down to: I am very sorry, but I could not read your attachment because it was saved in a format that my office could not read. Could you please resend the document in the universal document format "Open Document Format" (ODF), the international ISO standard for document exchange?

Naturally the message should be adapted to the situation, recipient and context in order to have the right tone. If people feel attacked or criticised for having used the "wrong" format, such reminders may end up being counterproductive. But discarding the possibility of changing social habits is no less counterproductive, and ignores evidence to the contrary: Just ask all the people who are now sorting their garbage for recycling and compare that to the position they took 30 years ago.

Support ODF plugin for Microsoft Office?

Although it might seem strange to suggest that anyone should improve a Microsoft product, we should also consider the usefulness of improving the ODF plugin. Making it very easy for all users of Microsoft Office to interact via ODF would provide a major advantage for ODF over OpenXML.

Community comments to the ISO process

Another comment on Groklaw proposes to turn the incorporated denial of service attack that is OpenXML back on Microsoft by extensively commenting on each of the 6000 pages of specification during the review process prior to the ISO vote.

Preventing ISO acceptance of OpenXML could indeed be an important step, and while one might have sufficient confidence in the ISO process to work better than that of ECMA, some support on this side might be very helpful.


Finally, I was (for the most part positively) surprised by the interesting discussions that arose from my usage of the terms "Danaergeschenk" and "Salomonian," including Bob Sutor making Danaergeschenk the word of the day on his blog.


Although I think some people might have taken this a little too seriously, there was some interesting discussion regarding my use of "Danaergeschenk" in my article.

Some people felt that I should have used "Trojan Horse", which is a common expression in both German and English, but that never really occured to me for various reasons. I checked this page for a translation of Danaergeschenk, and ruled out Trojan Horse for various reasons: The Trojan Horse wasn't Trojan, it was Greek, for which Danaer or "Danaos" is original Latin term. It also isn't common to return horses to the stores around christmas. And as some people right pointed out, the terms have different connotations and emphasis.

So after some consideration, I decided to go with "Danaergeschenk", even though I knew this was entirely unknown to English speakers, which is why it was briefly introduced in the beginning. Given that words like "Fahrvergnügen" made it into English, I thought this might prove to be a fun addition, even if people followed this advice and simply called it D12K.


As far as "Salomonian" is concerned, I did not expect it to be that difficult, as king Solomon is a very common reference in German. For those who'd still like to know how it was meant, I believe this comment explains it quite well.

I guess that usage of both these words are owed to my humanistic education, which had me study Latin for six years. My apologies to all who felt I subjected them to the pain of that education subsequently.

The author is initiator and president of the Free Software Foundation Europe (FSFE) and his personal blog is available at the Fellowship of FSFE.

This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )