Each year for the annual Open Source Security and Risk Analysis report, the authors highlight key aspects around open source that you likely wouldn’t expect. In the 2020 edition, we gave some coverage to the Google LLC v Oracle America, Inc. case before the US Supreme Court. In case you missed it, Oracle sued Google over Google’s use of Java SE API signatures in Android. Android is open source, but a ruling against Google could have had ramifications for the entire development community – not just open source communities.
Most modern software systems use APIs of one form or another. Mobile applications talk with server systems over APIs. IoT systems use APIs to send sensor data for analysis. Complex distributed micro-services architectures are also API driven, as is much of the data economy. These APIs are the grandkids of the type of API that Google was accused of misusing, but none-the-less a ruling against Google’s use of the Java SE API might impact them as well.
The type of API referenced in this case is a library interface. Such interfaces are made available by the library authors for programmers to access. What the API does will vary by the library, and what the library’s authors intend for a usage pattern. For example, an email library might have Create, Read, and Send methods on it. Those are obvious method names for such a library and are provided to enhance usage and interoperability. One might even argue that standardizing those methods could increase the usage of email.
In fact, we could go further and argue that such methods might belong on any messaging system such that which messaging system used is up to the user based on which library they used. If we accept that, then the eco-system of messaging libraries would benefit from a consistent interface. In other words, all messaging libraries would have the exact same calling convention.
Copyright law is what controls these types of arguments, and copyright law with computer software is particularly nuanced. A basic element of copyright protection is that the thing being protected is an expression of an idea or process and not the idea or process itself. Accordingly, it could be argued that in cases where there is really only one way to effectively express a functional purpose, that should not be copyrightable subject matter. So, if an interface can only be expressed in one consistent or conventional way, then that functional expression should not be copyrightable. In essence, a ruling for Oracle would mean that the first person to define such a library would hold the copyright and be able to charge everyone else a license fee.
Observers of the Oracle v Google case were hoping for some clarity on what is copyrightable subject matter in the case of library interfaces and, while the court did find for Google and ultimately that the use of the APIs in question was not an infringing use, it was a narrow ruling. Specifically, the court held that Google’s use of the Java code at issue was what’s known as “fair use.”
It should be noted, that “fair use” is really a defense against a claim of copyright infringement. So those hoping to read a lot into the court’s application of “fair use” are wise to do so with the warning that, as a defense, fair use is very fact specific and still likely to only come into play after a claim of infringement has been leveled. In this case, the court found that Google’s use of about four-tenths of a percent of Java code, and that fact that such code was further incorporated into a totally different product was a transformative enough use of the code at issue to qualify it as a fair use of that code.
In creating Android, Google sought to attract a large developer base who would then create applications for their new platform. Becoming proficient in any programming language requires time and an understanding of the various APIs available to the platform. While Google might create a new and unique API for Android, it chose to use the Java SE declarations for 37 of its packages – a decision that would accelerate Android application development by providing a familiar environment for Java developers. Since a smartphone isn’t a generic computing environment requiring a “run anywhere” paradigm, Android developers tuned their APIs to the platform – a decision that meant only 11,500 lines of common code were required to provide that Java experience.
This decision also had ramifications on the potential market for the copyrighted work. What consumers see when they think of Android is different than what a developer sees. An API is a means to express ideas created by developers and as such the implementation of an API is far more valuable than the expression of its interface. That Google invested in implementing a Java SE compatible programming interface is part of the success of Android and not part of the decline of Java SE based applications. With the US Supreme Court finding in favor of Google, development teams everywhere can continue innovating secure in the knowledge that implementations matter more than an API definition.