(For part I of this series of reflections on the importance of Open Standards please see my previous blog entry of Sep 11, 2008.)
Those who don't like Openness and Open Standards often claim that there was no precise definition of an Open Standard, that the term created nothing but confusion and was, therefore, not good to be used. As a proof I have often heard people referring to the Open Standards entry in Wikipedia which lists about a dozen specific definitions.
Indeed, after the rise of the concept of Open Standards, many organisations as well as governments using the term and adopting the concept developed their definition. But this is pretty much the normal process with new concepts and terms, isn't it. And how much do the definitions actually differ?
If we take a closer look and try to boil down these different definitions in order to distill the common ground between them it becomes pretty clear that there are two major issues around a standard which are addressed in the definitions:
1. The development process of the standard;
2. The terms and conditions for availability and implementation of the standard.
This is, in fact, what makes the concept of open standards so important and valuable: that it addresses both development aspects and business aspects. And that it makes sure that openness is not, can't be and must not be limited to either of these aspects but needs to cover both of them.
As far as (1) the standards development process is concerned, there is a good deal of commonality across all definitions. Openness and transparency, balance and consensus are key elements of the process definition. Similarly, the notion that the development process of a standard must not be controlled by a single vendor of group of vendors, but that the procedures must be fair to all, is widely acknowledged and included in the definitions. To sum up: there is a solid consensus around what constitutes an open standards development process; this does, however, not say that this is always appropriately implemented in standards organisations, nor that the processes are always appropriately practiced.
Regarding (2) the terms and conditions for availability and implementation of the standard, this is where the controversy is located. Looking at the availability, there is agreement that an Open Standard should be available for free or for a nominal, low sum. But there is strong dissonance on the terms and conditions for implementation. While some require royalty-free licensing of intellectual property (mostly patents) contained in Open Standards, others claim that (F)RAND ((Fair)Reasonable and Non-Discriminatory) conditions are what characterises and Open Standard. Some definitions, e.g. the ITU-T definition, acknowledges both options and says that “IPRs essential to implement the standard [are] to be licensed to all applicants on a worldwide, non-discriminatory basis, either (1) for free and under other reasonable terms and conditions or (2) on reasonable terms and conditions (which may include monetary compensation). But also the “other reasonable terms and conditions” quoted above are a matter of dispute since they might contain constraints which make it impossible for an Open Source community to implement a standard even though it is licensed royalty-free.
In our recent announcement of IBM's new IT standards policy, we, of course, cover the issue of what makes a proper process and what makes a proper standard, as well. This announcement is all about Open Standards, its a commitment on IBM's side to Open Standards. Two of the IBM principles for IT standardisation touch on the issues of the standards process and of the availability of the standard for implementation, respectively:
Advance governance rules within standards bodies that ensure technology decisions, votes, and dispute resolutions are made fairly by independent participants, protected from undue influence.
Collaborate with standards bodies and developer communities to ensure that open software interoperability standards are freely available and implementable.
Coming back to the definition of Open Standards, openness is a spectrum rather than an absolute criterion. And it depends on the specific requirements, e.g. For a specific application, to define the exact level of openness required. As Bob Sutor outlined in his blog a while ago,
I’ve also put forth the idea that we should consider “closed” and “open” as two ends of the spectrum. Here “closed” means “it’s mine, you can’t have it” and “open” means “here take it, do whatever you want with it.” Most standards fall somewhere in between, with very few things being all the way at one end or the other.
Defining the term Open Standard, or more precisely: referring to the concept of Open Standards will be most effective by taking the actual objectives into consideration. This means to take into account that openness is a spectrum, as well, and that in some cases some concessions might be acceptable.
Clearly, in my view, some elements of what makes an open standard are non-negotiable. This concerns foremost the process. Openness, transparency, a fair processes that is free from undue influence are a must for an Open Standard.
Likewise, the fact that open software interoperability standards ought to be available royalty-free and ought to allow for Open Source communities to implement them without restrictions is essential. However, there might be other areas than software interoperability where more restrictive terms and conditions could still be acceptable.
But one thing is also clear: where the pendulum points too much towards closed on the spectrum it is no more an Open Standard.
The argument that there was no precise definition for Open Standards does not quite hold. In fact, the term Open Standards is a lot more precise and clear than, for instance, the terms 'standard' or 'specification'. 'Open Standard' always points at two dimensions: the process of standards development and the conditions of standards availability. And openness marks the line of demarcation and indicates what is still acceptable as and Open Standard and what is not.
The point that the term Open Standard was not clear enough is in reality very often a dummy argument used by those who want to avoid taking a position on the issue of license terms and conditions associated with a standard. The concept of Open Standards, however, does not allow that this aspect is being neglected or ignored. Because the aspect is highly relevant for openness and for the new paradigm of open computing which includes Open Source and Open Innovation as further cornerstones alongside Open Standards.
In other words: as the concept of Open Standards increasingly gains momentum. Open Standards meet the requirements in today's market place. The issue of a single, ever-valid definition is, in the end, a non-issue. After all, Open Standards meet important needs both in the first, second and third sector.
No comments:
Post a Comment