Swiss Internet User Group (SIUG)       an initiative of CH Open siug@siug.ch

Strict Definition of the Notion “Open Standard”

This is version 0.7.en1 (2010-01-16)
The current version is always available under this URL: https://strictly-open.xyz/standards
Author: Norbert Bollow (contact information)

The goal of this definition to create a strict and precisely-defined notion of Open Standards in the context of computer software. Strictly open standards guarantee that programs of different vendors are interoperable with each other. In addition, the use of strictly open standards makes it possible to replace individual programs or system components by software from another vendor. Users of IT systems have thereby freedom of choice to switch to a different software vendor if necessary, without disproportionate difficulties and costs. (Avoidance of lock-in effects.) For special use-cases which are not completely covered by open standards, the interfaces should nevertheless be defined on the basis of open standards. The corresponding notion of Open Interfaces builds upon the notion of Strictly Open Standards that is defined here.

Criteria for “Strictly Open Standards”

A technical specification which aims at achieving interoperability of computer programs with other computer programs or with hardware components may be referred to as a Strictly Open Standard if it fulfills all of the following seven criteria¹. Following the custom in ISO/IEC standards, the imperative “shall” is used to indicate normative requirements.

Note 1: We explicitly demand these strict criteria only for interoperability standards which are relevant for computer programs, because it is specifically in this area that because of the increased economic network effects of the internet age, and because of the increasing importance of Free and Open Source Software (FOSS), the traditional criteria of ISO, IEC, ITU and other standardization organizations are no longer sufficient.

(a) Public specification: The specification shall be published. Royalty-free copying and redistribution² shall be allowed.

Note 2: In the area of standardization which is addressed by this definition, generally not even ISO succeeds in convincing market participants to buy copies of standards expensively. For standards which are not available free of charge for download from the internet, there is a very high risk that they will not be implemented by sufficiently many software vendors to effectively prevent lock-in effects. The condition that it shall be allowed to redistribute copies of the standard is important in particular for standards which are available free of charge, because otherwise there is the risk that the standard might one day disappear from the internet if the copyright holder looses interest.

(b) Strictness: The specification shall be formulated precisely and sufficiently strictly, so that it ensures interoperability³ of conforming implementations within the scope of its stated objectives.

Note 3: Here interoperability is meant in the sense of the definition in ISO/IEC 2382-01: "The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units".

(c) Technical quality: The specification shall be technically correct⁴, mature⁵ and stable⁶.

Note 4: Correctness means that there shall not be any factual errors, such as contradictions or errors in the application of other standards which are cited as normative references. This applies both to the normative and to the informative part of the specification. Such errors will be noticed during the diligent development of a complete implementation of the specification; it is therefore possible to find and correct such errors before a specification is formally accepted a standard.

Note 5: Maturity means that the specification can be reasonably expected to meet all foreseeable current and future needs within the scope of its stated objectives.

Note 6: Stability means that the standard can be reasonably expected to remain essentially unchanged, subject only to the possible correction of a small number of minor errors. Stability in this sense is not in contradiction with the development of extensions or of a new version of the standard, provided that the new or extended version is designed so that it can be used in parallel with the old version.

(d) Complete implementation: There shall be at least two interoperable complete implementations, or one complete implementation of which the source code has been published.⁷

Note 7: If there is only one complete implementation (and it is not a formal reference implementation) then probably the program was not created by implementing the specification, but rather the specification was created as documentation for the program. In this case it is not ensured that the specification contains all the information that is needed for the independent creation of a compatible and interoperable implementation.

(e) Freedom of implementation: There shall be no restrictions⁸ which would prevent implementing⁹ the standard, under any model of software licensing, partially, fully, or with extensions. In particular, there must not be any requirement of royalty payments for any use of the standard, because that would contradict implementation in Free and Open Source Software (FOSS). Restrictions which discriminate against other models of software licensing are likewise unacceptable. If patent licenses are required for implementing the standard, or for deploying an implementation, these licenses may be subject to a reciprocity requirement, but must otherwise be freely available to all interested parties without discrimination and without requiring explicit agreement to a license agreement¹⁰.

Note 8: The situation regarding patents can be different in different countries, but in view of the highly globalized nature of the market for software and related services, Open Standards must be globally free from patent based restrictions.

Note 9: The freedom of implementation is required also for all data formats, protocols and cryptographic algorithms which are referenced in the normative text of the specification.

Note 10: Such licenses are typically phrased as promises of non-assertion of patents under a condition of reciprocity, see for example Sun's OpenDocument Patent Statement and Microsoft's Open Specification Promise.

(f) Openness of further development: It shall be ensured¹¹ that if further development¹² of the standard is necessary, this can be done by means of a process in which all market participants are free to participate without restriction. It shall be ensured that proposed changes are accepted only if they do not unfairly disadvantage any group of market participants.

Note 11: In this context ensuring means on one hand that there shall be clear rules of procedure which promise to all market participants the possibility of influencing changes to the specification, and that on the other hand in the actual work of the concerned committees these rules are followed in such a way that all aspects which are brought up are taken into consideration in an appropriate manner.

Note 12: This criterion concerns only the further development of a specification which has already been accepted as a standard. It does not matter how the specification was developed initially.

(g) Loss-less migration: If it is intended with the specification of a data format to replace¹³ a previous version, or another older standard, then the new specification shall define data formats that support representing all information¹⁴ that can be represented by the old data format. (The implementation of such features may be declared optional.)

Note 13: This refers to situations where the user needs which were addressed by the old standard are intended to be fully addressed by the new standard. This concerns for example the situation of a competing standard which is based on a different, possibly better, solution approach. Therefore, this criterion is weaker than the principle which is postulated (but not enforced) by ISO that competing standards for the same purpose should be avoided.

Note 14: If a standard defines too many features which are not needed for typical uses cases, the correct procedure is not to remove features from the standard, but rather to standardize profiles which constitute selections of features for particular categories of use cases.

Permission to copy and to quote this definition

Drafts and released versions of this definition are available under the Creative Commons Attribution-No Derivative Works 2.5 Switzerland License.