Holders of zero-tolerance positions on both sides of the divide need to realise that accommodating open source productively inside standards bodies is both viable and happening now.

You’ll recall that open source and open standards are orthogonal concepts where even the words they share (like “open”) are defined differently. That doesn’t mean they are mutually exclusive, nor that they are bad together – they can be cultivated well in the same garden. There is great value from accommodating the two orthogonal concepts so that neither is invalidated by non-mandatory elements of the other. When they combine, great value is unleashed.

Open source has been implementing open standards from day 1, and new standards have been arising from open source work for ages. We have to be cautious about conceptual “hybrids” of open source and open standards though; as there are some parameters of each open source and open standards that are incompatible with the other. The right starting point is understanding the orthogonality of both before modelling the fit of each into the other once the obstacles are understood and respected.

Ultimately software freedom is purely a function of the presence of the freedom to use, improve and share the eventual software. But what has made open source compelling to industry — and in most cases to the people at Standards Development Organisations (SDOs) wanting to accommodate open source — has been the most common route to producing software with those characteristics, which is a collaboration process that also leverages those freedoms. By granting permission in advance within strict boundaries, open source unlocks frictionless innovation.

Levels of Accommodation

So how can open source and open standards co-exist? We lack generally agreed good too bad patterns, not least because some voices prefer to continue to confuse open source and open standards. One approach, anchored in the open source concept of “software freedom” (the ex ante freedom to use, improve and share software without essential renegotiation of rights), considers at what point that freedom is exhausted; in the creation of the standard, or in the creation of its implementations.

Each of these “levels” is triggering for someone and for some reason:

1. A few companies still fear open source tooling, resisting any incursion of open source software into their company and thus rejecting as discriminatory the use of open source tools.
2. Some companies allege anti-trust concerns over collaborative methods that lack the formalism of familiar standards processes.

Both of these “inner source” inclusions are becoming largely uncontroversial; multiple SDOs now offer “open” venues within their processes that consume software freedoms and exhaust them in the delivery of a standard, where software freedom is exploited but not transmitted.

The “open source” inclusions definitely have more points for discussion:

3. Many SDOs have royalty free (RF) intellectual property (IP) modes already. In some, such as W3C, they are the default; in others, such as ECMA and OASIS, they are a member-selectable option either for a whole standard or for particular elements.
4. Full compliance with OSI’s Open Standards Requirement for Software (OSR) can prove controversial, despite merely explaining the obvious consequences of embracing a method that expects all necessary rights to be granted in advance of use. Ensuring selected deliverables are OSR-compliant seems within reach of any SDO, especially in a segmented work area.
5. The mere phrase “reference implementation” raises concerns about even sample code in some flavours of standards process. Inherent in their view of a standard is the expectation that it will be instantiated in multiple, completing, closed implementations. The very proposal of a shared implementation, let alone one that is considered normative, is thus anathemic. Yet shared implementation of some flavour is proving popular even at SDOs where the controversy rages.

Progress Through Compromise

Either way, in SDOs where patents are a dominant theme, which are the cases generating the most controversy in Europe because of 5G, accommodating the need for developers to collaborate freely and to generate work product that can be deployed freely remains a crucial important topic — not least since 5G has scope that encroaches into the domains of SDOs that have an implementation-led rather than a requirements-led approach. The path forward has to involve compromise that does not impact mandatory characteristics of either open source or open standards.

As the debate progresses, advocates of open source/free software need to recognise that a strong requirements-led SDO universe exists and must be accommodated. A dogmatic “no software patents anywhere” zero-tolerance policy will do nothing to advance the scope of software freedom. The attacks made on OASIS in 2005 when they added an RF IP mode were poorly-judged since this move unlocked most subsequent OASIS standardisation for open source implementation. Similar intolerance now would be a massive mistake.

Similarly patent-reliant companies in the sector need to drop their own no-compromise zero-tolerance approach. Claiming open source doesn’t mean what everyone outside their industry understands it to mean is not the path to compromise. Their attempts to try to paste the words “open” and “source” over false compromises that affect the very viability of open source and are not generally recognised as satisfying the term-of-art “open source” are at best unwelcome.

The solution — a viable compromise for both camps at the SDOs where the open source journey is still stalled — almost certainly starts with adding a suitably sand-boxed RF IP mode akin to the approach taken by OASIS since 2005 (and by others subsequently). Yes, there needs to be carefully consideration of the policies and processes, but with the existing approach of ECMA and OASIS to work from surely it’s time to stop stalling and start innovating with open source?