Open standards are publicly available specifications for achieving a specific task.

Fortunately, we also find a link to a paper by Ken Krechmer, The Meaning of Open Standards (note he just presented it at a conference again in January 2005). This appears to be a oft-cited work and reading it, I understand why. One of the ideas that I think one should take away from Krechmer's work is that "open standards" tends to imply more than letting everyone know what the standard is - it includes an attempt to create an "open" standard setting process based on "open meetings, consensus and due process."

In addition, one might be interested in Krechmer's "ten rights that enable Open Standards":

1. Open Meeting - all may participate in the standards development process.
2. Consensus - all interests are discussed and agreement found, no domination.
3. Due Process - balloting and an appeals process may be used to find resolution.
4. Open IPR - IPR related to the standard is available to implementers.
5. One World - same standard for the same capability, world-wide.
6. Open Change - all changes are presented and agreed in a forum supporting the five rights above.
7. Open Documents - committee drafts and completed standards documents are easily available for implementation and use.
8. Open Interface - supports migration and allows proprietary advantage but standardized interfaces are not hidden or controlled.
9. Open Use - objective conformance mechanisms for implementation testing and user evaluation.
10. On-going Support - standards are supported until user interest ceases rather than when implementer interest declines (use).

Most formal SSOs and many consortia consider that Open IPR refers to the fact that holders of Intellectual Property Rights (IPR) must make available on Reasonable And Non-Discriminatory (RAND) terms their IPR (implementation).

We can contrast this definition with that of Bruce Perens, another oft-cited source for a definition of "open standards". Perens' definition includes six principles:

• Availability
• Maximize End-User Choice
• No Royalty
• No Discrimination
• Extension or Subset
• Predatory Practices

Let's Make an Open Standard!
Having explored a little bit just what an open standard might be, let's now turn to a short look at how the standards setting process works. The first thing you will need is someone who wants to create the standard (we'll look at who these "someones" are shortly). In the diagram below, you'll see that I've set up a fictional group of five companies that have joined together with the intent of creating a standard. They get together and decide to adopt some of the principles discussed earlier in order to conduct an open standard setting process as they intend this to be an "open standard".

The standard these companies are developing in this scenario is "Standard X". As the diagram shows, Standard X is made up of 4 requirements (or specifications - look back at the Wikipedia definition). So, in the course of developing the standard, each company will have input into what 1, 2, 3, and 4 will be.

So far, so good. Now let's suppose that Company C says, we have an idea that we think would serve perfectly as Requirement #3. But, it is some of our valuable IPR, so we can't just stick it in there for free or we'll lose our investment. What are the other companies to do? How should the group handle this situation?

Some would say a RAND approach would be ok - the other companies tell Company C the IPR can become part of the standard, but Company C must agree to limit their license fees to what is "reasonable" (after all, they deserve to get back their investment eventually) and they can't discriminate against who they'll grant a license to (that is, they can't lock out their competitors).

Others would say, Company C, you can put it in there and license it, but it has to be royalty-free. You can't make anyone pay for it and it has to be on a non-discriminatory as well. Hopefully you can see what kind of problem this might present for a FOSS developer, especially if they have to pay any licensing fee, even if it is deemed "reasonable" (which Krechmer points out is a very vague term that is rather inconsistent with "open"). In addition to the license problems, FOSS developers may have a problem if they are trying to release their project under a license like the GPL that doesn't permit things like patent encumbrances.

Who's Setting the Standards
The next question we should address is that of who gets to say whether a standard is an "open standard". This very question goes to the heart of the dispute between the BSA and the European Commission. The BSA is complaining that the EC's standard is not an open standard.

To provide an analogy, think of how you would answer the question, "is this license, X, an 'open source license?'" How would you decide? Most people would probably accept it as being "open source" if it got the seal of approval from the Open Source Initiative(OSI). If you visit their web site, you'll see that they list many, many licenses as "open source" and you are free to "say that your software is 'OSI Certified Open Source Software'" if you use one of the licenses listed.

However, for "open standards", it does not appear to be so clean cut. One group you may turn to would be the newly formed Open Standards Alliance. Unfortunately, if you visit the site you'll see the group is not really up and running yet. According to this article, the group has been organized as a 501(c)(3) and is working on

a reference base for open standards and software applications that meet the definition of "open" as determined by members in a subsequent meeting.

As you can see, it would appear at the present time that there is no widely accepted body for establishing "open standards". As such, this can create problems for "end users" trying to implement "open standards" policies. The EC incident referenced earlier is one example. Another good example might be the State of Massachusetts and their efforts to promote both "open source" and "open standards" as described in this CRN article, Massachusetts Senator Hails Compromise On Open-Source Effort. In that case, the State was trying to implement an "open standard" but met resistance (most notably from Microsoft). As a compromise, it appears they have moved to define an "open standard" more around the issue of an "open format". You'll notice thought they still try to define an "open standard" as one

based on an underlying open standard, developed by an open community, and affirmed by a standards body; or, de facto format standards controlled by other entities that are fully documented and available for public use under perpetual, royalty-free, and nondiscriminatory terms.

What About Microsoft's "Open Standards"?
As you may recall from earlier, the State of Massachusetts recently took steps to realign the meaning of open standards to ensure proprietary companies(wink, wink) could offer software to the State. But is a Microsoft solution really an "open standard" solution? Microsoft would probably like for you to think so. I imagine their argument would be something about how they comply with the State of Massachusetts's policy on software that meets the "open standard" definition. Microsoft's Office suite (MSO) formats are a de facto standard (yeah, I don't like saying that, but with their market share it is arguably true) and Microsoft can claim they license the format under a perpetual, royalty-free, non-discriminatory term. Ah, but do they really?

To answer that question we need to shift gears a little bit and try to understand Micro-speak. Instead of "open standards", Microsoft appears to favor the term "interoperability". You can find Bill Gates playing this up in a recent "Executive Email" page on the company's About Us pages. More importantly you will find a link to a site Microsoft has set up about "interoperability". And check out this language about patents

With respect to patents, Microsoft will generally license our patents under fair and reasonable terms so long as licensees respect Microsoft's intellectual property rights. These licensing terms are similar to how others in the technology industry license their own patents, typically referred to as "commercially reasonable" terms. Where Microsoft determines to license patents, we will generally do so nonexclusively. For products that practice Microsoft patents, the royalty rates will follow industry norms. Microsoft will consider all requests for licenses but reserves the right not to license certain IP.

Ah, but their direct efforts are not the only place where we see Microsoft's hand at work. We can look back to the Business Software Alliance's (BSA) recent complaint about the EC action. Keep in mind that many consider the BSA and Microsoft to be the same thing. You can read the BSA white paper regarding the EC policy and find that they decided to hide their objections to "royalty free" IPR terms in a footnote on page 3 of the report. Nevertheless, they decided to make a big deal out of it for the media. I think the more important issue to come out of the white paper is how they spend so much time discussing "open source" software. A cynical person might think they are trying to get people to associate "evil", "free", "open source" software with "open standards" in an effort to paint them all into one corner. Indeed, if they were to ever succeed in demonizing open source software, open standards would likely go out the window as well. (jmo, but it is too late for them on this if for no other reason than the cat is out of the bag - I'm still not sure why they persist with this strategy.)

Full Circle?
Finally, we come back around to the news about Larry Rosen and his call for action regarding RAND patent terms that have been incorporated into the new OASIS IPR policy. OASIS (remember, one of those groups trying to define "open standards") recently approved a new policy regarding IPR that contemplates three different IPR "modes" described as

1. RAND - requires all Obligated Parties to license their Essential Claims using the RAND licensing elements described in Section 10.1.
2. RF on RAND Terms - requires all Obligated Parties to license their Essential Claims using the RF licensing elements described in Sections 10.2.1 and 10.2.2.
3. RF on Limited Terms - requires all Obligated Parties to license their Essential Claims using the RF licensing elements described in Sections 10.2.1 and 10.2.3.

written assurance that upon approval by the OASIS Board of Directors of the relevant OASIS specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms.

Today's Situation
Hopefully this article has helped to clear up some of the issues regarding "open standards" and some of the players in the battle. At the very least, I hope it helps you better understand some of the recent news about open standards that you may have been reading. I also hope this article has shown some of the ways that Microsoft and its allies are working to pervert the term "open standards" or to somehow malign it with a negative connotation in an effort to gain an advantage over FOSS.

Some who have read my articles know that I have hypothesized in the past that standards will become a major battlefront in the IP wars. If you don't believe me though, you might want to listen to Larry Rosen:

"The next big battleground between the Open Source and proprietary software communities will be in the area of Open Standards. You need Open Standards to implement Open Source. However this need not be a battle."