Google LLC v. Oracle America, Inc.
SUMMARY OF ARGUMENT
The Java SE declarations of this case are simply a language of commands. As an application programming interface, or API, they exhibit features common to any language: a structured vocabulary and grammatical syntaxes, which a computer system understands as instructions to perform predefined tasks. What Oracle accuses as infringement is “reimplementation,” namely the building of a system, in this case Google’s Android platform, that repurposes the same words and syntaxes of the Java declarations.
This fact pattern—reimplementation of a command language—is strikingly common. The earliest forms of communication featured command languages; today private industry and government frequently reimplement APIs. The many instances of reimplementation highlight both widespread expectations that reimplementation is noninfringing and the broad repercussions that would obtain should copyright law defy those expectations.
I. Instances of reimplementation abound. Historical command languages—collections of named commands with actions implemented by human recipients—include naval flag messaging, the Victorian language of flowers, and dictionaries of telegraphic codes in the early 1900s. Non-computer command languages remain in use today: Radio communication abbreviation systems have ongoing law enforcement and military applications, and hospitals use named color codes to trigger emergency procedures. In all of these examples, one finds frequent reimplementation in the form of reusing commands in new dictionaries or procedure manuals.
Computer command languages, namely APIs, are also common and commonly reimplemented. Cloud computing, one of the largest technology sectors today, relies extensively on APIs, and reimplementation of leading firms cloud computing APIs is frequent practice for competitors, including Oracle itself. Internet communications and computer peripherals similarly depend on reimplementation, by virtue of their conformance to technical communication standards that incorporate APIs.
Governments are also involved in the business of API reimplementation. Federal agencies and other government entities produce, reimplement, and direct reimplementation of APIs to serve public objectives such as health care interoperability, aviation safety, and law enforcement coordination. Indeed, a binding executive policy from 1998 is inconsistent with copyrights in APIs; to read it otherwise would render practically every federal agency in violation.
II. These many examples of reimplementation offer multiple lessons on the value of freedom to reimplement and the danger of letting copyright law interfere with that freedom.
First, there is a consistent consensus view that reimplementation of APIs and other command languages is not copyright infringement. Numerous actors, including the United States, reimplemented historical command languages such as telegraph codes on a regular basis. Practices of the technology industry that forms technical standards reflect an expectation that reimplementation is not copyright infringement; the 1998 executive policy reflects the same.
Second, competition would suffer should reimplementation require a license. Dominant firms in the technology sector can lock in software developers with their APIs, and new entrants that seek to challenge those market leaders need to reimplement those APIs in order to overcome that lock-in and compete on a level playing field.
Third, API reimplementation is frequently a centerpiece of efficient and effective government. Reimplementation enables standardization, which has advantages for public safety and welfare, as well as advantages for the government itself in terms of better interagency coordination and taxpayer savings.
Oracle perhaps hopes to characterize this dispute as an idiosyncratic matter of limited consequence beyond the parties. The wide range of technologies and practices described in this brief make that characterization unrealistic. The outcome of the present case will have broad ramifications on the public and private sectors, should copyright law be rendered inconsistent with longstanding expectations of freedom to reimplement.
ARGUMENT
I. Reimplementation of APIs and Other Interfaces Is Prevalent, Expected, and Valuable
Reimplementation of APIs and command languages abounds throughout history and in modern technology. Three classes of examples of reimplementation are considered below: Historical command languages, modern communication and Internet technologies, and government use of APIs. These instances exemplify the value of reimplementation and the expectation that it is allowed.
Attempting to avoid the dramatic consequences of its legal theory, Oracle has tried to distinguish the present case from these other situations. These attempts fail. First: Oracle argues that the reimplementation in the present case was only partial and incompatible with the original Java declarations. But many of the reimplementations described below are partial and incompatible too. Second: Oracle may argue that standardized APIs necessarily include an implied license for use. But there is no viable implied-license doctrine of copyright law for this purpose.2 Third: Oracle distinguishes Google’s literal copying from other reimplementations that translate an API into another computer language. But translations are derivative works3 and the reimplementation must still literally copy the API’s vocabulary. Furthermore, this distinction would make infringement trivial to avoid. Google could mechanically translate its reimplementing code into the C++ language to avoid literal copying; this code would still receive Java commands in the Java language with no change for programmers.4 Thus, Oracle’s attempt to limit the fallout of the present case is unavailing.
A. Historical Communication Systems Show the Commonality of Reimplementations
Though APIs are a creation of the computer age, the broader use of command languages among humans was common. Nothing in Oracle’s theory of the case requires a reimplementation to be a computer program, and reimplementations of non-computer command languages were made by many, including government agencies.
1. Flag Signal Codes
When Admiral Lord Nelson at Trafalgar hoisted his famous slogan “England expects every man will do his duty,” he availed himself of a long line of command lan-
guage reimplementations in the form of maritime flag signaling. The history of this form of communication shows the extensiveness of the practice of reimplementing languages in new settings.
Use of flags for naval communication can arguably be traced back to the Greeks,5 but modern forms arise in the mid-18th century. The general approach that developed was a two-step translation process: Flags were used to represent digits of numbers and later letters, and signal books associated numbers with words or messages. For example, a ship might raise three flags representing the digits 2, 2, and 4; an observer would then look up the number 224 to receive the message “engage the enemy.”6
This system thus entailed two command languages: one associating flags with numbers, and another associating numbers with instructions. Reimplementation would have involved reusing flags to represent similar symbols, or reusing numbers for instructions. Both occurred numerous times in the history of maritime flag signaling.
The numeric signaling system is generally attributed to Bertrand-Francffois Mahé de La Bourdonnais, a French naval officer whose flag signaling system was de-
scribed in a 1769 treatise.7 Admiral Sir Charles Knowles apparently relied on the numerical signals of La Bourdonnais, but devised his own “tabular method” of flags for the numbers.8 Both systems were the basis for Admiral Lord Howe’s signal books of the late 1700s.9 Howe’s books only provided for naval commands, though, which Admiral Sir Home Popham augmented in 1800 to add a complete alphabet and general-purpose vocabulary, thereby producing the “telegraphic” flag code that Nelson used at the Battle of Trafalgar.10 Captain Frederick Marryat adapted Popham’s code for commercial ships; his code of signals contained two parts comprising a “vocabulary adapted from Popham.”11 Marryat’s commercial code in turn was “the source and inspiration” for the International Code of Signals, which included many identical flags.12 The last of these codes, still in use today, retains the legacy of three centuries of history: The flag colors
remain the four “very striking colours”—white, red, blue, and yellow—selected by La Bourdonnais.13
2. Floriography
Although the symbolic use of flowers dates back to at least the Song of Solomon, an acute interest in floriography, or the language of flowers, developed rapidly during the late Georgian and early Victorian eras. For early-1800s enthusiasts, flowers conveyed not just symbolism but a complete, grammatically complex communicative system that exhibits both the key characteristics of command languages and frequency of reimplementation.
Floriography was arguably popularized in England via the writings of Mary Montagu, wife of the English ambassador to the Ottoman Empire, who in a letter published in 1763 described a “Turkish love-letter” comprising a series of objects each associated with a phrase—cinnamon for “my fortune is yours,” for example.14 Romantic poets seized upon the practice, interpreting it (apparently incorrectly) as a covert means for forbidden lovers to communicate.15
Across the 19th century, dictionaries of flowers and their meanings became wildly popular, with over 200 competing dictionaries and regular reprints of the most popular editions.16 The most comprehensive of these, such as Henry Phillips’ 1825 treatise, included extensive grammatical frameworks complete with pronouns, articles, conjugations, and negators.17 Phillips’ vocabulary was not limited to romantic notions, but could express mundane commands and instructions, with floral elements representing dates, times, numbers, and even monetary amounts.18
Copying of floriographic vocabularies was typical. Phillips himself purported that he drew terminology from earlier sources “to avoid perplexity,” though he invented the numerical and time representations.19 A modern comparison of leading references on the language of flowers, including Phillips’, observes a general “pattern of similarity” across both American and British dictionaries, but also a trend of adding new meanings as new flowers came into popularity or were better understood.20 Furthermore, though the dictionaries generally duplicated the general meanings of flowers, they did not use the same text to explain the definitions; some just matched words to flowers while others provided effusive description or even poetry.21 Each dictionary of the language of flowers thus reimplemented its predecessors, reusing the vocabulary but not necessarily the explanatory text.
Reimplementation of the language of flowers was ultimately necessary for the language to be useful. If every floriographic system used its own vocabulary, then one could only transmit a botanic message if the recipient worked off of the same vocabulary as the sender. Advertisements invoking the language of flowers, which were apparently common at the time, would have failed to work had there not been compatibility among understandings.22 Accommodating those already familiar with an existing language was thus as relevant to the floriographer as to the Java declaration reimplementer.
3. Telegraphs and Radio
Along with the rise of the electric telegraph across the late 19th century came the development of telegraphic codes, dictionaries of often-arbitrary code words associated with phrases intended to reduce the length of telegrams. Hundreds of such codes were published from the mid-1800s onward, each with its own associations between codes and meaning: Hesternal translated to “Do not renew” in the Western Union codebook,23 but in the ABC Code meant “Will proceed home immediately after the inquiry is held.”24
Much like the Java declarations, telegraphic codes were command languages—shortcuts for commands that instruct the recipient on what to do, even commands that accept parameters just like software APIs.25 And it was common practice to “reimplement” telegraphic codes by adapting parts of existing vocabularies into new ones.26 Most notably, the federal government engaged in this practice extensively. The War Department’s 1885 telegraphic code made only minor modifications to Robert Slater’s code—even the title was nearly identical.27 The subsequent War Department code from 1900 was again a pastiche of the Western Union code and an army-specific dictionary.28 In other words, the War Department produced multiple partial reimplementations of privately published telegraph codes.
The War Department did not reimplement telegraph codes gratuitously. Exactitude in command words, telegraphed via error-prone dots and dashes, was no less essential for telegraphic codes than for software APIs—a one-letter error in a coded telegraph prompted a tort case before this Court in 1894.29 And telegraph operators familiar with certain vocabularies (or at least pronounceable words) had difficulty transcribing messages filled with newly manufactured words.30 By basing codes off of known systems, the War Department and others could reduce errors by taking advantage of skilled telegraph operators’ familiarity with existing code systems—much like how Google’s Android assisted programmers already familiar with the Java declaration interface. Reimplementation thus likely served, at least in part, to ensure accuracy in the Army’s communications.
Telegraphic codes evolved into radio brevity codes, which have become familiar standards. Roger and over and out are part of the lexicon of procedure words for
radiotelephony,31 and ten-four derives from a system of “ten-codes” developed for and used today by law enforcement.32 Again, reimplementation of radio brevity codes was common. Procedure words derive from Morse code signals—Roger from Morse code R originally meaning “received”—and have now been adapted by multiple entities such as NATO and the Coast Guard, though with differences in each.33 And individual police departments use local variations of ten-codes.34 Organization-specific reimplementations of these command languages are thus ordinary practice for public entities.
4. Hospital Codes
Code blue is the famous catchphrase for cardiac arrest, but beyond that hospitals often maintain complete vocabularies of color codes representing emergent conditions—code red for fires, code pink for infant abductions, and so on.35 The color codes are a command language since the announcement of any code triggers response actions for hospital staff; indeed a key responsibility of each hospital using these emergency codes is “implementation” of procedures to respond to the relevant situation.36 Like the Java declarations, these codes are named shortcuts to sets of instructions implemented at each hospital.
A hospital reusing another’s color codes for its own emergency procedures, then, would be reimplementing a command language, and such practice is common. There is no standard color code scheme, and color codes have historically been vastly inconsistent across hospitals.37 In 2000, responding to a fatal misunderstanding of a color code alert, the Hospital Association of Southern California recommended a color code scheme for use in local hospitals.38 The New Jersey Hospital Association adopted almost the same color code in 2004, the only change being code amber for child abductions, rather than code pink as California had used.39 Oregon and Washington hospital associations followed suit, explicitly noting that their codes were “similar to what is being used in California.”40 The Maryland Department of Health also appears to have reimplemented the California code: Its 2002 Universal Emergency Code is largely identical with only a handful of exceptions, such as code white for oxygen outages rather than pediatric emergencies.41
Reimplementation of color-code languages in hospitals ensures patient and hospital staff safety. Medical professionals who move between hospitals carry with them expectations of what each color code means, which can lead to confusion when a hospital’s meanings are different.42 A Maryland-trained doctor who relocates to California might disastrously respond to a code white with an oxygen tank rather than a pediatric defibrillator. Hospitals reimplement emergency code language for the same reason Google reimplemented the Java declarations—to simplify the learning curve for users familiar with an existing system. In the case of hospitals, the consequences of freedom to reimplement can be dramatic.
B. APIs Are Frequently Reimplemented by Private Firms, Including Oracle Itself
As historical command languages have given way to computer APIs, reimplementation has remained consistent. API reimplementation is common among technology firms, and it ensures a competitive marketplace.
1. Cloud Services
A defining feature of modern technology is cloud computing. Reimplementation in the $200 billion43 cloud computing market provides a striking example of how Oracle’s API copyright theory could stifle competition.
Cloud computing involves providing services that a personal computer ordinarily offers, such as file storage and numerical processing, on distant computers over an Internet link.44 Many companies offer cloud computing services, but the unquestioned leader is Amazon Web Services,45 with a file storage service called S3.
APIs are the mechanism for accessing cloud services. To store or retrieve a file on S3, a computer programmer issues commands following the vocabulary and syntaxes of the Amazon S3 API, including cryptic words like encoding-type, continuation-token, and x-amz-date.
A competing cloud service must also implement an API, and under Oracle’s theory the API cannot reimplement S3’s without permission. Indeed, this case’s litigation has apparently had its effects on the cloud services market: Companies find it “a legal grey area” and “dangerous” to reimplement Amazon’s APIs, and one firm named Eucalyptus announced licensing Amazon’s API in 2012.47
Even mere uncertainty over API copyrights essentially locks in Amazon’s dominant position in the cloud services market. Programmers will be unlikely to switch
over to a competitor with an incompatible API, due to the time and costs required to learn the competitor’s API and to rewrite software for it. Thus, “offering some degree of compatibility would be helpful for the newcomers.”48
Nevertheless, numerous cloud services reimplement the Amazon S3 API, despite the legal uncertainty.49 Among those reimplementers is Oracle itself: Oracle’s
Cloud Object Storage service includes an “Amazon S3 Compatibility API” that replicates, down to the letter, Amazon’s command words and syntaxes.50 Oracle representatives claim that the reimplementation was permitted under a 2010 blanket open-source license, but that license attaches to API-using software rather than the API itself,51 and in any event Oracle’s blanket-license theory is inconsistent with its 2012 Eucalyptus deal—Amazon needed not negotiate a license if it already offered a blanket one in 2010.
More important than Oracle’s licensing gaffe is why Oracle reimplemented Amazon’s API at all. The reason was almost certainly to simplify switching costs for programmers wanting competitive choices for cloud computing.52 If, as Oracle suggests, copyright prohibits API compatibility, then emerging cloud service firms such as Oracle can only compete on a level playing field subject to the grace of dominant gatekeepers, with API copyrights as the keys.
2. Technical Standards and the Internet
Beyond cloud services, nearly every information technology system today depends on reimplementation, because modern technology relies on technical standards that almost always include APIs that must be reimplemented.
A technical communication standard is an agreed-upon protocol by which computers communicate.53 Generally developed by voluntary consensus-based industry consortia called standard-setting organizations, technical standards are the basis for practically all online communications: Web pages follow the HTML and CSS technical standards, videos generally conform to the International Telecommunication Union’s H.264 standard, emails are transmitted in accordance with the SMTP standard, and so on.54
These standards generally contain APIs much like the Java declarations: extensive vocabularies of command words combined with syntaxes for using them.55 That is unsurprising because technical standards are command languages, formal mechanisms for controlling actions of a computer. A web designer, wanting to create a red line at the top of a page, expects to be able to issue the declaration “border-top-color: red” to achieve this result according to the CSS standard for web page design; web browser software such as Firefox or Internet Explorer must implement that CSS declaration and myriad others in order to present web pages correctly.56
The $1.2 trillion57 Internet-related economy thus depends in large part on freedom to reimplement APIs found in technical standards. One might hope to find such freedom in license arrangements, but very few standard-setting organizations deal with licensing of copyrights in APIs—likely because those organizations believed no copyright interest was infringed in API reimplementation.58 Oracle’s copyright theory, if validated, could throw the Internet economy into disarray as it scrambles to devise licensing arrangements on decades-old, heavily entrenched technical standards.
3. Computer Hardware
Technical standards do not implicate only computer software; they are found in computer hardware too. Computer peripherals, such as keyboards and scanners, must exchange information and instructions with a computer to perform actions such as typing a letter or storing an image. In the early days of personal computing, this communication was mediated by software called “drivers” that manipulated the computer’s operating system directly to instruct the device.59 This direct-manipulation approach is perhaps akin to a judicial clerk opening up a judge’s personal notebook and writing in it; unsurprisingly device drivers caused system crashes and other serious problems for computers.60
A better approach is to have a formal procedure—an interface—between device and computer that sets boundaries and conveys structured information, perhaps like a case memorandum from clerk to judge. These interfaces are today’s technical standards such as USB, Wi-Fi, and Bluetooth, all of which are in common use today, and all of which incorporate extensive APIs that each peripheral and computer must reimplement in order to communicate.61
The standardization of computer peripheral APIs has created a robustly competitive market. For just Bluetooth technology, the standard’s special interest group maintains over 34,000 member companies and reports 3.7 billion Bluetooth devices shipped in 2018, devices ranging from audio headsets to x-ray imaging to cars to industrial equipment monitors.62 Each of these thousands of companies, in order to participate in this massive computer peripheral market, must regularly comply with technical standards and thus reimplement APIs. API reimplementation is what keeps the computer hardware market both competitive and crash-free.
C. Government Entities Often Mandate Reimplementation or Reimplement APIs Themselves
Public entities also engage in API reimplementation. In some cases a government will require or encourage private firms to reimplement APIs; in other cases the government itself is the user of reimplementations. Amici’s brief supporting the certiorari petition already provided three examples of this: the Department of Health and Human Services’ rulemaking on APIs for electronic health records, the Federal Communications Commission’s adoption of the ATSC standard for digital television, and local governments’ use of smart-city technology that uses standard APIs.63 Reimplementation of APIs in these examples served to enhance patient care choice, reclaim valuable wireless spectrum, and save taxpayer dollars by avoiding vendor lock-in, among other things.64 These, however, are far from the only examples of how API reimplementation facilitates efficient and effective government.
1. Law Enforcement Agency Cooperation
Because of the need to share information across jurisdictions, law enforcement agencies extensively use API reimplementation in the course of protecting public
safety. Of many possible examples, the following is one. In 2001, the Department of Justice engaged in a project to streamline data sharing.65 The project soon evolved into a multi-year effort to develop a “framework that enables the justice and public safety communities to effectively share information at all levels of government—laying a foundation for local, state, tribal, and national justice interoperability.”66
That interoperability meant creating an API. The Department of Justice described its work, named the Global Justice XML Data Model, as an “interface” intended for “interoperability.”67 The GJXDM was also called “an object-oriented data model composed of a well-defined vocabulary,” using the same term “object-oriented” with which the district court described the Java declarations.68
The GJXDM was apparently not original, but drawn from other local, state, and federal law enforcement APIs.69 In turn, the Justice Department encour-
aged other law enforcers to use GJXDM in their own systems—in other words, to reimplement both the Justice Department’s API and those of the older systems the Justice Department had reused.70
The success of the GJXDM is evident in cases it solved. Police across Pennsylvania were able to track down a bank robber within hours because their departments reimplemented the API, and New York police were able to apprehend suspects in a homicide for much the same reason.71 The GJXDM was so successful, in fact, that in 2005 the Department of Homeland Security partnered with the Justice Department to build a successor interface, the National Information Exchange Model, that would provide the benefits of a common vocabulary across all of government.72 Reimplementation of APIs, and the interoperability that results, can thus have important consequences for public safety and government efficiency.
2. Meteorology
API reimplementation is also central to the government’s ability to broadcast important information to the public. The federal government’s National Weather Service provides an example.
The World Meteorological Organization operates a global weather information network, of which NWS operates a national hub to centralize reports from weather stations across the country.73 For this infrastructure to work, weather reports must be coded precisely so that every component in the network can understand them. The international coding system for weather reports is an API. A WMO-standard weather report opens with an “abbreviated heading” containing a four-letter code identifying the type of report—“BBXX,” for example, indicating a surface observation from a ship.74 The standards then define structures of information for each report type.75 The WMO weather report standards thus define a vocabulary of heading codes and syntaxes for each, and computer systems that interpret weather reports must understand those heading codes and syntaxes—they must reimplement WMO’s API.
In the United States, NWS weather reports use the codes and syntaxes of WMO with domestic adjustments, such as to remove some metric units.76 The NWS weather hub and other services are thus a partial reimplementation not fully compatible with WMO’s weather reporting API. Furthermore, any computer software designed to interact with NWS weather reports would need to implement the NWS API, and by extension parts of the WHO API. Reimplementation of interfaces abounds in the field of providing a public weather service.
3. Aviation
Air traffic control is replete with command languages. Communication between aircraft and airport control towers is conducted according to specific command phrases, in the United States defined by the Federal Aviation Administration.77 The FAA’s command language is a partial reimplementation of another command language, the lexicon of the International Civil Aviation Organization.78
The FAA also deals with computer-based APIs. In its program to manage the operation of small unmanned aircraft, commonly called drones, the FAA recently developed a program for Low Altitude Authorization and Notification Capability. Part of this LAANC program is an “API-based interface” between the FAA and service providers that provide software for drone users.79
While the FAA has not published the exact specification of the LAANC API,80 the agency’s high-level description indicates that the API contains a hierarchically structured, comprehensive set of named commands not unlike the Java declarations.81 As a result, service providers for drone users must reimplement the FAA’s API, and the FAA must implement parts of that API on its own service too because the API is “bidirectional.”82
D. API Copyright Directly Conflicts with Binding Federal Policy
Oracle’s position in this case would render many federal agencies in violation of a decades-old policy of the Executive Branch, because of those agencies’ use of technical standards containing APIs. United States policy has long preferred government agencies to adopt privately developed technical stan-
dards rather than inventing new ones.83 Thus, in 1998, the Office of Management and Budget promulgated Circular A-119 requiring that “federal agencies must use voluntary consensus standards in lieu of government-unique standards . . . except where inconsistent with the law or otherwise impractical.”84
In defining “voluntary consensus standards,” the OMB circular required that such standards “include provisions requiring that owners of relevant intellectual property have agreed to make that intellectual property available” on licensing terms granting broad availability.85 The provision is unsurprising: It ensures that a holder of an intellectual property right covering part of a technical standard cannot hold up the government or regulated entities from implementing the standard, but instead must offer fair and reasonable licenses.86
If copyrights in APIs are infringed by reimplementation, then those copyrights would plainly fall within “relevant intellectual property” under OMB’s definition, so any technical standard containing an API would be required to have provisions on copyright licensing before an agency can adopt the standard. But voluntary consensus standard-setting bodies almost uniformly lack provisions for licensing of copyrights in APIs,87 which likely means that many federal agencies would violate OMB’s policy. The ATSC standard for digital television, for example, contains several APIs but has no provision for licensing of their copyrights,88 so the FCC would have violated OMB Circular A-119 when it adopted that standard in 2002.89
The recent 2016 revision of OMB Circular A-119 only creates further problems. The notes to the revision state that, with regard to the “voluntary consensus standard” definition, “no substantive changes are intended.”90 Yet the definition itself now interchanges “intellectual property” and “patent” arbitrarily,91 leaving it uncertain whether the phrase “relevant intellectual property” in the policy continues to refer to copyrights or no longer does (which would be a substantive change).
The striking mismatch between API copyrights and OMB Circular A-119 does not just demonstrate an absurdity in Oracle’s theory of the case. The mismatch re-
veals a view, apparently held by OMB as well as the industries developing technical standards, that copyrights are not “relevant intellectual property” for reimplementing an API.92 Caution is merited before interpreting copyright law inconsistent with that consensus view.
II. Historical and Modern Practices Counsel Against Reimplementation Being Copyright Infringement
The many examples explored above offer multiple important lessons on copyright and API reimplementation.
A. Industry Expects Not Copyright Incentives to Create APIs, but Freedom to Reimplement
There has always been an expectation that reimplementation is broadly permitted. Conversely, history and modern practice refute the notion that the incentives
of copyright protection are necessary to encourage new APIs or command languages.
From the earliest days of telecommunications, command languages have been reimplemented with regularity.93 Today, scores of technical communication stan-
dards mandate API reimplementation yet make no provisions for licensing copyrights in APIs, suggesting that industry believes that no license is necessary.94 And government agencies use reimplementation to achieve outcomes such as portable health care, law enforcement coordination, and military success95—again expecting copyright licensing to be unnecessary.96 These many examples show a consensus that APIs and other command languages may be reimplemented without a copyright license.
These examples also undercut Oracle’s claim that copyright incentives are needed to encourage production of APIs. The many command languages and APIs described above were produced and improved, despite the developers knowing that their work would likely be reimplemented by others for free. And even if copyright incentives are valuable to a few API developers, those incentives come at the cost of upsetting an overwhelmingly larger set of settled expectations on the permissibility of reimplementation.
B. Robust Competition Depends on Emerging Firms’ Freedom to Reimplement APIs
API reimplementation ensures that emerging technology firms can compete with incumbents on a level playing field. Should reimplementation be copyright infringement, then leading technology firms could use copyright as a tool to lock out competitors from non-copyrighted markets.
Modern technology systems depend on interoperability. Developers of health care management software, for example, must reimplement numerous APIs and interfaces to make their products compatible with the many medical devices, records systems, wellness apps, and other technologies already on the market.97 Thus, “[s]tandardization provides enormous value to both consumers and manufacturers.”98
Health care is not the only example of reimplementation begetting competition. Internet platforms and software have thrived by reimplementing Internet APIs.99 Thousands of computer peripheral manufacturers all reimplement APIs found in technical standards for device communication.100 Copyright in APIs threatens to entrench incumbents by taxing new entrants with switching costs—indeed, the evidence seems to suggest that uncertainty about API copyrights, created by this litigation, has already initiated entrenchment in the cloud computing industry.101
The risk of technological dominance via copyright law should be especially concerning given the larger conversation about “big tech” generally. Indeed, for many of those concerned with a lack of competition in the social media and Internet platform industries, a common proposal for remedying that situation is in fact API reimplementation: directing the leading online platforms to use standardized interfaces to their operations so that new entrants can reimplement those interfaces and thus interoperate competitively with the incumbents.102
While the merits of mandatory interoperability are a matter for debate, it certainly would be counterproductive to give dominant firms a veto power over competitive interoperability. Copyright law has never been intended as a veto power over free markets in technological services,103 and this case should not change that.
Competition concerns also favor resolving this case on the absence of a copyright interest in an API, rather than on fair use. Fair use determinations often require a fullblown trial, which may as a practical matter deter new entrant competitors from reimplementing APIs even if on the merits they would be permitted to do so.104
C. Reimplementation of APIs Often Serves Americans’ Security and Welfare
Freedom to reimplement APIs often advances important public purposes, by virtue of the intrinsic tie between reimplementation and standardization. Standardization of health care records ensures that patients receive adequate care from multiple providers.105 Standardization of hospital codes ensures that hospital staff respond to emergencies correctly.106 Standardization in aviation ensures that airplanes do not crash.107 Standardization in broadcast information, such as television and weather reports, ensures that the public can receive important alerts and information.108 To the extent that copyright interferes with API reimplementation, it may interfere with these important interests.
Standardization within the government’s internal operations is equally important. Law enforcement agencies require common data exchange vocabularies in order to administer justice collaboratively.109 Standardization in technology procurement saves future taxpayer dollars from vendor lock-in.110 Military operations have always depended on standardization of command communication, from the days of telegraph codes onwards.111 Reimplementation of APIs is a common denominator for efficient government..
CONCLUSION
For the foregoing reasons, the decision of the Court of Appeals should be reversed.
Respectfully submitted,
Charles Duan
Counsel of Record
R Street Institute
1212 New York Ave NW Ste 900
Washington DC 20005
(202) 525-5717
[email protected]
Meredith F. Rose
Charlotte Slaiman
Public Knowledge
1818 N Street NW Ste 410
Washington DC 20036
(202) 861-0020
Counsel for amici curiae
January 2020
