2. Interoperability information: technical definitions and law & economics simplifications ... 28 2.1. Access to interoperability information ... 29 2.1.1. Software reverse engineering (decompilation)... 31 3. API specification versus implementation... 36 3.1. Decisions of the European Commission adopting the specification/implementation dichotomy .. 38 3.2. Implementation v. specification: some more hints from US case law ... 40 3.2.1. E.F. Johnson Co. v. Uniden Corp... 40 3.2.2. CMAX/Cleveland v. UCR ... 41 3.2.3. How to distinguish between copying ideas and expressions?... 42 4. Investigating the legal status of interoperability information: US case law and doctrines... 44 4.1. The protection against copying of non-literal elements... 44 4.1.1. The Whelan or “look and feel” test ... 44 4.1.2. Adoption of the “three-step test” of Computer Associates v. Altai... 45 4.2. Merger doctrine... 46 4.3. Scenes à faire doctrine ... 48 4.4. Fair use ... 49 4.4.1. Risks in applying fair use to determine the legal status of interoperability information ... 49 4.4.2. Decomposing the access phase and the re-implementation phase... 51 5. Investigating the legal status of interoperability information: the European setting... 53 5.1. European doctrines allowing literal copying... 56 5.2. According to the commission, several APIs are not innovative in themselves ... 57 6. A Japanese perspective... 58 7. Vertical and horizontal access; transformative and substitutive uses... 59 8. Elimination of free riding vs. the creation of economic monopoly ... 63 8.1. The limits of technology copyright and its natural antibodies ... 66 9. Further dimensions ... 68 9.1. Contractual arrangements... 68 9.1.1. Licenses and copyright misuse... 69 9.1.2. Copyright and patent preemption of restrictions on reverse engineering... 70 9.2. May patent law (as currently applied to software) limit interoperability?... 71 9.2.1. If patent can be used to hinder interoperability, is it a good idea to do so? ... 74 9.3. A possible economic criticism (IP as a tool enabling desirable business models) ... 77 10. Conclusions... 78 11. Main open problems (left for the second and third papers)... 80 11.1. Limitations on access and decompilation – Second paper... 80 11.2. Interoperability and competition policy – Third paper ... 81
1. Introduction
In the field of software, the term interoperability describes the capability of different programs to exchange data, to read and write the same file formats, and to require services from one another.1 Loosely
speaking, interoperability is a synonym of compatibility.2 Software interoperability is at the core of several
recent antitrust cases and policy debates. In the field of competition policy, the European Microsoft case (Microsoft IV),3 concerning the disclosure of information necessary to achieve interoperability among client
and server computers,4 is worth mentioning. Similarly popularized by mass media (as a war between Apple’s
iTunes and the French Parliament) is the discussion concerning interoperability between digital rights management (DRM) technologies, leading to the adoption of specific regulations in France5 and fostering
much debate in other countries.6
The interest concerning interoperability information comes from the fact that controlling interfaces among different pieces of software (and/or hardware) is strategically crucial. And this strategic relevance originates from technological and economic phenomena, in particular from the modular nature of software programs and various kinds of network effects.7 In the US v. Microsoft (Microsoft III),8 the US Department of
Justice (DoJ) summarized this point in a very effective way, quoting a Microsoft executive’s statement: “to control the APIs [Application Programming Interfaces]9 is to control the industry”.10 I will come back on the
definition of APIs and other kinds of interoperability information (see § 2); the point of the DoJ, however, is clear: being able to decide which programs are compatible with a crucial platform such as Windows, and to what extent, gives the possibility of dominating the entire software industry. Moreover, it can be argued that “owning” interoperability information is a way of controlling even more than the software industry, since this control could lead to significant influence in several other fields, from information and communication technology in general, to the whole content industry.11 Nevertheless, because of several sound reasons,12
antitrust authorities and legislators have usually adopted an agnostic attitude with respect to the actual legal status of information needed in order to achieve interoperability.
1 The Digital Millennium Copyright Act 1998 (or “DMCA”), s.1201 (f) (4), defines interoperability as “the ability of computer
programs to exchange information, and of such programs mutually to use the information, which has been exchanged”. This definition has been borrowed, almost word by word, from the one provided by Recitals 10-12 of the Council Directive 91/250/EEC of 14 May 1991 on the legal protection of computer programs (hereinafter, Software Directive). Recital 11: “interoperability can be defined as the ability to exchange information and mutually to use the information which has been exchanged”.
2 See below, § 2, for more rigorous definitions.
3 With Microsoft IV I refer to the Case COMP/C-3/37.792 Microsoft, that led to the Commission Decision of 24.03.2004 relating to a proceeding under Article 82 of the EC Treaty. The European Court of First Instance delivered its judgement on Microsoft’s Appeal on
the 17th of September 2007, substantially confirming the approach of the Commission (apart from some minor issues related to
the Trustee established to monitor Microsoft’s compliance). I refer to this ruling as Microsoft CFI.
4 Actually, among operating systems (OSs) running on these computers, in particular when the servers are operated by non-
Microsoft branded OSs.
5 Chapitre IV (Mesures techniques de protection et d’information) of the LOI n° 2006-961 du 1er août 2006 relative au droit d’auteur et aux droits voisins dans la société de l’information (modifying the French code de la propriété intellectuelle).
6 In Italy, for instance, see the proposal of reform of the Author’s Right Law (Legge 22 aprile 1941, n. 633). 7 See General Introduction to this dissertation project, § 2.2.
8 With Microsoft III or Microsoft US case I refer to the famous US antitrust case, which risked leading to the dismembering of
Microsoft, following J. Jackson’s ruling 87 F.Supp.2d 30 (D.D.C., 2000). In appeal, the case was vacated and remanded, with ruling 253 F.3d 34 (C.A.D.C., 2001). The case has been ended by the Consent Decree ratified by J. Kollar-Kotelly, with ruling 231 F.Supp.2d 144 (D.D.C., 2002). Consider also that with J. Jackson’s findings of fact I refer to ruling 84 F.Supp.2d (D.D.C., 1999). The measures adopted with the Consent Decree will stay in place only for 5 years, unless the Court finds “willful and systematic violations” of the terms of the agreement.
9 APIs (or Application Programming Interfaces) are a kind of interoperability information: see below for a definition.
10 United States v. Microsoft, 65 F.Supp.2d (1999) 1, at p.15. Also quoted in : T.A. PIRAINO,JR., Identifying Monopolists’ Illegal Conduct Under the Sherman Act, 75 New York University Law Review, 809 (2000), pp. 888—889; P.J.WEISER, The Internet, Innovation,
and Intellectual Property Policy, 103 Columbia Law Review, 534--613 (2003).
11 See, among many, BRIAN FITZGERALD, Intellectual Property Rights in Digital Architecture (Including Software): The Question of Digital Diversity, 23 European Intellectual Property Review, 121--127 (2001).
12 In fields which are subject to rapid technological development, the law should be as general as possible and based on general
principles, in order not to be made obsolete by the fast pace of technology; moreover, the UE Commission and other communitarian authorities and courts do not have direct jurisdiction in the majority of Intellectual property rights related issues, which essentially remain a national competence.
An example of this agnostic attitude is the recent Decision of the EU Commission in the Microsoft (IV) case.13 In that Decision, the Commission imposed on Microsoft the disclosure of “interoperability
information” for any undertaking interested in developing certain kinds of workgroup server operating systems.14 This information has to be made available “on reasonable and non-discriminatory terms.”15 At the
same time, the Decision stated that “[t]o the extent that any of this interface information might be protected by intellectual property in the European Economic Area, Microsoft would be entitled to reasonable remuneration”16, without providing any
guidance concerning the cases in which such a protection may indeed exist17. This agnostic attitude is even
more evident in the Court of First Instance’s ruling:
“Although the parties devoted lengthy argument, both in their written pleadings and at the hearing, to the question of the intellectual property rights which cover Microsoft’s communication protocols or the specifications of those protocols, the Court considers that there is no need to decide that question in order to resolve the present case.”18
The Consent Decree which brought to an end (at least for the moment) the main chapter of the US Microsoft antitrust saga (Microsoft III)19 adopted wording that is similar to that of the Commission:
“Microsoft shall disclose […] for the sole purpose of interoperating with a Windows Operating System Product […] the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product.”20 And “Microsoft shall offer to license […] any intellectual
property rights owned or licensable by Microsoft that are required to exercise any of the options or alternatives expressly provided to them under this Final Judgment.” But “[b]eyond the express terms of any license granted by Microsoft pursuant to this section, this Final Judgment does not, directly or by implication, estoppel or otherwise, confer any rights, licenses, covenants or immunities with regard to any Microsoft intellectual property to anyone.”21
From previous quotations it is clear that – when antitrust authorities decide to mandate the disclosure/licensing of interoperability information – the existence and the kind of legal protection concerning that information is relevant, at least in order to determine if the disclosure may be onerous or not (evidently a quite substantial aspect of these kind of decisions)22. Moreover, and apart from its antitrust
relevance, the protection of interoperability information that may be offered by intellectual property rights could have several effects, which are different from the ones arising from pure trade secret. For instance, intellectual property rights would allow an injunction against any use of these pieces of information,
13 See supra note 3.
14 Article 5 (a) of the Commission Decision in Microsoft IV (see supra note 3). 15 Ibidem.
16 Press Release IP/04/382, Brussels, 24 March 2004 (emphasis added).
17 This attitude of the Commission is perfectly consistent with the competences of the European Union, which leave to
Member States the bulk of the intellectual property related legislation. However, the technical nature of the subject matter and the difficulties in coordinating IP law and antitrust law (not to mention the fact that trade secrets may be considered as quasi-property rights in some European countries, including Italy, after the recent modifications to the Industrial Property Code, introduced by the Decreto Legislativo 10 febbraio 2005, n. 30) make this formally unimpeachable attitude of the EU Commission practically problematic.
18 Microsoft CFI (see supra note 3), § 283. The Court also explains (§ 313) that this agnosticism is possible, since “there is no need
to decide whether Microsoft’s conduct constitutes a refusal to license intellectual property rights to a third party, or whether trade secrets merit the same degree of protection as intellectual property rights, since the strict criteria against which such a refusal may be found to constitute an abuse of a dominant position within the meaning of Article 82 EC are in any event satisfied in the [European Microsoft] case”.
19 United States District Court for the District of Columbia, Civil Action No. 98-1233 (Ckk), State of New York, et Al. v. Microsoft Corporation, publ. as 231 F.Supp.2d 144 (D.D.C., 2002) (hereafter, Consent Decree). The measures adopted with the Consent Decree will
stay in place only for 5 years, unless the Court will find “willful and systematic violations” of the terms of the agreement.
20 Section III.D of the Consent Decree (see supra note 19).
21 Section III.I of the Consent Decree (see supra note 19) (emphasis added).
22 Some commentators (and an old jurisprudence) actually argue that the existence of intellectual property rights should offer a
complete shield against antitrust infringement. On this point, I remand to JOSEF DREXL, IMS Health and Trinko - Antitrust Placebo for
Consumers Instead of Sound Economics in Refusal-to-Deal Cases, 35 International Review of Intellectual Property and Competition Law,
788--808 (2004). The author – who criticizes this approach – defines “inherency doctrine” the approach, “according to which intellectual property law defines the scope of protection and competition law must not interfere”. Drexl confronts this approach with the “theory of complementarity,” according to which “intellectual property law and competition law pursue identical goals. Both fields of law are designed to promote competition and innovation.” Under this theory, “the intervention of competition laws apparently has to depend on the effects of a given IP right and its exercise on the market.” (In the third paper of this dissertation, it will become apparent that I favour the complementarity approach.)
independently of the fairness of the means adopted to acquire them, potentially voiding reverse engineering of much of its utility in the field of software.23
Despite the relevance of interoperability information in case law and policy debates and the richness of the literature about the legal protection of software,24 only a relatively small portion of this literature explicitly
deals with the specific problem of the legal status of software interfaces.25 In 1989 Cornish observed that, at
the time, there was “still considerable misunderstanding about interfaces and access protocols, and therefore about how they should be characterised in relation to copyright concepts”. 26 Unfortunately, misunderstanding
remains widespread today and no clear-cut solution concerning the legal status of these pieces of code seems to have been reached: according to Välimäki, “[i]t hasn’t been, and still isn’t, so clear that some form of intellectual property can really cover interoperability information”. 27 Rotenberg even argues that “interfaces
are neither completely private, nor completely public property, but something in between.” 28 Even Parasidis,
in one of the most specific articles about this topic,29 offers a detailed survey of US case law, concluding that
“the extent of copyright protection afforded to APIs varies considerably depending on the specifics of the underlying computer program and the nature and function of the APIs with respect to that program”.30
Making some clarity about the legal status of interoperability information – or, at least, understanding the reasons of the apparent lack of clarity in this field – is thus the first goal of this dissertation and the main purpose of the paper at hand. However, before concluding this introduction and despite the fact that I will not analyze this problem in the paper at hand, let me also mention that software programs can be seen as authentic “engines of free expression,” so that interoperability-related issues have significant implications in terms of freedom of speech and similar issues of constitutional relevance.31
23 The paper will discuss in detail the scope and broadness of fair use defences and specific exceptions to copyright related to
interoperability. (Reverse engineering will be specifically discussed in the second paper of this dissertation.)
24 Some of the authors having written about this topic include Gordon, Landes, Posner, Gemignani, Ginsburg, Menell,
Reichman, P. Samuelson and Liebowitz, just to quote a few of them.
25 Among the ones explicitly dealing with interfaces, interconnections, interoperability and APIs, see GIOVANNI GUGLIELMETTI, L'invenzione di software -- brevetto e diritto d'autore, (Giuffrè first ed, Milano. 1996); N.T.NIKOLINAKOS, The New Legal Framework for
Digital Gateways – the Complementary Nature of Competition Law and Sector-specific Regulation, 9 European Competition Law Review, 408--
414 (2000); C.R.MCMANIS, Taking Trips on the Information Superhighway: International Intellectual Property Protection and Emerging Computer
Technology, 41 Villanova Law Review, 207 (1996).
26 W.R.CORNISH, Inter-operable Systems and Copyright, 11 European Intellectual Property Review, 391--393 (1989).
27 MIKKO VÄLIMÄKI, Software Interoperability and Intellectual Property Policy in Europe, 3 European Review of Political Technologies,
1--11 (2005). See also MIKKO VÄLIMÄKI & VILLE OKSANEN, Patents on Compatibility Standards and Open Source – Do Patent Law
Exceptions and Royalty-Free Requirements Make Sense?, 2 SCRIPT-ed, (2005).
28 BORIS ROTENBERG, The Legal Regulation of Software Interoperability in the EU, NYU School of Law, Jean Monnet Working Paper
07/05 (2005).
29 EFTHIMIOS PARASIDIS, A Sum Greater than Its Parts? Copyright Protection for Application Program Interfaces, 14 Texas Intellectual
Property Law Journal, 59 (2005).
30 Id., p. 89.
31 Let me sketch in this footnote some lines of reasoning that I will completely ignore throughout this paper, but that I consider
relevant in order to address the issue of software interoperability, especially because sometimes the purely law&economics based reasoning does not lead to unquestionable results. In particular, I want to summarize the point of view of Boris Rotenberg (Rotenberg, Regulation of Software Interoperability), who approached the problem of software interoperability from a peculiar perspective. The author started his reasoning from the well known decomposition of networks in three different layers (the physical one, the “logical” or “code” one and the content one), highlighting that the most relevant bottlenecks are likely to lie in logical layer. In fact, it is the layer, “which is responsible for filtering and channeling information to the users”, while “abundant bandwidth and vast increases in processing power […] are rendering access licences as well as content regulation and monitoring increasingly suspect from a constitutional point of view”. Hence, Rotenberg argues, “one compelling way to redefine ‘interoperability’ and third party access is through the lens of the fundamental right to freedom of expression (Art.10 ECHR [European Convention on Human Rights]), and the implicit right to non-discrimination. Approaching software regulation from the viewpoint of fundamental rights forces us to acknowledge software’s unique hybrid (or dual) nature as both a means for expression, and expression in its own right. The above approach might shed new light on the question whether European law strikes the right balance between granting copyright to software writers, and enabling expression in the form of software and otherwise. Overbroad copyrights will not only silence competing software programs. Indeed, the danger exists that this same copyright enables the platform owner to have extensive control on complementary expression in the form of software code, and in the form of digital content. Eventually, this approach makes us realise that the balance struck by the law ought to be about more than just software innovation.”
Rotenberg acknowledges that “[i]t has been argued that software code is not about making a point, particularly not a political one”, but he refutes this approach, arguing that “[s]oftware, whether open or closed, is more than just bits and bytes. It determines which programs can be run, it empowers some speakers and can exclude others, and helps to determine a specific society’s culture. To be sure, the power to construct and control channels of communication through law is a most serious political question in the digital era. On one side the school of thought that believes information as the basic building block of knowledge should (and wants to) be free. On the other side stands the idea that in a market economy, value added to raw information has been and inevitably will
1.1. Plan of the paper
Before describing the plan of the paper at hand, it should be noticed that this paper presuppose a general understanding of the basic economic insights concerning the workings of the software industry. A synthetic summary about these topics (and several references) are provided in the General Introduction to the dissertation, briefly touching several quite well-known (but crucial) points: network effects, learning costs, and different approaches to incremental innovation.32 Some further economic issues will be discussed in section 8
(see below), after having described the legal background of field of analysis. The present article proceeds in several sections.
Section 2 offers an introduction to some relevant technical problems and proposes some definitions33
concerning the basic and fundamental technical “objects” discussed in the paper (APIs, communication protocols and similar interfaces). Since achieving interoperability with an existing software, established in the market, is frequently one, if not the main, goal of a decompilation project, this section will also explicitly address the problem of reverse engineering (from the legal point of view34 and from the point of view of
technical and economic feasibility).35 However, I will consider decompilation only as a (normally) necessary
preliminary step that is required in order to access interoperability information, the use and legal status of which constitutes the focus of this work. More specific issues concerning software reverse engineering will be addressed in detail in the second paper forming this dissertation.
Section 3 defines the fundamental distinction between specification and implementation of interfaces. Summarizing, an interface specification is essentially a set of technical requirements that must be respected in order to achieve interoperability, while an implementation is the actual software code that is written respecting the rules spelled out in the specification.
The goal of sections 4, 5 and 6 is to survey the status quo concerning the legal protection of