The Google/Oracle decision was bad for copyright and bad for software

Former Oracle CEO Larry Ellison, pictured here speaking at a conference in 2006, was one of many execs to take the stand in Oracle v. Google"/>

Oracle's long-running lawsuit against Google has raised two contentious questions. The first is whether application programming interfaces (APIs) should be copyrightable at all. The second is whether, if they are copyrightable, repurposing portions of those APIs can be done without a license in the name of "fair use."

In the first trial between the companies, the court ruled that Google had copied portions of Java but that these copied portions were mere APIs; as such, they were not protected by copyright law. An appeals court later reversed this part of the decision, asserting that the "structure, sequence, and organization" of an API was in fact protectable by copyright. The case was then returned to the trial court to ascertain whether the (previously acknowledged) copying of (now copyright-protected) Oracle material was an infringement of copyright.

In this second trial, held last month in San Francisco, a jury found that Google's use of the API code was protected as "fair use." Fair use is an affirmative defense; it acknowledges that the material in question is properly protected by copyright but that this unauthorized use is nonetheless allowed to more broadly serve the public interest.

Many in the software industry prefer that APIs be unprotectable by copyright, obviating the need to go to court in such cases, but they are still glad that Google's affirmative defense worked.

But I'm not sure that's the right way to understand what happened. In my view, the appeals court made the right call on copyright—but the jury probably didn't on fair use.

The great war: idea vs. expression

Source code and APIs sit in an awkward spot with regard to copyright law. Copyright protects expression rather than mere ideas. Moreover, it is intended to protect creative works, not those that are inevitable consequences of some idea or functional requirement.

The literal source code of a program has, since 1980, been unambiguously copyrightable as expressive text. The compiled executable derived from that source code is functional, so it might not at first seem to benefit from the same protection. Since the 1983 Apple Computer, Inc. v. Franklin Computer Corp. decision, however, compiled code has also been protected by copyright; this decision enabled the distribution of compiled shrinkwrap software.

But what this protection actually means is less clear. Since source code and compiled executables both skew so heavily towards the "functional," the nature of this protection has never been as robust as it is for, say, a TV show or a novel.

Consider an example: the rules of a game are, in the abstract, a mere idea. But when you embody the idea as "expressive text," only a limited number of reasonable formulations are possible. (Rulebooks, by their nature, are extremely functional documents.) "Expression" is thus so closely tied to the underlying "idea" that in US copyright law, the two merge (this is called the "merger doctrine"), which strips the written rules of their copyright protection.

This functional/expressive duality makes copyright law difficult to implement for software. On the one hand, courts agree that source code text is expression. On the other hand, they agree that software is functional, and that the expression found in the code is driven by an idea. Whether a piece of software is deemed to be "more expression" or "more idea" is therefore somewhat arbitrary, and it varies according to the scope of what is being examined.

An individual fragment of code like a = b + c; is too closely driven by a functional need—"efficiently add two numbers and store the result in a third"—to justify copyright protection. A program category—"a word processor" or "an operating system"—is clearly an idea and similarly not protectable. But between these extremes lie many levels of abstraction—language expressions, code blocks, functions, libraries, and so on—that do warrant protection.

The courts have devised an approach to determining which parts of a program are protected and which are not. The "structure, sequence, and organization" (SSO) of a codebase, an idea introduced in 1986's Whelan v. Jaslow, covers those elements of the code that are not strictly governed by the program's functional needs.

In the early years of the Whelan approach, only the very broadest ideas and the very narrowest fragments of code (those for which the merger doctrine applied because the source code is inextricably tied to the idea expressed) were excluded from copyright protection. Every other aspect of a program was copyrighted. This allowed courts to make broad decrees—for example, that cloned user interfaces could be copyright violations even if the actual source code used to implement them is unique.

Subsequent courts have weakened this protection. The strict test described in Whelan v. Jaslow came too close to protecting algorithms and ideas—which copyright is not meant to protect—and almost any element of source code could thus be deemed non-essential and therefore protected. Cases like Healthcare Affiliated Services v. Lippany broadened the use of the merger doctrine in order to exclude greater portions of the literal source code from copyright protection.

The standard still used today was created in 1992 as part of Computer Associates v. Altai. The decision in that case acknowledged the old SSO principle, but it also said that "ideas" existed at every level of a program's organization. Thus, even in individual functions and modules, both "ideas" and "expressions of ideas" commingle, and courts must disentangle the unprotected and protected bits. Since Altai, not much beyond the literal source code has received substantial copyright protection.

Enter the API

These protections, such as they are, ought to be as applicable to APIs as they are to source code, and the appeals court was correct. APIs are not something that is wholly distinct from source code. An API at its heart is a combination of literal source code—the functions, classes, data structures, and so on that constitute a software interface—and some form of behavioral contract. APIs suffer the same conflict between expression and idea; while functional needs can shape an API and in some cases may even be a straitjacket that constrains an API's expression, they do not exclude creativity.

And just as with source code, APIs have a "sequence, structure, and organization," a non-literal component in addition to and on top of their literal code. The breadth of design decisions, the interactions between different parts of the API, and the organization into logically related units, for example, are all elements related to but beyond the literal source.

The Java API that Google partially copied is a perfect example. Some aspects of the API are quite functionally driven. Strings, for example, have a length concept, and this is done in substantially the same way in many languages. java.lang.String calls the function int length(), .NET's System.String calls it int Length { get; } (using marginally different syntax but the same name and type), C++'s std::string calls it size_t size(), using a near synonym as its name.

But other aspects are not. Java, like many other languages, defines a selection of data structures as part of its API. (For instance, most libraries include a structure that's an ordered sequence of objects with objects accessible using integer indices and which allows new objects to be inserted at the end; a structure that's an ordered sequence of objects and which allows new objects to be inserted at any position; a structure that contains a unique and unordered set of objects; and a structure that contains a mapping from one set of unique, unordered objects to other objects.) But these aren't identical; a wealth of subtleties define each implementation.

APIs suffer the same conflict between expression and idea; while functional needs can shape an API and in some cases may even be a straitjacket that constrains an API's expression, they do not exclude creativity.

For example, providing both of those last two structures is strictly speaking redundant, as each one can be used to implement the other. Reflecting this, they can have types that are related, but they don't have to be. Such differences might be relatively small, but even these kinds of differences will influence how developers make use of an API.

Other decisions are more impactful. Many data structure libraries include some kind of iteration capability, to allow each element of the structure to be accessed in turn, but the approach taken by Java is quite different from that of .NET or C++. Not only are the literal names different—java.util.Iterator compared to System.Collections.IEnumerator or C++'s iterator concept—but so are the capabilities. Iterators can be viewed as referencing the "fence posts" that exist "between" objects, as Java's are, producing an object each time the iterator is moved from fence post to fence post, or as referencing the objects themselves, as in C++ and .NET. Java's Iterator and .NET's IEnumerator "know" how many objects exist in the data structure and won't let you move them beyond the end of the it; C++'s equivalent, in contrast, doesn't know this and will typically let developers reference no object at all.

To handle this, C++ usually requires iterators to be used in pairs, to denote the range of objects being iterated. This in turn makes it very easy for C++ developers to enumerate the objects in partial ranges. This is much more awkward in Java and .NET. Conversely, the enumerators and iterators used in Java and .NET are much easier to pass around in functions, making it straightforward to create functions that operate on and manipulate full ranges (.NET's LINQ being perhaps the best example of this).

All of these approaches meet the same broad functional goals. But the functional goals are not so strictly constrained as to eliminate creativity. Developing a good API that affords the right balance between expressive power for developers and ease of use for newcomers is a difficult, creative task, representing not science but some level of artistry. Many APIs, it turns out, are poorly designed, written in such a way as to make incorrect usage easy and correct usage difficult. (C's string API is a good example of this.)

Some of the APIs that Google copied were trivial. But others, such as the data structures in java.util, the SQL interface in java.sql and javax.sql, the I/O routines in java.io and java.nio, and many others, are anything but. As such, it's entirely appropriate to protect APIs, both in their literal text and in their sequence, structure, and organization. In my view, then, the appellate court got this one right. So what impact will this have on developers?