decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
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
Proprietizing Standards
Friday, July 20 2007 @ 10:25 AM EDT

I offered to let any participants in the meeting in Portugal regarding Ecma-376 respond to the meeting notes we published from one member of the committee, Rui Seabra.

While we wait, there is more on that front, this time from India, where the technical committee there is still considering Ecma-376 issues. Earlier, we mentioned to you some questions that Dr. G. Nagarjuna, Chairman FSF India, submitted to the Working Committee, Board of Indian Standards on Wordprocessing. In this Issue Sheet [PDF], we find answers from Microsoft's Vijay Kapur, followed by responses from Dr. Nagarjuna.

For example, here's one such exchange:

Backward compatibility for all vendors: Can any third party regardless of business model, without access to additional information and without the cooperation of Microsoft implement full backward compatibility and conversion of such legacy documents into MS-OOXML comparable to what Microsoft can offer?

Mr V. Kapur: Implementing backward compatibility is an application function not a file format specification requirement. The ECMA 376 specification is capable of faithfully representing information in the legacy binary file formats. This point was treated in detail in the response to the question raised by Dr. Nagarjuna. Microsoft can offer? Availability of Binary File Formats -- It is to be noted that Microsoft has made the .doc, .xls, and .ppt binary file format specifications available under a royalty-free covenant not to sue to anyone who wishes to implement all or part of these specifications in their products. Anyone can get access to the specification now, using the method described in the following Knowledgebase article at the link: http://support.microsoft.com/default.aspx/kb/840817 - How to extract information from Office files by using Office file formats and schemas (relevant extract below)With both format specifications being available for a developer, a converter can be written in such a way that a DOC or XLS document can be converted into an Open XML document with content and representation intact. This point should be treated as closed as there is no contradiction.

Dr. Nagarjuna: Availability of the specification of binary formats does not solve the problem of another vendor's ability to implement. What is required is a mapping between the existing proprietary formats and OOXML if the stated objective of OOXML, namely, to faithfully represent legacy formats in XML is to be met. The link provided by MS is not an article. It is misleading to say so. MS did not publish the specification of proprietary documents at any accessible place. They are promising to provide to those who sign an MOU with the company. This is unacceptable since, implementing this standard mandates the need for private understandings. That is not the purpose for which standards are specified. They are specified precisely to eliminate such a requirement. The question asked was a very serious and a CORE issue: the answer given is not satisfactory. A satisfactory answer to this consists in publishing the mapping between OOXML and proprietary documents. Since this is not the case, the issue is open, and forms a sufficient reason to vote against OOXML.

I strongly urge any of you interested in OOXML to read the other exchanges most carefully. You will find them illluminating. Today is the last day to write to Massachusetts, I believe, for those who wish to. The address is standards at state.ma.us . Here are two other documents from the process in India, also PDFs:

While I haven't seen any reaction officially from Microsoft about the shocking events in Portugal, Microsoft's Jason Matusow does present what I assume is their reaction to getting caught stacking the deck in committees all over the place. You can see an interesting chart on the US committee on Rob Weir's blog in a July 15th entry. After some snarky remarks about people who are against OOXML, Matusow concludes like this:

IBM is welcome to their opinion of the standardization of Open XML. They are working in more than 100 countries to oppose its adoption and will push as hard as they can to achieve this goal. They are advocates for the technologies that best fit their products and business model – their actions regarding Open XML are in their best interests…not that of their customers. If they don’t want to support the Open XML standard in their products, they are not obliged to do so. Working to defeat the standard is 100% an industry competitive play and not about customer benefit.

As you can see, he spins this ODF/OOXML saga as if it were just a couple of vendors doing their level best to beat each other in the marketplace. This isn't between Microsoft and IBM. It's a lot more than that. And IBM isn't the only major company in opposition by any means. Google opposes its adoption, for example, as you can see in this email to the Standards Council of Canada:

Google would like to dissaprove, with comments, the request from Microsoft to for their OO-XML to become an ISO standard. Please add the comments to the site. Our comments are in the file objections.pdf, attached to this message and referenced in ISO_Comment_OOXML.pdf

But it isn't just companies. There is a great deal at stake for the public. I'm not a vendor. I'm just an individual. Yet I care. If there is a noticeable flaw in the standards process, it's that the vendors don't represent me. I don't benefit at all financially from any decision anyone makes, so how does Jason explain why I care?

Here's one reason I care: I want a level playing field, so as a customer I can freely choose between all products available. I don't want to have to use Microsoft products or be dependent on them for anything. I don't mind if I choose to use them, but I don't like to be forced. Whatever standard is chosen, it should be one that makes it possible for everyone to equally use the standard and get equal results. OOXML can't offer us that, in that it appears to favor Microsoft, which is retaining certain proprietary information or only making it available under NDA. As a customer, that bothers me in a standard. I think it should. And proprietary extensions bother me, even if one can get access up to a point by signing an NDA. No one should have to contact a vendor and sign an NDA to use a standard. Period. It puts control of the standard in the hands of a vendor, a single vendor. And what, precisely, are the terms? Are they carved in stone or can Microsoft change the terms whenever it feels like it?

And second, I want to be able to use GNU/Linux in peace. OOXML's patent promise worries me, because it doesn't seem to cover future versions. Is the plan to turn around someday and use patents to crush Linux vendors and end users who don't pay the Microsoft patent tax? Or use patent law to limit what the competition is allowed to do? Or just let the proprietary extensions achieve that goal? Such goals do not belong in a standards process. I also haven't forgotten this worrying language in Microsoft's Open Specification Promise:

Q: Is this OSP sub-licensable?

A: There is no need for sublicensing. This promise is directly applicable to you and everyone else who wants to use it. Accordingly, your distributees, customers and vendors can directly take advantage of this same promise, and have the exact same protection that you have.

Q: Is this Promise consistent with open source licensing, namely the GPL? And can anyone implement the specification(s) without any concerns about Microsoft patents?

A: The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s). We leave it to those implementing these technologies to understand the legal environments in which they operate. This includes people operating in a GPL environment. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).

Thirdly, I, as a customer, have a stake in the standards process being honestly followed. Technical merit should matter. I find it deeply disturbing that Matusow ends this report on South Africa's TC voting no on OOXML with the thought that he thinks Microsoft will be able, I gather, to prevail despite the technical committee's overwhelmingly negative vote:

On Wednesday the 18th the SC34 mirror committee for South Africa held a meeting that, as I understand it, was originally intended to be informational but instead resulted in vote and the conclusion that the SC34 mirror committee was not the right entity to be casting the official vote for South Africa. In other words, it will be another 3-4 weeks before South Africa casts its ballot, and just like all national body votes, will be part of the ballot resolution process that may not happen until early 2008....

Many countries will vote yes, some will vote abstain, and some will vote no. Those that vote no will likely include comments and those comments are the primary focus of the ballot resolution meeting. Following that, some of the no votes may move to yes. In other words, it is best to keep your eye on the long-term picture in this process.

Normally, bodies do follow the recommendations of the technical committee. And why wouldn't they? How else do you decide if an offering should be a standard? Stacking the decks to get the votes you want despite the technical concerns? I'm not sure I've understood him precisely, so perhaps he'll clarify.

For myself, I don't forget the Halloween Documents. I know they laid out a plan to hinder FOSS. Remember this one?:

In addition to the attacking the general weaknesses of OSS projects (e.g. Integrative / Architectural costs), some specific attacks on Linux are:...

  • Fold extended functionality into commodity protocols / services and create new protocols

Blunting OSS attacks...

De-commoditize protocols & applications

OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market.

David Stutz makes a very good point: in competing with Microsoft's level of desktop integration, "commodity protocols actually become the means of integration" for OSS projects. There is a large amount of IQ being expended in various IETF working groups which are quickly creating the architectural model for integration for these OSS projects.

Is that not pretty much what we are witnessing in the OOXML story?:

1. De-commoditize protocols - by adding proprietary extensions to a standard.
2. Prevent standards organizations from making it possible for FOSS to easily interoperate.

Now, I don't care how proprietary Microsoft wishes to be itself. It can DRM itself up to its eyeballs for all I care. I don't use the stuff, so it doesn't affect me. And when I read about their latest patent application, the one that proposes riffling through all our personal papers on all our computers so as to report to advertisers what we are interested in, I note it with alarm for my friends and loved ones who still use Microsoft software and make a mental note not to let a company that can come up with that idea anywhere near my computer, but other than that, I just laugh.

But when you proprietize standards, you touch me. And that is precisely what is happening with OOXML. Microsoft's own expert at the Portugal meeting said so pointblank: Microsoft will add proprietary extensions, he said, to do things ODF can't do. Now, as someone else on the committee pointed out, proprietary extensions are not the only choice. Microsoft could open up so we can all interoperate on a level playing field. I believe that is the EU Commission's goal. Proprietary anything isn't appropriate in a standard, because it forces those of us who are not interested in proprietary software to use it or deal with it anyway. It compels those of us who wish to avoid that vendor to have a relationship with it against our will. And it gives the vendor control and a head start in the market, which is exactly what standards are supposed to prevent. It's Microsoft saying, "I've got mine. I can open my documents fine. Too bad about you. Your solution is to limp along in Linux or buy our products or pay for our patents. One way or another, you have to pay us." That, to me, is a subversion of the standards process.

That's the good part to Microsoft, I suppose, but it's the reason I don't like it. I shouldn't have to do business with Microsoft, unless I want to. And you shouldn't either.

Finally, I want to control my own documents. I wrote them, and I wish to control them. This is the part I hope Massachusetts thinks about carefully. An important goal of government is to preserve documents so they don't become inaccessible to the public. Proprietary extensions by definition slam that door in your face, because you then lose control over your own documents. You can never have access now except through Microsoft, and if you think that company is going to be around in fifty or 100 years, you need to ask: are you positive? Can you guarantee it? And even if they are, whose documents are they now? Yours? Or Microsoft's? Who controls access?

If your goal is to avoid lock-in to a single vendor, then proprietary extensions should scare you silly. It doesn't matter then how many companies use the format or how many business partners want it or even if it is a de facto standard -- you are now dependent on one single vendor. That unhappy fate is precisely what ODF, and only ODF, can prevent.

So, why not just bite the bullet, merge ODF with Ecma-376, and make it possible for everyone to interoperate freely as we already can in email? I can send an email to my friends from my Linux computer or my Mac and they can still read it just fine, even if they do use Windows and love HTML email. I remember Eric Kriss told ComputerWorld why not:

He said technical people at Microsoft told him it would be “trivial” to add support for ODF to the new Office 2007. The resistance to doing so came from the vendor’s business side, according to Kriss....

As part of his e-mail exchanges with Gutierrez, Yates didn’t deny Burke’s involvement in promoting the amendment sponsored by state Sen. Michael Morrissey that sought to take away much of the IT division’s decision-making authority.

So, evidently Microsoft knows how to make ODF capable of doing whatever it has to do for true interoperability and without annoying translators that I doubt will ever really work well. It would be "trivial", the man said. They just don't wish to, for business reasons, and so they fight it. That is fine for Microsoft, but what about standards bodies? Is it reason enough for them? Massachusetts? Is it enough for you? If so, why?


  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 )