The Open Source Initiative hosted a BoF last Thursday evening at OSCON 2006, and one of the primary topics of discussion was possible compliance criteria for an open standards requirement. Lots of thought and effort has gone into developing a strawman proposal, and the discussion is just beginning. I would strongly encourage you to participate in the discussion if you have a standards and open source background. The discussion list sign-up is located at http://opensource.org/osr/.
This issue has been simmering for a while now, all the way back through debates about the relationship between standards and open source, and comments from various open source participants about various standards development organizations' IPR policies. The topic is coming back into the forefront.
The rest of this post is the edited version of my first post to the OSI discussion alias. I will happily entertain debate and discussion here, but would encourage your participation in the OSI discussions if you want to be heard in the outcome.
First, let me state I agree with the goal of developing a clear statement supporting the ability to develop open source software implementations of standards. Second, the following views and ideas were shaped over the years of participation in the POSIX/UNIX standards development process from the late 1980s. (I'm still in recovery.)
I want to set the stage with a few definitions I keep in my head, so
hopefully this is actually coherent.
Specifications and Standards:
A specification is simply a document describing some interface for
interoperability. Lots of companies publish specifications to enable
customers and partners to better interoperate with their products. In
such cases, where the specification is published by a single commercial
entity, it benefits the company by encouraging lots of add-ons.
A standard is a specification that has been put through some form of consensus process by a collection of interested parties. It may be a formal government supported de jure process with checks and balances to ensure that the consensus isn't anticompetitive collusion. It may be an industry or trade organization (CBEMA, ECMA, IEEE) with a broad interest in an area, e.g. computing standards. It may be an industry group with narrower focus (e.g. OASIS, W3C, IETF). The consensus process has rules that define such things as participation, acceptance, interpretation, amendment and withdrawal.
The economic purpose of a standard is to encourage and enable multiple implementations of the thing specified, i.e. it is the opposite of a company specification which benefits the company's own ecosystem. A standard is designed to increase choice and benefit consumers. A successful standard has to have multiple implementations that conform and interoperate. If there's only one implementation, then it is just a vendor specification regardless of the process it was put through to receive a stamp of approval.
[For taxonometric completeness:
- A de facto standard isn't. A de facto standard is a technology that is so ubiquitous as to be "a standard in fact". But it's typically controlled by a single vendor, i.e. not a lot of consensus involved.
- A corporate standard is an ambiguous entity that may be selecting de facto technologies to simplify and narrow procurement choice, OR a reference to de jure standards that is designed to increase procurement choice. Sometimes both. Context is everything.]
Patents and Standards:
Patents exist to protect a single implementation of an idea. They serve
a completely different purpose in the economic spectrum to standards
which encourage multiple implementations. Because of this, every
standards organization has developed some form of IPR policy to attempt
to survive the discovery of a patent in their midst, and indeed to
discourage participants from embedding them so as to avoid such problems.
This does not mean there are not examples of industry standards groups being mirrored by trade organizations and relationships with patent sharing agreements. But within the standards organization itself, there is neither the legal bandwidth or financial depth to deal with them directly. (And yes, some naive vendors would love to have a patent on a standard because obviously the world will want to beat a path to their door to pay a tax on the standard, but it seldom actually works out this way.)
So here are my concerns per the current compliance criteria.
Criteria 1: The standard must include all details necessary for interoperable implementation.
This is tough. Standards participants are there because of some level of experience and expertise (regardless of whether they are lone participants or corporately sponsored). By definition the context of the discussions and debate result in a standard that has "holes" where things were simply "understood" by the participants. This is why every formal organization needs rules to interpret and amend standards. (Standards are actually living documents, but with a lifecycle more akin to trees than people.) English is an inexact language.
As well, some holes are deliberate. There is sometimes a fine line in relaxing the standard to allow implementation and conformance for as wide a set of participants as possible, without breaking the underlying interoperability model. Without the IETF requirement of two independent and interoperable implementations, there is NO WAY TO KNOW if the standard includes all details necessary for implementation, or more exactly, all details necessary for interoperability.
Criteria 2: The standard must be freely and publicly available (e.g. from a stable web site) under royalty-free terms.
I have no issue with this one per se, except that some of the core standards in our industry embodied in open source were expensive books in the past (e.g. ISO/ANSI C/C++, POSIX, UNIX, SQL). REQUIRING this royalty free access seems a bit off. Didn't stop us before. Won't stop us in the future.
Criteria 3: All patents essential to implementation of the standard must be licensed under royalty-free terms.
Today any standard can be shot by an idle patent from outside its community of interest, regardless of the occasional pathological abuse from within (i.e. Rambus), and regardless of the IPR policy in place. Just like any community developed project licensed under an open source license. No rules the OSI puts in place will change this.
You're asking me as a standards participant to agree to the terms for your "open standard" definition, when I already have the ability to so declare through the standards orgs IPR policy or any public non-assert or covenant I make about my own patents, only to have it taken away by a non-participant at ANY time. Why does this criteria have ANY value to me as a standards participant?
Criteria 4: There must not be any requirement for execution of a license agreement, NDA, grant, click-through, or any other form of paperwork to deploy conforming implementations of the standard.
By requiring no paperwork or click through to deploy conforming implementations of a standard, you just narrowed the definition of an "open standard" to only open source projects freely available on the web. No product based on open source even fits if it has a support/maint contract in place. And I think you would discover that if your definition of "open standard" excludes a standard that is properly implemented multiple times by closed source commercial products that interoperate, you'll be laughed out of the house of "open" by all participants in standards orgs the world over.
Criteria 5: Implementation of the standard must not require any other technology that fails to meet the criteria of these requirements.
The requirement that "open standards" implementations must not require any other technology that does not itself meet the open standards criteria dooms this to a utopian failure. Many standards depend upon other standards. If one at the bottom of the pile (or the end of the dependency list as the case may be) can invalidate the entire chain, I see no value as a standards participant to ever buying into your definition of "open standard". It puts the implementation burden on me in such ways that I may not have control over it. POSIX (IEEE) was based on C (CBEMA). Different orgs, different rules of engagement, with different non-overlapping parties of participation.
The Term "Open":
The term "open" is perhaps a red herring here. The term was polluted
with respect to standards at least 15 years ago and customers and
vendors alike have long memories. We started with "standards", and the
messaging battle moved to "open systems" to get away from the constraint
of standards to which a vendor might have to actually conform and
certify. The term "open" was slammed onto "standards" to try to find yet
more definitional integrity OR ambiguity, depending upon who you were. (Indeed we get to see the current fetish with marketing people and "open" in open source today.)
Instead of trying to force a definition into a space where you are sailing into the teeth of the gale of mass vendor mass marketing that aligns with your goals only partially, and historical shoals on which to run aground, perhaps we can modify the terminology to suit the OSI need and to be readily defensible by the OSI. What you really want is a "open source enabled standard", where regardless of the consensus process used to arrive at it, the product (i.e. the standard itself) can easily be identified as being implemented in open source software.
Implementation:
Culturally, you want standards organizations to adopt something similar
to their IPR policy with respect to "open source enabled". You want each
to have the simple ability to say that within their overall process of
standards development, they can readily identify a standard as "open
source enabled".
Participants in standards efforts are the customers of standards organizations. As such, there needs to be the flexibility in the system to encourage the right thing to happen while preventing such a hard-line discussion that even should the OSI definition of "open standard" be adopted by the organization, the participants are sufficiently disenfranchised in how they meet their business needs that they move their standards setting efforts elsewhere.
Organizations as engineering-centric in their process as the IETF could create their own implementation by simply requiring one of the "at least two independent and interoperable implementations" be licensed under an OSI compliant license. OASIS on the other hand could add an upfront step in the scope and reference terms of the working group similar to their IPR policy where the working group agrees to provide a reference implementation under an OSI compliant license. It wouldn't require every OASIS standard so to do, but rather gives their working groups the policy framework up front to declare their intentions for all to see (and OSS developers the encouragement to participate).
This gives vendor participants that support open source the ability to selectively support standards with open source implementations to competitive advantage, while still providing closed implementations themselves in other areas.
Those are the opening concerns and ideas. Looking forward to the discussion.
Related Posts:
- Corwin's Razor and the OASIS IPR Policy (I discuss why I think the OASIS IPR policy was a good policy.)
- Standards and Open Source Software at OSBC (I discuss the economic connection between standards and open source and use ODF as a current example.)
Comments