In public discourse and public policy, "open standards" are a now Good Thing (in the sense of 1066 and All That). However, the more that "open standard" is deemed good and important without having a common meaning, the more that interests will attempt to stretch its meaning in one way or another. In this case, one way means to allow actual royalty-bearing (RAND) standards as "open standards" and the other way is to require open source (or even free) implementations.
The Wikipedia entry for Open Standards shows the variability in the definitions of the term. Most pressingly, it has examples of legislation that uses the buzzword "open" but in very different ways.
It is an issue with a lot of angles. For example, the Digital Standards Organization (another fakey body from the people who brought you NOOXML.COM) is very concerned with ideas of "vendor capture." At the other end, I have long been calling for "verifiable vendor-neutrality" which takes into consideration both crypto-monopolization and cartel-ish exclusion, in particular in Is our idea of open standards good enough? And the Open Source Initiative has an angle too, which is that an open standard is something that allows an open source implementation.
In a related discussion on this at ConsortiumInfo.org, I suggested that what would be useful would be an ISO standard giving definitions for different kinds of openness. The need for this came clearer only today with the reported debate in Europe about draft European framework for interoperability (I trust my readers are sophisticated enough to see past trivializing words like "spat"!)
Openness is a motherhood term now, so of course there will be surprises and debate about what kind of motherhood we actually mean. My opinion, for what it is worth, is that RAND-z and RF is necessary but not sufficient for openness, and that governments embarking on an open standard policy need to put in place some patent-limitation plan which would bring existing, market dominating, royalty-bearing standards into the RAND-z fold by, say, 2010. This necessarily will mean that some successful consortia and even some SCs within ISO will have the ground cut out from under them: tough titties.
So what would such a standard contain?
I agree with a comment Andy Updegrove made about the idea, to the effect that pinning down a meaning for "openness" might be futile and that concentrating on enumerating the various categories would be the way forward.
What would such a standard have?
I think it would be useful to have:
- An enumeration of the various qualities that are roped into different ideas of openness. (See here for Updegrove's example.) RAND-z and RF fit here.
- A grouping of these into some distinct blocks that reflect typical community positions. I would make a distinction between open source, open standards and open technologies (where an open technology is one where there is an open standard, truly open licensing (see below) and open source implementability.
In particular, the OSI Open Source Definition, the GPL, W3C license, RAND, NDA.
- A minimal set of pre-fab licenses for the major different classes of openness, so that consortia and so on can easily cut and paste. Again the Open Source Initiative is the model here: I'd see this as a way of trying to encourage their project (without stepping on their toes.)
I have been critical of some aspects of the use of "open" in the past: see Is our definition of open standards good enough? where I put forward the idea of verifiable vendor neutrality which would allow checks against both crypto-monopolization and cartel-ish technology-exclusion behaviours.
But I have two other concerns about the current kinds of licenses and promises at consortia and by the global corporations.
The first is that the licenses are typically made only in respect to particular standards: so if company A has granted a license for standard B, and you implement standard B, you are OK, but if you use the same technology on implementing standard C you are not covered.
The second is that even if company A has granted license for both standard B and C, and you implement either, you still may not actually be covered: this is because typically the grant is to "necessary" or "essential" claims. This does not mean that optional parts of the standard are not covered, I should stress: but what it means is that if there is no other way to implement a standard than to use the IP-encumbered way, then you are allowed to use that IP-encumbered way.
I don't think either of these is nearly good enough to sustain the kinds of openness that people think they are buying into. Think about how the anti-aliasing patents have held up open source software, for example. It will not meet the public policy requirements that the drive to openness is aiming at if at every turn implementers of standards are forced to pick the low quality implementation technique.
Of course, in general you only expect suits over IP when someone has some money. I am not predicting any kind of future where IBM sues a small developer for implementing something that IBM has open licensed for ODF but not OOXML, or where MS sues some small developer for using a method MS has a patent for but which was not "essential" to use. But it is certainly an issue for public policy holders to consider, IHMO.
But whenever I have mentioned in public forums that the essential claims provisions seem to mean that if there are multiple implementation techniques, you are not covered, I am often rewarded by blank stares. I think this is because the drafting lawyers interpret the problem of making sure that the open standard can have open implementations (which is what the public policy agenda is) as being the same as making sure that the open standard can have at least one open implementation (which is not the same thing, because different implementation strategies vary in their performance or quality properties.)
What is needed for openness is open licenses that all the technology being granted being usable in any open standard, whether there are alternative implementation strategies or not.