OSI Supports Open Standards
The Open Source Initiative agreed what made a standard open back in 2006 and today collaborated with the Free Software Foundation on a press statement about it.
Published 15:11, 25 April 12
Back in 2006, a detailed discussion at the Open Source Initiative - where I am today a director - led to the creation of a statement about what makes a standard open, and a set of criteria for determining if the requirement was met and a standard compliant. Both are very simple as well as fully explained.
To save you the click-through, here's the OSI Open Standards Requirement and Criteria in full:
The RequirementAn "open standard" must not prohibit conforming implementations in open source software.
The CriteriaTo comply with the Open Standards Requirement, an "open standard" must satisfy the following criteria. If an "open standard" does not meet these criteria, it will be discriminating against open source developers.
- No Intentional Secrets: The standard MUST NOT withhold any detail necessary for interoperable implementation. As flaws are inevitable, the standard MUST define a process for fixing flaws identified during implementation and interoperability testing and to incorporate said changes into a revised version or superseding version of the standard to be released under terms that do not violate the OSR.
- Availability: The standard MUST be freely and publicly available (e.g., from a stable web site) under royalty-free terms at reasonable and non-discriminatory cost.
- Patents: All patents essential to implementation of the standard MUST:
- be licensed under royalty-free terms for unrestricted use, or
- be covered by a promise of non-assertion when practiced by open source software
- No Agreements: 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.
- No OSR-Incompatible Dependencies: Implementation of the standard MUST NOT require any other technology that fails to meet the criteria of this Requirement.
Nearly a decade after that original discussion at OSI - which itself was in the context of fairly established thinking - the UK Government seems to think this is still an open, undecided question. Why is that? It appears to be because industry bodies with a deep interest in protecting their existing, proprietary interests in the UK Government have lobbied that Government to re-open the issue. Moreover, during a change of leadership the responsible individuals in the Government decided to give those incumbents a second chance in a consultation (which still needs your input, by the way).
Why do they want that second chance? It's not as Stephen Walli suggests because there is a historic case for (F)RAND terms in standards. While that argument can be made in some markets, it can't in software. No; they want it because they understand the threat from open source solutions to their incumbent control of Government ICT and want to keep them out. They know that the standards mandate - once a way of controlling suppliers - has metastasised into a way for supplier to control customers if restrictions on implementation are allowed.
Certain variants of (F)RAND terms - the ones that include a need for an implementor to have a relationship with the patent holder before use of the standard - are toxic to open source communities. An (F)RAND policy allows patent holders to decide whether they want to discourage the use of open source. Leaving that capability in the hands of some (usually well-resourced) suppliers seems unwise.
That's why the OSI today supported a press release from a broad group of entities which protect digital rights in the UK. It's not just in the media sector that the relationships with government seem just too cosy. The definition of open software standards is essentially settled; stop letting vested interests tell you otherwise.