Intellectual Property

Unfair Use, Revisited: Why SCOTUS Should Review Copyrightability And Fair Use Of APIs In Google v. Oracle

This issue is far from settled, and SCOTUS review is the last resort to clarify the matter. 

By  
on

Whether you like it or not, software is an essential part of the operation of every business.  From custom-developed mobile applications to software-as-a-service solutions, computer software is no longer a supporting element but an indispensable part of every business.  Nowhere is this point more prevalent than with mobile devices, their operating systems, and corresponding applications.  I have previously written why Oracle’s ongoing battle with Google over Google’s use of Java application programming interfaces (“APIs”) is important to your business.  In January of this year, Google filed a petition for writ of certiorari to challenge the two appeals court rulings in Oracle’s favor. Essentially, Google is again trying to get the Supreme Court to review another appellate court reversal of a district court decision in Google’s favor, and the copyrightability (and fair use of) application programming interfaces (APIs) may hang in the balance.

Understanding the background of the case Oracle brought against Google is important, and I have previously summarized the background of the case in my prior writing here.  Suffice it to say that after unsuccessfully negotiating a license from Sun Microsystems (later bought by Oracle) to certain components of Java not otherwise publicly available through an open source license, Google did the next best thing — it wrote its own version of Java, but apparently copying the same names, organization, and functions as the Java APIs ostensibly to save development time (but more on that in a moment).  The dispute essentially pivots around whether APIs are protectable copyrightable expression, and if so, whether Google’s use of the Java APIs constitutes “fair use” under copyright law.  What is important to note now is that the Federal Circuit overturned the lower court’s finding of fair use by Google (again) and Google is seeking review by SCOTUS (again) to hopefully settle the issue once and for all.

It is important to note that any determination of these issues will have a significant impact on a vast majority of the software used today.  APIs do not refer to techno-jargon — they are essential pieces of code designed to help different software applications and operating systems to basically interact with each other.  Pardon the oversimplification, but in the context of Google/Oracle, think of them as a wall outlet that different software applications can “plug” to talk to the Google Android operating system.  With this in mind, now think about Oracle being able to prevent anyone from “plugging into” Java APIs without paying the piper (Oracle).  Google claims this can limit (if not stifle) innovation, while Oracle claims it’s much ado about nothing because Google didn’t get a license so it chose to copy what it needed for its Android platform.  Who is right?  The Federal Circuit seems to have sided with Oracle, but I think that SCOTUS needs to take a closer look.

What SCOTUS needs to address is the nature of what an API really is, and if copyrightable, whether Google’s use constitutes fair use.  Unlike other types of software programs, APIs are basically building blocks that define ways of communicating between components that help programmers streamline implementation of software without understanding all the underlying elements of the software.  In essence, the independent programmer can write code to call specific functions that are defined by the API.  In the present case, Google has referred to the APIs having two key components: the “declaration” and the “implementing code.”  The declaration is basically a label that calls upon a longer, pre-written module that would run, relieving the programmer of having to write the code for that function. For example, a programmer created the graphical button on this website at the top of this article to share it on LinkedIn, but the LinkedIn API is actually facilitating the call to the module to share the document through LinkedIn without the programmer having to write the code to share it to the platform.  It not only makes coding easier, but helps facilitate interoperability between systems.

In the present case, Google drives this difference in arguments that give pause to the Federal Circuit’s rulings in favor of Oracle.  In a brief filed by 78 computer scientists in support of Google (and consisting of some pretty eminent computer scientists, such as Apple co-founder Steve Wozniak), they explain the difference between an “interface” and a “program”:

Software interfaces, including those embodied in the Java Application Programming Interface (API) at issue here, are purely functional systems or methods of operating a computer program or platform. They are not computer programs themselves. Interfaces merely describe what functional tasks a computer program will perform without specifying how it does so. The Java API’s functional interfaces, called declarations, are written using the Java programming language, which mandates each declaration’s precise form.

In contrast, implementations provide the actual step-by-step instructions to perform each task included in an interface. Sun implemented the Java API for desktop computers. Google reimplemented—or wrote its own original implementation of—the Java API when it created the Android platform for smartphones and tablets. Android was highly transformative: It enabled programs written in the Java programming language to successfully run on smartphones and tablets for the first time. Doing so required Google to make significant additions to the Java API to handle mobile-specific features, like touchscreen inputs.

Simply put, these eminent computer scientists (and Google) feel strongly that APIs should be rated differently than programs because they do not “run” per se, but only specify what a program does, not how it does it.

Sponsored

It should also be noted that Google claims it only copied a very small percentage of Java code (3 percent of the 37 disputed APIs) and only the declarations.  Google actually wrote all the implementing code for Android.  So why copy these declarations?  Because the Apple iPhone was already on the market by this time and Google wanted to leverage developers’ familiarity with Java API declarations to develop to the Android operating system so Google could compete with Apple in the mobile smartphone space (which would expand Java in the mobile space, too).  You can disagree, but the whole point of APIs is to facilitate interoperability, so it’s no wonder Google feels strongly that copyright should not extend to APIs under Section 102(b) of the Copyright Act (as well as the merger doctrine), and if it does, re-implementing APIs should be fair use — a reasoned analysis that the lower courts took pains to address that Google feels the Federal Circuit did not appreciate or understand.

From my perspective, this issue is far from settled and SCOTUS review is the last resort to clarify the matter.  As stated in the amicus brief mentioned above, such interfaces helped facilitate the spread of popular operating systems (e.g., Linux, Apple OSX, and iOS) as well as the functioning of the internet and cloud computing. Whether SCOTUS will do the heavy lifting to clarify the matter, or punt by denying certiorari, is one thing (as they have punted it before).  Whether SCOTUS will get it right is an entirely different proposition.  Either way, the future of software development using APIs will be anything but business as usual.

Tom Kulik is an Intellectual Property & Information Technology Partner at the Dallas-based law firm of Scheef & Stone, LLP. In private practice for over 20 years, Tom is a sought-after technology lawyer who uses his industry experience as a former computer systems engineer to creatively counsel and help his clients navigate the complexities of law and technology in their business. News outlets reach out to Tom for his insight, and he has been quoted by national media organizations. Get in touch with Tom on Twitter (@LegalIntangibls) or Facebook (www.facebook.com/technologylawyer), or contact him directly at tom.kulik@solidcounsel.com.

Sponsored

Topics

, , , , , , , ,