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. 1Which 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 2Mazer 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.