top of page

Open Standards

Open Standards facilitate interoperability and data exchange among different products or services and are intended for widespread
adoption.

Open standards can provide several benefits:

    • Application Independence: To ensure that access to resources is not dependent on a single application. 


    • Platform Independence: To ensure that access to resources is not restricted to particular hardware platforms. 


    • Long-term Access: To ensure that quality scholarly resources can be preserved and accessed over a long time frame. 


    • Architectural Integrity: To ensure that the architectural framework for IT developments is robust and can be further developed in        the future. 
 

Open standards principles are used by government around the world for example UK government to make services better for users and cheaper to run. 

How are standards developed?

​

Well, it's complicated. There are hundreds or perhaps thousands of standards organizations around the world, and many of them are part of multiple larger standards organizations. And there's no one guidebook to rule them all, which is why we end up with a spectrum of standards, such as open or closed, industry or vendor standards, and so on.

Open standards example: The Internet

​

In its explanation of open Internet standards, The Internet Society (a global organization that helps drive Internet policy and technology standards) says, "The Internet is fundamentally based on the existence of open, non-proprietary standards. They are key to allowing devices, services, and applications to work together across a wide and dispersed network of networks." The page lists The Internet Engineering Task Force (IETF), The Internet Research Task Force (IRTF), and The Internet Architecture Board (IAB) as the core groups behind the development of the open Internet standards. "These organizations are all open, transparent, and rely on a bottom-up consensus-building process to develop standards. They help make sure open standards have freely accessible specifications, are unencumbered, have open development and are continuously evolving,"

What makes a standard ‘open'?

​

Well, that's also complicated because different standards organizations and advocates offer different guidelines. Let's look at one open standards organization, OASIS, for an example.

Whereas ISO is an organization composed of many national standards bodies, OASIS is a nonprofit consortium that drives the development, convergence, and adoption of open standards for the global information society. Let's take a high-level look at the requirements OASIS has for developing open standards.

How do other open standards advocates define 'open standards'?

​

Bruce Perens, creator of The Open Source Definition, outlined six criteria an open standard must satisfy:

​

  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 into 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 otherwise prohibit extensions.

The Free Software Foundation Europe (FSFE) collaborated with other individuals and organizations in the tech industry, politics, and community to outline a different five-point definition. According to the FSFE, an open standard refers to a format or protocol that is:

​

  1. subject to full public assessment and use without constraints in a manner equally available to all parties;

  2. without any components or extensions that have dependencies on formats or protocols that do not meet the definition of an Open Standard themselves;

  3. free from legal or technical clauses that limit its utilisation by any party or in any business model;

  4. managed and further developed independently of any single vendor in a process open to the equal participation of competitors and third parties;

  5. available in multiple complete implementations by competing vendors, or as a complete implementation equally available to all parties.

The Open Source Initiative (OSI), the organization responsible for reviewing and approving licenses as Open Source Definition (OSD) conformant, says "an ‘open standard' must not prohibit conforming implementations in open source software." OSI provides a list of five criteria an open standard must satisfy. "If an ‘open standard' does not meet these criteria, it will be discriminating against open source developers," the site says:

​

  1. 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.

  2. 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.

  3. 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

  4. 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.

  5. No OSR-Incompatible Dependencies: Implementation of the standard must not require any other technology that fails to meet the criteria of this Requirement.

How do ‘standards collaborations' differ from ‘open source collaborations'?

​

Standards and open source projects are different collaborations. They're different economic tools in a marketplace with different goals, outcomes, and processes. As it explains:

​

  • Standards take longer to develop and change. Whereas open source projects can develop quickly, standards encourage multiple implementations and tend to enter a market with some maturity and competition. Standards and specifications don't change quickly, so they are developed with the expectation that they'll need to last for longer periods of time. For example, moving from HTML1.0 to HTML5 standard took about 18 years, and we've had TCP since 1981 with few changes.

​

  • Standards are consensus-based compromises. Open source projects are driven by contribution and meritocracy.

​

  • Standards define useful predictable boundaries. Well-run open source projects are the building blocks of rich, varied ecosystems.

bottom of page