Not as the Oracle Foretold - US Supreme Court Decides on Copyright Infringement in relation to APIs

APIs, or Application Programming Interfaces, are absolutely everywhere these days. APIs allow for two pieces of software to 'speak' with each other, sharing information across to allow for interactivity and interconnectivity between different software applications. While many providers share their APIs freely for implementation, there is still certain rights that attach to those APIs in the form of copyright over the code itself. Just like text in a book, code can be protected by copyright and, in many instances, is absolutely worth protection if a particular coding language becomes very popular. This has been the central focus of an epic legal battle between Oracle and Google in the US, which has spanned for nearly 10 years (discussed previously on this very blog), and the highly anticipated US Supreme Court decision has finally been handed down in early April 2021. 

The case of Google LLC v Oracle America Inc. concerned the Java SE program, which uses Oracle's Java programming language. Parts of the Java SE program's code (roughly 11,500 lines of code) was used in the development of Google's Android operating system, which formed a part of the Java SE API. Java SE is commonly used to develop programs primarily to be used on desktop and laptop computers, which also extends into the realm of smartphones. Oracle subsequently sued Google for copyright infringement over this copied code, and the matter finally ended with the Supreme Court after a long 10-year journey through the US courts. 

The Supreme Court were tasked at looking at two questions: (i) whether Java SE’s owner could copyright the portion that Google copied; and (ii) whether Google’s copying nonetheless constituted a “fair use” of that material. 

Justice Breyer, handing down the majority's judgment, first started off discussing the basic requirements for copyright protection. This means that the work has to be one of authorship, original and fixed in a tangible medium. Copyright encompasses many types of works, such as literary, musical and architectural works, but in a more unconventional manner it includes 'computer programs', which are "...a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result". In terms of limitations, copyright does not extend to "...any idea procedure, process, system, method of operation, concept, principle, or discovery". In addition to copyright protection in general, one has to consider the remit of 'fair use', which allows for the use of copyright protected works for various purposes, e.g. criticism, satire and news reporting. 

The first question, as set out above, concerned whether the provision extending copyright protection to 'computer programs' includes APIs and/or whether they are excluded as 'processes', 'systems' or 'methods of operation' from copyright protection. However, the Supreme Court skipped the copyright aspect of the matter and immediately dove into whether Google's use of the API was fair use.

Justice Breyer noted that computer programs differ from other 'literary works' in that such programs almost always serve functional purposes, which makes the application of copyright to them more difficult. He also mentioned that, in discussions to extend copyright to computer programs, it should not "...grant anyone more economic power than is necessary to achieve the incentive to create". The key is to not allow copyright to stifle innovation in the realm of computer programs. 

Justice Breyer also mentioned that fair use can be used to distinguish between expressive and functional features of computer code where those features are mixed, and allow for different programs to be more readily distinguished in the light of protection. 

Turning to actually considering whether Google's copying fell into fair use, the Supreme Court had to look at the well-established factors of fair use: (i) the nature of the copyrighted work; (ii) the purpose and character of the use; (iii) the amount and substantiality of the portion used; and (iv) market effects. 

In relation to the first factor, the Supreme Court discussed the use of APIs in general as a way for computer programs to speak to each other. APIs also comprise three different 'functional' aspects, which are various parts of code that handle different aspects of the APIs functionality. Justice Breyer highlighted that the parts are inherently functional and bound together by uncopyrightable ideas (i.e. task division and organization) and new creative expression in the form of Android's implementing code. In their view the nature of APIs diminishes the need for copyright protection over them.

In terms of the second factor, the focus is on the transformative nature of a copyright protected works use. Google sought to make new products using the API and to expand the usefulness of the Android OS - argued to be transformative and innovative around the copying of the API. The Supreme Court also noted that one has to consider both the commerciality and good faith in relation to the copying. Justice Breyer determined that, while Google's use of the API was a commercial endeavor, it doesn't mean that the use cannot be transformative. Good faith was not a consideration in the case, but Justice Breyer did highlight that the other factors on the copying of the API weight towards a finding of fair use. 

The Court then moved onto looking at the amount of the work copied. As discussed above, Google copied approximately 11,500 lines of code, which was a mere fraction of the totality of 2.8 million lines in Java SE. While the amount is important, it's the substance of what was copied that is the most important part when thinking about substantiality. Why the lines were copied was to enable Java experienced programmers to work with Android; without which this would have been very difficult. This objective for the copying was to enable the expansion of Android, not to replace Java SE, and the Court did see that this favored a finding of fair use.

Finally, the Court turned to the market effects of the copying, i.e. did it impact the market value of the protected work. Thinking of the use of the code, it was in a market sector where Sun Microsystems (Oracle's predecessor) was not well-positioned, and the primary market for Java SE was PCs and laptops. Android used in smartphones was in no way a substitute for traditional computers where Java SE was typically used. However, the code's implementation did benefit Android through attracting developers to improve the OS. The Court saw that the copying didn't impact Sun Microsystem's position in the marketplace, and issues with an impact on creativity within the development of programs like Android, weighed for a finding of fair use. 

Rounding things off, Justice Breyer discussed the application of copyright in the world of computers and the difficulties the old concept has in adapting to this new environment. In his view, copyright very much persists in computer programs (and their underlying code), but emphasized the fair use doctrine's place in the same. 

The Supreme Court ultimately concluded that Google's copying was fair use as a matter of law and therefore there was no infringement of Oracle's code.

The case is a massive milestone in the application of copyright in computer programs and code, and as the court observed, Google only took "...what was needed to allow users to put their accrued talents to work in a new and transformative program". This is curious and can open the door for others to copy code as and when needed, without licensing, if it is used to allow for innovation through the implementation of well-established technologies. Justice Thomas did indeed write a very strong dissent to the majority's verdict, which highlights the blurring of copyright in relation to code. It remains to be seen how this precedent is applied by the courts in future cases, but it could very well lead to the limits of fair use in relation to code being tested sooner than you think. 

A Gentleman's Code - The Copying of Software Code and Copyright

Computer programming, especially to the layman, can be both incredibly daunting and very confusing, as the languages, while logical, can be quite impenetrable. Since computers and computing have become near ubiquitous in modern society, so has programming become a part of our lives, even if not directly. Due to this, the value of code and programs can be substantial, especially for ones that are lucky enough to become standards, or just plain popular. Code and copyright rarely meet, but in the vein of the above, can code be construed as a copyright protected work, and if so, how much can you copy before you're infringing the rights attached to the code?

The case of IPC Global Pty Ltd v Pavetest Pty Ltd (No 3) dealt with equipment used to test asphalt and construction materials, built by IPC, which included custom programming to enable the user to test said materials and view results. This piece of software was installed on the users' computer. Two individuals, Con Sinadinos and Alan Feeley, worked at IPC (with the latter working as a consultant as a part of Alueta). The pair then resigned from IPC in 2012, establishing a competitor company, Pavetest, which launched competing testing products. Mr Feeley had in his possessions copies of IPC's programs on his computer that he took with him when leaving IPC. He then provided them for a programmer who made copies of the programs, leaving some parts of the Pavetest identical to that of IPC's programs. IPC then took Pavetest (and the individuals) for, among other claims, copyright infringement and breach of confidence.

Although Justice Moshinsky had a wide array of issues to decide, focus for the purposes of this article will remain on the question: "...did Pavetest infringe copyright in the UTS software by the creation of version 1 of the TestLab software? In particular, did version 1 of the TestLab software reproduce a substantial part of the UTS software?"

After discussing, at length, the companies and the development of the two competing pieces of software, the court focussed on the matter of copyright infringement.

Original code? Nah... (Source: xkcd)

The courts have struggled with defining what amounts to a 'substantial amount', as per section 14 of the Copyright Act 1968, which was discussed by the High Court of Australia in IceTV: "The case law does disclose that special difficulty has been encountered in considering the relationship between the phrase “a substantial part” in s 14(1) of the Act and the definition in s 10(1) of that species of “literary work” which is a “computer program”, being: “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” (Emphasis added) The phrase emphasised suggests the importance of function, although this is usually encountered in patent and designs law, rather than in the “traditional” law of copyright respecting original literary works".

The courts have developed a test to determine whether a computer program has been infringed, there is ‘the need for some process of qualitative abstraction of the material features of the computer program in question’, and the copying of those features in the potentially infringing program (i.e. of a program calculates figures based on data, the program features of the calculation would be more important than the aesthetic function of the same under this context).

While the respondent conceded that the code is a copyright protected work, that substantial parts of the code were copied (but not to the degree of being a substantial part under section 14), and that this was done on behalf of Pavetest with the authorization of the individuals above, the court still had to consider whether the copying was indeed substantial under the law.

Due to the coder working for Pavetest to be able to rewrite the code so as the new version didn't infringe IPC's copyright, there clearly was a wide margin of expression in how the code could be implemented, while still having the same functionality. The writing of the code therefore included a degree of choice and judgment, making the expression of that functionality original under copyright. While some parts of the code would not be essential, Justice Moshinsky still upheld that they were original works equally to those parts that were essential. Finally, the amount of code, albeit a small amount (roughly 10,000 lines of code from about 250,000 lines), the copying was substantial, according to the judge, due to its necessity to achieve the desired functionality, rather than just simply through a quantitive measure. Pavetest had subsequently infringed the rights in the code.

The case is a very interesting one, and highlights a need for anyone copying others' code (which seems to be an industry standard, albeit only in parts of programming) to be cautious, and to rewrite anything that could be deemed to be a substantial copying. Software creation is incredibly complex and difficult, and one can appreciate the adoption of shortcuts, but the courts will clearly combat any abuses of others copyright works, even if it's just 'meaningless' code.

Source:  IP Whiteboard

Retrospective - Computer Software and Copyright

In a world where everything is becoming more and more digital and reliant on computers to handle most tedious or complex tasks, software is king; it is what executes these tasks and makes things easier to do on the aforementioned devices. With the software business booming, more and more value can be placed on having the right software for the right task in the highly competitive space, and with that the desire to protect your product. Even in the wake of the Alice decision some time ago (discussed on this very blog here and here) the protectability of software still remains, albeit quite hindered. In light of the more difficult protectability of software through patents, copyright shines brighter and as a possible alternative, yet poses a question which might be less glaringly obvious to most: is software protected under copyright?

A fairly recent case in the UK Court of Appeals, SAS Institute Inc v World Programming Ltd, attempted to take on this issue and decide once and for all whether copyright does afford protection to software and its underlying code. The SAS Institute is a software development company well-known for its analytical software, often referred to as the SAS System (or just plainly SAS). A core component of the SAS System is SAS Base; a piece of software which allows the user to easily write and run scripts to analyze and use data. The scripts themselves were written in a programming language developed by SAS called SAS Language. Finally, the SAS Base software can be extended upon by three additional components: SAS/ACCESS, SAS/GRAPH and SAS/STAT respectively. In addition to the software SAS have also written manuals for the use of its software. The SAS environment was quite tightly controlled, and customers had no secondary options which to use in the execution of their developed scripts for the platform (the SAS Language only functioned through SAS' System). Their competitor, World Programming, sought to create an alternative piece of software capable of utilizing the SAS Language, so that any programs written in the Language can be used in both their suite and SAS' - the end-result being a program called the World Programming System. The software endeavored to mimic SAS' System as closely as possible; however they had not accessed SAS' source code in their development, merely copying the outputs and inputs of the System. Due to this, SAS sued WPL, asserting that the company had copied its manuals; through the copying of the manuals they had infringed SAS' copyright in their extension components; WPL had infringed its copyright in a version of its System, the Learning Edition, and breached its terms in its misuse; and WPL had infringed SAS' copyright in its manuals after creating its own version called the WPL Manual.

Being 'creative' in programming can be difficult

Confusion in terms of acronyms aside, the court was therefore faced with the ultimate determination of whether copyright exists in SAS' software, and whether WPL had infringed that copyright. Under EU legislation, more specifically Directive 91/250/EEC (now governed by Directive 2009/24/EC with no substantive differences), computer programs are wholly protected by copyright as a form of expression; however the underlying principles of those programs are not. To put this into more simple terms, the code executing a specific function in its particular expression can be protected, but the idea of that execution is not, allowing anyone to create a program doing the same thing, so long as the expression of that execution is not the same as other expressions of it (i.e. different code, same result). Computer programs have since been included in the UK Copyright, Designs and Patents Act 1988, under section 3.

To look at things further, the scope of what is protectable under the above Directives was left quite open, but was subsequently added to in the case of Infopaq International v Danske Dagblades Forening, where the European Court of Justice saw that copyright protects an author's "...intellectual creation" (the wording used in the Berne Convention), potentially encompassing programs quite readily if it can be seen as such a work - supplanting this definition in the Directive's interpretation. What is important in this term's application, in the Court's judgment, lies within whether a computer program can be seen as an 'intellectual creation', and in assessing this the court must decide that if the expression within the computer program is purely a technical one (i.e. derived from necessity for things to work right), the work cannot be seen as an intellectual creation under this definition. To put things in more simplistic terms: "...the author [has to be] able to express his creative abilities in the production of the work by making free and creative choices". If a programmer, in the creation of a specific application, can express his or her creativity and choices in how the program works, it can be protected by copyright. Even if the program has very specific functionality, or combines several different functional approaches to the execution of its desired task, the law does not protect it under copyright. In the court's view the copyrightability of functions or functionality, no matter how well used or combined, would be tantamount to the copyrightability of an idea, and therefore is not within the remit of copyright.

Finally, the court had to assess whether the manuals created by SAS are protected as works, and whether WPL had infringed those manuals' copyright protection.Their content was largely informative, and therefore would encompass most of the 'ideas' expressed in the aforementioned programs, or as expressed by Lord Justice Lewison: "...what counts as an idea, for the purposes of a computer program, also counts as an idea for the purposes of a manual". With this in mind, should the manual express the idea in a way which can be seen as protectable, it can fall within the remit of the law. His Lordship dismissed both claims on the manuals, effectively dismissing their protection due to a lack of any protectable expression, as they merely described the function of the programs without adding anything original on the author's part.

In the end SAS lost their appeal and the Court of Appeal closed the door on the copyright protection for programs, at least for the most part. The case was appealed to the UK Supreme Court, however leave was not given, solidifying the law's position through the Court of Appeal's judgment. The position presented in the case differs drastically to what has been discussed in the United States, where programs can be protected by copyright. Nevertheless the case is without a question an important milestone in relation to copyright and computer software, and this writer for one believes it will stay as such for a while.

APIs Protected By Copyright, Programmers Stand Aghast

The more and more information becomes digitized and hidden beyond a invisible wall to the layman in the form of code and programming languages, the more convoluted its application can become in the world of intellectual property law. One phenomenon of this world are APIs, or in other words, Application Programming Interfaces. APIs are software-to-software applications released by companies, like Google, which enable other developers to more easily access and use their services, such as embedding Google's search services onto a web blog allowing for readers to search the site more easily. Effectively it allows for the two applications to communicate between each other without any interference by the users themselves. APIs have been fought over for some time by the two tech giants, Google and Oracle, since 2012, and came to a head early last month in the US Court of Appeals.

The case, decided in May 2014, dealt with 37 API packages released by Oracle (at the time Sun Microsystems) which pertained to its Java platform. The two parties, Google and Oracle, attempted to reach an agreement to use the Java platform in Google's new mobile operating system, Android, but failed to do so eventually. Nevertheless Google developed its own similar platform to be used in Android, Dalvik, which consisted of over 160 APIs, of which 37 corresponded to the Java APIs in contention; something which Google had copied verbatim into its own code. Oracle subsequently took Google to court over copyright infringement, and in a decision by the District Court of California some two years ago the court saw that APIs were not copyrightable. Oracle appealed the decision, which ended up in the Court of Appeals last year.

Many developers' thoughts after the decision 

Under the 'merge' doctrine, if there is only a finite amount of ways through which an idea can be expressed it is said to 'merge' the idea-expression doctrine, or in other words, prevents copyright from protecting the expression as part and parcel to the idea. Should there only be a single way to implement said idea no copyright protection will be given to the merged idea. The District Court initially saw that Oracle could not protect its APIs as their expression was the idea, and could not be protected. On appeal the Court of Appeal saw different, deciding that the copied code could have been implemented in unlimited ways, not limiting the expression of the idea and warranting copyrightability. The declaration of the source code by Oracle therefore does not preclude its copyrightability, as was seen by the District Court initially. Even if the code consists of short phrases or sentences, i.e. lines of code, it does not preclude copyright protection.

Should the disputed APIs be merely a system or a method of operation, they cannot be protected under copyright. A myriad of cases have stated that programs and code cannot be protected by copyright; however the approach by the District Court was seen as being erroneous. Under the Court of Appeals' decision even though computer programs contain functional elements it does not fully leave out the possibility that they may contain elements which are protected by copyright. This does not completely cover the effect of the program, but merely the expression within that code for that function. Should Google have implemented that very function through a different expression, there would be no risk of infringement.

Google's last argument was for interoperability, in that the verbatim copying of Oracle's code was essential for the interoperability of Java and Android, initially supported by the District Court. However, the Court of Appeals saw differently, as precedent heavily approached interoperability as a fair use right, not as a requirement for copyrightability. This gave the final blow to Google's argument in the appeal case, with the Court of Appeals fully rejecting the District Court's initial decision and deciding that APIs could be protected by copyright.

Needless to say this decision has created quite the fervor and will undoubtedly be appealed on Google's part. The precedent set can be argued to be dangerous, and present a hurdle for the free development of technology, at least on the programming side. As more and more programs have to be able to interact with each other for a convenient, practical and fast experience for the consumer, locking down APIs can hinder this development quite significantly. Developers could be cherry-picked or even prevented from using certain APIs or even charged exorbitant amounts for their use; however this is pure speculation. Whether the case goes further will remain to be seen, and will set an interesting cloud over the programming sphere for the time being.

Source: Ars Technica