July 2016

A Software Architect's Perspective on APIs and Copyrights

copywright

The topsy-turvy legal struggle between Oracle and Google over Java got me interested in the issues that have produced such divergent judgements and such passionate responses. Initially, it seemed that it was about patents, then it turned into a battle over copyrights, and then narrowed to fair use. And this battle isn’t over yet. As a programmer and an architect, I first tried to understand how the legal system thinks about copyright. So, I started thinking about books.

A book is protected by copyright. A typical book consists of chapters that consist of paragraphs that consist of sentences, and eventually we reach words. The same book may also contain illustrations, a table of contents, and a cover. A book may have a particular type of binding and the pages may have a certain thickness and feel. So, when a part of a work is used by another author, how does the legal system decide whether it is an infringement? Simply using the same words in different sentences isn’t enough; after all, we all use the same language. Simply repeating the sentence doesn’t do it either. You are allowed to quote parts of another book in your own work. This is called fair use. Are the titles protected?

Are the events described in a fictional work protected? There is no one answer. Like all things in law, there is a large case history about what is an infringement and what isn’t. The underlying conclusion I came to is that the legal 2 system treats the work as a whole, and then sees how much or what parts of the whole constitute sufficient grounds for infringement. Of course this approach does not provide a clear answer because it is impossible to enumerate all the possible ways that could constitute infringement.

And, yet, I like this approach. This is systems thinking. As an architect, I am used to thinking of systems as a whole. When we think of systems, we think of the parts of the system and how they interrelate with each other, within different perspectives. The perspective is important because we may think of the same system in completely different ways depending on who we are. For instance, as the driver of a car I have different concerns from the passenger in my car; while the designer of the car thinks of it in an entirely different way.

So, let’s examine Java. This particular dispute is from the perspective of the developer. Java software consists of many parts. There is a Java language specification, there are many libraries, there are programs to compile the language, there are programs to package the compiled output, there are fonts, there is a virtual machine to run the compiled output, and there is a fair amount of documentation. There is even the steaming coffee cup logo to go with it. These are just a few components that come to mind.

To complete the notion of a system, we must also look at the interrelationships. The documentation of the libraries obviously depends on the API because that’s a key part of what the documentation is about. Of course, the API depends on the implementation. You cannot provide services that you don’t implement, much like a car with an automatic transmission doesn’t have a lever to shift gears. At an even more subtle level, the API for one part may refer to the API for another part, and even the implementation of one part may use the API or implementation for another part. So, these parts are all intertwined. As an architect, I want to tease them apart in a way that makes things understandable and manageable. Nevertheless, take it from me, not everything can be or should be separated. Indeed, once you accept that one part of a system is a creative expression subject to copyright, then it is not hard to accept that other parts also share that creative expression since they are all interrelated.

So this is what the legal system contends with, when asked to adjudicate about copyright. What is the entire work? How much was copied and does that constitute infringement? This is a daunting task with considerable subjectivity and, perhaps, that is why it gets handed over to a jury to decide on a case by case basis. The higher echelons of our legal system have not been amenable to absolute tests. For instance, you cannot look at the percentage of text that you may have copied to say whether that’s an infringement. And, in this case the higher courts rejected the notion that copying an API is unconditionally permissible.

So how far does this analogy of examining software as a creative work like a book go? Java libraries are organized into packages. Can we think of the Java packages as chapters of a book or the API as the title of the chapters? Here the analogy appears to be fairly weak. The chapters are normally sequenced while there is no particular ordering constraint for Java packages. The title is merely informative or suggestive of what is to follow while the API describes in precise detail exactly how to make use of the underlying implementation.

The analogy between books and software begins to fray to much greater extent when we consider how we interact with them. Typically, we read books. All other uses are marginal – including burning them to express disapproval or holding them up to hide our face. Software is different. We interact with software; we do things with software. When you stream a movie from Netflix, a complex series of interactions ensue. Netflix downloads software into your display device (e.g. browser on your PC); that software then uses APIs to communicate with other software on Netflix servers to show you the list of movies that you might be interested in. Once you make your selection, the software then streams the movie into your device, which also contains software to display it on your monitor or TV. Indeed, the TV may contain software as well. So, software interacting with humans and software interacting with other software is pervasive.

So, here we come to the other aspect of software. Software is used for “doing things” and APIs are central to doing things with it. Indeed, the developer, much like the designer of a car, is intimately concerned about the how the software will be used. The API design reflects it. So, when the district judge ruled that APIs couldn’t be copyrighted, he viewed them as essential for “doing things” and when the Federal Court overruled him, they viewed APIs as an essential part of a creative work.

For me, as a software architect, all of these aspects are parts of the same system. The legal system tries to tease the system apart and apply different parts of the law to different parts of the system. It is a hard task. Some might consider it nearly impossible. And, yet, billions of dollars are at stake and the decision will have an impact on the entire industry. One way for us to think about it is to go back to the underlying constitutional rationale: Copyrights exist for the public good. Let that be the cornerstone for this decision.