1. Unfolding interoperability

In simple terms, “[i]nteroperability is the ability of different systems to work together by exchanging information”.[2] Under the Digital Markets Act (DMA),[3] “‘interoperability’ means the ability to exchange information and mutually use the information which has been exchanged through interfaces or other solutions, so that all elements of hardware or software work with other hardware and software and with users in all the ways in which they are intended to function”.[4] Interoperability has always been one of the main behavioral remedies for restoring competition in the tech sector.[5]

There are two main types of interoperability. First, vertical interoperability refers to “the ability of services at different levels of the digital value chain to work together (e.g., different app stores being installed on the same operating system)”.[6] It ensures non-discrimination in accessing features of a company’s operating system or other services. Third party developers depend on and at the same time compete with large incumbents which provide the essential operating system and often products that are vertically integrated and in competition with those offered by the third parties.[7] Second, horizontal interoperability refers to “to the ability of products and services at the same level of the digital value chain to work together (e.g., different text message services)”.[8] Horizontal interoperability enables to share network effects and lower switching costs for end users and barriers to entry for other businesses.[9]

2. Benefits and challenges of interoperability

Interoperability may be beneficial as it can reduce users’ dependency on products and services belonging to the same ecosystem, lessening lock-in effects. It may also increase competition between two different ecosystems, because of more efficient switching possibilities.[10] Interoperability obligations may limit the ability of companies to suppress competition, but they do not limit their incentives to harm competition. Due to information asymmetries between enforcers and firms, the latter are generally more informed about their internal technological capability than the former.[11] As a further downside, interoperability obligations may disincentivize companies from engaging in research and development and future innovation. Interoperability may also raise security and privacy concerns as it requires sharing of information. Finally, especially in the U.S., one issue that has been considered is that interoperability instead of increasing product choices, may lead rivals to develop the same products offered by a dominant company under a different brand, with the risk of crowding out real competition.[12]

3. Enforcing interoperability in the EU system

At the EU level, interoperability obligations can be mandated as an ex ante remedy, through regulations such as the DMA, or as an ex post remedy by traditional competition law enforcement.

3.1 Interoperability as an ex ante remedy: the DMA applied

As an ex ante regime, the DMA applies before any harm to competition and consumers is caused, and designated gatekeepers are entrusted to ensure that their services comply with the regulation.[13] The DMA provides interoperability obligations for designated services. Article 7 DMA enshrines horizontal interoperability obligations that currently apply to WhatsApp and Messenger, requiring them to make their basic functionalities interoperable with other messaging apps. Article 6(7) DMA enshrines vertical interoperability obligations that currently apply to designated operating systems: Microsoft Windows, Google Android, Apple iOS and iPadOS. Third party developers should have access to the same operating system’s features that are available for gatekeepers’ services. Under both provisions, measures to respect users’ choice, security, integrity and privacy are laid down.[14]

Several tools and proceedings are available to the Commission to enforce the DMA. The Commission and gatekeepers meet in the so-called regulatory dialogue, and fines can be imposed at the end of non-compliance proceedings. Specification decisions can be adopted to identify mandatory measures that certain gatekeepers should adopt.[15] The Commission has recently issued two specification decisions on interoperability under Article 6(7) DMA for Apple iOS and iPadOS.[16] Article 6(7) DMA requires interoperability by design for new features that are released after the designation of a company as a gatekeeper. For existing features, Apple adopts a request-based approach, where third party developers that wish to interoperate with iOS should send their request to Apple. One of the specification decisions identifies a series of measures to ensure transparency of this process, vis-à-vis third party developers. The other specification decision concerns interoperability of connected devices, such as non-Apple smartwatches with iOS. Third party developers should have access to the same features available to Apple. These measures should be able to increase competition constraints on Apple and provide more choices for iPhone users to switch to a non-Apple phone and choose among different smartwatches’ providers.[17]

3.2 Interoperability as an ex post remedy: the Android Auto case

Interoperability can also be imposed as an ex post remedy by traditional competition enforcement law. Arguably, competition law is flexible enough to address any potential anticompetitive practices raised by interoperability. Theories of harm may include the Essential Facility Doctrine (EFD) and refusal to deal; margin squeeze; unfair terms and conditions etc. Problems arise when imposing interoperability remedies which involve a high level of technicality and antitrust authorities may be reluctant to assess technical product features and impose measures accordingly.[18]

In the Android Auto case,[19] the European Court of Justice (ECJ) mandated interoperability as an ex post obligation in antitrust. A third party app developer was refused access to Google Android Auto system, and the Italian competition authority that investigated the case found that such refusal may have not been objectively justified or driven by security issues, but, on the contrary, motivated by a self-preferencing goal. In fact, the competing app provides maps for recharging electrical vehicles which could be a direct rival of Google maps. The case was investigated under the EFD, and according to the ECJ, “where a dominant undertaking has developed infrastructure not solely for the needs of its own business but with a view to enabling third-party undertakings to use that infrastructure, the condition laid down [in Bronner[20]] relating to whether that infrastructure is indispensable for carrying on the business of the entity applying for access, in that there is no actual or potential substitute for that infrastructure, does not apply”.[21] Hence, the ECJ found that “the refusal, by an undertaking in a dominant position which has developed a digital platform, to ensure, at the request of a third party undertaking, that that platform is interoperable with an app developed by that third-party undertaking is capable of constituting an abuse of a dominant position even though that platform is not indispensable for the commercial operation of that app on a downstream market, but is such as to make that app more attractive to consumers, where that platform has not been developed by the undertaking in a dominant position solely for the needs of its own business.”[22]

In this case, the duty to deal means also a duty to accommodate third parties’ requests, and Google should deliver a specific template to enable the requesting party to interoperate with Android Auto. Arguably, this is a step further to the traditional framework of the EFD whose requirements have already been lowered by the Court over the years.[23]

In the aftermath of the Android Auto case, at the EU level, it will be easier for third parties to obtain access to a platform’s operating system and obligate to deliver technical solutions that ensure interoperability, as all platforms are, to a certain extent, open to third parties. Hence, compared to the DMA, and in the light of the recent developments of the EU jurisprudence, competition law has a broader scope. In fact, the DMA only applies to designated gatekeepers and specific core platforms’ services, while competition law can impose interoperability requirements to all dominant companies vis-à-vis third parties and for any services. However, the ECJ delivers general principles and ex ante regulations seem better suited than competition law to provide and design technical solutions that can ensure interoperability.[24] Furthermore, while the DMA mandates interoperability free of charges, competition law, as stated by the ECJ in Android Auto, requires “an appropriate financial contribution from the undertaking which requested interoperability”[25]. Even if such contribution can be defined in terms of being “fair and proportionate”[26] and even if it may rely on the FRAND conditions, litigation on compensation may arise, and this will lower the effectiveness of this ex post antitrust remedy.[27]

4. Enforcing interoperability in the U.S. system

In the U.S. system, interoperability is mostly mandating on a case-by-case basis by antitrust enforcement. Nevertheless, there are sector regulations such as in the telecommunication industry where interoperability is regulatory imposed.[28] As a general approach, since the Trinko case in 2004,[29] interoperability remedies are disfavored by U.S. judges. In fact, the Supreme Court adopted the term “forced sharing” to highlight the negative connotation of sharing obligations.[30] In the late 90s, the settlement decision in U.S. v. Microsoft[31] imposed interoperability requirements and a technical committee was set up to ensure compliance. A positive outcome from this case was that competition at the vertical level was enhanced, especially for web browsers. However, as a negative point, Microsoft slowed down the compliance procedure and when the 10-year period provided by the order expired, the tech giant did not comply with many of the requirements imposed. Arguably the process was not adequately supervised by the Court to prevent Microsoft from engaging in malicious compliance tactics.[32] Finally, in a later case, U.S. v. Google Search,[33] the DOJ is asking for some interoperability requirements in order to increase competition in the search engine market.[34]

5. Exceptions to interoperability obligations

Whether an ex ante or an ex post remedy, interoperability obliges companies to provide technical solutions for rivals’ products by allowing them to interoperate with their ecosystem and potentially compete with their own products and services. In both sides of the Atlantic, dominant undertakings may rely on few exceptions to refuse to interoperate. Firstly, a company may refuse interoperability if it would “compromise the integrity or security of the platform concerned”.[35] Secondly, privacy concerns may also be raised by a company to refuse access to its own operating systems. However, in both cases, it might be difficult to disentangle real privacy and security concerns from opportunistic strategies. Companies may in fact use privacy as a pretext to avoid interoperability obligations and as a shield against the real intent of harming competition.[36] Companies should prove that such refusal is necessary and that there are no other less restrictive alternatives that guarantee the attainment of the same results for users’ privacy or platform’s integrity.[37] Because of information asymmetries between enforcers and private companies, this is an extremely challenging task for enforcers and “an evidentiary issue for courts”.[38]