THE LEGAL STATUS OF SOFTWARE INTEROPERABILITY INFORMATION A Law & Economics Analysis of Application Programming Interfaces and Communication Protocols

THE LEGAL STATUS OF SOFTWARE

INTEROPERABILITY INFORMATION

A Law & Economics Analysis of

Application Programming Interfaces and

Communication Protocols

Federico Morando([email protected])

International Programme in Institutions, Economics and Law - Carlo Alberto, Turin

and

Bocconi University, Milan

Florence, 29th October 2008


THE LEGAL STATUS OF SOFTWARE INTEROPERABILITY INFORMATION:A Law & Economics Analysis of Application Programming Interfaces and Communication Protocols.

2

Interoperability information: definitions

• APIs (Application Programming Interfaces) and CPs (Communications Protocols) are pieces of software designed to allow interoperability (≈ compatibility) at computer or network level

− API = interface a computer program provides to allow requests for services to be made of it by other pieces of software

− CP = set of standard rules for data exchanging (signalling, authentication) over a communications channel (network)

• API as a broad term in the literature about interoperability

− “API” frequently encompassing CPs and other interfaces− “API” as a single interface or the entire set used by a program− “API” referring to both the rules to respect in order to

interoperate and the actual code embedding these rules• specification vs implementation



3

Interoperability does matter (not only for geeks!)

• “to control the APIs is to control the industry”− significant switching costs (tipping/lock-in)

• network effects (direct and indirect)• learning costs

− interoperability used as tool to organize/shape the industry• e.g. game platforms and exclusivity in exchange for access to

interoperability information

• software interoperability has been at the core

of several recent antitrust cases and policy debates− European Microsoft antitrust case− policy debate concerning interoperability between DRM

technologies• interoperability matters also for content industry• Loi DADVSI in France



4

Legal status of APIs: in the Literature

• Typically considered a very uncertain field:−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”

−Rotenberg: “interfaces are neither completely private, nor completely public property, but something in between”

−Parasidis: detailed survey of US case law focused on APIs, 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”



5

Main claims of the paper: Descriptive level

• the legal status of interoperability information is not as unclear as part of the literature suggests− a multidisciplinary approach is needed:

law&economics, but also technology• under this approach, basic L&E tools may provide insights• however, technological issues are frequently confined among

the “specificities of the case at hand”

− one of the pillars of copyright law, the idea/expression dichotomy, may be rephrased in a specification/implementation distinction

• to do so, some technical understanding is necessary• doing so allows rationalizing allegedly “unclear situations”

and “conflicting case law”

• far from being always “case specific” a certain level of technological understanding allows for a systematic reading of case law



6

API specification vs implementation

• specification: an accurate description of a set of requirements, to be satisfied by a certain product− an API specification may be embodied in a manual or other document− a specification document is a copyrighted work (as a math book)

− this does not give exclusionary power over ideas and technical teachings

• implementation (of a given specification): a product respecting the criteria stated in the specification− API implementation: actual source/object code

− if a specification is a math book, an implementation is a collection of solved exercises (applying theorems and formulas taken from the math book)

• analysing an implementation (through decompilation) helps in understanding the initial specification− E.g. we may understand theorems studying solved exercises− however, this is far from being easy, quick or errors proof



7

Complementary Software

(B)

Complementary Software

(B)

Original Software

(A)

Competing Software

(C)

API SPECIFICATION

API IMPLEMENTATION

Implementation v. Specification

Vertical Interoperability (A-B)

Horizontal Interoperability (A-C)



8

Legal status of APIs: my positive description

• one may distinguish specifications and implementations− idea/expression dichotomy as the legal analogous

• surely tricky, but regularly used to decide whether non-literal elements (like the “plot” of a literary work at various levels of abstraction) may or not be copyright protected

• interface specifications are basically a collection of unprotected and unprotectable elements− again, a given description of a specification may be copyrighted (as a math

books is copyrighted) but technical principles should remain free (as a mathematical algorithm or theorem)

• interface implementations are pieces of software which are clearly protected− a significant amount of developers’ effort goes in writing actual lines of

code in specific programming languages− this is protected expression and copyright law has been devised to avoid

free riding on it



9

Economic Coherence of the Proposed Approach

• strong patent-like property rights may be a sufficient

condition to stimulate investments in a static setting− but this is not a necessary condition− risk of “side effects” on subsequent innovation (dynamic setting)

• copyright offers the possibility of preventing free

riding through a “legal monopoly” on expression− sufficient protection to avoid major market failures (piracy)− possible to recoup sunk “development” costs− admittedly imperfect: partial free riding on ideas (sunk “research” costs)

• the “imperfection” of copyright makes it desirable− minimum obstacles to follow-on innovation− no monopoly on ideas

• other advantages of incumbent may compensate partial free riding (lead time)• another name for “free riding” may be sharing and diffusion of knowledge



10

Unexpectedly,the Literary Work Metaphor Makes Sense

SOFTWARE SOURCE CODEANCIENT GREEK POETRY



11

Literary Work Metaphor (cont.ed)

• the metaphor does not make sense because of similarities in

the object of protection− even if this may have triggered the analogy, along with distribution-related

similarities (e.g. FNAC, selling books, CDs, DVDs and software)

• it is the relative weight of pure “research”-related vs

“development”-related costs which is similar in literature and

in software development− the protection of the mere “external form” is – in both cases – capable of

eliminating the majority of market failures related to free riding

• possibly, there is more “research” as a precondition of

software development− this is more than compensated by the additional cost of “accessing to (a significant

part of the) ideas”, which requires complex and time-consuming reverse engineering activities

• yet, complete free riding would not be so easy even with direct access to source code• e.g. commercial firms respecting viral open source licenses in order to get the right to “build

upon” existing open projects (why would they do so, if rewriting a functionally equivalent, but fully commercial and trade-secret-protected, software were easy and cheap?)



12

Access and Reimplementation Phases

• to use interoperability information, 2 steps

are needed− access

−reverse engineering (decompilation) is used to understand an existing implementation and reconstruct a functional proxy of the original specification (technical requirements)

− reimplementation−the reconstructed specification may be used to achieve

vertical interoperability (complementary products) or horizontal interoperability (substitutive products)

−should we treat vertical and horizontal interoperability in different ways? (as suggested by Weiser 2003)



13

Access and Reimplementation

• Non-tech. example: blind person wanting to read a

book− to achieve access, a Braille version could be realized (by a

computer or someone else) or a computer (with OCR) could be used to artificially “read” the book

• in any case, the book is copied or otherwise reproduced• we need a fair use defense or a specific exception, or copyright is

violated (even if the original copy is legally owned)

− the use this visually impaired person could do of knowledge acquired reading the book is not limited by the fact he/she needed an exception to enjoy it

• if a ferocious critique of the book is written or a book competing in the same market niche is realized by this person, the original fair use test should not take into account this “ultimate effect” of gaining access to ideas embodied in the book

• this is true no matter how valuable are the ideas learned accessing the book and no matter how negative is the impact on sales of the critique



14

Access and Reimplementation: normative recommendations

Copyright may need to be formally violated during this phase

- need for fair use/exceptions- it is at this stage that a fair use (or analogous) test should be performed

No need for copyright violations

- general analysis of copyright violation•similarity in an abstraction-filtration-comparison test•merger doctrine; scènes à faire

ReimplementationAccess

• two-steps analysis: (1) accessing to interface specifications; (2) re-implementing the interface• not relevant for fair use test whether reimplementation leads to actual or potential competition• in general, vertical and horizontal interoperability should both be allowed, as long as there is no evidence of copying (of the code/expression of the original implementation)

− possible to interpret in this way Art. 6 of the Software Directive• Commission seems to agree, but some commentators disagree (e.g. Hart)



15

Main claims of the paper: Normative level

• no major legislative changes are needed (in copyright law)− we should avoid using patent-like protection for software, especially for

aspects such as interfaces• patent law may already offer unnecessary protection, especially in the US

• using the descriptive part to interpret case law, leading to:− explicit specification/implementation distinction

• not doing so, some courts reached “reasonable decisions”, based on shaky arguments

− distinguish access to information and its reimplementation• possible to treat in a similar way vertical and horizontal interoperability

• as opposed to Weiser’s approach• interoperability exceptions (Art. 6 SW Dir.) interpreted in a broad way

• as opposed to Hart’s arguments

• (al least) as long as the cost of reverse engineering is significant− the previous approach does not only make sense from a “formal” point of

view• it also makes economic sense

− there are reasons to rely on this assumption specific paper



16

Essential Bibliography

• E. PARASIDIS, A Sum Greater than Its Parts?: Copyright Protection for Application Program Interfaces, Texas Intellectual Property Law Journal (Winter, 2005)

• P.J. WEISER, The Internet, Innovation, and Intellectual Property Policy, 103 Colum. L. Rev. 534-613 (2003)

• About reverse engineering, software platforms and interoperability− A. JOHNSON-LAIRD, Software Reverse Engineering in the Real World, 19 U. Dayton

L. Rev. 843 (1994)− P. SAMUELSON and S. SCOTCHMER, The Law and Economics of Reverse

Engineering, 111 Yale L.J. 1575, 1608–13 (2002)− J. FARRELL and P.J. WEISER, Modularity, Vertical Integration, and Open Access

Policies: Towards a Convergence of Antitrust and Regulation in the Internet Age, 17 HARV. J.L. & TECH. 85, 114 (2003)

− P. SAMUELSON, R. DAVIS, M.D. KAPOR, and J. H. Reichman, A Manifesto concerning the Legal Protection of Computer Programs, Columbia Law Review, Vol. 94, No. 8, pp. 2308-2431 (Dec., 1994)

− Estelle Derclaye, Software Copyright Protection: Can Europe Learn From American Case Law? Part 1, European Intellectual Property Review, 2000, 22(1), 7-16 and …, Part 2, European Intellectual Property Review, 2000, 22(2), 56-68

− R.J. HART, “Interoperability Information and the Microsoft Decision”, EIPR, Vol. 28, Issue 7 (July 2006)

Documents

THE LEGAL STATUS OF SOFTWARE INTEROPERABILITY INFORMATION A Law & Economics Analysis of Application Programming Interfaces and Communication Protocols