Copyhype

This morning, the Federal Circuit dove into the wild and wooly world of software copyright, hearing oral arguments in Oracle v. Google. The case between the two juggernauts could have enormous implications for the software industry, which contributes more than $260 billion to the U.S. GDP each year and employs 2 million U.S. workers.

Oracle licenses the programming language Java.¹Which it acquired after purchasing the original creator of Java, Sun Microsystems, in 2010. To keep things simple, I’ll use “Oracle” throughout this article to refer to Oracle or Sun. One of the key features of Java is the Java Virtual Machine, which enables Java programs to run on any platform—a software developer can “write once, run anywhere” using Java.

To facilitate development of Java applications, Oracle also created a set of packages, or APIs. Each package is made up of multiple classes, and each class consists of a set of methods, each of which performs a specific function. Rather than writing a specific function from scratch, a Java developer can simply drop in a reference to the API.

While Google had become dominant in the desktop world by the mid 00’s, it was facing a lot of competition in the quickly growing mobile space. It acquired Android, Inc., in 2005 for the mobile software platform the company was developing, and began discussions with Oracle to license the Java operating system in order to quickly tap into a community of developers to build up a universe of apps.

But after five years, negotiations fell apart. Undeterred, Google created its own virtual machine and packages, but also copied verbatim the declaring code of 37 of the most popular Java packages. Oracle sued for copyright and patent infringement.

The procedural history of the case so far is a bit complicated because of the complexity of the issues. The trial was broken up into phases to address the patent and copyright issues separately. During the copyright phase, the jury was told to assume that the code was copyrightable to determine whether Google infringed the API packages, whether the infringement was fair use, and whether any copying of other snippets of code was de minimis. The trial court would later determine whether, as a legal matter, the code actually was copyrightable—the thinking was that this sequence would avoid a retrial if the judge found the code was not copyrightable and an appeals court reversed; the appeals court could then simply reinstate the jury’s verdict.

The jury found that (assuming the code was copyrightable) Google had infringed the 37 Java API packages but deadlocked on the fair use question. It also found that all snippet copying was de minimis except for one, a snippet named “range-Check.”

However, when the court then looked at copyrightability in the first instance, it held that Google had not copied anything protected by copyright. It based its holding first on the fact that Google had not copied the code that implemented methods from Java. Second, the “structure, sequence and organization” of the 37 packages that Google did copy from Java—amounting to over 7,000 lines of code—was not copyrightable because the court considered it a “system” or “method of operation,” both of which are not copyrightable under Section 102(b) of the Copyright Act.

Oracle appealed the decision to the Federal Circuit, which must determine whether the statutory copyright protection for software extends to source code and the structure, sequence and organization of the Java packages that Google admits to copying and whether that copying qualifies as fair use. Affirmation would endorse the type of free-riding Google engaged in here and erode the ability of software creators to invest in the constant innovation that drives this vibrant sector.

When does copyright protect software?

Software is protected under the Copyright Act as a “literary work.” Figuring out what exactly is protected and is not protected, however, can quickly become complicated, as application of copyright’s doctrines occur at a much more conceptual level than other subject matter. For example, copyright protects form, not function²Mazer v. Stein, 347 US 201 (1954).—but how is that applied to software code, all of which performs some sort of function?

The district court’s holding that Google only copied nonprotected “methods of operation” seems most vulnerable on appeal. The court itself even admitted that “nothing in the rules of the Java language . . . required that Google replicate the same groupings.” Any concerns that protecting Oracle’s expression in its Java packages would prevent other developers from the underlying functional ideas are overstated. Indeed, Google was here able to deliver the same functionality without copying the Java implementations.

It’s difficult also to see how the interoperability argument holds up: Java and Android are not interoperable. Oracle’s appellate brief points out that this, in fact, is one of the primary reasons the two parties failed to reach a licensing agreement: “Google wanted to be the only company ever allowed to use the Java packages commercially without making its implementation compatible with the Java virtual machine and therefore interoperable with other Java programs.” The reason Google copied the 37 packages was to attract app developers more easily, not to create a compatible product. At the very least, the question of interoperability should be addressed as part of the larger fair use inquiry, not under the threshold question of copyrightability.

Last week, IP attorney Lee Gesmer discussed some further legal nuances in the case that are well worth a read.

In the end, a win for Google at the Federal Circuit would not, as some have said, be a win for innovation and interoperability—just the opposite, in fact. A win would create a preference for copying and free-riding over innovation. And, as stated above, the copying here created less interoperability rather than more.

This is especially concerning because of how Google increasingly operates. Some have suggested that Google uses open source as a “Trojan Horse” for locking users into its own closed ecosystem. That is, it creates an open space that is freely available to jump start its marketshare, than slowly creeps toward closed systems as it increases dominance. Last month, Rom Amadeo discussed this in an Ars Technica article, Google’s iron grip on Android: Controlling open source by any means necessary. Amadeo said:

While Android is open, it’s more of a “look but don’t touch” kind of open. You’re allowed to contribute to Android and allowed to use it for little hobbies, but in nearly every area, the deck is stacked against anyone trying to use Android without Google’s blessing. The second you try to take Android and do something that Google doesn’t approve of, it will bring the world crashing down upon you.

Judges seemed skeptical of Google’s argument this morning, but a ruling is not expected for several months.