No Definitive Answer on Copyrightability, but a Thumb on the Scale

Google emerged from a 10-year, all-out battle with Oracle over Google's reproduction and use of the Java application programming interface (API).

Copyright practitioners have been waiting to hear whether the declaring code portion of APIs can be copyrighted. The Supreme Court decided not to answer that question. But it left some grounds at the bottom of this cup of java from which the future might be divined.

Note: depending on your definition of API, the term "declaring code" can be considered interchangeable with "API." The important point is analyzing the copyrightability of whatever portion of code remains after being separated from the underlying substantive/complex portion of the code (the "implementing code").

Why Is This Case So Important?

In my opinion, Google v. Oracle is not so much about copyright theory as it is about the extent to which the Copyright Act can be used to erect a functional barrier to market entry.

Consider that Google determined that it could—and did—rewrite millions of lines of code to create its own platform (Android). Op p. 3. But without reusing about 10 thousand lines of the Java API, Google knew the industry would never accept Android.

In other words, it was not the nuance, organization, or "magic" of the Java code (called the "implementing code") that made it valuable. It was its existence as a standard interface with which programmers were familiar.

The Court recognized such important realities of standardization in code development:

• reimplementation of interfaces is necessary if programmers are to be able to use their acquired skills.?
• reuse of APIs is common in the industry.?
• copyright on largely functional elements of software that have become an industry standard gives a copyright holder anti-competitive power.

Op. p. 26.

Indeed, the Court concluded:

Given the costs and difficulties of producing alternative APIs with similar appeal to programmers, allowing enforcement here would make of the Sun Java API’s declaring?code a lock limiting the future creativity or new programs. Oracle alone would hold the key.

Op. p. 34 (emphasis added).

What Is an API?

As elusive as the answer to the copyrightability question is an intuitive description of APIs. The Court provided a somewhat helpful—but also somewhat strained—analogy about instructing a robot to find a recipe in a cabinet. Op. p. 7. Justice Thomas likened APIs to a defined-term with a lengthy definition. Dissent p. 2.

It may be easier to focus on the purpose APIs serve. They are an organizational structure that allows one to ignore the dizzying details underlying that structure. They are akin to the outline of a brief, the sections of a detailed repair manual, the list of topics on the first slide of a presentation.

The Supreme Court Punts on the Big Question

If I copy your outline, but write my own arguments, is it copyright infringement? What if I copy the section headings of your repair manual but come up with my own fixes? What if I copy the topics of your slide presentation but swap out the individual slides in each section?

To get to an answer, you'll need to ask two questions:

1. Are things such as outlines, section headings, or lists of topics copyrightable in the first place?
2. Does using such aspects of a work (without the underlying substance) constitute fair use?

The Court declined to answer the API-specific version of question 1. Op. p. 15

But Court ruled that the answer to the API-specific version of question 2 was "Yes"—at least in Google's case.

Unfortunately for those of us who do not own a stake in Google, the answer to question 2 is significantly less helpful than the answer to question 1 would have been. The fair use analysis is too highly fact-specific and subjective to be generally applicable:

Th[e] background, as well as modern courts’ use of the [fair use] doctrine, makes clear that the concept is flexible, that courts must apply it in light of the sometimes conflicting aims of copyright law, and that its application may well vary depending upon context.?

Op. p. 15.

For example, the amount of code taken and the specific effect on the market at issue controls the fair use analysis. id. p. 19. Those facts will vary wildly from case to case. Thus, any individual court ruling will have relatively limited relevance to other cases.

The answer to Question 1 would have been more far-reaching. It would have provided a threshold answer to whether the Copyright Act will ever allow a software development company to copyright its API/declaring code and use the copyright to corner the market.

Thumb on the Scale

The Court expressly stated that it would not consider the question of whether APIs are copyrightable. Op p. 15. But, in the context of fair use, it provided some pretty big hints on the majority's view.

One element of the fair use test is "the Nature of the Copyrighted Work." 17 U.S.C. § 107; Op. p. 21. Thus, the Court was forced to comment on how copyrightable an API might be. When discussing the nature of the work at issue, the Court stated:

"the declaring code is, if copyrightable at all, further than are most computer programs . . . from the core of copyright."

Op. p. 24 (emphasis added).

Indeed, the Court drew a dividing line between declaring code and other code:

Like other computer programs, it is functional in nature. But unlike many other programs, its use is inherently bound together with uncopyrightable ideas (general task division and organization) and new creative expression (Android's implementing code)

Op. 23-24.

Those uncopyrightable aspects, as the Court described them, seem pretty pervasive in the declaring code:

• "[the declaring code] is inextricably bound together with a general system, the division of computing tasks, that no one claims is a proper subject of copyright.
• It is inextricably bound up with the idea of organizing tasks into what we have called cabinets, drawers, and files, an idea that is also not copyrightable.
• It is inextricably bound up with the use of specific commands known to programmers, known here as method calls (such as java.lang.Math.max, etc.) that Oracle does not here contest.

Op p. 22-23 (separated into bullet points).

It is important to note that in order to reach the fair use analysis, the Court had to "assume, for arguments' sake, that the material was copyrightable." Op. p. 1. With that assumption, the Court went hunting for aspects of creative expression, and came up with little.

Indeed, the "kind of creativity" embodied in declaring code, according to the Court, was that which would make it "easy to remember" and "learn." Op. p. 23. Creative or not, those aspects invoke a strong sense of functionality. And, while functionality does not automatically preclude copyright protection, it does squeeze the vice.

Consider that declaring code in APIs was already the remnant of boiling off the implementing code, where much of the creativity or "magic" would have lain. Op. p. 23. Consider also that even less of the work will remain after excising the uncopyrightable aspects listed above. And consider that the Court applied an awfully functional-sounding description ("easy to remember") to whatever might remain.

That description is awfully close to the type of operational rudiment copyright fails to protect:

We have no reason to believe that the Copyright Act seeks to protect third parties’ investment in learning how to operate a created work.?

Op. p. 34 (citing Campbell v. Acuff-Rose Music, Inc., 510 U. S. 569, 577 (1994)).

Finally, Just Thomas' dissent garnered only the agreement of Justice Alito. There were, for example, no other concurring opinions addressing copyrightability or others adopting the dissent's view that such works are copyrightable.

Simply put, the above statements and votes, leave declaring code in no more secure a position than teetering on the brink of copyright protection.