|Did you know...?|
LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.
The US Court of Appeals for the Federal Circuit (CAFC) has overturned [PDF] a district court ruling on API copyrightability in Oracle v Google, which makes for a dramatic reversal in that litigation. With Oracle the victor (for now), the judgment looks, at first glance, to be troubling for the US software industry. The case is far from over, however, so there could be more sharp turns as it continues its way through the court system. For one thing, the CAFC raised the question of "fair use", which could upend things again depending on what decision is made.
Much has happened since LWN last covered the case, which all started a few months after Oracle acquired Sun (who developed Java) in 2010. That's when Oracle sued Google in the US District Court for the Northern District of California for alleged patent and copyright infringement in its implementation of Java as part of the Android operating system.
In his decision [PDF] for that court, Judge William Alsup ruled that APIs are not subject to copyright. The jury also ended up throwing out the claims of patent infringement. Oracle appealed the copyright ruling (but not the jury's decision on the patents) to the CAFC, and last week it got what it hoped for: a complete reversal of that ruling. In its 69-page ruling, the CAFC demonstrated a lot of things. It showed an excellent grasp of the technicalities of computer software, the Java programming language, and the differences between Oracle's Java and Google's Java-like system that powers its Android operating system. It showed a strong grasp of American copyright case law and legislation, tracing the history of various doctrines in copyright law and explaining much of the basics of copyright law. If I were a US law professor teaching copyright, I would definitely include this ruling in my course syllabus, if only for the sheer depth of the decision.
Most interesting (and potentially distressing) for software developers and businesses — indeed, the entire US software industry — is the actual reasons why the CAFC overturned Judge Alsup's decision. In this case, after talks for a license to Java with Sun broke down, "Google copied the declaring source code from the 37 Java API packages verbatim [...] [and] wrote its own implementing code, except with respect to: (1) the rangeCheck function, which consisted of nine lines of code; and (2) eight decompiled security files" (pages 10-11). It is important to note for the purpose of this ruling that Google has actually conceded to this verbatim copying in court. Having reviewed the facts, the CAFC goes through argument after argument on why it reversed the lower court's ruling.
As the CAFC was handling a copyright appeal from a court within the Ninth Circuit territory, it applied Ninth Circuit copyright doctrine. That includes an "abstraction-filtration-comparison" test to determine whether one program is "substantially similar" to another (the bar to meet for copyright infringement via copying): first, you abstract away the expression of the software idea from the idea itself; then, you filter out the parts of the software that aren't subject to copyright; and lastly, you compare the alleged infringing work with the plaintiff's work. The CAFC brings this test up to bat away the argument that APIs aren't copyrightable because they are functional works, as opposed to expressive forms of creativity like music: "This test rejects the notion that anything that performs a function is necessarily uncopyrightable" (page 23).
The CAFC threw out Google's "merger doctrine" defense (i.e. when an idea has only one viable form of expression, you can't distinguish between the two and therefore can't copyright either) on the grounds that Google could have rewritten the few thousand lines of Java source code and achieved the same effect: "nothing prevented Google from writing its own declaring code, along with its own implementing code, to achieve the same result" (page 32).
The CAFC also tossed out Google's "short phrases" defense regarding method declarations (basically, Google argued that you can't get a copyright on a short phrase). The court asserted that there was sufficient creative expression for them to meet the threshold of copyrightability: "Because Oracle 'exercised creativity in the selection and arrangement' of the method declarations when it created the API packages and wrote the relevant declaring code, they contain protectable expression that is entitled to copyright protection" (page 34).
The "scenes a faire" doctrine — meaning you can't get a copyright on certain expressions if they are "commonplace[,] [...] indispensable [...] and naturally associated with the treatment of a given idea," (page 35) — also doesn't help Google. That's because Google didn't demonstrate that the Java code it used was commonplace and indispensable in that fashion.
Rounding out the issue of copyrightability, the CAFC found the structure, sequence, and organization of Oracle's Java APIs to be "creative and original", as well as one of many possible ways to implement the Java programming language itself. The CAFC notes that, as this finding is consistent with the abstraction-filtration-comparison test it referred to earlier, it demonstrates the copyrightability of Oracle's Java APIs.
Although this is indeed a dramatic reversal of a ruling which seemed to adhere to the expectations of many in the software world — that APIs aren't copyrightable because of the need for interoperability — it is important to keep the ruling in perspective. First, this ruling only applies to courts within the Ninth Circuit, which encompasses most of the western US. Second, the court has not stated that interoperability and reimplementation of APIs without authorization are banned in that region. Indeed, Oracle itself makes this clear (as cited in the ruling): "Oracle claims copyright protection only in its particular way of naming and organizing each of the 37 Java API packages" (page 43). Thus a reimplementation with new source code, names, and structures would avoid the CAFC's ire. Unfortunately, such dramatic changes would leave you with a different API, so that leeway seems somewhat useless to software developers.
Third, the CAFC didn't rule on "fair use". The fair use doctrine gives courts some discretion to find that certain unauthorized uses of copyrighted works are not infringing. The test includes the following (which are not exclusive):
The jury at the district court couldn't decide whether or not Google's use of Java was fair, and Judge Alsup didn't address the issue because he didn't think that the APIs were copyrightable at all. Since the CAFC (rightly) feels that it's more appropriate to let the lower court handle this issue, as it has much more familiarity with the whole of the case than does the CAFC, it has remanded the case back to the district court to make a fair use determination.
The CAFC did specifically note that Google may be able to persuade a jury that its use of Java was fair. Unfortunately, fair use as a defense in these situations won't prevent a significant chilling effect on independent software developers and smaller companies who may have been interested in reimplementing APIs as part of a commercial project. Indeed, this ruling may have opened the floodgates for "API trolling" within the Ninth Circuit.
It's worthwhile to note, as the FSF has, that Google could have avoided this legal mess by using a GPL-licensed version of Java, such as IcedTea. But Google chose not to. Given last week's ruling, it seems possible that there are people on Google's Android team feeling some regrets about that decision.
It's also important to realize that this case is not closed. With the fair-use issue back to the district court to make a ruling, and an appeal route on the CAFC's copyrightability ruling to the Supreme Court available to Google, this litigation isn't going to stop anytime soon. More twists and turns are possible in the coming months and years.
Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds