What is an Open Standard?

The term "Open Standard" is somewhat contentious, having a fairly broad definition depending on the interests of those promoting it. This page exists to resolve any ambiguity or confusion about what we mean.

At present, the NZ government, via the NZ Government Open Access and Licensing Guidelines, defines an open standard (with regard to file formats - see bottom of page). The definition, as of 11 August 2015, is unsatisfactory, as it makes allowance for fully captured standards, and royalty-bearing standards which we see as anathema to the goal of open standards: to make it both possible and desirable for anyone and everyone to comply, for the benefit of society.

The UK Government has provided a very thorough set of of "open standard principles" which focus on exactly what we have described here: leveling the playing field for all software suppliers for the benefit of "the user", namely society at large.

Opensource.com (run by RedHat software) offers an in depth description of what makes up an Open Standard. 

For the purposes of this initiative, we have based our definition of "Open Standard" on that provided by Bruce Perens in his "Open Standards: Principles and Practice"):

An Open Standard is more than just a specification. The principles behind the standard, and the practice of offering and operating the standard, are what make the standard Open. The principles of Open Standards:

  1. Availability – Open Standards are available for all to read and implement.
  2. Maximize End-User Choice – Open Standards create a fair, competitive market for implementations of the standard. They do not lock the customer in to a particular vendor or group.
  3. No Royalty – Open Standards are free for all to implement, with no royalty or fee. Certification of compliance by the standards organization may involve a fee.
  4. No Discrimination – Open Standards and the organizations that administer them do not favor one implementor over another for any reason other than the technical standards compliance of a vendor's implementation. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services.
  5. Extension or Subset – implementations of Open Standards may be extended, or offered in subset form. However, certification organizations may decline to certify subset implementations, and may place requirements upon extensions; see Predatory Practices.
  6. Predatory Practices – Open Standards may employ license terms that protect against subversion of the standard by embrace-and-extend tactics. The licenses attached to the standard may require the publication of reference information for extensions, and a license for all others to create, distribute, and sell software that is compatible with the extensions. An Open Standard may not othewise prohibit extensions.

We do not see compliance with an Open Standard as a proxy for implying practical interoperability between any two software products which implement the Open Standard. We do, however, see an Open Standard as a rich and independent common reference point, not controlled by any one self-interested entity, for those developing software products. Open Standards compliance is 

  • measurable, and
  • serves to minimise the distance between any two implementations required to achieve practical interoperability.

Our goal is that anyone may implement software that implements and complies with an Open Standard with confidence and without requiring permission from any entity. Doing so will not incur a present or future liability for patent infringement or any other royalty or related costs for either the developer or any user of the software. 

The ideal open standard is one which has multiple, compliant implementations on different software code bases, and to which changes can only be made with the agreement of multiple parties, at least one of which has no commercial interest.

We have provided some examples of open, proprietary, and "fauxpen" standards.