Google v Oracle: A Comment and a Call to Action.

• Author: Pileggi, Justine

Introduction I. The Backdrop A. Modern Software Development B. Legal Implications for Copyright C. Technological Patrons D. Java Application Programming Interfaces (Java APIs) E. Java APIs and Android F. Setting the Stage II. Case History A. District Court Decision B. District Court Appeal C. Jury Verdict on Google's Fair Use Defense D. Circuit Appeal E. US Supreme Court III. Case Comment A. The AFC Test B. Encroachment of the Public Domain IV. Canadian Law V. Conclusion INTRODUCTION

Software development today is a complex, collaborative process, a universe away from the punch-card programming and enormous IBM mainframes of computing's, (1) humble beginnings in the 1970s. The software industry is of increasing importance to the global economy, especially with the rise of cloud computing, (1) software as a service (SaaS), (2) and device programing for the Internet of Things (IoT). (3) These expansions in computing has led the software industry worldwide to grow to nearly US$6Billion in annual revenue. (4)

When computer software emerged as a commercial product in the 1970s and 1980s, there were discussions on whether copyright would be the correct legal mechanism to protect owners and developers. (5) Copyright emerged in most jurisdictions as the chosen mechanism, and other protections, such as patents, were preserved for tangible computer-based inventions or apparatuses. (6) Copyright protection for software or computer code and its ability to serve as an effective regulatory mechanism is being repeatedly tested as new coding paradigms and industry practices emerge. There have been fundamental changes to both the way code is developed, as well as the end-result computer code.

Any challenges in providing copyright protection for software today are aggravated by the speed of technological change, not to mention that these changes are often without precedent or analogy in other works that enjoy copyright protection. In response to the shifting terrain, the law changes only incrementally and often develops unevenly as the case law accumulates. (7) Copyright is also a creature of statute, that needs to accord with international norms. This adds additional complexity to any Parliamentary or legislative changes that might get proposed, and timeframes get extended even if industries and academics stress the urgency of change. The result is a copyright regime that tends to prefer established interests rather than the underlying imperative of fostering creative output. 8)

The landmark decision of the Supreme Court of the United States (hereinafter "SCOTUS"), Google v Oracle, (9) attempts the grapple with this terrain, and balance interests between owners and creators. The decision and the lower court rulings along its trail to the SCOTUS have inspired both vehement critics (10) and passionate defenders, (11) but scholarly analysis has generally refrained from considering whether the decision has adequately accounted for the realities of software coding and industry practices today.

This essay endeavors to provide this missing analysis and show that the reasoning provided by the district court and the SCOTUS do not adequately account for the culture and current nature of copyright development and, as a result, have provided a ruling that incentivizes industry players to act in ways that will prove detrimental to creative output. There is also the real risk that Oracle sets a precedent that can be used to erode what I will call the 'technological commons,' the resources with which digital creativity is fundamentally and inextricably entwined. The analysis proceeds in four sections. Part I sets out the backdrop in which modern software development takes place and situates Java Application Programming Interfaces (APIs) and the Android platform within that backdrop. Part II reviews the Judicial history of Oracle, and Part III comments on reasoning in the decision. Part IV considers how Oracle would have been decided in Canada and makes recommendations regarding how a decision could be reached here, in a manner that avoids the uncertainty and equivocation that inheres in the US decision.

1. THE BACKDROP

   1. Modern Software Development

      Software development today is inherently collaborative, and this collaborative element has been intensified due to modern reliance on the Internet and on a coding paradigm called object-oriented programming (hereinafter "OOP"). The Internet has enabled remote creation, dissemination, and use of software across international boundaries, and has been essential to the productivity of the industry. The Internet is also instrumental for modern software running many aspects of our daily fives, from critical infrastructure to devices like cars or thermostats in our age of the IoT.

      The advent of OOP, like the Internet, has brought a major shift in code design and capacity. It is a coding approach that differs significantly from the dominant approach that preceded it, procedural programming. The procedural style generates code that uses a linear, top-down approach, such that you have code that is essentially a series of steps for the computer processor to carry out. This series of steps operates on data structures (lists or numbers, databases, etc.) to solve problems and generate results. These data structures are available to be viewed or modified by all the sub-procedures that compose the program. When one subprogram alters a data set, that data set is altered for the entire program, and from a security standpoint this sort of data exposure is problematic. The other major disadvantage is that procedural programs, cannot be 'disassembled,' its component structures directly recycled and used in other similar software (or even reused within the same program). When using the procedural paradigm, every time a programmer encounters the same problem when writing different software, she or he must rewrite and customize the code that solves that problem, so that it can respond to the needs of the program as a whole. Procedural programs tend also to be wedded to the operating systems they were designed for and cannot be used on other platforms without serious changes. It is inherently not a portable or efficient approach to writing code. Essentially, procedural programs can be thought of as single discrete units, tailored to particular circumstances.

      Contrast this customized set of instructions, and its universal data access, with the OOP. With the OOP paradigm, each "object" is a self-contained unit, such that it generates its own data and operates on it separately from the rest of the program. Rather than a sequence of steps, the code is divided into chunks of code and data (objects). The code within an object can only access and modify specified data. OOP can solve the same problems or offer consumers the same functions as procedural programs, but coding with objects means that the software gains the property of modularity, such that each of these object units can be reused within the program itself, as well as in other pieces of software. This quality of modularity brings this puzzle-like quality to modern software, where objects can be substituted in or out, replaced, or updated independently, or copied from other programs to fulfill other functions. This puzzle-like quality disrupts the sense of the program as a discrete unit.

      There are other benefits of modularity, which explain in part the popularity of OOP today. Relying on pre-written objects means there is a radical decrease in the amount of code that needs to be written to execute the task. This facilitates writing longer and more complex software. All the programmers writing in a particular language have access to compilations of these pre-writes (often called libraries), which means that the software that is generated today is more generic. These preprogrammed objects also make software code more portable, because the object can potentially be used in any number of environments (cell phone applications, computer software, IoT, etc.). Over time, frequently used functions have been compiled in pre-written libraries and are now ubiquitously accessed by programmers to save time.

      There are also security benefits with OOP, because by encapsulating and sequestering data to each of these objects, it becomes more complicated for malicious actors to access or modify data in the program as a whole. These security benefits mean that it becomes practical to apply software solutions to critical infrastructure issues or to rely on IoT without overt security concerns.

   2. Legal Implications for Copyright

      To understand the theoretical legal justification for applying copyright protection to software code, it is helpful to draw an analogy to traditional written works, like stories or poems. Under the Berne Convention, the "mode or form of its expression" for any production in the "literary, scientific and artistic domain" is considered a work protected by copyright. (12) The expressive requirement refers to the unique expression of an idea, sometimes referred to as the idea/expression dichotomy, (13) where the particular expression of an idea is protected, while the original idea remains in the public domain, so that others can interpret and use the concept in their own creative endeavor. There is an inherent similarity between a procedural program and a short story. Both are fixed once completed, in the sense that they cannot be altered without changing the expressive quality of the work. Recall that changing a component of a procedural program changes the work as a whole, and even reordering the lines of code may cause the program to function incorrectly. In this aspect, a procedural program is appropriately analogized to a short story, the creative expression of a single person, and one can follow the logic of applying copyright protection.

      It is notable, however, that modern OOP designs inherently decrease the expressive space (in the legal sense)...