The ongoing Oracle v. Google case is headed to the Supreme Court, and we submitted an amicus brief in support of Google today.
As a recap — Oracle sued Google in 2010, accusing the tech giant of copying over 11000 lines of code from Oracle’s Java programming language application programming interface (API). Google deployed the code in Android, now the most popular mobile operating system in the world.
An important point we want to emphasize — this case should be resolved on copyrightability grounds, not the fair use doctrine. The U.S. Court of Appeals made this error and we hope the Supreme Court doesn’t repeat it. Fair use is a powerful and important component of copyright law, but it shouldn’t be used for this specific case regarding APIs. Here’s why:
First, the importance of API reimplementation to competition is incompatible with fair use litigation, which can often require a full-blown trial since the doctrine is a mixed question of both law and fact. If one virtue of API reimplementation is to encourage small, competitive entrants, requiring these new entrants to cover the cost of federal litigation would eviscerate that virtue as a practical matter. Uncertainty in the fair use doctrine is especially problematic with respect to API reimplementation. Though fair use is predictable in many literary domains such as news reporting and parody, the fact that it is so open-ended and case-specific creates uncertainty particularly in new domains such as software interfaces. That uncertainty would be especially troublesome for risk-averse entities who may have the strongest cases for reimplementation.
When it comes to cases dealing with APIs in particular, the use case for a fair use is likely to look a bit like Google’s: Building a business or expanding a business using an API to provide interoperability or enhanced functionality or usability. Where those use cases can be expected to differ from Google is in the size of their litigation budget. A large company like Google can afford to litigate a fair use case it knows it should win. A small business often cannot. To make this right actually meaningful to innovative small businesses who wish to use APIs in the commonly accepted way, the Court should hold that APIs are not copyrightable, rather than relying on fair use in this case.
An internet platform or a computer programming language may become popular with a group of developers, and then with a group of users as a result. Both the developers and the users want to have access to each other, so the platform grows. A new platform then faces a significant barrier to entry: All the users and developers are on this other network. A few users may want to switch, but they cannot get much use out of the new network without developers, and vice versa. Instead, the new platform or new language needs to be interoperable with the old system. Using or reimplementing the dominant firm’s API is an important path to market for a competitor.
If there is no copyright protection, this is a business risk a potential competitor may be willing to take. If that potential competitor must rely on the fair use exception to copyright protection, it becomes a different calculus. Now the company must go to court to vindicate its right to use the software. This entails significant legal risk as well as the financial and time resources required for litigation. Startups, small businesses, and their funders are not likely to be willing to take on this type of fight. Consumers will be left with few options, little innovation, and less progress.
Also, the statutory factors of the fair use doctrine are plainly unhelpful when applied to API reimplementation. The third factor of the fair use doctrine, the “amount and substantiality of the portion used,” for example, seems backwards in the API context. In fair use traditionally we see greater social value in the works that are more original, more different, and use less of the pre-existing work. However, when we think about the use of APIs, we hope that the second user provides greater compatibility. Greater compatibility with the original is the socially valuable use, rather than less. But greater compatibility also requires more copying, not less. The fourth factor, market effect, risks courts conflating the value of the API with that of the products and services underlying the API.
If the Court does apply fair use here, it should identify factors specific to API reimplementation, which should in some cases be different from the way fair use has been used in the past. In order to avoid confusion among the courts and to ensure a competitive marketplace, the Court should provide clear, specific rules on the reimplementation of APIs. The best way to ensure this is to hold that APIs are not copyrightable.