Content uploaded by Begoña Gonzalez Otero
Author content
All content in this area was uploaded by Begoña Gonzalez Otero on Nov 01, 2020
Content may be subject to copyright.
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
Jörg Hoffmann and Begoña Glez. Otero
Demystifying the role of data interoperability in the access
and sharing debate
Max Planck Institute for Innovation and Competition Research Paper Series
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
1
Demystifying the role of data interoperability in the access
and sharing debate
Jörg Hoffmann* and Begoña Glez. Otero**
Abstract: In the current data access and sharing debate, data
interoperability is widely proclaimed as being key for efficiently
reaping the economic welfare enhancing effects of further data re-use.
Although we agree, the role data interoperability plays for data access
cannot be straightforwardly answered. First, data interoperability, as
a technical mechanism, is an inherent part of some regulated data
access rights. In these particular cases, data interoperability is the key
enabler for efficient (re-)use of data. This example shows the relevance
of addressing data interoperability within the corresponding obligation
of the access right. It also reveals that interoperability becomes key
from a market failure perspective if the failure stems from a lack of
efficient data use or potential lock-ins. Another example where data
interoperability goes hand in hand with data access regimes are digital
platforms. However, digital markets have a tendency to “tipping”. Such
a tendency is not natural but induced by individual practices, e.g. the
obstruction to interoperability. To this end, subjecting dominant online
platform companies to additional interoperability obligations and
stricter monitoring could be an effective approach to control the abuse
of market power. Likewise, the current EC’s ambition to pave the way
towards European digital sovereignty highly depends on the design of
a data interoperability policy within the context of access to and re-use
of data. With this background in mind, our contribution answers the
question of when and how data interoperability, as a precondition to
data quality, should be addressed by the legislature. The paper brings
together the technical, legal and economic aspects of data
interoperability, conceptualizing it within the data sharing debate. It
first elaborates on the notion of interoperability in the current data
access and data governance frameworks. An analysis of the different
technical interoperability facilitators and the existent legal framework
that may hinder data interoperability in this context follows. The debate
of APIs is still ongoing and brings on fundamental questions to the
proper functioning of exclusive rights. To which extent do IPRs and
trade secret protection may encumber data interoperability? What
would be the implications of granting IPR or trade secret protection for
APIs, both in terms of raising incentives for their provision and with
regard to effects on competition? The paper continues by considering
the pros and cons of a more normative approach toward data
interoperability. Data interoperability should be treated only as a
means to an end and not as an end in itself. It should be taken as a part
of the broader data sharing and access discussion, reflecting on the
positive and adverse effects alike. To this end, a public law approach
within the realm of a data governance solution seems more favourable.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
2
Such governance solution could also entail a more consistent solution
to conflicting IP, database sui generis and trade secrets protection in
data, which is currently not thoroughly and clearly assessed either.
These conflicts need a more holistic assessment of overlapping
exclusive rights and their re-usability options.
Acknowledgements: This paper builds upon work carried out at the
‘IoT Data Interoperability’ Workshop, organized by the Max Planck
Institute for Innovation and Competition in October 2018. The authors
are grateful to Beatriz Conde Gallego (MPI Munich), Simonetta
Vezzoso (University of Trento), Ian Brown (visiting CyberBRICS
professor at FGV Law School), Marcus Irmscher (Rahi Systems
Engineer) and Bertin Martens (JRC of EC) for valuable comments on
an earlier version of this article.
*, ** Max Planck Institute for Innovation and Competition, Munich. E-
mail: joerg.hoffmann@ip.mpg.de; begonia.otero@ip.mpg.de
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
3
Content:
A. Introduction 4
B. Clarifying terms: Interoperability and its enablers, data
standardization and APIs 7
B.I. Looking for a definition of interoperability 7
B.II. Conceptual frameworks 11
B.III. Enablers of data interoperability 13
C. The role of data interoperability in data related market failures
17
D. APIs: IP and Competition Law considerations 22
E. Fostering re-usability of data with a normative interoperability
approach 31
F. Conclusions 36
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
4
A. Introduction
In the ongoing debate about how to achieve the full realisation of the
data economy, a lack of data interoperability has been rightly identified
as a main impediment. Couple of years ago, the International Data
Corporation’s report distinguished three main paths followed to solve
the lack of data interoperability1: First, firms and public bodies
increasingly opening up their data via Application Programming
Interfaces (APIs) granting access to third parties. Second, specific
industry data standards and more high-level architecture standards have
been developed to make data easily accessible and transferable. Third,
a new category of firms has emerged, which focus on data
transformation and provide services directly to final users.
Additionally, future data marketplaces could also act as data
normalizers and define standard data models and formats for all the
traded data.
From a regulatory perspective, there are different strategies and
options to enhance data access, sharing and re-use across society.2 In
the case of regulated data access regimes, what we have noticed is that
only thinking about the access right itself is not enough. Data
interoperability, as a technical mechanism, is an inherent part of some
data access rights.
In such cases, data interoperability is the key enabler for efficient
(re-)use of data. Thus, it is important to address data interoperability
within the corresponding obligation of the access right. Interoperability
becomes key from a market failure perspective if the failure stems from
a lack of efficient data use or potential lock-ins.
A clear example where data interoperability goes hand in hand
with data access regimes are digital platforms. The use of data is now
the world’s biggest business. Some $1.4trn of the combined $1.9trn
market value of Alphabet and Facebook comes from users’ data and the
firms’ mining of it, after stripping out the value of their cash, physical
and intangible assets, and accumulated research and development. 3
Digital platforms provide a basis for delivering or aggregating services
and content from service and content providers to end users. These
1 IDC, “Technical Barriers to Data Sharing in Europe” (January 2017)
<https://view.publitas.com/open-evidence/d3-12-technicalbarriers_06-01-2017-
1/page/1> (accessed 13.09.20).
2 OECD “Enhancing Access to and Sharing of Data: Reconciling Risks and Benefits
for Data Re-use across Societies” OECD Publishing, (Paris, 2019)
<https://doi.org/10.1787/276aaca8-en> (accessed 13.09.2020).
3 Cf. Viktor Mayer-Schönberger has noted that access to capital is no longer the
biggest problem for startups. It is access to data. See The Economist, “Who owns
the web’s data?” (October 22, 2020)
<https://www.economist.com/business/2020/10/22/who-owns-the-webs-data>
(accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
5
basic operating principles are found in platforms in a variety of sectors
and they are reflected in other definitions of digital (or online)
platforms, such as that proposed earlier by the European Commission.4
Digital platforms are key enablers of digital trade.5 They facilitate
access to information; they also reduce the traditional friction of
matching supply and demand. As such, digital platforms may serve as
a driver for innovation. However, several governmental and academic
studies6 have found violations of antitrust7, consumer protection and
privacy law. These are motivated by certain characteristics of digital
platforms, namely, network externalities, economies of scope and their
inherent advantages as to access to data. Some giant platforms have
occupied a gatekeeper position allowing them to decide on
economically dependent ecosystem partners, to determine the
conditions for access and to control the consumer interface. Information
asymmetries take place, not only between big tech platforms and small
businesses and consumers, but also between big tech platforms and
governments. High concentration of market power throughout many
different markets together with certain acquisitions of startups and the
potential to leverage data specific competitive advantages is likely to
lead to market foreclosure effects ultimately causing both static and
dynamic inefficiencies. In order to reduce the potential leveraging of
data power, it is currently discussed to impose data sharing obligations
for platforms. To this end, a good example of how to address the
interoperability provision would be the imposition of ex ante rules of
4 European Commission, “Public Consultation on the Regulatory Environment for
Platforms, Online Intermediaries, Data and Cloud Computing and the Collaborative
Economy” (2015) <https://ec.europa.eu/digital-single-market/en/news/public-
consultation-regulatory-environmentplatforms-online-intermediaries-data-and-
cloud> (accessed 13.09.2020).
5 Digital trade is a broad concept, capturing not just the sale of consumer products on
the Internet and the supply of online services, but also data flows that enable global
value chains, services that enable smart manufacturing, and myriad other platforms
and applications. USTR, Key Barriers to Digital Trade (2017) <https://ustr.gov/about-
us/policy-offices/press-office/fact-sheets/2017/march/key-
barriers-digital-trade#:~:text=Digital%20trade%20is%20a%20broad,myriad%20oth
er%20platforms%20and%20applications> (accessed 13.09.2020).
6 Among other Jacques Crémer, Yves-Alexandre de Montjoye, Heike Schweitzer,
“Competition Policy for the Digital Era” (2019)
<http://ec.europa.eu/competition/publications/reports/kd0419345enn.pdf>; (accessed
13.09.2020); Stigler Committee on Digital Platforms. Final report (2019); Australian
Competition and Consumer Commission, “Digital platforms inquiry - final report
(parts 1–3)” (July 2019); Philip Marsden, Rupprecht Podzsum, “Restoring Balance to
Digital Competition – Sensible Rules, Effective Enforcement” Konrad Adenauer
Stiftung e. V. (2020), Jason Furman, Diane Coyle, Amelia. Fletcher, Philip Marsden
and Derek McAule, “Unlocking Digital Competition” (London: HM Treasury, 2019).
7 Past October 20, 2020, the DOJ filed a civil antitrust lawsuit in U.S. District Court
for the District of Columbia to stop Google from unlawfully maintaining monopolies
through anticompetitive and exclusionary practices in the search and search
advertising markets and to remedy the competitive harms.
<https://www.justice.gov/opa/pr/justice-department-sues-monopolist-google-
violating-antitrust-laws> (accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
6
conduct for dominant platforms with more stringent interoperability
obligations as a potential remedy against the data induced power
asymmetries. Subjecting dominant online platform companies to
additional interoperability obligations and stricter monitoring could be
an effective approach to control the abuse of market power.
Similarly, the current EC’s ambition to pave the way towards
European digital sovereignty highly depends on the design of a data
interoperability policy within the context of access to and re-use of data.
Such design needs to reconcile the interests of all parties implied and
must reflect on the positive and adverse effects of data sharing. The
accomplishment of high levels of trust among the participating parties
is a key aspect of further incentivizing data sharing. Data trusts and
hybrid federated infrastructural models such as Gaia-X8, intended to
build European Data Spaces will very much depend on a proportionate
and clear legal framework for data interoperability.
Technically, data interoperability depends on certain facilitators,
namely data standardization and APIs. This paper explores data
standardization as a technological enabler of data interoperability
considering both positive and negative effects.9 Yet, the debate about
APIs is still ongoing and brings on fundamental questions to the proper
functioning of exclusive rights. To which extent do IPRs and trade
secret protection may encumber data interoperability? What would be
the implications of granting IPR or trade secret protection for APIs,
both in terms of raising incentives for their provision and with regard
to effects on competition? To this end, there are three key aspects that
need to be considered: First, whether APIs, as part of a computer
program, can enjoy the same copyright protection; second, what
happens if a third party uses the underlying right when establishing data
interoperability, and, third, to what extent the user of an API can rely
on current exceptions and limitations.
Furthermore, standardization of APIs, working as plug-and-play
gateways, could provide better levels of data interoperability but might
as well bring new challenges for competition law as it may expose the
party seeking access to potentially share ‘their’ data in return. Opening
up APIs by providing plug-and-play solutions may thus contain the risk
of inappropriately reinvigorating data-induced market dominance,
potentially causing further market foreclosure scenarios.10 Analysing
how firms use APIs for data transfers and what happens when sensitive
data is exposed or the API is hacked are important within the data
8 Gaia-X: A Federated Data Infrastructure for Europe, <https://www.data-
infrastructure.eu/GAIAX/Navigation/EN/Home/home.html> (accessed 13.09.20).
9 For a detail study on data standardization, Michal Gal, Daniel Rubinfeld “Data
Standardization” NYU Law Review (2019) 738-769.
10 On adverse effects of extensive data sharing see e.g. Jörg Hoffmann, Safeguarding
Innovation through Data Governance Regulation: The case of Digital Payment
Services (2020) 21-25 with further references.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
7
sharing debate, but would involve further considerations on data
protection law, cybersecurity, liability and cross border enforcement
that are out of the scope of this paper.
Our original intention was to assess data interoperability in all
regulatory interventions of the EU legislature, which have generated
either data governance obligations or data access rights for private
actors.11 However, while we were diving in this endeavour, we realized
we needed to take a prior step. That is, to conceptualize data
interoperability within the data sharing framework. As a result, this first
paper answers the question of when and how data interoperability12, as
a precondition to data quality, should be addressed by the legislature
and whether amendments in the respective IP and trade secret regimes
are necessary.
Our conceptualization consists of the following: (1)
understanding the notion of interoperability in the current data access
and data governance frameworks (2) comprehending the different
technical interoperability solutions and (3) assessing the existent legal
framework pertaining IP rights and trade secrets that may hinder data
interoperability in this context.
The paper continues with an analysis of whether a more
normative approach toward data interoperability could truly help
fostering data re-use and thus the full realisation of the data economy.
We build on the assumption that interoperability should not become
another policy on its own. Data interoperability should be considered
as a part of a broader data sharing and access discussion and it should
always reflect on the positive and adverse effects alike in order to
reconcile the different interests implied.
B. Clarifying terms: Interoperability and its enablers, data
standardization and APIs
B.I. Looking for a definition of interoperability
Interoperability, like openness, is something that we generally think of
as a “good thing”. Yet, an extensive review of definitions in technology,
business, policy and legal literature, even of case studies, reveals that
there is not one acceptable uniform definition of interoperability. This
may bear certain risks with regard to already or future legislative action
in this field. As data interoperability and data access are inherently
11 This assessment is developed in a second paper to be published soon.
12 Data interoperability is also considered as a precondition for open data. Cf. Laura
DeNardis (ed.) “Opening Standards. The Global Politics of Interoperability” (MIT
Press 2011).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
8
tangled, the use of one or another definition of interoperability might
have effects on the concrete data access regime.
Generally speaking, interoperability is a technical mechanism for
computing systems to work together – even if they are from competing
firms.13 Yet, one can find several definitions for interoperability in the
fields of engineering and computer science literature. Among them, the
joint technical committee of the International Organization for
Standardization (ISO) and the International Electrotechnical
Commission (IEC) defines interoperability as ‘the capability to
communicate, execute programs, or transfer data among various
functional units in a manner that requires the user to have little or no
knowledge of the unique characteristics of those units.’14 It means that
interoperability aims to achieve the harmonious working of
heterogeneous software products and services that make up the ICT
infrastructure, but the needs for interoperability extend beyond this
sector.
In an even broader view, interoperability is defined by the
Institute of Electrical and Electronics Engineers (IEEE) as ‘the ability
of two or more systems or components to exchange information and to
use the information that has been exchanged.’15 Most recently, in the
IoT context, interoperability has been defined as the ability of two
systems to communicate and share services with each other.16
From a more general perspective, the Oxford Dictionary gives a
definition for interoperability as ‘ab[ility] to operate in conjunction’.
This implies that two interoperable systems can understand one another
and use the functionality of each other. From a policy perspective, the
Data Commons Framework developed by the Berkman Klein Center
does not precisely define interoperability but rightly divides it in
different layers: technology, data and format, human and institutional,
and organizational, which all imply a certain degree of data
standardization.17
13 Ian Brown, “The technical components of interoperability as a tool for competition
regulation” (Preprint 12 October 2020), 3.
14 ISO/IEC 2382-1:1993 Information Technology – Vocabulary – Part 1: Fundamental
terms. International Organization for Standardization (ISO)”
<http://www.iso.org/iso/catalogue_detail.htm?csnumber=7229>
(accessed 13.09.2020).
15 IEEE, “Standard Glossary of Software Engineering Terminology” (1990) Doc IEEE
Std 610121990, 3.
16 Jussi Kiljander et al, “Semantic interoperability architecture for pervasive
computing and internet of things” (2014) IEEE Access 2, 856–873.
17 Elena Goldstein, Urs Gasser, and Ryan Budish, “Data Commons Version 1.0: A
Framework to Build Toward Al for Good” (2018) <https://medium.com/berkman-
klein-center/data-commons-version-1-0-aframework-to-build-toward-ai-for-good-
73414d7e72be> (accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
9
The EU legislature defined the concept of interoperability for the
first time in Recital 12 of the Computer Programs Directive as ‘the
ability to exchange information and mutually to use the information
which has been exchange’. Some scholars have rightly emphasized that
this concept of interoperability as isolated policy on compatible
computer programs might no longer be applicable18, for instance if we
are talking about sharing services over a software system as in the IoT
context.
The European Commission Expert Report ‘Competition policy
for the digital era’ 19 defines three different types of interoperability.
‘Data interoperability’ is according to the report equivalent to data
portability but with a continuous potentially real time, access to
personal or machine user data.20 ‘Protocol interoperability’ refers to
the ability of two services or products to interconnect, technically, with
one another.21 ‘Full protocol interoperability’ refers to ‘standards that
allow substitute services to interoperate, e.g. messaging systems’.22
Furthermore, the interim report on digital advertising by the
United Kingdom’s Competition and Markets Authority (CMA) coined
the term ‘content interoperability’ as ‘[the] ability to post content across
several platforms simultaneously; the ability to view posts from friends
on other social platforms; and how the standards surrounding these
features should be developed and monitored.’ 23
This vast amount of definitions shows that there is no one-size
fits-all definition of interoperability24 rather it is a very context-specific
concept that crosscuts a wide spectrum of laws, policies and
technologies, where standards play a prominent role.
One common point of all the previous definitions is that
interoperability always denotes the ability of either a system, a product
or a service to communicate and function with other technically
18 Michael Anthony C. Dizon, “Decompiling the Software Directive, the Microsoft
CFI Case and the i2010 Strategy: How to Reverse Engineer an International
Interoperability Regime” (2008). Computer and Telecommunications Law Review,
Vol. 14, p. 213 Available at SSRN: <https://ssrn.com/abstract=1407131>; Wolfgang
Kerber, Heike Schweitzer, ‘Data Interoperability in the Digital Economy’ (2017),
JIPITEC 8 (1); Begoña González Otero, Interoperabilidad, Internet de las Cosas y
Derecho de Autor, (2019) Reus, Madrid.
19 Jacques Crémer, (n. 6).
20 Ibid, 58. This definition can be misleading, as data portability is a right and should
not be mixed with the concept of data interoperability, which in principle is technical.
21 Ibid.
22 Ibid.
23 Competition and Markets Authority (CMA) “Online Platforms And Digital
Advertising, Market Study Interim Report” (2019), 26
<https://assets.publishing.service.gov.uk/media/5dfa0580ed915d0933009761/Interi
m_report.pdf>; (accessed 13.09.2020).
24 John Palfrey and Urs Gasser, Interop: The Promise and Perils of Highly
Interconnected Systems, Basic Books (2012) Introduction.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
10
different. Consequently, one of its primary benefits is that
interoperability can preserve key elements of alternative technical
solutions and thus innovation and competition while ensuring that
systems work together. However, one of the tricks to the creation of
interoperable systems, products and services is to determine what the
optimal level of interoperability will be: in what ways should the
systems, products and services work together, work across, and in what
ways should they not?25
The norm in the software industry has been to build distributed
systems26, which normally began as fully compatible or interoperable.
Yet the bigger the firms grow, the less interoperability they allow to
better reap network effects and to better foreclose others.27 Designing
decentralized or distributed systems are more burdensome, as they
require high levels of coordination and investment and involve the
setting of standards in collaboration.28 However, the building of
decentralized and distributed systems keeps gaining track as it is
essential for the deployment of working IoT technologies. The firm
needs to balance relevant considerations because allowing for ample
interoperability might entail losing the firm’s competitive advantage,
while a too restrictive access will struggle to engage with users of the
system.
Similar considerations apply to products and services. On the
product level, the idea of “device neutrality” arose a few years ago as
an essential freedom of users to access digital content and use the
25 John Palfrey, Urs Gasser,Interop (2012), p 11.
26 See among others: Timothy F. Bresnahan, Shane Greenstein “Technological
Competition and the Structure of the Computer Industry” The Journal of Industrial
Economics (1999) 47(1), 1; Lawrence A Sharrott, “ Centralized and Distributed
Information Systems: Two Architecture Approaches for the 90s.” in M.J. Ball et al
(eds) Healthcare Information Management Systems. Computers in Health Care.
Springer (New York, 1991).
27 This was pointed already in the explanatory memorandum of the Computer
Programs Directive Proposal when referring to the production of inter-operative
systems. See European Commission, Proposal for a Council Directive on the legal
protection of computer programs (1989) COM(88) 816 final, 3.11. See also Michael
Katz, Carl Shapiro, “Systems Competition and Network Effects” Journal of Economic
Perspectives, Vol 8 – 2 (1994), 93–115. Joseph Farrell and Timothy Simcoe, 'Four
Paths to Compatibility', The Oxford Handbook of the Digital Economy (Oxford
University Press 2012). Cory Doctorow, “Adversarial Interoperability: Reviving an
Elegant Weapon from a More Civilized Age to Slay Today’s Monopolies” EFF
Deeplinks (2019)
<https://www.eff.org/es/deeplinks/2019/06/adversarial-interoperability-reviving-
elegant-weapon-more-civilized-age-slay> (accessed 13.09.2020).
28 Hadil Abukwaik, Davide Taibi, and Dieter Rombach, “Interoperability-Related
Architectural Problems and Solutions in Information Systems: A Scoping Study” in
P. Avgeriou and U. Zdun (eds.) ECSA Proceeding, LNCS 8627, 308–323 (2014).
Chris Gebhardt, “Decentralized Information and the Future of Software – Draft”
(2019) <https://infocentral.org/drafts/DecentralizedInformation.html#monetization-
and-incentives> (accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
11
applications and operating systems they wish.29 This means a
dissociation of operating systems from devices, which requires device
(data) interoperability. The provision of digital services implies the
electronic delivery of information including data and content across
multiple platforms and devices like web or mobile. Interestingly, in the
field of services, an industry consortium, the Web Services
Interoperability Organization, was founded in 2002 and chartered to
promote interoperability among the digital services provided across the
web.30
B.II. Conceptual frameworks
Conceptual frameworks help us to consider interoperability in different
contexts and from different perspectives.31 It is particularly relevant to
understand what syntactic and semantic interoperability are. Overall,
because they are like magnetic poles. It is hard to encounter one without
the other.
Syntactic interoperability refers to interoperation of the format as
well as the data structure used in any exchanged information or service
between heterogeneous entities.32 An interface needs to be defined for
each resource, exposing some structure according to some schema.
29 The idea was first proposed in 2014 by a member of the Italian Parliament, who
proposed a law that should include the users freedom to access content and use the
applications they wish, provided they are legal, they do not impair safety and security,
and they are not in violation of other laws or court orders. A limitation of this freedom
by device manufacturers should be examinable on the grounds of anticonsumeristic
behavior. See: Mastrolonardo, Raffaele. "Net neutrality could become law in Italy -
unless internet users would rather opt out", ZDNet
<https://www.zdnet.com/article/net-neutrality-could-become-law-in-italy-unless-
internet-users-would-rather-opt-out/> (accessed 13.09.2020). Later, the Body of
European Regulators for Electronic Communications (BEREC) published the report
“On the impact of premium content on ECS markets and the effect of devices on the
open use of the Internet”(2018)
<https://berec.europa.eu/eng/document_register/subject_matter/berec/reports/8013-
berec-report-on-the-impact-of-premium-content-on-ecs-markets-and-the-effect-of-
devices-on-the-open-use-of-the-internet> (accessed 13.09.2020). Similarly, the
French peer, l'Autorité de régulation des communications électroniques et des Postes
(ARCEP) published a report “Smartphones, tablets, voice assistants-Devices:weak
link in achieving open internet access” (2018)
<https://archives.arcep.fr/uploads/tx_gspublication/rapport-terminaux-fev2018-
ENG.pdf> (accessed 13.09.2020).
30 <https://en.wikipedia.org/wiki/Web_Services_Interoperability>
(accessed 13.09.2020).
31 Among the latest: European Interoperability Framework, SWD (2017) 112 final,
Annex to EC European Interoperability Framework – Implementation Strategy, COM
(2017) 134 final, 18 to 28; New European Interoperability Framework (EIF), 2017,
21 to 32. Available at: https://ec.europa.eu/isa2/eif_en (accessed 13.09.2020).
32 Magdha Noura, Mohammed Atiquzzaman and Martin Gaedke, “Interoperability in
Internet of Things: Taxonomies and Open Challenges” Mobile Netw Appl 24 (2019)
799.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
12
Web Service Definition Language (WSDL) and RESTful designed
APIs are examples. The content of the messages needs to be serialized
to be sent over the channel and the format to do so (such as XML or
JSON). The message sender encodes data in a message using syntactic
rules, specified in some grammar. The message receiver decodes the
received message using syntactic rules defined in the same or some
other grammar. Syntactic interoperability problems arise when the
sender’s encoding rules are incompatible with the receiver’s decoding
rules.33
Semantic interoperability as defined by the World Wide Web
Consortium (W3C) refers to the “enabling of different agents, services,
and applications to exchange information, data and knowledge in a
meaningful way, on and off the web”34 The Web of Thing (WOT)
addresses the current fragmentation in the Internet of Things by
exposing things and systems data and metadata through APIs. But such
efforts have been hampered because the corresponding parties need to
exchange information about certain aspects –i.e. the disclosure of
specifications or the explanation of an implementation - of an API35 and
non-technically spoken, many devices do not speak the same language
and cannot exchange across different gateways and smart hubs.36 If the
data generated by systems and products have a defined data format, but
the data models and schemas used by different sources are dissimilar,
not always compatible, and data representation is not consistent, data
communication will not work.
In the context of data sharing, semantic interoperability plays a
key role. It is essential for the efficient use of data and for enabling data
driven innovation. Data driven innovation builds on the information in
the data. No any data serve or constitute data driven innovation, but
only information that is implemented on a knowledge level. This
already requires syntactic interoperability, which depends on a certain
degree of semantics to allow for access and a certain degree of
communication. Moreover, the more interoperability of products and
services throughout different sectors is demanded, the higher the need
of semantics is. With semantic interoperability in place, various
corporate data governance systems may work seamlessly together –
decreasing cost that may arise due to a lack of interoperability and thus
33 Ibid.
34 W3C, “W3C Semantic Integration & Interoperability Using RDF and OWL” (2001)
https://www.w3.org/2001/sw/BestPractices/OEP/SemInt/,
(accessed 13.09.2020).
35 Martin Bauer et al, “Semantic Interoperability for the Web of Things” (2016),
doi: 10.13140/RG.2.2.25758.13122
36 Maria Shiao, “Internet of Things. Standardisation and Architectures. Workshop
Report” (2015) European Commission, 4, <https://ec.europa.eu/digital-single-
market/en/news/standards-and-architecture-iot-path-convergence-main-outputs-
workshop-iot-standardisation-and> (accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
13
further incentives data sharing.37 Potential reuse of an already existing
technical solution together with less data interoperability conflicts.
However, semantic interoperability, seems not be sufficiently
addressed in the current regulatory framework of data governance
regimes.
B.III. Enablers of data interoperability
The main technical enablers to achieve syntactic and semantic
interoperability are the following two: data standardization and
application programming interfaces (APIs). There is a key difference
between them. Namely, when a firm chooses one or the other enabler
this has important consequences from a competition and innovation
perspective. APIs represent an endpoint interface and are usually
designed unilaterally by the owner of the system, product or service;
they are not a give-and-take agreement and do not require full
disclosure.38 On the other hand, data standardization such as data
models, data formats or protocols, require the agreement of the parties
involved, therefore, collaboration and disclosing of information is
required.
From a data standardization perspective, data formats relate to the
organization of information according to pre-set instructions,39 while
data models are conceptual representations that help in the visual
representation of the information contained in data.40 In principle, data
37See for instance the 2020 guidelines "Interoperabilität durch standardisierte
Merkmale” (Interoperability by standardized properties) of the German Mechanical
Engineering Industry Association (Verband Deutscher Maschinen-und Anlagenbau –
VDMA), which are based on the creation of common semantic attributes and data
models. More information at: https://www.vdma.org/v2viewer-/v2article/render/397
46287 (accessed 13.09.20).
38 Therefore, they should not be conceptualized as data standards. Cf. Michal Gal,
Daniel Rubinfield “Data Standardization” NYU Law Review (2019) 750 referring to
Oscar Borgogno, Giuseppe Colangelo “Data Sharing and Interoperability: Fostering
Innovation and Competition Through APIs” Computer L. & Security Rev. (2019) 8,
stating that the most commonly used data standards are Application Programming
Interfaces (APIs).
39 A significant challenge for data formats relates to how the structure and description
of data and metadata (data about data, such as the author or producer of the dataset
and the date the data was produced) can be organized consistently. See Luis González
Morales, Tom Orrell “ Data Interoperability: A Practitioner’s Guide to Joining Up
Data in the Development Sector” (2018) 22.
<http://data4sdgs.org/resources/interoperability-practitioners-guide-joining-data-
development-sector> (accessed 13.09.2020). See also: Daan Broader, Dieter van
Uytvanck, “Metadata Formats” in The Oxford Handbook of Corpus Phonology
(Oxford University Press, 2014).
40 See Amarnath Gupta, Data Model vs Data Format, Big Data Modelling and
Management Systems, University of California in San Diego, available at:
https://www.coursera.org/lecture/big-data-management/data-model-vs-data-format-
xZmuD (accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
14
formats better serve to achieve syntactic interoperability, while data
models work for both syntactic and semantic interoperability. More
metaphorically put, a data model is as the architect´s-building plan
while the format is the type of bricks used. A data communications
protocol deals with the rules for the transmission of data between two
or more points (or nodes, as they may also be called).41 Central to these
rules is the concept of layers. Protocol layers were conceived in order
to divide the duties of a protocol into manageable chunks.42
APIs are a type of computer program interface consisting on sets
of functions, procedures, definitions and protocols for machine-to-
machine communication and the seamless exchange of data.
Conceptually APIs can be divided into “specifications” and
“implementations”. Specifications are made of declaring code, but they
do not instruct a computer to do anything. Implementations are a set of
step-by-step instructions to be used directly or indirectly in a computer
in order to bring about certain result.43
The expansion of cloud computing brought the rapid
development and adoption of a technology referred to as web services.
Web services stands as a key one for allowing computers to
communicate machine to machine, server to server and to exchange
data. The W3C has defined web services as a software system designed
to support interoperable machine-to-machine interaction over a
network.44 Web services technology have transformed digital services.
Amazon Web Services (AWS)45 is the first reference that might come
to mind, but all existing digital platforms use web services.46 A key
feature of web services is the degree of interoperability they offer, so
that applications can be written in various languages and are still able
41 An example is SOAP, a lightweight protocol intended for exchanging structured
information
in a decentralised, distributed environment over a network. See W3C, “SOAP Version
1.2 Part 1: Messaging Framework” (Second Edition, 2007),
<www.w3.org/TR/soap12/> (accessed 13.09.2020).
42 Edward Insam, TCP/IP Embedded Internet Applications (Elsevier, 2003) 55.
43 Brief Amici Curiae of 83 Computer Scientists in Support of Petitioner, No. 18-956
(2020) 7. Available at <https://www.supremecourt.gov/DocketPDF/18/18-
956/128391/20200113145027664_18-956%20Google%20v%20Oracle%20Compute
r%20Scientists%20Merits%20Amicus%20FOR%20FILING.pdf> (accessed
13.09.2020).
44 See <https://www.w3.org/TR/ws-gloss/> (accessed 13.09.2020).
45 Amazon evolved from selling books, to selling a much more diverse set of goods,
to needing an (internal) platform supporting the provisioning general purpose network
and compute resources necessary to support the development of an (external) platform
that facilitated third party sellers’ access to Amazon’s global market presence. For
further details see Jon Swartz, “How Amazon created AWS and changed technology
forever” Market Watch (2019)
<https://www.marketwatch.com/story/how-amazon-created-aws-and-changed-
technology-forever-2019-12-03> (accessed 13.09.2020).
46 GoogleSearch API is another example of Web services.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
15
to communicate by exchanging data with one another, server to
server.47
Looking at the definition of web service (a software system
designed to support interoperable machine-to-machine interaction and
exchange of data over a network), one might correctly assume that they
resemble to the definition of APIs (software interface designed for
machine-to-machine communication and the seamless exchange of
data). Most specialists say that web services are a type of API, which
can only be accessed through a network connection.48 Yet, not all APIs
are web services. APIs can be on- or offline. Another central difference
is that APIs can utilize any kind of communication convention
(communication agnosticism) while web services are restricted. A web
service developer has more restrictions in terms of design. However, an
API developer can utilize different tools to make its program simpler
and less complex or the other way around. Thus, APIs can utilize any
kind of communication convention and are not restricted as a web
service is.
Maybe that is the reason why a majority of firms providing web
services have decided to design unilaterally their own APIs for their
web services. These are the so-called “Web-APIs” 49 which allow for
data exchange machine-to-machine (or as the Open Data Directive
refers to “dynamic data” made available via APIs).50 The primary intent
of web APIs is to exchange (or even modify)51 data between software
systems. Web APIs, same as APIs, can be open or restricted.
From a data interoperability perspective, it is relevant to see how
much web APIs design rely on semantics. The two mostly spread
designs are the SOAP specification (Simple Object Access Protocol)
and the REST principles (Representational State Transfer). Web-APIs
47 Marshall Breeding, “Introduction to Web Services” Library Technology Reports
(2006) <https://journals.ala.org/index.php/ltr/issue/view/152>
(accessed 13.09.2020).
48 See <https://blog.thedigitalgroup.com/api-vs-web-service-understanding-the-
difference>; <https://nordicapis.com/what-is-the-difference-between-web-services-
and-apis/#:~:text=There%20you%20have%20it%3A%20an,all%20APIs%20are%20
web%20services.> (accessed 13.09.2020).
49 See https://en.wikipedia.org/wiki/Web_API (accessed 13.09.2020).
50 See Art. 2 (8) and Recitals 31 and 32 of the Directive (EU) 2019/1024 of the
European Parliament and of the Council of 20 June 2019 on open data and the re-use
of public sector information, ELI: http://data.europa.eu/eli/dir/2019/1024/oj.
51 “Operations to modify data are a core part of the Web API. In addition to a simple
update and delete, you can perform operations on single attributes and compose upsert
requests that will either update or insert an entity depending on whether it exists”. See
<https://docs.microsoft.com/en-us/powerapps/developer/common-data-
service/webapi/update-delete-entities-using-web-api#:~:text=Operations%20to%20
modify%20data%20are,depending%20on%20whether%20it%20exists.> (accessed
13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
16
adhering to the SOAP specification52 facilitate exchanging structured
information in a decentralized, distributed environment. Even if the
World Wide Web infrastructure is distributed, as indicated earlier,
decentralized and distributed system infrastructures require higher
investments due to their complexity than centralized ones.53 The REST
principles appeared as a more flexible approach to build lightweight and
fast web and mobile applications and gained popularity over SOAP.54
REST architecture relies on the idea that any API or web API must
comply with certain principles to be certified as “RESTful”.55 Such
design principles or constrains are highly based on data semantics to
ensure that the API is predictable and easy to understand and use by a
third party invoking it.56 These design principles also implied the idea
of disclosing information, as the API documentation (the
specifications) to be RESTful needs to be easily accessible and
comprehensible by other firms. The “Unified API” by the City of
London Railway57, the use of “REST” APIs58 by several municipal
public transport providers59, the “RESTful” API of UBER60 are
examples. In the last two years, another design approach is rapidly
increasing its adoption by firms and developers. Instead of using a data
protocol or a set of design principles, GraphQL is an open-source data
52 The SOAP specification was initially designed as SOAP was designed as an object-
access protocol by Microsoft and IBM. However, later on it became the underlying
layer of a more complex set of web services. For further details see
https://en.wikipedia.org/wiki/SOAP (last accessed 12.08.20).
53 For a comparison between centralized, decentralized and distributed systems see:
<https://www.geeksforgeeks.org/comparison-centralized-decentralized-and-
distributed-systems/> (accessed 13.09.2020). On the relationship between federation,
distribution and decentralization, see: Gaia-X: Technical Architecture
(2020) 23 <https://www.data-infrastructure.eu/GAIAX/Redaktion/EN/Publications/g
aia-x-technical-architecture.html> (accessed 13.09.2020).
54 For differences between SOAP and REST see:
<https://testautomationresources.com/api-testing/differences-web-services-api/>
(accessed 13.09.2020).
55 Representational State Transfer (REST) are a set of design principles presented by
Roy Fielding in his PhD “Architectural Styles and the Design of Network-based
Software Architectures” in 2000.
<https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm> and
<https://restfulapi.net/> (accessed 13.09.2020).
56 Ruben Verborgh, Andreas Harth, Maria Maleshkova et al. “Semantic Description
of Rest APIs”, available at:
https://tomayac.com/papers/semantic_description_of_rest_apis.pdf
(last accessed 12.08.20).
See also: https://dzone.com/articles/rest-its-all-about-semantics (last accessed
12.08.20.) and https://scotch.io/bar-talk/designing-a-restful-web-api#:~:text=REST
%20is%20basically%20a%20list,easy%20to%20understand%20and%20use.&text=
Semantics%2C%20semantics%2C%20semantics%3A%20The,Status%20Codes%20
and%20HTTP%20Authentication) (last accessed 12.08.20).
57 See: https://tfl.gov.uk/info-for/open-data-users/unified-api#on-this-page-3
58 REST stands for representational state transfer.
59 Ably Hub, “The maturity of public transport APIs 2019” (2019). Available at:
https://files.ably.io/research/whitepapers/the-maturity-of-public-transport-apis-2019-
ably-realtime.pdf. (last accessed 13.09.20).
60 See: https://developer.uber.com/ (last accessed 13.09.20).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
17
query and manipulation language (a syntax) that describes in steps how
to ask for data from the API, preventing excessively large amounts of
data from being returned.61
All these approaches toward effective design of web APIs, which
main function is data communication machine-to-machine, clearly
shows how important and complex the achievement of high levels of
semantic data interoperability is. This also becomes necessary for
effective data access and reliable data sharing. However, this does not
mean that web APIs or APIs based on any of these designs’ principles
are open by default. APIs, as it happens with software, offer the dual
virtues of practical modular design and precise metering of access.62
They have become the foundation of almost any digital infrastructure
and a critical facilitator for data interoperability –besides data
standardization.
C. The role of data interoperability in data related market failures
Data interoperability is the key prerequisite for efficient data sharing
and data driven innovation. Indeed, the expected economic and social
benefits of data access and sharing are enormous. Data driven
innovations have already transformed multiple sectors in the economy
and are a new disruptive source of productivity growth.63 In particular,
the advanced use of data analytics and artificial intelligence enables
undertakings to scale their business at much lower costs than in
analogue times.64 Data are the essential inputs for AI applications. Even
beyond productivity growth, a greater availability of data can create
beneficial spill-overs.65 Data has also a central role in online markets.
Value creation is reinforced through a recursive data capture and data
61 It was built by Facebook and recently moved to the GraphQL Foundation, hosted
by the Linux Foundation. For more details see: <https://graphql.org/learn/> (accessed
13.09.2020).
62 Seth G. Benzell, et al. „The Paradox of Openness: Exposure vs. Efficiency of APIs”
<http://ide.mit.edu/sites/default/files/publications/The%20Paradox%20of%20Openn
ess%208-3-19.pdf> (accessed 13.09.2020).
63 According to one of the most recent studies conducted by the OECD, data access
and sharing can help generate social and economic benefits worth between 0.1% and
1.5% of gross domestic product (GDP) in the case of public-sector data, and between
1% and 2.5% of GDP (in few other studies up to 4% of GDP) when also including
private-sector data. See OECD, Enhancing Access to and Sharing of Data (2019), 60.
64 And this goes much beyond ‘scaling without mass’. Cf. Erik Brynjolfsson and
others, ‘Scale Without Mass: Business Process Replication and Industry Dynamics’
(2008) Harvard Business School Technology & Operations Management Unit
Research Paper No 7/16.
65 OECD (n. 64), 64
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
18
deployment feedback loop which is enabled by machine learning (ML)
technologies.
Amidst fierce global competition, AI has become – according to
the European Commission - one of “the most strategic technologies of
the 21st century”.66 The EC has already outlined the strategic role the
right EU legal framework for AI should play for defining the future we
would live in. It is thus of utmost importance that the EC pursues a
strategic manoeuvre with regard to IP and data access innovation
policies and AI. This already led to direct market interventions through
data access, portability and data governance regulation - some still
adhering to competition specific traditional refusal to deal
considerations - together with data sharing remedies in both merger
control and abuse of dominance cases. Moreover, there are private data
sharing initiatives.
Yet, there is also a cost to data sharing and re-use. Private firms
may incur costs when they share data with parties that can harm their
interests. They take data sharing decisions in function of the expected
benefits and costs.67 Furthermore, other negative externalities may arise
due to increased data sharing. This implies data protection and data
security concerns but potential negative effects of data-induced
distortions of competition.68 Although increased data sharing may
create both static and dynamic efficiencies, if it does not go hand in
hand with data interoperability consideration, this may also create the
ability for undertakings to enter into strategic market foreclosing
behaviour that bars others from market entry or may eventually lead to
anti-competitive market concentrations, such as the so-called digital
“gatekeepers” or data-opolies.69
Regulating data sharing and thus any attempts of the EU and its
Member States to directly shape data driven innovation should still
reflect on traditional market failure considerations stemming from
economic normative regulatory theory. Markets are constituted by the
consent of economic citizens to individual transactions and typically do
not require centralised coordination in the sense of a centrally planned
economy. The legal foundation of markets consists in the freedom-of-
66 European Commission, Communication on Artificial Intelligence for Europe
(2018) COM(2018) 237 final, SWD(2018) 137 final, 1.
67 Bertin Martens, et al, “Business-to-Business Data Sharing: An Economic and Legal
Analysis” (July 22, 2020) 5, <https://ssrn.com/abstract=3658100> (accessed
13.09.2020).
68 For an overview on potential adverse effects see Hoffmann (n. 10) 1-26.
69 See: Ariel Ezrachi, Maurice E. Stucke, “eDistortions: How Data-Opolies are
dissipating the Internet’s potential”, in Guy Rolnik (ed.) Digital Platforms and
Concentration, Stigler Center, University of Chicago Booth School of Business
(2018), 5, <https://promarket.org/digital-platforms-concentration/>
(accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
19
contract principle, which is safeguarded by competition law.70
Decentralised decision making between the parties of the contract is to
be favoured because individual economic preferences of numerous
economic agents would be outvoted in a centralised decision-making
process, and this would contradict the principles of individual freedom
and self-determination, which are also enshrined in Articles 6, 16 and
17 CFR.71
In order to assess market failure in data access cases, one has to
distinguish between personal and non-personal data. Whereas data
protection laws may already create high hurdles for switching and
create lock-ins, non-personal data cases – particularly in after-market
constellations – need a different assessment. On the off chance that it
goes to the question whether enough data is really utilized and re-used,
the role data pools, data trusts and data marketplaces play as data
sharers and data normalizers need to be taken into account.72 Only if all
of these options fail to provide for efficient data use one may actually
identify a market failure. Even though it seems that particularly large
platform undertakings are currently systemically blocking access to
data, this does not automatically mean that any market operator is
systemically excluded from markets.73 The current discussion on the
planned European Digital Markets Act and the 10th Amendment of the
German Antitrust Code are looking at both asymmetric access and
interoperability obligations exclusively for the undertakings with
paramount importance across markets, i.e. gatekeepers.74
Applying this principle of an open market and competition system
to the question of how to regulate access to data and data
interoperability one should note that states should refrain from directly
innovation-enabling ex ante regulation going beyond merely
70 Franz Böhm, Wirtschaftsverfassung und Staatsverfassung (1950), 50 et seq.; Böhm,
‘Privatrechtsgesellschaft und Marktwirtschaft’ (1966) ORDO 75, 92.
71 Josef Drexl, ‘Competition Law as Part of the European Constitution’ in Armin von
Bogdandy and Jürgen Bast (eds) Principles of European Constitutional Law (2010)
633, 660.
72 Cf. Heike Schweitzer, Martin Peitz, Datenmärkte in der digitalisierten Wirtschaft:
Funktionsdefizite und Regelungsbedarf? (2017) Discussion Paper No. 17-043, ZEW,
4ff.
73 ibid. 5.
74 European Commission, “The Digital Service Act Package” (2020)
<https://ec.europa.eu/digital-single-market/en/digital-services-act-package>
(accessed 13.09.2020); European Commission, “Digital Services Act package: Ex
ante regulatory instrument for large online platforms with significant network effects
acting as gate-keepers in the European Union’s internal market, Inception Impact
Assessment” Ref. Ares(2020)2877647 - 04/06/2020 (2020). The text of the German
draft bill of 9 September 2020 (GWB10) can be found at
<https://www.bmwi.de/Redaktion/DE/Downloads/G/gwb-digitalisierungsgesetz-
referentenentwurf.pdf>, and English version can be consulted at <https://www.d-
kart.de/en/blog/2020/02/21/draft-bill-the-translation/> (accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
20
safeguarding the well-functioning of open competitive markets.75
Market considerations build their assumptions on the fact that under
conditions of effective competition, rule-based economic freedoms of
action lead to results that correspond to positive general welfare
effects.76 One of the prerequisites of a competition system is the
primacy of exclusivity and imperfect knowledge that is usually
constituted by a property system or factual exclusivity combined with
contractual freedoms. These are primary enablers of markets, framed
by regulation , which safeguards freedom of competition.77 Under these
circumstances markets evolve spontaneously and usually regulate
themselves.78 Indeed, even though the current platform regulation
debate is foreseeing stronger ex ante regulation against platforms with
paramount importance across markets, competition –as institution –
should still be the guiding principle for pro-innovation regulation.
Competition serves as an incentive for innovation and a means to new
discoveries.79 Translated in the data context, some form of factual
exclusivity of data is still a prerequisite for data specific markets and
market force led data driven innovation. This also holds true under
utilitarian incentive considerations. To this end, it should be kept in
mind that data may have high economic and competitive value. Data
may thus not only be valuable trade secrets, the aggregation of high
value information and the inferred information in ML applications may
provide huge competitive advantages. Factual exclusivity over valuable
information may be one of the key competition parameters, may also
serve as investment incentive, and may attenuate the relevance of IP
protection from an AI perspective. Factual data exclusivity and
expertise are the key competitive factors with regard to the development
of AI. 80
75 This applies to interoperability too. See Wolfgang Kerber, Heike Schweitzer,
‘Interoperability in the Digital Economy‘ (2017) 8 JIPITEC 39, 1, 71-75.
76 Ernst-Joachim Mestmäcker, ‘Europäische Wirtschaftsverfassung’ (2009) EUP, 2.
77 Walter Eucken, Die Grundlagen der Nationalökonomie (1947, 9th ed. 1989), 256;
Franz Böhm, Wirtschaftsverfassung und Staatsverfassung (1950), 50.
78 Friedrich August von Hayek, ‘Der Wettbewerb als Entdeckungsverfahren,
Freiburger Studien’ (1969), 249 -265.
79 Even though there are different opinions on the question of how much competition
is actually necessary to foster innovation, competition is still the allocation model in
market economies. Cf. Kenneth J. Arrow, ‘Economic Welfare and the Allocation of
Resources for Invention’ (1962) National Bureau of Economic Research, ‘The Rate
and Direction of Inventive Activity: Economic and Social Factors’ 609, 620. Different
opinions on this: Joseph Schumpeter, Theorie der wirtschaftlichen Entwicklung
(1912), 157 and Aghion and Howitt, ‘A model of growth through creative destruction’
(1992), 60 (2), Econometrica, 323. Cf. DOJ (n. 7).
80 Reto M. Hilty, Jörg Hoffmann, Stefan Scheuerer, “Intellectual Property
Justification for AI” (2020) available at
<https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3539406>
(accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
21
Despite potential lacks of data sharing, data commons or open
data by default, comparable to Ostrom’s ‘commons’81 considerations,
should not be the guiding principle.82 Indeed, similar to traditional
‘service public’ considerations in the utilities sectors, data has already
widely been recognised as an infrastructure.83 Such reasoning may
provide for a justification for broader B2B data access regimes in the
EU. Contrary to some (former) existent natural monopolies in the
telecommunication or electricity sector however, there is typically no
natural monopoly in B2B data specific markets that would justify a
universal open data access regime. There are strong data network
effects and data specific economies of scope. Yet, data need to have
certain correlations in order to really provide for something new on the
knowledge level and thus for constituting data driven innovation. Using
completely randomized data to train a certain ML model for example
will not improve its quality.84
Notwithstanding the potential positive effects of a lack of data
interoperability, a simple access right that does not further reflect on
modalities of the sharing of data within a broader data governance
framework may fall short of remedying the identified market failure.
Data lock-in scenarios may not be entirely solved by simply outlining
the privately enforceable obligation of sharing of information in a
processable and electronically readable, interoperable, format. In order
to fully reap off the advantages of data sharing without causing other
negative externalities – particularly privacy and data security related –
a broader regulatory approach is necessary. Thereby the transactions
costs should also be explicitly considered and thus a public law
approach dealing with non-waivable data interoperability obligations
may be the favourable way forward.85
81 Elinor Ostrom, Die Verfassung der Allmende (1999). Even there, one hast o assess
that efficient ccoperation within commons systems only worked for smaller, very
restricted cooperation mechanisms.
82 Hoffmann (n. 10), 16-18.
83 K.S. Rahman, ‘Regulating informational infrastructure: Internet platforms as the
new public utilities. Georgetown Law Technology Review 2, 234-252; Gintare
Surblyte, ‘Data as digital resource’ (2016) Max Planck Institute for Innovation and
Competition Research Paper No. 16-12,
<https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2849303>
(accessed 13.09.2020), M. Janssen, S.A. Chun, J.R. Gil-Garcia Building the next
generation of digital government infrastructures (2009) Government Information
Quarterly, 26, 233-237.
84 Looking for structures and regularities in data is not enough to understand or acquire
knowledge. Knowledge cannot be derived through induction alone; it requires a
theory or a prior framework that can be tested. Humans necessarily predetermine this
framework and thus data have to be related – at least to some extent. See R. Vigo,
‘Complexity over uncertainty in generalized representational information theory
(GRIT): A structure-sensitive general theory of information’ (2013) 4 Information 1-
30, 4.
85 Cf. on high transaction costs in data trading, Schweitzer, Haucap (n. 72), 6.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
22
For instance, what mostly all governmental and academic studies
about digital platforms have in common is that economies of scale and
traditional and data-driven network effects not only have characterized
the evolution of the online system but also had led to the rise of key
online gatekeepers with the potential to foreclosure other market
participants.86 While such a dynamic is welcomed when it delivers
greater efficiencies, innovation and quality, disruption is problematic
when it challenges the boundaries of law, causing market distortions. In
order to ensure a level playing field, there is a public interest in
competition rules being applied equally to the market players. In this
regard, data interoperability has the potential of becoming a distortion-
preventing tool. Among others, the 2018 Study on Abuse for the
German Ministry for Economic Affairs and Energy pointed, digital
markets have a tendency to “tipping”. Such a tendency is not natural
but induced by individual practices, e.g. the obstruction to
interoperability.87
All in all, outlining specific data access rights may not suffice for
efficiently reaping off the welfare enhancing effects of increased data
sharing. To this end, data interoperability has its specific role to play.
As efficient re-use of data depends to a high extent on data
interoperability, a lack of interoperability or stand-alone
interoperability regulation may already provide or hinder efficient data
sharing and thus may either efficiently provide for a remedy for the data
specific market failure or may prevent the adverse effects of too
excessive data sharing. Indeed, the negative externalities that come with
an increased sharing and use of data are typically addressed in specific
legal regimes respectively.88 Yet, data interoperability, the scope and
modalities of the data access right and other options of remedying the
negative externalities should always be looked at together.
D. APIs: IP and Competition Law considerations
As we have seen, APIs are one of the technical means to facilitate data
interoperability. This type of software interface has attracted a lot of
attention in the last decades because free implementation of API
specifications has been not only essential to realizing fundamental
innovations in computing it is also essential for efficient data sharing
and thus data driven innovation. Any firm will be faced with competing
86 Cf. (n. 6).
87 Heike Schweitzer, Justus Haucap, Wolfgang Kerber, Robert Welker
“Modernisierung der Missbrauchsaufsicht für marktmächtige Unternehmen” Projekt
Nr. 66/17 (2018), 12.
88 For instance, the current discussion with regard to the European competition policy
is focusing on further adapting competition laws for tackling (- or regulating) so-
called undertakings with tantamount importance for competition across markets. This
is currently discussed in Germany under the draft of the 10th amendment of the
German Antitrust Code for example.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
23
options and will need to make trade-off decisions. To maximise the
likelihood of an API project succeeding and minimise design delays,
the firm should establish a set of guiding principles to address
architectural preferences and delivery approaches, this means how to
balance the dual virtues of a practical modular design and a precise
metering of access. Consequently, APIs are instruments that allow for
controlling follow on innovations not only in the software market but
in any data-driven market that requires a network (web services or IoT)
and the innovation capacities of whole data ecosystems and thus their
monetization. In this context, there are three relevant questions that
need to be addressed: First, the “appropriation” of APIs through IPRs,
where the jurisprudence and academic debate on the copyright
protection of APIs remains; second, what happens if a third party uses
the underlying right when establishing data interoperability, and, third,
to what extent the user of the API can rely on exceptions and
limitations.
As to the “appropriation” of APIs, the first question that comes to
mind is whether APIs can be the object of an intellectual property right.
Copyright protection of APIs has drawn criticism for decades. The
Computer Programs Directive makes clear that ideas and principles
underlying any element of a computer program, including those which
underlie its interfaces, are not protected by copyright.89 Contrary to that,
the expression of API specifications and API implementations, could
qualify for protection as independent works subject to the originality
threshold.90 Even if the CJEU gave a purposive interpretation of the
Directive so that the functionality of software interfaces (as it is the case
with APIs) should not restrict interoperability91, the question of
protection of APIs as independent works of copyright remains
unsettled. As some have rightly pointed, while data and user interfaces
are substantially different from APIs, the interpretation made by the
CJEU would appear to offer ground for reaching the conclusion that
choices for interfaces concerning the implementation of abstract ideas
contained in the source code can be sufficiently original, as were
deemed to be those concerning languages or formats.92
89 Article 1(2) Directive 2009/24/EC of the European Parliament and of the Council
of 23 April 2009 on the legal protection of computer programs (Codified version),
ELI: http://data.europa.eu/eli/dir/2009/24/oj. This was made clear by the CJEU both
in 2010, case C-393/09, Bezpečnostní softwarová asociace - Svaz softwarové ochrany
v Ministerstvo kultury [2010] ECLI:EU:C:2010:816, and 2012, case C-406/10, SAS
Institute Inc. v World Programming Ltd [2012] ECLI:EU:C:2012:25.
90 Case C-393/09, Bezpečnostní softwarová asociace - Svaz softwarové ochrany v
Ministerstvo kultury [2010] ECLI:EU:C:2010:816 para 41 – 43; Case C-406/10, SAS
Institute Inc. v World Programming Ltd [2012] ECLI:EU:C:2012:259 para 35 and 39.
91 Case C-406/10, SAS Institute Inc (…) 39 and 46.
92 Nicolo Zingales, “Of Coffee Pods, Videogames, and Missed Interoperability:
Reflections for EU Governance of the Internet of Things”, TILEC Discussion Paper
No. 2015-026 (2015) 10, https://ssrn.com/abstract=2707570, (accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
24
Furthermore, web services can be considered a computer program
that happens to be also an API. A web service, as said earlier, is a
technology that accomplishes the task of communicating and
exchanging data over a network between two machines. It is expressed
in code. The “underlying” function of achieving the communication can
be enabled via a web API or via other data standardization means – this
is a design decision. Thus, in principle there is no merger between idea
and expression. Web services as long as they are original, could be
eligible for protection under the Computer Program Directive. In any
case, since the Supreme Court of the US admitted the petition from
Google in the (now) Google v. Oracle case, the discussion of potential
copyright protection of APIs is back on the table.93
Regardless, having access to API information is of importance to
competitors in software dependent markets. As a representative of the
US government stated during the Microsoft case: “[t]o control the
interface specifications is to control the industry.”94 It is for this reason
that the Computer Programs Directive provides for a limited exception
to copyright infringement in the case of decompilation95 performed to
achieve interoperability. However, the Directive falls short at imposing
a positive obligation to disclose interoperability information. At best,
the Directive does not enable copyright holders to rely on their
copyright and prohibit others from uncovering such information
through decompilation when such information is not made available by
the copyright holders themselves. Decompilation is a technically
complex, costly and time-consuming reverse engineering technique that
is best avoided where possible. Article 6 of the Directive codifies the
legal position under EU law. It does not require the authorisation of the
copyright holder where such action is ‘indispensable to obtain the
information necessary to achieve interoperability of an independently
created computer program with other programs’96 The indispensability
requirement restricts the scope of the copyright exception for the only
purpose of achieving interoperability with an independently created
program. Three additional conditions must be fulfilled for
decompilation to be lawful. First, the performer must be a licensee or a
lawful user of the software. Second, the information sought must not be
available to the party carrying out the act through any other means (for
instance, a refusal to license). Finally, decompilation must be restricted
to the parts of the program necessary to achieve interoperability (which
in principle might be very difficult to delineate for a third party).97
Added problem is that for interoperability to take place, the third party
93 Google LLC v. Oracle America, Inc., U.S. docket number No. 18-956 (Nos. 2017-
1118, 2017-1202 (Fed. Cir. Mar. 27, 2018).
94 United States v. Microsoft Corp., 87 F. Supp. 2d 30 (D.D.C 2000).
95 Decompilation is a reverse engineering technique that mainly consists in translating
object code into source code.
96 Article 6 Directive 2009/24/EC on the legal protection of computer programs.
97 For a detailed assessment of Article 6 of the Computer Programs Directive see:
Begoña González OteroInteroperabilidad, Internet de las Cosas y Derecho de autor
(Reus, 2019) 232.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
25
needs to exactly adhere to the relevant specifications and decompilation
does not guarantee this. Furthermore, decompilation becomes futile if a
computer program is provided as a service. Additionally, decompilation
is totally useless if the owner of the API modifies the specifications
relatively often, as tends to be the case.
Another IPR to consider as to the appropriation of APIs are
patents. Under the European Patent Convention, computer programs ‘as
such’ are excluded from patent protection.98 However, the case law of
the European Patent Office (EPO) and the examination guidelines that
derive from this case law make it clear that this exclusion does not apply
when the computer program has a technical character.99 This limitation
to the exclusion100 is the narrow squeak through which software
developers try to push their products to obtain a patent. Traditional
APIs, which are part of computer program, or when the computer
program is embedded in a device, could easily be protected under a
computer implemented implementation.101 However, APIs could also
be considered aspects of the computer program where the invention as
a whole does not claim an abstract or non-technical subject matter. If
only a portion of code from a computer program that relates to the
computer-implemented invention has been used by an unauthorized
party, it may not necessarily lead to patent infringement.
This might be more problematic in the case of web services as
they are a type of technology which happens to be also an API. As in
the case of computer programs, while each case depends on its own
merits, there is a rather clear line to decide whether an invention has the
required technical character: computer programs, or in this case a web
service, are methods to accomplish tasks or solve problems (the
communication and exchange of data over a network between two
machines). As long as the method remains abstract, it cannot be
patented under the rules of the EPC even if it runs on a computer. As
soon as the method is put to specific, technical use, it will be treated
just like any other solution for a problem and subjected to the further
patent requirements of novelty and inventive step. This type of
protection could be relevant for the webservice/API implementation,
where the technical effect might take place. The specifications part,
which is no more than declaring code, but it is the part that contains
essential information for a third party if wants to invoke data
98 Articles 52(2) and (3) European Patent Convention.
99 Guidelines for Examination Part G II 3.6; EPO T 1173/97 and EPO G 3/08. The
EPO assesses the technical effect without taking into consideration the prior art.
Therefore, simply replacing a process or the acts of a human being, which are not
considered to be technical, does not suffice to give the invention a technical character.
See: EPO T 1227/05; EPO T 1784/06; EPO T 1370/11; EPO T 1358/09.
100 Limitation that one cannot explicitly find in the wording of the EPC.
101 Some examples of patents relating to computer program interfaces can be found in
EPO Dec. T 2217/08 (Executable code/Microsoft) and T 1415/07 (Converting
graphical programs/National Instruments).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
26
interoperability, would not be covered by the scope patent. Conversely,
API specifications would not be part of the patent application nor they
will be disclosed. In these cases, a reverse engineering exception for the
purpose of achieving interoperability could help. Such an exception
only exists in the text of the Agreement of a Unified Patent Court
(UPC)102, which entry into force is still unknown. Article 27 regulates
the ‘[L]imitations of the effects of a patent” and its letter (k) states
that “the rights conferred by a patent shall not extend to any of the
following: (k) the acts and the use of the obtained information as
allowed under Articles 5 and 6 of Directive 2009/24/EC, in particular,
by its provisions on decompilation and interoperability.’
The main problem here is that, as explained above the
decompilation exception is quite complex and, in the end, does not
really guarantee that interoperability would be achieved. Additionally,
a restrictive interpretation of this limitation in the field of patent brings
two additional obstacles. First, only the acts and the use of the
information obtained through reverse engineering techniques such a
black box analysis103 and decompilation104 are regulated. The reason is
obvious. Copyright protects the expression of the computer program,
the code. Reproduction of the code is essential for the program to
function. However, the underlying principles of the program, the ideas,
fall out of the scope of copyright protection. For this reason,
observation, studying and testing of the functioning of a program is
allowed to a lawful user.
Nevertheless, if patent law needs to provide a limitation over the
same acts, would this not mean that functions contained in the code of
the program are given patent protection? Would this not be a tacit
admission that computer programs “as such” could be within the scope
of the patent? There is no need to provide a limitation over something
that is already excluded of patent protection. Second, what happens
with the acts and the use of information obtained through
decompilation? In the copyright case, interoperability information
discovered after decompilation can only be used for the creation of an
independent program, which interoperates with the one decompiled.
How Article 6 Computer Program Directive could be applied in the
field of patent law is uncertain. What seems clear is that decompilation
as such constitutes an infringement of the exclusive rights of
reproduction and adaptation of the computer program (thus the
copyright limitation), but in any case, decompilation of a computer
program as such could constitute patent infringement. Therefore, how
Article 27(k) UPC Agreement would apply to patent cases is extremely
difficult to say. If it were merely meant to preserve and shelter the
existing copyright limitations, it would seem redundant. If not, it gives
more reasons for concern as it would constitute a limitation which scope
102 Agreement on a Unified Patent Court, OJ C 175, 20.6.2013, p. 1–40.
103 Article 5 (3) Computer Program Directive.
104 Article 6 Computer Program Directive.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
27
is decidedly unclear. On top of that, both possibilities bring a field of
more potential national law fragmentation, decreasing the level of legal
certainty.
Notwithstanding the fact that terms and conditions to access APIs
are more often found in separate contractual annexes to software
licenses, seems to suggest that protection of APIs under copyright or
patent law is less and less reliable.
Without legal intervention, APIs specifications and API
implementations need no disclosure and access to them needs to be
requested on a contractual basis. APIs can be ‘open’ or ‘restricted’. In
the case of truly “open” API, any third party at any point, under any
circumstances, is able to invoke it and the owner will strive to fulfil the
request. APIs are often authenticated and typically limited both
technically (amount of data transmitted) and through usage policies.
Thus, no personal data or security breaches would be made available
through an open API. Public-facing APIs are often documented
exhaustively, as their primary added value for the system´s owner is in
empowering third parties to deliver benefit to the platform by extension
as it might encourage adoption.105 This is not the case with restricted
APIs, where the figure of trade secrets applies for the best candidate of
APIs appropriation. Even if the European Trade Secrets Directive
(TSD) is a new legal instrument, with very recent implementations by
most Member States.106 The definition of a trade secret provided by the
TSD repeats the wording of Art. 39(2) TRIPS Agreement.107 The
protection of APIs specifications and implementations as trade secrets
is a matter of fact.
From the perspective of a third party, there is normally no
limitation on the use of the trade secret once lawfully attained and it is
not feasible to differentiate between acquisition and use.108 However,
the TSD is even more restrictive than the decompilation exception of
105 Chris Riley, Unpacking interoperability in competition, Journal of Cyber Policy,
5:1 (2020), 99.
106 At the EU level, the trade secrets civil legal protection was harmonised for the first
time by the Directive 2016/943/EU on the protection of undisclosed know-how and
business information (trade secrets) against their unlawful acquisition of the 8th
June.2016.
107 Article 2(1) TSD: “‘trade secret’ means information which meets all of the
following requirements: (a) it is secret in the sense that it is not, as a body or in the
precise configuration and assembly of its components, generally known among or
readily accessible to persons within the circles that normally deal with the kind of
information in question; (b) it has commercial value because it is secret; (c) it has been
subject to reasonable steps under the circumstances, by the person lawfully in control
of the information, to keep it secret”.
108 Roland Knaak et al, “Comment on the Max Planck Institute for Innovation and
Competition on the Proposal for a Directive on the Protection of Undisclosed Know-
How and Business Information (Trade Secrets) Against Their Unlawful Acquisition,
Use and Disclosure” IIC 45(8) (2014) 953, 961.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
28
the Computer Programs Directive. It allows reverse engineering109
where the acquirer is free from any legally valid duty to limit the
acquisition of the trade secret.110 The question is whether the
restrictions on the use of information achieved via decompilation,
imposed by Article 6 of the Computer Programs Directive could
amount to a “legally valid duty” and this would take reverse engineering
of a computer program to find its APIs out of the scope of Article 3
TSD. The novelty of the Directive and the actual absence of case law
causes uncertainty on this point.
Appropriation of APIs, due to network effects and switching
costs, that acting together can cause market monopolization and thus
consumer welfare loss, including spurring excessive marketing costs,
increasing prices for consumers and increasing barriers to further
innovation. On the other hand, one could consider that foreclosing API
documentation may unlock downstream innovation and can seed the
growth of competitors, but the platform owns the only master key.
However, this argument is difficult to stand alone when potentially
facing disruptive innovation options.111 Restricted APIs clearly provide
one more opportunity for lock in. This brings us to the refusal to deal-
cases where the question of using the information for the facilitation of
vertical or horizontal interoperability becomes relevant for enabling
intra-brand or inter-brand competition.112 As already outlined above,
109 Article 3 (1) (b) of the TSD defines reverse engineering as observation, study,
disassembly or testing of a product or object.
110 Article 3 (1) (b): “1. The acquisition of a trade secret shall be considered lawful
when the trade secret is obtained by any of the following means: (b) observation,
study, disassembly or testing of a product or object that has been made available to
the public or that is lawfully in the possession of the acquirer of the information who
is free from any legally valid duty to limit the acquisition of the trade secret”.
111 On the role of market concentration and innovation see Kenneth J. Arrow,
‘Economic Welfare and the Allocation of Resources for Invention’ (1962) National
Bureau of Economic Research, ‘The Rate and Direction of Inventive Activity:
Economic and Social Factors’ 609, 620. Different opinions on this: Joseph
Schumpeter, Theorie der wirtschaftlichen Entwicklung (1912), 157 and Aghion and
Howitt, ‘A model of growth through creative destruction’ (1992), 60 (2),
Econometrica, 323. Joseph L. Bower and Clayton M. Christensen, “Disruptive
Technologies: Catching the Wave.” Harvard Business Review (1995)
<https://hbr.org/1995/01/disruptive-technologies-catching-the-wave>
(accessed 13.09.2020).
112 To ensure that their APIs are accessible, firms publish documentation outlining
how their API is designed, what kind of information third parties can access, the
manner in which they have to make the call to receive a reply, and the terms of use
for the API See, e.g.,Microsoft API and Reference Catalog, Microsoft Developer
Network, <https://docs.microsoft.com/en-us/previous-versions/iis/microsoft.web/mi
crosoft-api-and-reference-catalog> (accessed 13.09.2020); Google APIs Explorer,
Google, <https://developers.google.com/apis-explorer> (accessed 13.09.2020).
Sadly, this documentation “is notoriously neglected and often out of date or
incomplete, meaning the specifications that set forth purportedly permissible
interactions may be incorrect, while other technically possible interactions could be
undocumented. See Suzanne Van Arsdale and Cody Venzke, “Predatory Innovation
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
29
interoperability has always played a peculiar role in this kind of cases.
However, access to API information might not always be indispensable
when interoperability could be attained by other means, as the CJEU
has also ruled.113 Recently a refusal to deal case in Switzerland about
data interoperability information provides a new court practice for these
tensions between copyright and competition law.114 The decision
analyses the relationship of these two legal regimes with respect to
decompilation of data interfaces in the credit/debit card payment
transactions systems.115 The Swiss Court, in balancing the interests in
conflict, prefers a narrow interpretation of the scope of copyright while
prominence is given to fair competition. The Federal Court upholds that
the principles of the Swiss Cartel Act and the specific provisions of the
Copyright Act codifying the decompilation exception to computer
programs116 aim at the same objective, therefore the copyright holder
should support decompilation when it has pro-interoperability effects.
This seems to go even far beyond the Microsoft case.
in Software Markets”, Harv. J.L. & Tech. 29 (2015) 243, 263 citing Ian Sommerville,
Software Engineering (Addison-Wesley, 9th ed. 2011) 64. Documentation is often
low priority, so emergency fixes may be made and forgotten, leaving documentation
and code unaligned
Sommerville at 239.
113 Case T- T-751/15 Contact Software [2017] ECLI:EU:T:2017:602. The General
Court also upheld that Article 102 was not applicable because Contact Software’s
claimed need for direct access to interoperability information failed to satisfy the
indispensability requirement, as Contact Software’s customers could obtain the
interface information through a licensing process. However, what is interesting is the
assessment of the Court on the relevance of achieving interoperability as to fulfil the
indispensability requirement. The Court found that other PDM software vendors
(competing with Contact Software) had stated that even without the interface
information for CAD software products, they nonetheless reached an interoperability
degree of 8/10. The GC agreed with the Commission that this demonstrated that the
interface information was not indispensable for Contact Software to compete on the
PDM software market.
114 Bundesverwaltungsgericht, B-831/2011, decision of 18 December 2018,
<https://www.bvger.ch/bvger/de/home/medien/medienmitteilungen-archiv-2002---
2016/medienmitteilungen-2019/sanktion-gegen-six-group-bestaetigt.html> (accessed
13.09.2020).
115 For a detail analysis of the decision see Rolf Weber, “Data Interfaces: Tensions
between Copyright and Competition Law – A New Swiss Court Practice for an Old
Problem” GRUR Int. 69(2) (2020) 119-127.
116 Article 21 of the Swiss Copyright Act codifies a broader decompilation exception
than the one of the Computer Programs Directive: “Art. 21 Entschlüsselung von
Computerprogrammen (1) Wer das Recht hat, ein Computerprogramm zu
gebrauchen, darf sich die erforderlichen Informationen über Schnittstellen zu
unabhängig entwickelten Programmen durch Entschlüsselung des Programmcodes
beschaffen oder durch Drittpersonen beschaffen lassen. (2)Die durch
Entschlüsselung des Programmcodes gewonnenen Schnittstelleninformationen
dürfen nur zur Entwicklung, Wartung sowie zum Gebrauch von interoperablen
Computerprogrammen verwendet werden, soweit dadurch weder die normale
Auswertung des Programms noch die rechtmäßigen Interessen der Rechtsinhaber und
-inhaberinnen unzumutbar beeinträchtigt werden”.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
30
In any case it should be borne in mind that the usefulness of APIs
as enablers of interoperability for the firm depends on how to balance
the dichotomy of modularity design and access control. This assessment
should duly reflect on the fundamental freedom of any firm to freely
conduct their business.117
On a more radical approach, some have proposed the mandatory
opening of APIs in order to reap off the entire potential of data driven
innovation, completely negating potential utilitarian incentive
considerations with regard to the exclusivity and/or excludability of the
information in order to safeguard investment protection of firms118.
Therefore, parallel to considerations mentioned above, proposals for
mandating the openness of APIs should be taken with due caution.
Furthermore, API adoption is endogenous and according to recent
policy reports, is still relatively new for most organizations, with more
than half of the organizations only starting to create APIs in the last five
years.119 As shown previously, the web API design styles used by the
industry indicate that they are taking steps toward more data
standardization, and this is supported by the increased adoption of the
OpenAPI specification120, a broadly adopted industry standard for
describing APIs created by a consortium of industry experts.121 Yet, this
will bring interoperability through standardization considerations to the
table, with its benefits and costs.122 Furthermore, there are also aspects
of API standardization such as data format standardization and
semantic similarity of data that becomes relevant in this context and
which are not sufficiently addressed.
Additionally, APIs come normally with a license contract that
enshrines the terms and conditions under which access to the API, to
the interface specifications and further additions can be used by
developers. From a legal perspective, the legal framework pertaining
the licensing contract is thereby relevant and also needs reflection.
Lastly, from a competition economics perspective, another issue
needs further reflection. The current context of competition law practice
builds on the assessment of legal contracts governing prices and terms
117 Article 16, 6 CFR. .
118 Oscar Borgogno, Giuseppe Colangelo, “Data sharing and interoperability:
Fostering innovation and competition through APIs”, Computer Law & Security
Review 35(5) (2019) https://doi.org/10.1016/j.clsr.2019.03.008.
119 Smartbear, “The State of API Report “(2020)
<https://static0.smartbear.co/smartbearbrand/media/pdf/smartbear_state_of_api_202
0.pdf> (accessed 13.03.2020).
120 In 2020 OpenAPI continues as a dominant API standard, with a dramatic growth
for GraphQL as preferred design approach. See (Smartbear, “The State of API Report
“(2020)
<https://static0.smartbear.co/smartbearbrand/media/pdf/smartbear_state_of_api_202
0.pdf> (accessed 13.03.2020).
121 It has an open governance structure under the Linux Foundation.
122 Cf. Wolfgang Kerber, Heike Schweitzer, “Data Interoperability in the Digital
Economy” (2017), JIPITEC 8 (1), 6
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
31
of deals between undertakings. Highly trained lawyers and judges
understand the relevant nuances and can compare them to existing
precedents. Yet, determining whether a change to the permissions and
usage policies of an API constitutes a thoughtful response to a
legitimate security concern, or an anticompetitive act designed to
foreclose a competitor, is a different challenge. For instance, assessing
whether standardized APIs, working as plug-and-play could
inadvertently allow the API provider to get access to additional
information from the party invoking the API. This could have adverse
effects on competition. As this however ultimately depends on the
technology itself, more research is needed.
E. Fostering re-usability of data with a normative
interoperability approach
Interoperability has been a subject of vivid scholarly debate since the
end of the 1980ies.123 It again gained track in the current policy debate
concerning the right legal framework for a data driven economy.124 The
digital package published by the European Commission last February,
includes three strategic documents and in all of them, interoperability
is mentioned as one of the key aspects.125
A year earlier, the European Commission released an Expert
Report entitled “Competition policy for the digital era.”126 The report
used the word ‘interoperability’ 105 times and defined three separate
types of interoperability for purposes of understanding competition in
the digital economy: “protocol interoperability”, “data
interoperability”, and “full protocol interoperability”. The interim
report on digital advertising by the United Kingdom’s Competition and
Markets Authority (CMA) added another term: “content
interoperability.”127
123 See Frank Eliassen, and Jari Veijalainen, “A Functional Approach to Information
System Interoperability”, in Rolf Speth (ed.)Proceedings EUTECO 88 Vienna (1988)
1121-1135.
124 It should be borne in mind that interoperability also applies to hardware,
networking protocols and many other pieces of the information and communications
technology stack. However, the greatest focus in current policy debates is on the
software side, on the one hand looking at the services internet-connected layer, apps
and social networks and the World Wide Web. On the other hand, as data sharing
enabler.
125 European Commission, Shaping Europe's digital future, Communication (2020)
COM(2020) 67 final, A European Data Strategy, Communication (2020) COM (2020)
66 final, and White Paper on Artificial Intelligence Communication (2020)
COM(2020) 65 final.
126 Crémer (n. 6).
127 Competition and Markets Authority (CMA) “Online Platforms And Digital
Advertising, Market Study Interim Report” (2019)
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
32
Interoperability has been often used as buzzword and proclaimed
as ‘Holy Grail’ for reaping off the expected welfare enhancing effects
of increased data use. Yet, it is also commonly acknowledged that a
lack of interoperability and certain bundling strategies of firms may also
have certain welfare enhancing effects.128 It also has to be noted that
too much interoperability may have hidden costs and challenges for
society that need to be thoroughly assessed and addressed.
As already outlined above, one of the broadest and fastest
evolving discussions brought by the emerging data economy is the need
for more data interoperability.129 It can be found throughout the current
policy discussions and legislative proposals about facilitating access to
data either directly via competition law130 and sector-specific data
access regimes131 or indirectly through improving data portability.132
Moreover, the introduction of new consumer data rights, introducing
portability rights for consumers - potentially also relating to industrial
non-personal data - addresses the issue.133 Even in solutions related to
<https://assets.publishing.service.gov.uk/media/5dfa0580ed915d0933009761/Interi
m_report.pdf>; (accessed 13.09.2020).
128 Wolfgang Kerber, Heike Schweitzer, ‘Data Interoperability in the Digital
Economy’ (2017), JIPITEC 8 (1).
129 Ibid.
130 See for competition policy Heike Schweitzer, (n. 87); Jacques Crémer, (n. 6);
Philip Marsden (n. 6); Monopolkommission, “Control of abusive practices in the
digital platform economy” in Biennial Report XXIII (2020).
131 The sectors with already existent data access regulations in place are the
automotive, intelligent transport systems, gas metering and electricity sector.
Commission Regulation (EC) 715/2007 [2007] OJ L171/1 as amended Regulation
(EU) 595/2009 [2009] of 18 June 2009 on type-approval of motor vehicles and
engines with respect to emissions from heavy duty vehicles (Euro VI) and on access
to vehicle repair and maintenance information and amending Regulation (EC) No
715/2007 and Directive 2007/46/EC and repealing Directives 80/1269/EEC,
2005/55/EC and 2005/78/EC OJ L 188/1, smart metering information – Directive
(EU) 2009/73 of 13 July 2009 concerning common rules for the internal market in
natural gas and repealing Directive 2003/55/EC [2009] OJ L211/94, electricity
network data – Directive (EU) 2019/944 on common rules for the internal market for
electricity and amending Directive 2012(27/27/EU [2019] OJ L158/125 or electricity
transmission – Commission Regulation (EU) 2017/1485 of 2 August 2017
establishing a guideline on electricity transmission system operation[2017] OJ
L220/1, intelligent transport systems – Commission Regulation (EU)2015/703 of 30
April 2015 establishing a network code on interoperability and data exchange rules
[2015] OJ L 113/13.
132 On the regulatory shortcomings of the data portability right of the GDPR see
Article 29 Data Protection Working Party, ‘Guidelines on the Right to Data Portability
as last revised and adopted on 5 April 2017’ (16 EN, WP 242 rev.01); Commission,
COM(2020) 66 final (n. 1) 10, 21; Inge Graef, Martin Husovec and Nicola Purtova,
'Data Portability and Data Control: Lessons for an Emerging Concept in EU Law'
(2018) 19 German Law Journal 1356; Jacques Krämer, P Senellart and Alexandre de
Streel, ‘Making Data Portability more effective for the Digital Economy’ (2020)
CERRE report June 2020.
133 The concept of consumer data is strongly influenced by current regulatory
endeavours in Australia, under which sector-specific access rights are defined parallel
to horizontal regulatory approaches. See on the current discussion OECD, ‘Consumer
Data Rights and Competition - Background Note’ (2020) DAF/COMP(2020) 1.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
33
unfair commercial practices laws134, especially in cases of unequal
bargaining power between the data claimant and the data holder, i.e. the
refusal to grant access to certain data sets may tantamount to unfair
commercial practices, data interoperability needs to be considered.
Despite the ongoing and ever-growing discussion on creating
(more) mandatory access and portability rights however, it is crucial to
broaden the perspective from merely outlining the obligation to grant
access to data. Even though the rights of others to access data or get
their data ported correlate with the obligations of data-holders, merely
outlining rights without clearly defining the scope of the right and
performance needed simply renders any data access regime insufficient.
Therefore, mandatory access alone might not be sufficient for solving
the current issues that arise with regard to the actual impediments of
innovation and competition enabling function of increased data sharing.
This can be seen in already existent data portability and access regimes
and in the current debate pertaining digital services of platforms.
Taking the portability right under Article 20 (2), (1) GDPR as an
example. There is a broad consensus that so far, the portability right
does not lead to efficient solutions. The outlining of the right’s scope is
already unclear and too short-sighted and it also insufficiently addresses
large technical and other feasibility problems. Admittedly, it may be
argued that Article 20 GDPR should not establish high regulatory entry
barriers and may thus be a good first step towards breaking up consumer
lock-ins. Yet, it also has to be kept in mind that the data portability right
due to a lack of clearly outlining the modalities of the portability right
simply creates too high transaction costs for consumers. Although it
seems to be a common understanding that the data portability right
encompasses neither the right for the portability of data in real-time nor
does it entail interoperability requirements135 for enabling the technical
feasibility of data portability, the wording is simply not clear. Although
Recital 68 refers to ‘structured, commonly used, machine-readable and
interoperable format(s)’ one should bear in mind that recitals are not
binding. It is therefore not surprising that the discussion is shifting to
the question of how this data portability right in the GDPR can be
improved in terms of efficiency.136
134 Josef Drexl, ‘Designing Competitive Markets for Industrial Data – Between
Propertisation and Access’ (2017) JIPITEC 8 (4), 62,63.
135 The differences between data portability and data interoperability become clear
when thinking about how competition emerges in practice. In particular, data
portability does not port networks, only the personal data of the subject. Even if the
user of a social network can port their “social graph” of connections to a competing
service, one user only can’t force all of his or her connections to also switch services.
Data interoperability, with its real-time functionality, would overcome that gap by
allowing users to send messages through the first and second platforms.
136 See for the discussion about the data portability right of the GDPR Article 29 Data
Protection Working Party, ‘Guidelines on the Right to Data Portability as last revised
and adopted on 5 April 2017’ (16 EN, WP 242 rev.01); Commission, COM(2020) 66
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
34
Another way interoperability finds the way in the legal sphere is
via the scope of the access right itself. Such a right could entail certain
technical interoperability obligations that data holders need to comply
with in order to perform their access obligation. In the case of vehicle
repair and maintenance information (RMI) for instance, the CJEU
already ruled that the obligation to provide standardized access to RMI
in a standardized format does not entail the obligation for car
manufacturers to provide the information in amenable form to onward
electronic processing.137 The provided read-only access meets the
requirement of ‘unrestricted access in the form of a standardised
format’ outlined in Article 6 (1) Regulation (EC) No. 715/2007. The
Court’s interpretation of the access obligation enshrined in
Article 6 (1) Regulation (EC) No. 715/2007 has impact in the aftersales
services markets. Access to processable information is indispensable
for independent suppliers of aftersales services. Without access to
processable information on all components used by a manufacturer -
containing for each spare part of the manufacturer the part number of
their own compatible spare part - independent parts manufacturer can
hardly provide repairers with alternative spare parts. On the case at
hand, the provided access on the interface of the website displayed
authorised original spare parts dealers only. This may eventually not
only avoid market entry by independent spare part manufacturers, but
independent repairers alike. This may also increase maintenance costs
for consumers.138 The narrow interpretation enables vehicle
manufacturers to capture the spare parts hardware markets.139
Furthermore, data interoperability could become a legal tool for
enabling data access in the realm of current digital platforms’ debate.
There seems to be a broad consensus among governmental140 and
final (n. 1) 10, 21. For a more recent discussions see Inge Graef, Martin Husovec and
Nicola Purtova, 'Data Portability and Data Control: Lessons for an Emerging Concept
in EU Law' (2018) 19 German Law Journal 1356; Jacques Krämer, Pierre Senellart
and Alexandre de Streel, ‘Making Data Portability more effective for the Digital
Economy’ (2020) CERRE report June 2020; Kommission Wettbewerbsrecht 4.0, ‘Ein
neuer Wettbewerbsrahmen für die Digitalwirtschaft’ (2019), 39-44.
137 Case- 527/18 Gesamtverband Autoteile eV v. Kia Motors [2018]
ECLI:EU:C:2019:762.
138 Bertin Martens, Frank Müller-Langer, Access to digital car data and competition
in aftersales services (2018) JRC Technical Reports, JRC Digital Economy Working
Paper 2018-06, 7.
139 See Wolfang Kerber and Daniel Gill, “Access to Data in Connected Cars and the
Recent Reform of the Motor Vehicle Type Approval Regulation” 10 (2019) JIPITEC
244 para 1.
140 Crémer (n. 6); Monopolkommission (n. 145); Secrétariat d’État Chargé de la
Transition Numérique et des Communications Électroniques, Ministy of Economic
Affairs and Climate Policy, “Consideration of France and the Netherlands regarding
intervention on platforms with a gatekeeper position” (2020) <https://www.privacy-
web.nl/cms/files/2020-10/non-paper-fra-nl-ex-ante-regulation-platforms-final-
1410.pdf> (accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
35
academic studies141 that the inclusion of asymmetrical interoperability
obligations for dominant platforms (gatekeepers) could help at
correcting market foreclosures and information asymmetries. This is
the approach followed by the European Commission in the Digital
Services Act package, as to ensure that gatekeepers’ platforms behave
fairly and can be challenged by new entrants and existing competitors,
so that consumers have the widest choice, fostering innovation and
competition.142
However, the existence of already outlined private data access
rights is not enough. A public law approach within the realm of a data
governance solution seems more favourable. This is because of a lack
of feasibility of enforcing the rights due to high transaction costs, legal
uncertainty, technical impediments and opposing exclusive rights of
others. Such governance solution could also entail a more consistent
solution to conflicting IP, database sui generis and trade secrets
protection in data, which is currently not thoroughly and clearly
assessed either. Such conflicts need a more holistic assessment of
overlapping exclusive rights and their re-usability options. As stated in
the previous section however, solutions should still mirror traditional
market failure considerations and need to align the different interests
implied. Therefore, data interoperability should be treated only as a
means to an end and not as an end in itself.
This holds particularly true as data standards and standardized
ways of communication have still not reached high market penetration.
The term data governance is already used as micro economic
(corporate) data management concept concerning the capability that
enables an organization to ensure that high data quality exists
throughout the complete lifecycle of the data, and data controls are
implemented that support business objectives.143 The key focus areas of
data governance include availability, usability, consistency, data
integrity and data security as well as establishing processes to ensure
effective data management throughout the organization such as
141 Ian Brown “Interoperability as a tool for competition regulation” (preprint 30 July,
2020) doi: 10.31228/osf.io/fbvxd; Furman (n. 6); Mardsen (n. 6); Stigler Report (n.
6).
142 European Commission, “The Digital Service Act Package” (2020)
<https://ec.europa.eu/digital-single-market/en/digital-services-act-package>
(accessed 13.09.2020); European Commission, “Digital Services Act package: Ex
ante regulatory instrument for large online platforms with significant network effects
acting as gate-keepers in the European Union’s internal market, Inception Impact
Assessment” Ref. Ares(2020)2877647 - 04/06/2020 (2020).
143 Vijay Khatri and Carol V. Brown, ‘Designing Data Governance’ (2010)
Communications of the ACM 53 (1), 148; Leo L. Pipino, Yang W. Lee and Richard
Y. Wang, ‘Data Quality Assessment’ (2002) Communications of the ACM 45 (4),
211-218; Craig Stedman and Jack Vaughan, ‘What is data governance and why does
it matter?’, online available at:
<https://searchdatamanagement.techtarget.com/definition/data-governance>
(accessed 13.09.2020).
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
36
accountability for the adverse effects of poor data quality; lastly,
ensuring that the data, which an organization has, can be used by the
entire organization. Data governance strategies are ideally already
incorporated at the organizational practices level. They contain a
quality control discipline for assessing, managing, using, improving,
monitoring, maintaining and protecting organizational information as a
proper management system of data. This will not only lead to an
increasing consistency and confidence in decision-making, it also
maximizes the income generation potential of data (including the
avoidance of data silos in different departments and business units, the
reduction of errors in data sets and misuse of data, the establishment of
a common understanding of data and the compliance with
regulations).144 Yet, even though data governance strategies might
already be incorporated on a micro-level in firms, a lack of data
interoperability on a horizontal level between firms due to fragmented
data standards and various proprietary APIs, leads to data silos and the
balkanization of data. Despite international standardization endeavours
and other private and hybrid initiatives, at firms’ organizational levels
data interoperability is insufficiently addressed. As previously
mentioned, semantic and syntactic interoperability work like magnetic
poles. However, there is still a significant fragmentation at such levels
and the communication via technical means, i.e. web-services, OBD
ports or APIs, has not achieved the envisioned ambition of making data
re-usable. This increases up-front investment in the efficient re-use of
the data and raises transactions costs to outweigh a lack of quality data.
This in the end may further minimize the incentives to share data. It is
to this end where the role of the legislature becomes essential.
As sneak peek, our analysis of horizontally applicable data access
regimes and of the sector-specific data access solutions shows the need
for an even more comprehensive regulatory approach towards data
governance solutions that also reflect the importance of potentially
regulating data interoperability and standardisation and addressing data
safety and security issues, for ensuring the effectiveness of data
governance solutions.145 Despite the existence of already outlined
private data access rights, a public law approach within the realm of a
data governance solution is exactly what seems favourable. This is
because of a lack of feasibility of enforcing the rights due to high
transaction costs, legal uncertainty, technical impediments and
opposing exclusive rights of others.
F. Conclusions
Demystifying the role data interoperability in the access and sharing
regimes is a Sisyphus work. Data interoperability is a complex technical
144 Ibid.
145 The analysis will be published soon, in a follow-up piece.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
37
issue, and thus another example of how important a good understanding
of the technology is. As data interoperability counts with different
levels and, as the market failures ought to build upon the ones from data
access regimes, it should reflect on the same considerations. This
however is currently hard to predict, as the discussion and the policy
with regard to data access seems to move towards data commons and
away from market force driven solutions that enable data driven
innovation. Establishing data interoperability is thereby one of the key
ambitions of the EU policy strategy. As data interoperability is also
inherently tangled to the data access right, courts may interpret data
interoperability in the realm of defining the scope of the access right.
Ultimately, data interoperability may also be subject to direct data
governance market regulation and thus subject to different regulatory
goals, e.g. cyber security, data protection, data sovereignty, competition
or data driven innovation.
The existence of multiple notions of interoperability may affect
its own interpretation in the context of data access rights as well as in
further delineating a data governance regulation. Therefore, from a
legal policy perspective, a common understanding of data
interoperability in the specific legal context is highly desirable. This
will help to clearly outline the scope of data interoperability and
therefore, would provide for a more coherent delineation of data access
regimes when interpreted by courts. This is particularly relevant with
regard to a harmonised Digital Single Market and the need of cross-
border data flows. It would eventually increase legal certainty and
predictability to private actors, thus fostering trust and probably
increasing data sharing practices. Additionally, one should always bear
in mind that interoperability, even if enshrined in the obligations
correlating to data access rights, is still not a legal right or obligation
(although it might become one soon). Using it as equivalent to data
portability might come at the risk of confusing both. In addition, as
explained earlier, it is still under debate what, if any, interoperability
requirements the right to data portability of the GDPR entails.
In fact, technology may already govern data access and data
sharing without legal intervention. If legal intervention takes place
however, it may not only affect the efficacy of the access right itself,
but also affect the effective enforcement of such right. Thus,
interoperability is about to become another example of Lessig’s “code
is law”. From this perspective, there is the threat of using
interoperability as a goal and not as a means to an end. Pre-designed
data interoperability by default is indeed a key enabler for data driven
innovation. This however comes with the caveat of adverse effects of a
too high level of data interoperability. This not only relate to negative
effects of data sharing itself – among others privacy or data induced
competition concerns. It also relates to a potential hampering of
innovation with regard to data and APIs.
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
38
Additionally, policy makers should bear in mind that APIs are one
of the enablers of data interoperability. APIs represent an endpoint
interface and are usually designed unilaterally. They are not a give-and-
take agreement and do not require full disclosure. Data standardization
is another data interoperability enabler, where the design of data
models, data formats and protocols require the agreement of the parties
involved, therefore, collaboration and disclosing of information is
required.
The EU Commission policy rightly foresees the role of the
legislature being one that refrains from fiat and focusses on more
flexible regulatory approaches. To this end, fostering the building of
hybrid decentralized and distributed infrastructural systems, based on
the development of data standards or fostering the standardization of
APIs might be a better option than just mandating the full disclosure of
APIs. Opening up of APIs as a default rule, without taking market
failure considerations into account, negates potential utilitarian
incentive considerations with regard to the exclusivity and/or
excludability of the information in order to safeguard investment
protection of firms.
Therefore, Member States initiatives such as Gaia-X or data trusts
seem to be a good example of how to achieve high levels of semantic
data interoperability (also increasing data quality) and increase data
sharing with the use of data standards. Hybrid forms of setting de facto
data standards may also have spill overs. Yet one should keep in mind
that not addressing the issue of data interoperability on a multi-lateral
level may have potential negative effects for international firms –
despite current claims for a digital sovereignty of the EU.
From a competition economics perspective, traditional
considerations with regard to vertical and horizontal interoperability
cases may be still applicable in data cases and thus, essential facility
considerations. There might be cases however, where the factual data
exclusivity (based on a lack of interoperability information disclosure)
makes the assessment of potential consumer welfare enhancing effects
extremely complicated. Yet, data may be used for multiple other
occasions that lack traditional market specific foreclosure scenarios.
Data interoperability is always a matter of degree and does not
necessarily lead to a market foreclosure of competitors.
As to the appropriation of APIs via IP rights and trade secrets,
technological advancements in machine-to-machine communication,
i.e. web services, have brought back to the table the need of re-assessing
the balance between IP rights and the enabling of free flow of data in a
data driven economy. Even if under utilitarian efficiency considerations
IP protection of APIs might be justified, the existing exceptions and
limitations are not good enough as they do not ensure a balance between
the protection of interests of right holders and third parties. For instance,
the decompilation exception is dysfunctional and impracticable. It
Hoffmann / Otero: Demystifying the role of data interoperability
Max Planck Institute for Innovation and Competition Research Paper No. 20-16
39
requires high up-front investments by the legitimate user without any
guarantee that it will work, that is, it does not really guarantee that
interoperability would be achieved. Additionally, it does not allow for
free re-usability of the results.
From a global perspective, the Google v. Oracle case needs
thorough attention. Copyrightability of APIs may indirectly affect the
competition policy in software dependent markets.
Based on all the above, it seems that there is need for a more
comprehensive regulatory approach towards data governance solutions
that also reflect the importance of potentially regulating data
interoperability and standardisation and addressing data safety and
security issues, for ensuring the effectiveness of data governance
solutions.
These (sector-specific) data governance solutions are favourable
as they also have the potential to holistically address the different IP
and trade secret protection regimes, e.g. Open Data Directive and
database protection. It will also need to reflect on IPRs over means of
communications, i.e. APIs, OBD ports, web-services.
Therefore, despite the existence of some private data access
rights, a public law approach within the realm of a data governance
solution seems favourable. This is because of a lack of feasibility of
enforcing the rights due to high transaction costs, legal uncertainty,
technical impediments and opposing exclusive rights of others. Within
such data governance solution, conflicts of law and overlapping
exclusive rights could be better addressed and aligned. This may
provide for more practical, balanced solutions than adapting
dysfunctional existing exceptions and limitations in IP and trade secrets
regimes. Further elaboration on these solutions and policy
recommendations are part of the follow-on study we have conducted,
and that will soon be published.
