APPLICATION PROGRAMMING INTERFACES AND THE STANDARDIZATION-VALUE APPROPRIATION PROBLEM.

• Author: Sagdeo, Parth

TABLE OF CONTENTS I. INTRODUCTION 236 II. FROM API TO IP 237 A. A Short Introduction to APIs 238 1. Software Libraries as a Means for Abstraction 238 2. The Application Programming Interface 239 B. Copyright Law is the Only Existing IP Right That Can Protect Many APIs 240 1. Patenting APIs 241 2. Protecting APIs as Trade Secrets 241 3. Copyrighting APIs 243 III. THE RIGHT TO EXCLUDE OVERCOMPENSATES API OWNERS 244 A. Prior Scholarship 245 B. The Right to Exclude Enables Appropriation of an API's Standardization Value 247 C. API-Related Switching Costs as the Origin of Standardization Value 249 D. The Standardization-Value Appropriation Problem 252 1. The Appropriation of Standardization Value Has Social Costs 252 2. API owners Need Not Appropriate standardization Value To Be "Rewarded" for Their Creation 253 3. Preventing Appropriation of Standardization Value Does Not Disturb the API Owner's "Prospect" for Desirable Post-Creation Activity 255 IV. POSSIBLE SOLUTIONS TO THE STANDARDIZATION-VALUE APPROPRIATION PROBLEM 256 A. Should APIs Be Uncopyrightable? 257 B. Should Use of an API for Interoperability Be Fair Use? 258 C. Should APIs Be Subject to Fixed-Rate Statutory Licensing? 259 V. A VARIABLE-RATE COMPULSORY LICENSING REGIME FOR APIS 260 VI. CONCLUSION 262 I. INTRODUCTION

Application programming interfaces ("APIs") are the electrical sockets of modern software systems. Just as every electric device with a certain type of plug fits every outlet of the corresponding type, APIs allow software written at different times, by different people, and in different organizations to work together seamlessly. They have enabled, for example, millions of applications, worth billions of dollars, to be written for Android, iOS, and Windows by companies other than Google, Apple, and Microsoft, respectively. (1)

An API specifies how software components are supposed to interact with each other. (2) At a high level, this interface includes a list of commands that a first component can use to access functionality in a second component, and includes the specific format in which the first component should give those commands to the second component. (3) Some software components, such as a web browser's user interface, are readily visible to the user. (4) Many more components are hidden but perform key functions. For example, various software components are responsible for sending and receiving web page data over the Internet, parsing that data and rendering it in a graphical format, and managing persistent data (e.g., browser cookies) stored by websites. (5) APIs define the interaction between these components.

As discussed in Part II of this Note, the creation of APIs can involve considerable creativity and investment of resources. Depending on the circumstances, APIs can be protected by trade secret, patent, and/or copyright law. In practice, however, many APIs cannot be adequately protected by trade secret or patent law. Thus, copyright provides the most reliable means of intellectual property ("IP") protection for APIs.

Part III of this Note notes that IP protection of APIs has drawn criticism for decades. In particular, commentators have identified two features of APIs--network effects and switching costs--that acting together can cause market monopolization and other negative externalities including spurring excessive marketing costs, increasing prices for consumers (generating deadweight losses), and increasing barriers to further innovation.

Part III of this Note contributes to this longstanding discussion by examining the value of API copyrights, and finds that copyright overcompensates API owners in one key dimension: namely, the ability of owners to appropriate user switching costs. This overcompensation is the "standardization-value appropriation problem." This Note argues that preventing API copyright owners from appropriating standardization value averts the above-mentioned harms to general welfare (at least to the extent that they are greater for APIs than for other copyrighted works) and does not disturb the incentive structure underlying copyright.

Part IV of this Note discusses three possible legal regimes that prevent a copyright owner from appropriating standardization value: (1) a regime where APIs are uncopyrightable; (2) a regime where use of an API for interoperability is fair use; and (3) a statutory fixed-rate licensing regime. The Note concludes that all three of these regimes have substantial problems in optimally incentivizing innovation.

Part V of this Note proposes a variable-rate compulsory licensing regime for APIs. Under this regime, API owners must provide a compulsory license to others. The royalty rate for the license is calculated using fair, reasonable, and nondiscriminatory ("FRAND") licensing principles. The Note concludes that such a regime provides the closest-to-optimal incentive for innovation, while having higher but still-manageable transaction costs.

2. From API to IP

   This Part provides background on the technical and legal concepts discussed in this Note. Section II.A provides a short technical introduction to APIs. Section II.B discusses the types of intellectual property protection that an API can receive, and the circumstances in which intellectual property protection of APIs is effective.

   1. A Short Introduction to APIs 1. Software Libraries as a Means for Abstraction

      Virtually all computer programs written today are useless in isolation. Each depends on functionality provided by other software. Much of this functionality is provided by libraries: prewritten code that implements a series of related functions given well-defined inputs. (6) For example, operating system libraries (e.g., those provided by Windows, macOS, and Android) allow programs to communicate over a network, access storage devices, and modify what the computer displays. (7) Most programming languages (e.g., C, Python, and Java) also provide a "standard library" for that language. (8) Standard libraries allow programmers working in that particular language to access a computer's operating system. (9) Standard libraries also provide programmers with premade building blocks that implement commonly used functionality. For instance, Python has libraries for natural language processing, statistics, and bioinformatics. (10)

      The use of libraries has many benefits, including increased reliability, more readable code, and faster development of new applications. (11) Most importantly, libraries allow programmers to work at higher levels of abstraction--tying together "building blocks" of functionality rather than having to construct software from scratch. By using libraries built on top of libraries, application developers can create high-level software that does not concern itself with specific methods of computation or the manner in which the hardware needs to be used to achieve a specific result. This abstraction is incredibly powerful: it allows, for example, a quickly-written Android application to run on thousands of hardware configurations. Figure 1 shows how a hypothetical Android dialer application called "CustomDialer" can be built on several layers of libraries to leverage library abstraction.

      2. The Application Programming Interface

      An application programming interface ("API") is the interface between an application and a library. (13) It consists essentially of two parts: (1) its declaring code, and (2) its structure, sequence, and organization. (14) "Declaring code" is the code an application developer (i.e., a developer using the API) needs to use to call upon specific functionality in the library. (15) The API's structure, sequence, and organization ("SSO") is essentially the taxonomy under which the declaring code is structured. (16) Figure 2 shows the relationship between an application, an API, and a library. On one side of the interface, an application can use the API without knowing anything about how the underlying library works (i.e., about its implementing code), so long as they conform to the API's declaring code and SSO. On the other side, an API implementer can implement a library in any manner they see fit, so long as they conform to the API's SSO and declaring code. And although an API and a corresponding library are often both created by the same organization, in principle they are completely independent works. (17)

   2. Copyright Law is the Only Existing IP Right That Can Protect Many APIs

      The API's relationship with intellectual property law has been evolving for decades. (18) APIs have been held to be patent eligible, (19) patent ineligible, (20) copyright eligible, (21) copyright ineligible, (22) trade secret eligible, (23) and trade secret ineligible. (24) But, currently, copyright is the only form of intellectual property that can reliably protect publicly available software APIs.

      1. Patenting APIs

         Most APIs are not patent eligible, especially post-Alice. (25) Considering the components of an API--declaring code and its SSO--this is not surprising. Declaring code falls squarely within the printed matter exception to patentability because: (1) source code is printed matter; (2) it is nonfunctional (only the implementing code is functional); and (3) it is nonstructural (it has nothing to do with the structure of the computer readable medium it is typically stored on). (26) Because the SSO is how the declaring code is organized, it is essentially a "mere arrangement of printed matter," and so it too is patent ineligible. (27) APIs may become patentable if they are combined with novel hardware elements, (28) though in such cases it is not the API in itself that is protected, but its combination with patent-eligible elements.

      2. Protecting APIs as Trade Secrets

         APIs can theoretically be protected as trade secrets, but this protection is significantly limited by the secrecy requirement of, and reverse engineering exception to, trade secret law. one of the most important benefits of...