Some Thoughts on Interoperability

Interoperability enables diverse systems to communicate and collaborate seamlessly. Achieving true interoperability requires open standards—formalized, freely accessible specifications that prevent vendor lock-in and foster innovation and competition. However, not all standards marketed as “open” meet the stringent criteria necessary to ensure fairness and digital sovereignty.

This text explores the critical role of enforceable interoperability, a pragmatic approach that prioritizes measurable outcomes over rigid compliance. By focusing on EIFv1 (2005) as the gold standard for open standards, it highlights the risks of weakened definitions, such as those in EIFv2 (2010), and provides actionable recommendations for strengthening interoperability in complex ecosystems like cloud computing and telecommunications.

"Strict" Open Standards

An open standard, according to the strict definition of the European Interoperability Framework (‘EIFv1’, 2004), is a formalised and independent technical specification, allowing any player to access and implement it freely (without legal, operational or financial restrictions).

In 2012, the CNLL stressed that, to guarantee digital sovereignty and avoid supplier lock-ins, it is essential to base digital infrastructures on open standards in the strict sense (i.e. EIFv1-compliant), particularly for communication interfaces, data formats and protocols.

Source: https://joinup.ec.europa.eu/sites/default/files/custom-page/attachment/2021-11/EIF%20V1.0.pdf

Context:

In June 2002, European heads of state adopted the eEurope Action Plan 2005 at the Seville summit. It calls on the European Commission ‘to issue an agreed interoperability framework to support the delivery of pan-European eGovernment services to citizens and enterprises’. This framework would address information content and recommend tech- nical policies and specifications to help connect public administration information systems across the EU. The Action Plan also stipulated that the Framework would ‘be based on open standards and encourage the use of open source software’

The definition to remember:

The following are the minimal characteristics that a specification and its attendant documents must have in order to be considered an open standard:
- The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
- The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
- The intellectual property - i.e. patents possibly present - of (parts of) the standard is made irrevocably available on a royalty- free basis.
- There are no constraints on the re-use of the standard.

Criteria for an open standard according to EIFv1

The key criteria for an open standard, which the regulation of cloud services should systematically promote or impose, include :

1. Published and freely accessible specifications: All documentation related to the standard must be public, without financial or legal restrictions. This ensures that any player, whether an SME, a public authority or a private individual, can implement and use the standard.
2. Compatibility with competing implementations : An open standard does not favour any specific player and allows multiple implementations, including in open source software, to guarantee competition and diversity of offerings.
3. Technical neutrality and absence of blocking patents : No patent essential to the operation of the standard should restrict its use in any way whatsoever. Patents must be available under a royalty-free licence and not under a RAND (Reasonable And Non Discriminatory) or FRAND (Fair, Reasonable And Non Discriminatory) licence.
4. Independent and transparent governance : The development and maintenance of the standard must be overseen by an open organisation, where all stakeholders have equal influence.
5. Interoperability as the primary goal : The standard must be designed to maximise the ability of different systems and solutions, whether proprietary or open source, to interact with each other (NB: as we will see later in this text, this notion of purpose is akin to the notion of ‘enforceable interoperability’).

The EIFv2 trap

One word of caveat though: it is crucial to rely on EIFv1 (2005) as the reference framework for defining an open standard, and not on EIFv2 (2010), which has relaxed certain key requirements under the influence of non-European lobbies. The concessions made in the EIFv2, under the influence of American lobbies in Bruxelles, have reduced the effective scope of interoperability and technological neutrality, with a negative impact on digital sovereignty.

The shortcomings of the strictly prescriptive approach

The definition of an open standard in the LCEN (2004) remains insufficiently framed. It defines an open standard as ‘any interoperable communication, interconnection or exchange protocol and any interoperable data format whose technical specifications are public and without restrictions on access or implementation’.

This definition raises two major problems:

• It does not define ‘restrictions’ precisely, which opens the door to legal uncertainty.
• It does not explicitly impose a verifiable or enforceable obligation of interoperability.

It would therefore be useful to clarify this definition as follows:

‘An open standard is any communication, interconnection or exchange protocol and any data format whose technical specifications are public, accessible without implementation restrictions, and free of royalties or discriminatory commercial conditions, thus guaranteeing their free adoption. The open standard must include complete documentation enabling its implementation, as well as mechanisms ensuring and verifying its enforceable interoperability.’

Introducing: Enforceable interoperability

The idea of ‘enforceable interoperability’ introduced here is a strategic and pragmatic response to the complex problems associated with interoperability in ecosystems such as ERP, clouds and telecoms. This approach recognises the limitations of technical standards, notably their rigidity and their tendency to favour dominant players, while focusing on concrete ways of ensuring real, adaptable and verifiable interoperability.

Analysis of the situation

Standards vs. reality

• Imposition of standards : The forced adoption of certain complex standards can favour dominant players who have the resources to implement them quickly and efficiently, or who impose their own pre-existing implementation as the ‘standard’, while it penalises smaller players, who may prove unable to bear the associated compliance or development costs. A balance therefore needs to be struck between the need for a clear standards framework to guarantee interoperability and the preservation of a competitive and inclusive ecosystem, where standards must remain accessible, scalable and proportionate to the capabilities of the various players. One solution is to favour flexible approaches such as enforceable interoperability, which imposes measurable results without forcing a single technological implementation, while promoting technical neutrality and freedom of innovation.
• Apparent compliance with standards: The major suppliers have the means to ‘pretend’, by creating partial implementations that are deliberately not interoperable, or by introducing proprietary dependencies into their solutions.
• Diversity of open standards: In order to stimulate innovation and small players, the diversity of open standards should be protected rather than prevented, provided they meet enforceable interoperability requirements.

Bugs and interoperability

Gaps between the theoretical specifications of standards and their practical implementation often arise from bugs, which may be due to unintentional errors or, in some cases, to deliberate strategies to limit interoperability (cf. for example the AARD code, inserted by Microsoft in a beta version of Windows 3. 1 to detect and cause a cryptic error on DR-DOS, in order to discourage the use of this competing system, triggering a controversy documented by internal memos, a lawsuit and a settlement of 280 million dollars: https://en.wikipedia.org/wiki/AARD_code). Differences in the interpretation of technical specifications also contribute to compatibility problems.

These problems are exacerbated by the absence of effective mechanisms to compel suppliers to correct their faulty implementations. End-users or small players often have no means of redress to assert their right to effective interoperability.

A clear and enforceable definition of interoperability, combined with practical validation mechanisms (interoperability tests, certification), is essential to avoid vendor lock-in practices and guarantee the portability of services, data and applications.

Enforceable interoperability: a pragmatic approach

The central idea behind ‘enforceable interoperability’ is to enable any stakeholder, whatever its size, to ‘compel a supplier to comply with interoperability principles’. This is based on :

Clear definition of expectations

Rather than imposing precise technical standards, this involves defining measurable results. Example: a customer must be able to export and re-use its data in an open format that can be read by third-party tools.

Verification and recourse mechanisms

Suppliers must be held accountable for their implementations, with mechanisms to:
- Verify that their services comply with defined principles.
- Require corrections in the event of non-compliance.
- Impose dissuasive penalties for deliberate or repeated non-compliance.

Compatible implementation environment

Provide a framework where players (large or small) can test and validate interoperability. Example: a freely usable test suite and/or a reference implementation.

Technological neutrality

The concept of ‘opposable interoperability’ leaves the door open to various technological solutions, while imposing concrete results.

Example of application in the cloud

In the context of the cloud, opposable interoperability could include :
- Data interoperability : Obligation to provide open APIs enabling data to be exported without proprietary dependencies.
- Service portability : Ability for a user to move a workload or application from one provider to another without major modification.
- API interoperability : Clear documentation and automated tests to check that APIs work as advertised.
- Dispute Resolution: A third-party organisation or legal framework to arbitrate technical disputes.

Protecting small players

Enforceable interoperability, with its emphasis on rights and redress mechanisms, gives small players the tools to:
- Enforce their rights in the face of giants who are often reluctant to comply with standards or correct bugs.
- Develop innovative solutions without coming up against artificially high technical barriers.

Enforceable interoperability is an approach that refocuses the debate on practical effectiveness, avoiding the trap of rigid or imposed standardisation. It would make it possible to maintain an open and innovative ecosystem, while giving players - large and small - concrete means of guaranteeing the compatibility and portability of their solutions. By adopting this concept, we could meet the current challenges of the cloud, ERP and beyond, while protecting diversity and fairness in digital markets.

Recommendations

1. Base all normative approaches on open standards : It is imperative that interoperability and portability be based on open standards in the strict sense (EIFv1) , excluding any technological or legal dependency.
2. Incorporate EIFv1 as a reference framework : Refer to the EIFv1 (or any other document that adopts its principles) to clearly define what an open standard is and guarantee its application in the European digital ecosystem.
3. Adopt an enforceable legal framework for interoperability : Impose obligations for testing, full documentation and verifiable implementation to guarantee the effective interoperability of cloud services.
4. Encourage the active participation of European players : National and European bodies must play a key role in defining and maintaining these standards, to ensure that they meet local needs and do not favour the interests of non-European suppliers and align with European values. National bodies must guard against the influence of non-European players.
5. Promote education on open standards : Raise awareness, particularly among SMEs, of the importance of open standards and their role in digital sovereignty.

References

• Bradner, S. (1999). The Internet Engineering Task Force. In Open Sources: Voices from the Open Source Revolution. O'Reilly Media. ISBN 1-56592-582-3. Retrieved from https://www.oreilly.com/openbook/opensources/book/ietf.html

• Cox, B. (2024, December 5). The "simple" 38 step journey to getting an RFC. Benjojo's Blog. https://blog.benjojo.co.uk/post/rfc-in-38-simple-steps

• Lundell, B., Gamalielsson, J. and Katz, A. (2019) Implementing IT Standards in Software: challenges and recommendations for organisations planning software development covering IT standards, European Journal of Law and Technology, Vol. 10(2). https://ejlt.org/index.php/ejlt/article/view/709/

• Lundell, B., Gamalielsson, J. and Katz, A. (2023) Implementing the HEVC standard in software: Challenges and Recommendations for organisations planning development and deployment of software, Journal of Standardisation, Vol. 2. https://doi.org/10.18757/jos.2022.6695

• Lundell, B., Gamalielsson, J. and Katz, A. (2015) On implementation of Open Standards in software: To what extent can ISO standards be implemented in open source software? International Journal of Standardization Research, Vol. 13(1), pp. 47-73. http://doi.org/10.4018/IJSR.2015010103

Annex: Case Study - The IETF

The Synergy of Open Standards, Open Documentation, and Open Source

According to (Bradner, 1999) The IETF (Internet Engineering Task Force) has long been celebrated as a pioneer of open standards and a beacon of transparency in standards development. By ensuring that all documents, mailing lists, and meetings are freely accessible, the IETF has created an environment that fosters participation from a broad range of contributors, including small innovators and independent developers. This openness helps produce standards that are adaptable, widely implementable, and beneficial to diverse user and vendor communities. In contrast, restricted access in other standards organizations often results in overly complex protocols, limited engagement, and barriers to innovation, particularly for smaller players.

This ethos of openness is further reinforced by the IETF’s historic support for Open Source development. In earlier years, the IETF often encouraged "reference implementations" of its standards, creating accessible models that bridged the gap between theoretical specifications and practical applications. Although this practice has waned with the increasing complexity of modern standards, it exemplifies the intrinsic partnership between open standards, open documentation, and Open Source development. This synergy has driven some of the Internet’s most transformative advancements, underscoring the importance of maintaining transparency and accessibility in the standards development process.

Challenges for Small Innovators: The Reality of the IETF Process

Despite its strengths, the IETF process can present significant challenges for small innovators, as witnessed by (Cox, 2024). These difficulties do not undermine the organization’s achievements but rather highlight areas where further refinement could enhance inclusivity and efficiency.

The IETF’s standards development process, while open, is often long and complex. For instance, the journey to develop RFC9687 spanned three and a half years, requiring the authors to navigate a convoluted series of steps, including drafting, working group discussions, revisions, and final approvals. For small innovators with limited resources, sustaining such a commitment can be daunting. While the process ensures rigorous scrutiny, its time-intensive nature can act as a deterrent for individuals or organizations seeking faster pathways to standardization.

The technical demands of the IETF process also create a steep learning curve. Drafting an Internet-Draft (I-D) involves using specialized tools like xml2rfc and adhering to strict formatting and linguistic standards. These requirements can alienate newcomers, particularly those without prior exposure to the IETF’s methodologies or without support teams to navigate the technical intricacies. Even seasoned contributors sometimes struggle with the dense and precise language of IETF documents, which can obscure fundamental concepts and hinder broader comprehension.

Participation in the IETF often depends on established networks and collaborative relationships. Successful drafts typically require co-authors and engagement with working groups, which are divided into specialized areas of focus. This reliance on pre-existing relationships and networking opportunities can create barriers for independent contributors or those without connections within the IETF community. Although virtual attendance at meetings is free, in-person events remain a cornerstone of networking and informal collaboration. The high costs of attending these events—coupled with travel expenses—can exclude hobbyists, startups, and small organizations from fully participating.

The IETF’s consensus-driven model, while fostering collaborative decision-making, imposes additional challenges. Building consensus often requires extensive email exchanges and active engagement with working groups, which can overwhelm small teams or solo contributors. Moreover, the expectation that contributors provide a working implementation of their proposals adds another layer of complexity, requiring resources that smaller players may not possess.

Finally, the output of the IETF process—RFCs—often prioritizes technical precision over accessibility. While this ensures robust standards, the resulting documents can be difficult to interpret and implement, particularly for developers or innovators without prior experience with IETF protocols. This opacity, combined with the complexity of the language used in RFCs, can discourage smaller players from engaging with the standards or using them effectively.

Toward Enforceable Interoperability

The IETF’s commitment to openness is a cornerstone of its success, but the challenges faced by small innovators underscore the need for a more pragmatic approach to interoperability. The concept of enforceable interoperability offers a potential solution, shifting the focus from theoretical compliance to practical implementation. By emphasizing measurable outcomes—such as ensuring that standards are not only open on paper but also usable in diverse real-world contexts—enforceable interoperability can address many of the barriers highlighted in the IETF process.

Streamlining workflows, providing accessible tools and training, and lowering the financial barriers to participation could further enhance the IETF’s inclusivity. Reviving the practice of producing Open Source reference implementations could also bridge the gap between theory and practice, offering concrete examples that empower smaller innovators to engage more effectively with standards.

The IETF’s transparency and dedication to open standards have played a critical role in shaping the Internet as we know it. By addressing these areas for improvement, the organization could strengthen its support for small innovators, ensuring that its processes remain not just open but also equitable and accessible. This would solidify the IETF’s legacy as a driving force for truly enforceable interoperability, fostering a digital ecosystem that is innovative, inclusive, and resilient.