Open Standards and Implementability: The Two Definitions That Do Not Match

“Open standard” is used as an endorsement and defended as a definition. The two uses rarely coincide. A body that publishes its specifications freely and admits any member calls its output open; a procurement rule that requires open standards means something narrower and more testable; a vendor that supports a standard it participated in drafting uses the word to mean legitimate. Each claim is defensible on its own terms and none of them implies the others.

An implementer deciding whether a given specification is safe to build on needs properties, not adjectives. The useful approach is to decompose the claim into conditions that can be checked against documents.

The five conditions that get bundled

Most formal definitions in the policy literature converge on a cluster of conditions, and it is worth separating them because a specification can satisfy some and fail others.

Availability: the specification is published and can be read by anyone, without a fee or a membership agreement, and remains available after the body loses interest. This is the cheapest condition to meet, and the most often mistaken for the whole of openness.

Developmental openness: participation in drafting is open to all interested parties, on non-discriminatory terms, with decisions taken by consensus among participants. This condition is about the process, not the artefact, and it is the one that cannot be verified by reading the published document.

Rights: any party may implement the specification, including for commercial purposes, without paying royalties, and the patent commitments support that. This is the condition with the largest commercial weight and the least transparent evidence, as the analysis of patent commitments sets out.

Completeness: the specification is detailed enough that independent implementations can be built from it, with no undisclosed element required for interoperability. This condition is technical rather than procedural, and it is the one most quietly violated by mature specifications that rely on a reference implementation for the parts the text left open.

Maintenance: the specification has a process for revision that any implementer may participate in, and does not depend on a single vendor’s continued goodwill.

No standards body claims all five without qualification, and the disagreements between organizations are usually about which of the five is being asserted. A specification that scores highly on availability and developmental openness may be encumbered by royalties, and a royalty-free specification may be maintained by one firm with no external review.

Where the definitions collide

The European Interoperability Framework, published in its 2010 form, defined an open specification with an explicit list of conditions, including that the specification be adopted and maintained by a non-profit organization and that its development occur through an open decision-making procedure available to all interested parties. The definition was written for public-sector procurement, where the question is whether a government can commit to a technology without becoming dependent on one supplier.

A consortium’s own definition typically emphasizes membership: the specification is open if any organization may join the working group and any implementer may obtain the text. These two definitions diverge on the case that matters most, which is a specification published freely by a body whose membership is restricted and whose patent policy permits royalty-bearing licences.

The World Trade Organization’s Technical Barriers to Trade Agreement takes a third approach. It does not define open standards at all; it requires that technical regulations be based on relevant international standards, and it defines “international standard” in terms of a recognized body whose membership is open to the relevant bodies of at least all members of the WTO. The test is membership openness at the body level, not royalty status. A specification from a body meeting that test can require royalties and still serve as a TBT reference, which is why disputes over the agreement turn on whether a given forum’s membership is genuinely open rather than on licensing.

Three definitions, three different answers to the same question, and each is authoritative in its own jurisdiction.

What implementability adds that openness does not

Completeness is the condition that matters to a working programmer and the one least often tested by openness claims, because it is not a property of the process at all. A specification can be produced by a fully open process, published without fee, and still be unimplementable in the sense that matters: no two parties can build conforming products from it that interoperate.

Two mechanisms produce this result. The first is delegation to a normative reference that is itself restricted, so the open document is open only if the document it incorporates by reference is equally available. Specifications that cite a proprietary document by name are open at the surface and closed at the layer that determines behaviour.

The second is the use of implementation-defined behaviour at points where interoperability requires agreement. A specification that leaves the encoding of an optional field to the implementation is open in every procedural sense and still fails the completeness condition, because two implementations can both conform and still fail to exchange data.

The practical check for completeness is the one described in the account of reference implementations and conformance laboratories: whether a second implementation can be built from the text alone, and whether the two agree. No policy document substitutes for that exercise.

References that are normative but not free

A specification can be free while requiring, by normative reference, a document that is not. The pattern is most familiar from character encoding and from interface definition: a base document describes the mechanism in full but incorporates a table or a set of definitions defined elsewhere, under terms the reader must accept separately.

The implementability consequence is that the profile of a free specification can be closed to implementers who cannot obtain the reference. Whether that constitutes a practical barrier depends on who needs to read the reference: an implementer who can copy a table from a peer’s code does not need the document, whereas an implementer validating conformance does. Bodies increasingly respond by requiring that normative references to specifications be publicly available for the specification to be considered fully open, which converts a licensing question into a drafting rule.

Development openness runs into a related problem when the drafting body accepts only paying members. A specification produced that way can satisfy every availability condition and still fail the participation condition, and there is no way for an outside party to establish whether an objection was heard. The only artefacts an outsider can inspect are the published document, the change log, and the disposition of comments where the body publishes one. That makes the comment disposition record — a document most bodies treat as procedural paperwork — the single most informative indicator of whether the developmental claim is true.

Royalty-free versus FRAND as an openness test

Procurement rules that demand open standards usually mean royalty-free, and the reason is arithmetic rather than ideological. A royalty-bearing standard forces every implementer to negotiate, and negotiation costs more than small products can absorb regardless of the rate. A royalty of a fraction of a percent on a large volume is a manageable line item; the same rate on a small product with a long negotiation cycle is a barrier.

Bodies respond by offering both: a mandatory core with royalty-free commitments and optional extensions where royalties are permitted. The extension structure is therefore not purely technical, and an implementer choosing to support an optional extension is choosing to enter a licensing negotiation. The design consequence, noted in the discussion of patent pools, is that pushing functionality into optional clauses does not remove the encumbrance, it relocates it.

Reading an openness claim as a checklist

Given a specification and a claim that it is open, four questions produce a usable answer.

Is the current text, including errata, available without a fee and without accepting a membership agreement? Is there a published list of essential claims, and does every listed holder offer a royalty-free licence for the parts an implementation needs? Is every normative reference equally available, or does the commitment to openness stop at the first citation? And is the revision process open to parties who are not members, including the right to object?

None of those questions addresses behaviour above the encoding, which is where two conforming products most often fail to work together. The analysis of interoperability gaps treats those layers separately, because a specification can be open in every procedural sense and still leave the exchange underdetermined.

The answers are checkable, and they separate a claim into components. A specification that passes three of four is not a failure; it is a specification whose remaining condition determines who can afford to implement it. That is a more useful thing to know than a verdict about whether it is open, because the answer to that depends entirely on which of the definitions the questioner is using.