Editor’s note: The full white paper is available in the PDF format. You can read the executive summary online or in the PDF format.
Executive Summary
People all around the world depend on the Internet to live their lives and do their jobs. Behind the surface of applications, online services depend on “interoperability”, the ability of software to work together. This is what allows you to, for instance, send a document from the Outlook account on your iPhone to a friend’s Gmail, then edit the document on a Samsung tablet before saving it in Alibaba cloud, and finally posting it on Twitter using an application like Hootsuite.
As the Internet has become more and more crucial to daily life and the economy, coupled with growing concerns about competition online, there has been increasing discussion about mandating interoperability among software services and systems. The technical interface required to achieve such an outcome is often implicit, and one of the main aims of this paper is to make it explicit and bring its implications into the open.
This mandating of open interfaces is important, because – done well – it brings economic, social, and technical benefits, reduces the risk of market failure and stimulates sustainable innovation. But done poorly, it can threaten these outcomes and jeopardize other policy goals, such as privacy, security, and the resilience of systems.
This report aims to inform the debate as policymakers develop legislation and regulation that fosters positive technological innovation.
Arguments for mandating open interfaces
The main motivations for mandating open interfaces are to enable data portability, service interoperability, and data access among services. They have all been promoted as potential solutions to the current concentration of market power among a small number of large technology companies.
A key feature of many online services is the network effect, where the value of a service increases as the number of users increases. It is a driving force behind this concentration of power, as it discourages users from switching to other services.
Consumers should be able to switch between service providers with little or no friction, but if switching is too costly, complex, or difficult, the market has little or no incentive to offer competitive choice and value. Legally requiring specific mechanisms for data portability – the ability for users to port their data from one service to another – is seen as an opportunity to ease the process of switching between providers, increasing consumer choice and making the market more competitive.
Service interoperability lets users communicate with users of a different service, for example, between WhatsApp and Signal. It would enable communications across networks of users and is seen as an opportunity to mitigate some of the adverse consequences of the network effect and reduce the negative impact of switching.
Those who advocate open data access believe that it will help mitigate current trends of market concentration. In particular, they have proposed policies including mandatory open interfaces (including access to data) to allow interoperability between direct competitors and to enable innovative uses of data by new companies entering the market.
Practical considerations
All of these outcomes – service interoperability, data access, and data portability – assume the existence of a technical interface. Here are the key practical considerations:
- Describing the intended outcome. Is it service mobility (the ability to switch between two service providers who apparently offer the same service); shared data and state (an interface where services can share their data and/or state so both can process the same information in a similar manner); or inter-service collaboration (enabling real-time collaboration between services)?
- Identifying the locus of control. This could be substitutability, when an end user is able to substitute one service for another with relative ease; interoperability, when two users with different software can independently share data, or use the same service, without needing to migrate to different software; or collaboration, when two users of interoperable software can work in real time on the same task at the same time productively.
- Developing the interface. What kind of model should relevant regulatory standards be based on? A requirements-led model is used by industries where high degrees of interoperability are essential to market formation and operation, such as in the mobile phone industry. An implementation-led model allows an early market entrant or market leader to innovate privately and bring a new product to market, while exposing some form of open interface which over time will be implemented with new capabilities.
One way to require openness without committing to either model is to specify that the interfaces must be implemented as open source – published with a license that lets others use, improve and share them, subject to the license terms. The rights needed to implement an open interface and the software that serves it must also be made available – especially when it comes to intellectual property rights.
- Ensuring controlled, reliable, and secure communications. Since the open interface provides a point of contact between software systems it is important, from the outset, to consider its ongoing operation and ensure that it can achieve its intended outcome. This includes use and access policies, and other operational aspects that could affect its secure and reliable use, and which may need to adapt to meet the changing needs of the interoperating parties. Poor choices in an open interface mandate could lead to large differences in the cost, risk, and even feasibility of compliance – resulting in solutions varying greatly for externally imperceptible reasons. In addition, operational considerations can be “weaponized” to artificially restrict competitors.
Policy considerations
- The impact on market dynamics. In principle, a mandated open interface should not competitively disadvantage any market players. But it remains unclear whether imposing interoperability would strengthen independent efforts to create new digital alternatives or, instead, lead to easier acquisitions by the larger players and, therefore, consolidate the market even further.
Commercial pressures and the overall administrative burden may also be unsustainable for smaller operators. Therefore, if the goal is to avoid excluding any market participants, a great degree of openness and inclusivity is essential throughout implementation.
- From Policy to Practice. Translating high-level public policy objectives into the practical implementation of a mandated interface requires careful thought about the development of new standards, their legal status, and the disclosure requirements of existing mechanisms. For example, should governments increase the regulators’ powers to impose mandatory open standards that promote competition, as proposed in the US, or take the EU’s approach based on the principle that standards are voluntary, but that conformance may be required for compliance with some EU legislation?
- Conflicting Objectives and Legal Clashes. Potential conflicts with other policy objectives and legal regimes are one of the more complex challenges for mandating open interfaces, particularly as many of the services in question operate globally across jurisdictions. Interoperability has created some of the most complex legal disputes around the intellectual property of software, including attempts to use software patents to control application programming interfaces (APIs).
Interoperability through APIs will enable new data flows, but policymakers may limit them to their own jurisdiction, often against proposals to facilitate global data flows that are being discussed at the World Trade Organization and included in many bilateral trade deals. Furthermore, some trade agreements include the forced use of technical standards as a localization barrier, which could affect mandatory interoperability measures.
- Safeguarding Security and Privacy. Creating an open interface entails important security and privacy considerations, which should be factored in when assessing the overall desirability of mandating open interfaces. Data transfers should be underpinned by robust agreements that specify usage of data and retention periods, among other limitations, and should clearly set out proper sharing agreements.
Mandatory open interfaces would increase the points of interconnection among technical systems, potentially increasing dependencies, as more downstream systems become increasingly reliant on upstream ones. Mandatory access could, in principle, have a positive impact on the reliance problem by limiting the risk of an upstream provider abusing its position, but the creation of a single point of failure could also threaten security and privacy.
In summary
The practical and policy considerations give rise to three main issues when planning a mandate:
- Feasibility: The requirements and expected outcomes of the mandate, including how it’s created, developed and controlled, and an assessment of potential legal conflicts within and across different territories and jurisdictions. Establishing the requirements and expected outcomes of the mandate should include an assessment of technical compatibility and potential legal conflicts within and across jurisdictions.
- Unintended outcomes: There will be opportunities for new innovations and services – but it’s just as important to consider any negative outcomes, such as potential market barriers and the consolidation of a dominant player’s position. Finding the appropriate scope of the mandate, and the necessary mechanisms for collaboration to address issues as they emerge, will be a strong factor in its success.
- Dependencies: What are the broader implications for the technical and economic ecosystem? Any mandate, whether to govern an existing interface or for creating a new one, must also be considered a building block for how other services operate. Just as the interface could unlock significant opportunities, it may also become a critical infrastructure component for the services involved.
