1

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.

2

Additionally, future data marketplaces could also act as data normalizers and define standard data models and formats for all the traded data.

3

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.

4

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.

5

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.

6

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.

7

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.

8

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.

9

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.

10

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.

11

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.

35

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.

36

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.

37

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]

38

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]

39

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 10^th 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]

40

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]

41

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]

42

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]

43

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]

44

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.

45

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.

46

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]

47

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]

48

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.

49

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.

50

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

51

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.

52

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.

53

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.

54

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.

55

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.

56

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.

57

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]

58

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.

59

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.

60

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.

61

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]

62

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]

63

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.

64

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.

65

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.

66

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]

67

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]

68

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]

69

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.

70

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.

71

72

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.

73

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.

74

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.

75

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.

76

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.

77

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.

78

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.

79

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.

80

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.

81

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.

82

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.

83

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.

84

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