A reliable source sent me the Ecma terms of reference for Microsoft's Office Open XML format, which will be voted on Thursday at the Ecma International General Assembly in Nice. I also researched the process, and I'll explain it, but to give you the theme, their motto is "better a good standard today than a perfect one tomorrow."
How open a process will this be, since it is essentially a proprietary XML format? That is one question, and another is, is there a need for another standard, since the ODF standard is already under way as a PAS submission to ISO JTC1? Do we need another document standard for XML, when ODF already exists and is further along the conveyor belt of the standards process?
First, I'll show you the terms, and then I'll explain the process, which, by the way, doesn't include any required declarations of IPR details ever. The default is RAND, not necessarily royalty-free. The covenant not to sue might be enough to solve the RAND issue (it's not compatible with the GPL or most OS licenses), but only depending on what "conformant" means and whether Microsoft follows through, and what is actually covered by the covenant, none of which is clear. The terms are, on their face, disturbing.
Here are the terms, with my commentary in colored text:
Office Open XML Formats Terms of Reference
Office Open XML Formats
The goal of the Technical Committee is to produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the Office Open XML Formats. The aim is to enable 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. The Technical Committee will also be responsible for the ongoing maintenance and evolution of the standard.
[ So, their aim is to make the standard be compatible with Microsoft's XML format. That's plain as day. So, what? No changes, just rubber stamp?]
The objective of full compatibility with the Office Open XML Formats is adopted in order to
1. Guarantee continuous use of the existing base of Microsoft Office documents without losing any of the functionalities
2. Document all the options, properties, formatting, layout and other information of the existing Microsoft Office document base using the W3C XML 1.0 language
3. Guarantee interoperability by enabling standard-based XML 1.0 tools to create, read and write files conforming to the standardized file format
4. Support the needs of governments and businesses to archive and preserve documents using an Open Standardized Format
5. Enable standard transformations using W3C XSLT (or similar techniques) to extract or repurpose information from the file format
6. Support integration of custom defined schemas
[ Um, what was that last one again? Custom defined schemas? ]
Programme of Work
1. To Produce a formal Standard for office productivity documents which is fully compatible with the Office Open XML Formats (1)
a. 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
[ Doesn't this sound backwards? It sounds like they plan on making the standard fit the MS XML, "in the style of an international standard", instead of working to make the standard and then make sure the XML meets it.]
b. 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
2. To contribute the Ecma Office Open XML Formats standards to ISO/IEC JTC 1 for approval and adoption by ISO and IEC.
Upon completion of the Previous Items, the role of the Technical Committee will be:
3. To assume responsibility for maintaining the ECMA Office Open XML standard
4. To evaluate and consider proposals for complementary or additional technology
5. To assume responsibility for the evolution of the ECMA standard while ensuring backward compatibility with the previous versions to guarantee continuity in the use of the current and future formats
6. To establish and maintain liaison with other ECMA TCs and with other Standards Development Organizations (SDOs) as appropriate to facilitate and promulgate the work of the TC
(1) to be submitted by Microsoft Corporation.
Initial list of participants of the Technical Committee
* Not currently members of Ecma International
So, those are the terms. What happens next? First, they have to decide if there is a need for the standard, and hence for a technical committee to be formed. You and I might think there is no need, but it only takes three members to propose it, and it seems unlikely it won't happen. This article [PDF] that appeared in Forbes in February explains the process:
The Ecma process consists of three stages :
The GA approves and allocates new areas of work to new TCs, while TCs approve work items within their scopes directly.
The development of final drafts is under the full responsibility of a TC, which balances quality with speed, using Ecmas principle of better a good standard today than a perfect one tomorrow ! . The TCs almost always work on the principle of consensus, but they can use a simple majority vote. Each member has one vote, regardless of the size of the organization.
The GA approves the final drafts for publication as a standard or a technical report.
The process can be seen in this PDF, "Presenting Ecma," in a chart on page 8 and on page 9, it explains:
To begin work, several (3 or more) existing or potential Ecma members must agree a standard is required:
* If the work (area) is new, the GA has to approve it by simple majority, and the Secretary General of Ecma forms a new Technical Committee responsible for creating a standard.
* If the work fits in an existing TC, then the TC has to approve a project for the new work.
What matters is this part of the Ecma Code of Conduct, which states, so far as I understand it, that a patent holder doesn't have to declare anything about its rights at the TC level, or for that matter ever, as it will be assumed they mean RAND terms, which Ecma explicitly does not define:
The questions related to protective rights are in the competence of the General Assembly of Ecma and should not be discussed at the TC level.
Each draft standard shall be submitted two months ahead of a General Assembly. All members are required to state no less than two weeks before the GA or at the end of the postal voting period whether they claim any issued protective rights covering the subject matter of the proposed standard and/or have knowledge of such rights of third parties.
Replies to this request will be circulated in due time before the General Assembly.
When an answer is not received from a Company, the General Assembly may proceed to a vote on the assumption that this Company will act in accordance with the General Declaration, that is to license possible relevant issued patents on a reasonable and non-discriminatory basis.
It all seems very loose on IPR to me. Although not part of the code of conduct, this page explains even more explicity:
Submission of a patent declaration is not mandatory for Ecma members because the members of the Association are assumed to agree with the Ecma Code of Conduct in patent matters.
I think Microsoft could work its way through the entire process without a word about any patents it might or might not have or what it intends to do with them. That same page says that Ecma doesn't police its members but if it finds out RAND terms are not being followed, it can withdraw the standard. Of course RAND terms are not compatible with the GPL, so it's cold comfort anyway, if Microsoft were not to ever get around to fulfilling its promise to offer the standard under its covenant not to sue, or if the covenant's "conformant" language means something more exclusionary than we hope.
Further, the "Presenting Ecma" paper states on page 10 that "IPR and other nontechnical issues must be resolved outside technical meetings," and in fact, members of the TC can only vote against the draft on technical grounds:
Ecma is designed to defuse and separate the political and the technical:
* "No" votes at the TC may only be for technical reasons
*ALL members, not only Ordinary members, can vote at TC level
* At GA "No" votes and abstentions are not counted, only "Yes" votes are counted: only Ordinary members can vote at GA level
They *really* don't want IPR to even come up, I take it. When they say they offer industry a fast track, they mean it. And once you get on the fast track, how can you lose? Ecma's track record: 2/3s of their publications become an ISO/IEC
standard. Page 11 lists the members who get to vote:
They have nonprofit members too, like Mozilla, but they don't say if they get to vote or not. Apple isn't a voting member, except on the TC level, and neither is Novell, who expressed interest in the process, but who is not listed as a prospective member of the TC, I notice. In short, a stacked deck, methinks. No vote for Novell, as currently configured. Page 15 is where they say RAND doesn't mean necessarily royalty-free.
I guess the obvious solution that springs to mind is to have lots of new members join, pay the dues, and vote. Larry Rosen suggested that, but looking at the terms, what good would that do, if the goals are stated from the get-go as basically saying Microsoft's XML is to be made a standard? The only possible derailment would seem to be at the ISO level, not in ECMA, not unless there is something technically the matter. They view IPR as "political" and not relevant to what they are about, I gather. I'm not discouraging anyone, of course, but where in the Ecma process would there be a way to even raise the important patent issues? The issue about proprietary extensions? I don't see any place, so the questions we have about the covenant not to sue are not going to be hashed out in Ecma, from all I see, and we'll be left in the dark, unless Microsoft chooses to explain.
You might also enjoy reading page 20, What is Ecma's Value?
A proactive, problem solving experts' group that ensures timely publication of international standards;
Offers industry a "fast track", to global standards bodies, through which standards are made available on time;
Balances Technical Quality and Business Value:
*Quality of a standard is pivotal, but the balance between timeliness and quality as well: Better a good standard today than a perfect one tomorrow!
* Offers a path which will minimise risk of changes to input specs
* A "safe haven" for IPR
How does any of that speak to the issue of what government needs from an open standard, the stated requirements for adoption by the Commonwealth of Massachusetts? I see Andy Updegrove has the terms also, and he provides analysis. His is much stronger than mine:
In summary, what I read here is the following: the working group would be told to take the offered schema and convert them, without change (or charge), into a standard, apply the Ecma imprimatur, and then submit them to ISO, so that users of Microsoft Office may seamlessly use their documents in conjunction with other conforming software, and so that Microsoft may obtain a unique market benefit. The working group would also be told not in any way diverge from this goal in order to improve the standard, or to address the needs of the users of any other products in existence, or to accommodate the functionality of any other product, or to serve the interests of any other vendor, or of any customer that has needs that cannot be served by Microsoft Office.
I would submit that such a request is not consistent with the role of a standards body, but rather the diversion of an organization created to serve the needs of an industry to the unique demands of a single vendor. Were Ecma to be based in the United States, I would not be surprised if accepting such a charter would result (if discovered by the IRS) to the loss of the standards developer's tax-exempt status. . . .
A final note: as expected, there is no mention in the charter of any special IPR requirements that would be imposed on any member of Ecma. This would indicate that while Microsoft may renew it's royalty-free commitment, any other member(s) of Ecma with a relevant patent would have the right to charge a royalty to implement the resulting standard, or to require terms that would be inconsistent with open source licensing.
It will be interesting indeed to see what reception the Terms receive within Ecma, as well as how Ecma is viewed in the global standard setting community in the future (i.e., as a true standard setting body, or as a mere conduit for single vendors to ISO approval), depending on its whether the Terms, as offered, are approved.