Document Actions


Demystifying The Role Of Data Dnteroperability In The Access And Sharing Debate

  1. Jörg Hoffmann
  2. Dr. Begoña Otero


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 is 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 what extent could IPRs and trade secret protection 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 favorable. Such a 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.


1. 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 key impediment. A couple of years ago, the International Data Corporation’s report distinguished three main paths followed to solve the lack of data interoperability [1]: 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 end 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 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 those 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 studies [6] have found violations of antitrust [7], consumer protection and privacy law. These are motivated by certain characteristics of digital platforms, namely, network externalities, economies of scope and their inherent advantages such as 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. A 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, the idea of imposing data sharing obligations for platforms is currently being discussed. To this end, a good example of how to address the interoperability provision would be the imposition of ex ante rules of 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 a 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-X [8], 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 raises fundamental questions regarding the proper functioning of exclusive rights. To what extent could IPRs and trade secret protection 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] Analyzing 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 sharing debate, but would involve further considerations on data protection law, cybersecurity, liability and cross border enforcement that are beyond 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 engaged 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 interoperability [12], 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 existing 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 realization 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.

2. Clarifying terms: Interoperability and its enablers, data standardization and APIs

2.1. 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 tangled, the use of one or another definition of interoperability might affect 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]


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 applicable [18]; 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 number of definitions shows that there is no one-size fits-all definition of interoperability [24], 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 different systems, products, or services. 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 systems [26], 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 traction 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 overly 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 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]

2.2. 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. 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 within 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 API [35] 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. Not any data server 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 for 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 further incentivizes data sharing. [37] Potential reuse of an already existing technical solution together with less data interoperability conflicts. However, semantic interoperability, seems to not be sufficiently addressed in the current regulatory framework of data governance regimes.

2.3. Enablers of data interoperability


The main technical enablers to achieve syntactic and semantic interoperability are the following: 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 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 of 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 about the rapid development and adoption of a technology referred to as web services. Web services stands as a key technology in terms of 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 has 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 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 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 as restricted as a web service is.


Maybe that is the reason why a majority of firms providing web services have decided to unilaterally design 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 adhering to the SOAP specification [52] 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 than centralized ones due to their complexity. [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 Railway [57], the use of “REST” APIs [58] by several municipal public transport providers [59], the “RESTful” API of UBER [60] are examples. In the last two years, another design approach is increasingly being adopted by firms and developers. Instead of using a data protocol or a set of design principles, GraphQL is an open-source data 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, by which their 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 the principle of any of these designs 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.

3. 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 up 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 also has a central role in online markets. Value creation is reinforced through a recursive data capture and data 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 in defining the future we would live in. It is thus of utmost importance that the EC pursues a strategic maneuver 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 considerations, this may also create the ability for undertakings to enter into strategic market foreclosing behavior 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 centralized coordination in the sense of a centrally planned economy. The legal foundation of markets consists in the freedom-of-contract principle, which is safeguarded by competition law. [70] Decentralized decision making between the parties of the contract is to be favored because individual economic preferences of numerous economic agents would be outvoted in a centralized 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 systemically blocking access to data, this does neither mean that this conduct tantamount to an exploitative abuse case nor does it mean that any market operator is anti-competitively 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 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, could 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]


Despite potential lack 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 recognized 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 the advantages of data sharing without causing other negative externalities – particularly privacy and data security related – a broader regulatory approach is necessary. Thereby the transaction costs should also be explicitly considered and thus a public law approach dealing with non-waivable data interoperability obligations may be the favorable way forward. [85]


For instance, what the majority of 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 have led to the rise of key online gatekeepers with the potential to foreclose 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 out that digital markets have a tendency towards “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 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 excessive data sharing. Indeed, the negative externalities that come with 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.

4. 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 options and will need to make trade-off decisions. To maximize the likelihood of an API project succeeding and minimize 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 interoperability [91], the question of protection of APIs as independent works of copyright remains unsettled. As some have rightly pointed out, while data and user interfaces are substantially different from APIs, the interpretation made by the CJEU would appear to offer ground in terms of 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]


Furthermore, web services can be considered a computer program that happens to also be 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 decompilation [95] performed to achieve interoperability. However, the Directive falls short of 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] An additional problem is that for interoperability to take place, the third party 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 exclusion [100] is the narrow window through which software developers try to push their products to obtain a patent. Traditional APIs, which are part of a 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 also be 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 interoperability, would not be covered by the scope patent. Conversely, API specifications would not be part of the patent application, nor will they 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 analysis [103] and decompilation [104] 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 of which scope 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 the 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 the Computer Programs Directive. It allows reverse engineering [109] 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 triggers 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, interoperability has always played a peculiar role in this kind of case. 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 programs [116] 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 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 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 firms [118]. 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 specification [120], 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 become relevant in this context and which are not sufficiently addressed.


Additionally, APIs normally come 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 requires 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 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 anti-competitive 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.

5. Fostering re-usability of data with a normative interoperability approach


Interoperability has been a subject of vivid scholarly debate since the end of the 1980s. [123] It again gained traction 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]


Interoperability has often been used as buzzword and proclaimed as a ‘Holy Grail’ for benefiting from 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 regarding facilitating access to data either directly via competition law [130] and sector-specific data access regimes [131] 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 unfair commercial practices laws [134] – 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 be 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 requirements [135] 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]


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 an impact on 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 manufacturers can hardly provide repairers with alternative spare parts. On the case at hand, the provided access on the interface of the website displayed authorized 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 the digital platforms debate. There seems to be a broad consensus among governmental [140] and academic studies [141] that the inclusion of asymmetrical interoperability obligations for dominant platforms (gatekeepers) could help to correct 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 favorable. 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 a 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 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 endeavors 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 standardization 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.

6. Conclusions


Demystifying the role of data interoperability in the access and sharing regimes is a Sisyphus work. Data interoperability is a complex technical 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 harmonized 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 high level of data interoperability. This not only relates 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.


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 multilateral 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 still be 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 the 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 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 standardization and addressing data safety and security issues, for ensuring the effectiveness of data governance solutions.


These (sector-specific) data governance solutions are favorable 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 favorable. 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 a 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, which will soon be published.

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.

*by Jörg Hoffmann and Begoña Gonzalez Otero, Max Planck Institute for Innovation and Competition, Munich

[1] IDC, “Technical Barriers to Data Sharing in Europe” (January 2017) < > (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) < > (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) < > (accessed 13.09.2020).

[4] European Commission, “Public Consultation on the Regulatory Environment for Platforms, Online Intermediaries, Data and Cloud Computing and the Collaborative Economy” (2015) <> (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) <,myriad%20other%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) < >; (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] On 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. < > (accessed 13.09.2020).

[8] Gaia-X: A Federated Data Infrastructure for Europe, < > (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.

[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).

[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)” < > (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) < > (accessed 13.09.2020).

[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: <>; 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 < >; (accessed 13.09.2020).

[24] John Palfrey and Urs Gasser, Interop: The Promise and Perils of Highly Interconnected Systems, Basic Books (2012) Introduction.

[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 out 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) < > (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) < > (accessed 13.09.2020).

[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 anti-consumeristic behavior. See: Mastrolonardo, Raffaele. "Net neutrality could become law in Italy - unless internet users would rather opt out", ZDNet < > (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) < > (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) < > (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: (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.

[33] Ibid.

[34] W3C, “W3C Semantic Integration & Interoperability Using RDF and OWL” (2001) , (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, < > (accessed 13.09.2020).

[37] See 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: (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. < > (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: (accessed 13.09.2020).

[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),<> (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 <> (accessed 13.09.2020).

[44] See < > (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) < > (accessed 13.09.2020).

[46] GoogleSearch API is another example of Web services.

[47] Marshall Breeding, “Introduction to Web Services” Library Technology Reports (2006) < > (accessed 13.09.2020).

[49] See (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: .

[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 <,depending%20on%20whether%20it%20exists .> (accessed 13.09.2020).

[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 (last accessed 12.08.20).

[53] For a comparison between centralized, decentralized and distributed systems see: < > (accessed 13.09.2020). On the relationship between federation, distribution and decentralization, see: Gaia-X: Technical Architecture (2020) 23 < > (accessed 13.09.2020).

[54] For differences between SOAP and REST see: < > (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. < > and < > (accessed 13.09.2020).

[58] REST stands for representational state transfer.

[59] Ably Hub, “The maturity of public transport APIs 2019” (2019). Available at: . (Accessed …).

[60] See: (Accessed…).

[61] It was built by Facebook and recently moved to the GraphQL Foundation, hosted by the Linux Foundation. For more details see: < > (accessed 13.09.2020).

[62] Seth G. Benzell, et al. „The Paradox of Openness: Exposure vs. Efficiency of APIs” < > (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

[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, < > (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, < > (accessed 13.09.2020).

[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. Cf.

[74] European Commission, “The Digital Service Act Package” (2020) < > (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 < >, and English version can be consulted at < > (accessed 13.09.2020).

[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 <> (accessed 13.09.2020).

[81] Elinor Ostrom, Die Verfassung der Allmende (1999). Even there, one has to assess that efficient cooperation 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, <> (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.

[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.

[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: . 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, , (accessed 13.09.2020).

[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 of 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 Otero Interoperabilidad, Internet de las Cosas y Derecho de autor (Reus, 2019) 232.

[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).

[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.

[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.

[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) < > (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, < > (accessed 13.09.2020); Google APIs Explorer, Google, <> (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 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.

[115] For a detailed 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”.

[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) .

[119] Smartbear, “The State of API Report “(2020) < > (accessed 13.09.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) < > (accessed 13.09.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.

[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 a 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) < >; (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.

[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 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) < > (accessed 13.09.2020).

[141] Ian Brown “Interoperability as a tool for competition regulation” (preprint 30 July, 2020) doi: 10.31228/ ; Furman (n. 6); Mardsen (n. 6); Stigler Report (n. 6).

[142] European Commission, “The Digital Service Act Package” (2020) < > (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: <> ( accessed 13.09.2020).

[144] Ibid.

[145] The analysis will be published soon, in a follow-up piece.



Any party may pass on this Work by electronic means and make it available for download under the terms and conditions of the Digital Peer Publishing License. The text of the license may be accessed and retrieved at

JIPITEC – Journal of Intellectual Property, Information Technology and E-Commerce Law
Article search
Extended article search
Subscribe to our newsletter
Follow Us