As I mentioned earlier this weekend, I was away when the news broke about how Microsoft is planning to push its XML formats through ECMA and then perhaps ISO, thereby creating an “open” standard. As I’ve stated before, it is naive to have multiple definitions for “open” and we should really only be talking about standards being more or less open, and even then only when we speak about certain aspects of openness. So let’s examine some of the issues related to the five aspects of openness that I talked about in the linked entry:
- Modification by Others
I’ll also recall here what openness might mean in an extreme sense, though it seems to be easier to define “closed” than “open.” I’ll use the phrase “purely open” to mean “about as open as we can possible imagine a standard to be.”
Development: A purely open standard is created in a manner that allows anyone who wishes to participate to do so without discrimination. All proceedings and records of proceedings are public and decisions are made by consensus. No one can prevent anything that actually happened during the development of a standard from being recorded in the minutes. There are no secret agreements. No one person or organization can veto a decision.
Maintenance: Once created, a purely open standard is maintained by a community under terms similar to that which developed the standard. In addition, the community has a responsibility to maintain backward compatibility if it decides to do so. That is, openness gives the maintaining community the right to make significant modifications, but since membership is not restricted, the community may get enlarged at times by a sizable group of people who may either want to force the changes or maintain the status quo. (This is just democracy in action: if you get more people to vote for you, you win.) So while significant changes may be made in the evolution of a standard, it is not done at the whim of a single vendor unless that vendor can garner significant independent support. As in the development of a standard, all votes or positions taken during consensus creation are recorded for all to see.
Accession: Anyone who wishes to have a copy of a purely open standard may have one at no cost. When possible, the standard is available online and the document format used to represent the specification is an open document standard (I know this is recursive, but you know what I mean).
Implementation: A purely open standard can be implemented by anyone in any way desired with no payment of royalties.
Modification by Others: A purely open standard can be mined for its good ideas and used in part or in whole in other standards. In particular, a profile can be created that states which parts of multiple standards should be used together to achieve a certain end (for example, a subset of a set of standards for use on mobile phones).
We know the old situation with the Microsoft XML formats: they created them, they changed them whenever they wanted to do so, and they had a license that was restrictive and prevented GPL implementations. Not so open, and people noticed, particularly in Massachusetts.
What’s the situation with the new covenant not to sue and the plan for ECMA? Let’s look at the five areas for openness in this case:
Development: Microsoft has done all development on the Office XML formats by itself. Will the ECMA work be a rubberstamp or will ECMA members truly have a chance to participate? Will they do so? If the charter of the new technical committee allows no real modifications to what Microsoft has put forth, this fails this part of the openness criteria miserably. The new ECMA technical committee (TC) should have the opportunity to make whatever changes it sees fit. It is the responsibility of those who care and may even want to see some sort of OpenDocument Format/Microsoft XML format convergence to take part and lay the groundwork for that eventuality. But what if this causes product delays? Well, that’s just life in a standards world. HTML changed when it became standardized in the W3C from what Netscape and Microsoft had first implemented. The world is better for it.
Maintenance: Will the ECMA TC make whatever changes it, as a community, thinks to be appropriate beyond the first version? Backward compatibility with what the ECMA TC first standardizes and not necessarily with what it is handed as input is important, but the community can decide to do what it pleases. Again, life in a standards world. Vendors or groups can always implement the ECMA standard in the next version of their software. No single vendor should be allowed to make its own independent changes to the standard, unless this particular standardization effort is a sham. Also, this TC has to be a real joint effort and not just a single vendor making all the decisions. Just with Development, all minutes of all TC meetings should be public. For comparison, all the OASIS OpenDocument Format TC email list entries and minutes are public.
Accession: I suspect it will not be an issue getting a free copy of the spec, but we’ll need to watch this. Final ECMA specs are free in PDF form. The ISO usually charges for copies of its specs (with some exceptions), if this effort gets that far. Will we all be able to see the development of the spec in ECMA or will we have to wait until it becomes final there? This is important because developers need to see a spec as it develops so that they can prepare implementations, not to mention debug the spec in progress.
Implementation: Microsoft has made its covenant, but we’ll need to see what others do in ECMA. If the spec ends up being (F)RAND overall, it is not particularly useful for all types of implementation, particularly open source. So whatever Microsoft has or has not done so far, we will need to see what the licensing looks like in ECMA. To be blunt: I don’t think anything other than RF with some simple conditions like narrow defensive termination will be sufficient. Stay vigilant. We also need to see what the copyright license is like, since we have not seen anything about this yet. Microsoft has made progress in the openness direction with its covenant not to sue (and see Andy Updegrove’s latest analysis) but they need to continue that openness trend in ECMA.
Also, and this is really important, by standardizing its formats in ECMA, Microsoft should be giving up the right to include proprietary extensions of the spec when it creates its implementations. Repeat after me: NO PROPRIETARY EXTENSIONS.
Modification by Others: We’ll have to see what the copyright situation is here, as I mentioned above. Also, does the language in Microsoft’s covenant not to sue
This covenant shall not apply with respect to any person or entity that asserts, threatens or seeks at any time to enforce a patent right or rights against Microsoft or any of its affiliates relating to any conforming implementation of the Specifications.
mean that you can’t implement a subset of the spec to implement a profile, say, and still avoid difficulty? We don’t know, but we should find out.
Ok, so that’s a few things to think about in regard to Microsoft’s move to push its Office XML formats through ECMA. Now, what about OpenDocument Format? Whatever Microsoft does or does not do in ECMA, the ODF effort will continue full steam ahead and I still think Microsoft should both join the TC in OASIS and implement ODF. Compared with ODF, the Microsoft effort has many unknowns and still measures much lower on the openness scale. ODF is available NOW, is very open NOW, is very functional NOW, and has a bright FUTURE regarding more development by a real community.
In summary, the move last week was interesting, but does not radically change the world. In my opinion, ODF and the applications that support it now and plan to support it are the best bet for an interoperabile future. Indeed, the ECMA action might be viewed as a move to fracture the existing industry standardization, and should be viewed in that light until proven otherwise.