[Guest post] Go forth and reimplement your APIs: the April 5th Supreme Court judgment in Google v. Oracle

As IPKat readers will know, a few weeks ago the US Supreme Court delivered its much-awaited judgment in Google v Oracle. The IPKat is now pleased to host an analysis of the ruling by Kasper Drazewski (BEUC).

Here’s what Kasper writes:

by Kasper Drazewski

In 2010, when Oracle took over the failing Sun Microsystems and sued Google for USD 9 billion for copying parts of the Java API into Android, to many observers the very notion of copyrighting APIs was a novelty, if not purely absurd. Application Programming Interfaces could be likened to virtual terminals allowing programs to interact with each other. For languages like Java, this is crucial: they are only valuable if many programmers can freely use and improve them, and one cannot implement a language without the APIs. For this reason, Sun had taken no issue with Apache reimplementing Java and was similarly fine distributing for free its own open-source implementation.

However, what may have been fundamental to software people, proved quite difficult to explain to lawyers. In his 2016 testimony in the Northern District of California, former Sun CEO Jonathan Schwartz attempted the following analogy: it was like having restaurants fight over rights to an arrangement of hamburgers on a breakfast menu, instead of competing on the product. Judge Alsup, despite having been a programmer himself, admitted the witness was making no sense at all.

By the time Schwartz immortalized himself with the apparent belief that hamburgers belonged on breakfast menus, Oracle’s campaign had already been waged for four years – since the initial suit in 2010, it had seen a loss on grounds of patents, a loss on copyrightability, then a staggering win on copyrightability on appeal and now was being waged on the aspect of fair use. The jury sided with Google. The Federal Court again reversed on appeal, noting that verbatim copying of others’ work, to use it for the same purpose of function in a competing product, could not be deemed fair. The Supreme Court, already having refused once to hear the case after Oracle’s first successful appeal, this time granted certiorari to rule on the aspect of fair use.

This required the Court to perform a balancing act by weighing four factors, established by case law and codified in the 1976 Copyright Act: the purpose and character of the use, the nature of the copyrighted work, the amount or substantiality of the portion used, and the effect on the potential market for, or value of the work. Importantly, these are not exhaustive criteria; also their relative weight is assessed on a case-by-case basis. For this reason, the fair use doctrine has long attracted criticism for its unpredictability. This was meant to be remedied by the notion of ‘transformative use’, proposed in 1990 by Judge Pierre N. Leval, roughly defined by using the borrowed property as raw material for creating ‘new information, new aesthetics, new insights and understandings’. Although its ambitions to bring a solid conceptual base into fair use cases were slightly curbed by criticism for being unpredictable and vague in itself, ‘transformative use’ has become a useful benchmark for courts accepting or rejecting a fair use defense since the 1990s.

Starting its fair use analysis by commenting on the nature of the copyrighted work, the Court noted how the Java API contained three types of code. First, there was implementing code; this contained the actual instructions for tasks to be performed by the computer. This code had been written by Google. Secondly, ‘method calls’ which could be explained as commands associated with the calling up of each task. Oracle did not claim infringement there. Thirdly, there was code which associated the given method call with the corresponding implementing code. This type of code labels the individual tasks and organizes these tasks into packages and classes. The Court likened it to file cabinets, drawers and files. This code was found to be ‘inextricably bound’ to the ideas of division of tasks, of organizing tasks, to use of specific commands, all of which are not copyrightable. It is also ‘inextricably bound’ to implementing code, which is copyrightable, but was not copied.

Declaring code and implementing code had obviously different capabilities but also required different types of creativity, implying a different level of protection. Programming a task means choosing out of many ways of achieving its purpose, factoring in the memory size, CPU power or battery level. On the other hand, the function names in the declaring code were devised to be the most intuitive and easy to remember, to attract programmers who could use it and help develop it further. Due to extensive evidence showing the divide between the ‘user-centered’ declaring code and the ‘innovative’ implementing code, the Court concluded that declaring code – if copyrightable at all – is ‘further than most’ from what it called the ‘core of copyright’. On this basis, this criterion was found to point to fair use.

Looking at the purpose and character of the use, this part of the analysis centered on whether Google added something ‘new and important’ that would make its use transformative. In assessing this, the Court noted, that Google, through Android, offered a new range of tasks which were labeled and organized using the structure that was copied, albeit only insofar as needed to allow programmers to work them using a language they were familiar with. Notably, reimplementing interfaces is considered standard practice in the software industry, which is paramount to creating interoperable software and competing in the market; for this reason, Sun had also used pre-existing interfaces in creating Java. In view of these considerations, the character of the use – despite taking place in a commercial endeavor, and in questionably good faith – was found to support fair use as well.

In examining the amount and substantiality of the portion that was used, the Court noted that the 11,500 copied lines of code may objectively be seen as a lot. Still, when considered in context of the Java API, it was only 0.4 percent of the total set counting 2.86 million lines. Quantity alone is not always decisive: the Court pointed out that even a small taking can amount to a large part of the creative expression of the original work. In this case, however, the only purpose of the copied code was to call up the tasks it was bound to. Their copying was not dictated by their ‘creativity’ or ‘beauty’; it was only to allow programmers to use the language they knew and apply it using their own creativity. Hence, this factor too was found to weigh in favor of fair use.

Lastly, when assessing the market effect of the copying, it is not sufficient to look at the lost revenue. Market effects, the Court observed, can also kill the demand for the original work; these harms must be weighed against what the public stands to gain due to the copying. Sun had, in fact, tried to enter the smartphone market and started branding and licensing negotiations with Google. These failed as Sun insisted on necessary interoperability of all programs written for their platform; Google preferred to leave it open to developers. In reality, though, the two systems did not compete as they had their own market segments; simple devices like ‘feature phones’ or the Amazon Kindle would run on Java SE, while more advanced products like smartphones or the Kindle Fire would use Android. Evidence showed that Sun had sought to work with Google to expand the network of Java-trained programmers, while the attractiveness of its APIs to Google lie not in their creativity but in their widespread adoption and the fact that programmers were simply ‘used to it’. This also meant one more thing: to allow Oracle to enforce its copyright would risk harm to the public. The analogy used was that of a lock limiting the future creativity of new programs, with the rightsholder holding the only key. This, the Court found, was contrary to the basic objectives of copyright and again favored fair use.

‘Applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit’, SCOTUS noted, quoting Lotus Development Corp. v. Borland, to illustrate the point that the functional nature of computer programs renders it difficult to determine the adequate level of copyright protection. Historically, the functional nature of computer programs, oft accompanied with a near absence of an expressive or artistic aspect, had given rise to debates over whether they should be copyrightable in the first place. In 1974, this prodded Congress to appoint a dedicated body, the National Com­mission on New Technological Uses of Copyrighted Works, to examine the issue. The end report, delivered in 1978, took a clear position: software should be copyrighted, but copyright should not “grant anyone more economic power than is necessary to achieve the incentive to create”. It also noted that, despite the unique (read: functional) nature of computer programs, a case-by-case application of the existing doctrines – including fair use – was sufficient to prevent copyright holders from stifling innovation.

In its opening analysis, the Court observed that fair use is useful in assessing the lawful scope of copyright protection as it can distinguish between technologies. This includes differentiating between “expressive and functional features” in cases where they are mixed, as well as safeguarding the incentive to produce new material, being mindful of the risk of harms “in other markets, or to the development of other products”. Shortly put, this “context check”, as the Court called it, can help keep the copyright monopoly “within its rightful bounds”.

The Court’s observations on usefulness of fair use in the evaluation of software copyright cases were caveated by the dissent of Justice Thomas, supporting Oracle’s long-applied narrative that ‘code is code’. Thomas contested distinguishing among types of computer code can be conducted while examining ‘the nature of the work’ and noted that reuse of code in a new program can never have a ‘valid purpose and character’. The Court noted this dissent but disagreed, noting that Congress chose to place software in the copyright regime with no caveats, trusting in the existing doctrines to provide all the individual distinctions each case may require. Consequently, it was pointed out that just as fair use distinguishes between books and films, it must draw lines between computer programs; similarly, as it takes account of the market for scripts and paintings, it must give software the same consideration. This close to ‘all or nothing’ take proposed by the dissent was thus considered and rejected by the Court.

Notably, in discussing the dissent, the Court did not choose to venture into more detailed examples that would perhaps reflect the nature of the dissent to a greater degree. Justice Thomas’ critique targeted differentiation between types of ‘raw’ computer code, rather than entire programs as used in the example. However, this choice of the Court appears deliberate. To object to this reasoning would be to claim that copyrightability of software programs should be guided by different principles than copyrightability of parts of code, which would also contradict Oracle’s position since the inception of the case.

With all four factors found to support fair use, the judgment put an end to the $9bn ‘copyright case of the decade’. When it was first filed, the Internet was a different place and Google was a different company, still fighting for Google Books to be declared fair use and risking bankruptcy in the event of a failure. Facebook was yet to invent Timeline. Amazon had a 10% market share in North America. The big tech giants of the digital era had already emerged and were gaining speed, but the degree of market domination they would achieve ten years later was still difficult to fathom.

This leads to one more reflection: one may never know whether this oligopolisation of cyberspace had not in the meantime become another reason for the Court to think twice before allowing companies the level of control that comes with deciding who gets to reimplement their APIs and write compatible software. This could certainly be deemed a creative use of the last fair use factor, but the statutory list of four factors is by no means an exhaustive one.