With a ruling of April 5, 2021, the Supreme Court of the United States put an end to the long legal battle between Oracle America, Inc. and Google LLC, recognizing that it is legitimate, as a constituent of fair use, to use the latter’s code of Java SE software owned by Oracle to develop the operating system for Android smartphones. In the article the authors, after a brief overview of the case and exam of the U.S. Supreme Court decision, highlight possible implications of such decision in the European Union legal systems and then analyse whether it is advisable for software that are technological standards to be subject to the adoption of a solution similar to the one created in the patent field of SEPs.

With a ruling of April 5, 2021, the Supreme Court of the United States (Supreme Court) ended the decade-long legal battle between Oracle America, Inc. (Oracle) and Google LLC (Google), ruling that Google’s use of Oracle’s Java SE software code in developing the Android operating smartphone system constituted fair use.¹

Referred to as the “copyright case of the century,” this litigation is important not only because it involves two of the biggest high-tech industries worldwide, but also since it deals with two key issues in the long debate about the interplay between copyright and software development:

1. Whether the Application Programming Interfaces (APIs) are subject to copyright protection; and,
2. Whether use of computer software code by an unlicensed subject may constitute fair use and so does not constitute an infringement of copyright.

In the IT world, APIs are types of software interface/ abstract specifications that allow and facilitate interoperability between different applications. From a technical point of view, APIs are a sort of protocol of rules allowing two computer programs or computers to communicate and interact with each other and so to be interoperable with each other.

Going a little more in detail, APIs are structured into “packages,” which in turn are divided into classes characterized by “properties” and “methods”/“tasks” (Method). Methods are divided into:²

1. Method Header, which contains the name that identifies a specific Method as well as number, order, and parameters used by such Method;
2. Method Body, which contains the program code that implements the function identified by the Method corresponding to a specific Method Header.

In the modern IT industry APIs are so important because they allow programs and devices to communicate with one another. The case decided by the Supreme Court mentioned above concerns Oracle’s Java application program interfaces that interact with Oracle’s Java Platform and Android, the operating system for cellular telephones and tablet computers developed by Google.

Java, which was first released in 1995, is an “object-oriented computer programming language”³ running on almost all electronic devices and it is platform- independent because of Java virtual machines (JVMs). Java follows the principle of “write once, run everywhere.” When a JVM is installed on the host operating system, it automatically adapts to the environment and executes the program’s functionalities.

The business model implemented by Oracle and Google were substantially different. In the business model chosen by Oracle profits were earned by encouraging developers to create programs written in Java and then charging manufacturers a fee to embed in their devices the Java software platform needed to run those programs. Google chose a completely different way of doing business since it offered Android for free to device manufacturers and used Android to collect data and gain revenue selling advertising.

Oracle filed suit against Google in the United States District Court for the Northern District of California in 2010, alleging that Google infringed Oracle’s copyright by using, without authorization, the declaring code of Java, which is one of the most well-known and widespread programming languages and platforms software (which has become the common standard in the field of computer programming), and was developed by Sun Microsystem and purchased by Oracle in 2010.

More specifically, Oracle complained that Google had partially reproduced and used, without any license, the exact structure, sequence, and organization of the Java API, copying about 11,500 lines of the declaring code (Method Header), such as that part of the API that identifies and defines specific Methods (predefined functions and tasks present in the software library) and commands necessary to make the application execute a specific Method (and therefore a specific function). However, Google had not copied the implementation code (Method Body) of the Java API, namely the lines of source code that allow programmers to invoke a computing function corresponding to a specific Method.

Google admitted that it copied the Java API structure, but claimed this was lawful, i.e., the copied material represented “process, system, method of operation,” which cannot be protected under copyright pursuant to Section 102 (b) of the Copyright Act⁴ and, even if it was, Google’s copying was fair use and so could not be a basis for liability.

At the district court level, the jury was deadlocked as to fair use and the District Court judge decided that the API declaring code is not protected by copyright.⁵ Upon appeal, the Google defense was completely rejected by the Federal Circuit, holding that the part of Java API’s declaring code that was infringed is copyrightable⁶ and subsequently that Google infringed Oracle’s copyright by reproducing such code, finding no fair use as a matter of law.⁷ Google petitioned the Supreme Court with a writ of certiorari, seeking review of both copyrightability and fair use. With a six to two ruling, the Supreme Court reversed again, finding that Google’s copying of Oracle’s declaring code was fair use.

The Supreme Court assumes that the Java API declaring code is copyrightable (without going into the issue concerning) and focuses on only the fair use defence.

In summary, in the U.S. copyright system, fair use is a wide and flexible exception to copyright protection, that promotes freedom of expression by permitting the unlicensed use of copyrighted material, without the owner of copyright being able to forbid it. In accordance with Section 107 of the Copyright Act,⁸ the following four factors are to be considered and balanced (depending on the specific case) in evaluating a question of fair use:

1. The Purpose and Character of the Use: This factor considers whether the use in question advances a socially beneficial activity like those listed in Section 107 of the Copyright Act (i.e., criticism, comment, news reporting, teaching, scholarship, or research) or it is transformative (i.e., if it adds something new and important to the original work, such as a new expression, meaning, or message), even if for commercial purposes;⁹
2. The Nature of the Copyrighted Work: According to this factor, works that are fiction have a higher degree of protection than those that are factual and less creative;
3. The Amount and Substantiality of the Copyrighted Work (Re)Used in Relation to the Whole: If the amount used is very small and, in any case, insignificant in relation to the copyrighted work, this factor will favour a finding of fair use. On the other hand, if the amount used is the heart of the copyrighted work, this factor will favour the copyright owner, even if the portion used is a very small amount; and,
4. The Economic Impact of the Use Upon the Copyrighted Work, Including the Effect on Potential Markets: This factor considers whether the use led to any harm both to current and potential markets that could be exploited by the copyright owner or, on the contrary, enhanced the copyrighted work (for example if it reaches a wider audience thanks to the unauthorized use).

The Supreme Court considered each of the four fair use factors also on the basis of some previous decisions on fair use in the context of reverse engineering and interoperability¹⁰ and held that all the factors weighed in favour of fair use.

1. Google’s use of the Java API was transformative: it was aimed to create a new product, i.e., a new operating system (Android) in a computing environment (smartphone) different from that of Java (computer) and, thus, Google’s use was consistent with the creative process at the heart of copyright law.
2. The API lines copied by Google were part of the declaring code, which is functional in nature, but unlike other computer programs:
   1. They were inextricably bound together with uncopyrightable ideas (such as task division and organization, shortcuts, and, more generally, structure and organization of APIs) and new creative expression (new Android implementing code), and thus
   2. Their value is not derived from creativity, but rather from the number of programmers who learn to use it as well as the efforts to encourage programmers to learn how to use the API system (so that they use and continue to implement Java).

   According to the Supreme Court the declaring code, if copyrightable at all (which was assumed for the purposes of the fair use analysis), benefits from less strict copyright protection since not only is it a functional work reporting fact (factual), but unlike other computer programs (such as the implementing code), it is also further away from the very essence of copyright. Consequently, the case goes in the direction of fair use without any prejudice to the general copyright protection provided for computer programs, as previously claimed by the Federal Circuit.

3. Google copied only a small quantitative amount of Java API (approximately 11,500 lines of 2.8 million, i.e., just 0.4 percent of such API), which was not substantial because it served a valid transformative purpose: to create and improve Google’s own Android operating system, allowing programmers to make use of their knowledge and experience using an already well-known and widespread programming language (Java) and so also make computer applications developed in Java compatible with Android.
4. Google’s Android operating system was not a market replacement for Oracle’s Java since it was tailored only to smartphones and not to laptops and desktops, which were Java’s primary market. Therefore, Android did not harm the actual or potential markets for Java since Oracle was unable to enter and succeed in the smartphone market (regardless of Android’s smartphone technology). In addition, according to the Supreme Court, Oracle foresaw a benefit from the greater adoption of the Java programming language across different markets, since the use of Java programming language in Android has expanded the network of programmers able to use Java in any computing environment (including laptops and desktops).
5. Finally, the Supreme Court found that allowing enforcement of Oracle’s copyright recognizing strong authorial protection of Java APIs would inevitably undermine innovation, effectively attributing a monopoly position to Oracle and limiting creative progress, contrary to the American copyright law itself, whose main purpose is to encourage and protect creativity.

However, the decision of the U.S. Supreme Court was not unanimous. Justice Thomas (joined by Justice Alito) dissented, stating that the majority had erred in not discussing the copyrightability of Oracle’s API, especially of its declaring code.¹¹ According to Justice Thomas, the majority should have found that such code was copyrightable as an original work, since it could be considered a “computer program” pursuant to Sections 101, 109 (b), 117 and 506 (a) of the Copyright Act. Moreover, in his dissenting opinion, Justice Thomas argued that the majority had distorted the fair use analysis, since all four factors actually favoured Or acle, largely because Google has in fact copied and used the substantial and most important part of the Java API (i.e., the declaring code) in an insufficiently transformative way, in order to develop a similar product, with a disastrous effect on Oracle’s potential markets because Android has limited Oracle’s opportunities to license the Java API by creating a competing platform.

The Supreme Court decision is particularly significant, as it offers a highly specific analysis of the fair use doctrine and the related factors, highlighting the importance of balancing the traditional copyright protection with the circulation of knowledge and creativity in the digital era, especially in areas like software, where interoperability is fundamental for technological development.

Moreover, because of its importance, this decision could become a leading case for fair use of any copyrighted material and so have implications extending far beyond software. For example, in a famous case on appropriation of art, the estate of Andy Warhol has requested a U.S. Federal Court revisit a decision finding that the famous pop artist’s series of Prince images infringed a photographer’s copyright in light of the Supreme Court’s ruling on fair use in Google v. Oracle.¹² However, in this case the Second Circuit has recently stated that the Google v. Oracle decision could have relevance only for the specific and unusual context of the technological world and could not be applied to any fair use analysis in an artistic context.¹³

But what could be the possible impact of the Supreme Court’s ruling in Google v. Oracle in Europe?

Even considering the significant differences between the U.S. and EU copyright systems (in particular in relation to copyright exceptions), it seems likely that, if the Google v. Oracle case were tried in the European context, it would have a similar outcome, mainly for two reasons:

1. in accordance with many authors, the API would not be copyrightable under European copyright law (at least not in the broad sense recognized by the U.S. ruling); and,
2. unlike the U.S. fair use doctrine, which has an open and flexible concept of permitted uses of copyrighted works, the permitted exceptions under the EU copyright framework are specific and close. Thus, even if APIs could be copyrightable under European copyright law, they could be used without the owner of the copyright’s authorization only for the purpose of interoperability, as is discussed in the following paragraphs.

5.1. May API be Protected by Copyright in the EU? A Matter of Perspective

Up to this date, even thought it had ruled on software interoperability issues, the Court of Justice of the European Union (CJEU) has not commented yet on the possibility to assign even to APIs the same legal protection conferred by Directive 2009/24/EC on the legal protection of computer programs (Software Directive).¹⁴

Leaving aside the doctrinal debate on the copyrightability of the internal structure of software,¹⁵ there is no doubt that, because of their nature and structure, APIs could be potentially qualified as works that cannot be protected by copyright as well as creative works subject to copyright.

Indeed, at first sight, APIs are an organized set of commands, instructions, and functions, so they could be considered only mere interfaces/functionalities used in computer programs in order to exploit certain of its functions, which, in accordance with CJEU, are not protected by copyright under the Software Directive.

In the famous SAS Institute Inc. v. World Programming Ltd case,¹⁶ as well as in the previous Bezpečnostní softwarova asociace case,¹⁷ the CJEU has clarified that “neither the functionality of a software nor the programming language and the format of data files used in a computer program to exploit certain of its functions constitute a form of expression of that program” and thus they are not protected under the Software Directive, as otherwise there would be a risk of monopolizing ideas, with consequent detriment of technological progress and industrial development.

However, it cannot be a priori excluded that the development of APIs is a result of creative activity. Applying by analogy the principles stated by the CJEU in the SAS Institute case with reference to user manuals for computer programs, APIs could be considered eligible for copyright protection every time that the choice, the sequence, and combination of their elements (e.g., function, algorithms, mathematical concepts, which, considered in isolation, are not intellectual creations of the author of a software) are an expression of their author’s creativity.

In other terms, APIs might be protected by copyright as works under general copyright rules (not as part of a computer program) if they are their author’s own intellectual creation. However, in this case, their unauthorized use/reproduction would constitute a copyright infringement unless it falls under one of the specific copyright exceptions provided by European law.

5.2 Copyright Exceptions in Europe

The civil law approach to permitted exceptions stands in contrast to the flexible U.S. fair use doctrine. Indeed, civil law systems provide a close and exhaustive set of copyright exceptions, which can be found at the European level in Article 5 of Directive 2001/29/ EC¹⁸ (InfoSoc Directive). In the effort to harmonize the copyright legislation of EU Member States, the InfoSoc Directive lays out a set of mandatory and optional exceptions and limitations, in accordance with international obligations (with particular reference to the three—step test first enacted in the Berne Convention and then incorporated in WIPO and the TRIPS Agreement).¹⁹ Further exceptions have been recently introduced by the new Directive 2019/790/EC (Copyright Directive) in order to adapt certain exceptions and limitations to copyright and related rights to digital and cross border environments.²⁰

Most European countries implemented these limitations into their copyright statutory provisions, providing exceptions that are constructed strictly.

With particular reference to the Italian copyright law, the discipline of copyright exceptions is provided by some specific provisions, such as articles 65 —71 decies of Law April 22, 1941, No. 633 (Protection of copyright and other rights related to its exercise), which mainly concern use of copyright-protected material for non-commercial uses and for the purpose of criticism, research, and/or teaching. New exceptions are recently created by means of the legislative decree entered into force last 12 December 2021, which transposes the Copyright Directive in the Italian legal system.²¹

As far as software is concerned, the Italian copyright law provides some mandatory statutory specific limitation on the software owner’s exclusive right, mainly in order to guarantee interoperability, namely the ability to exchange information and mutually to use information which has been exchanged between software and computer systems.²²

In particular, in accordance with Articles 64 ter and 64 quarter of Italian copyright law (in line with Article 6 of the Software Directive and the aforementioned jurisprudence of the CJEU), the reverse engineering by way of decompilation of a program object code is permitted solely if it is the only way to obtain information necessary to achieve the interoperability and only when all the following conditions are met:

1. The decompilation is performed by a licensee or by another legitimate user / authorised person;
2. The information necessary to achieve interoperability has not previously been readily available to the persons referred to in point (i); and,
3. The decompilation is limited to those parts of the program strictly necessary to guarantee interoperability, with the express prohibition of using any information obtained through decompilation for purposes other than to achieve the interoperability or for the development / production / marketing of a computer program substantially similar in its expression to the decompiled software, as well as transferring this information to third parties.

In addition, in a very recent decision (Top System SA v. Belgian State),²³ the CJEU has clarified that a lawful purchaser of a computer program is also entitled to decompile such program (in whole or in part) also in order to correct errors (i.e., bugs) affecting the software’s operation, in compliance (if relevant) with any conditions set out in the licence agreement, even if such decompilation does not satisfy the aforementioned conditions.

These cases are quite different from the Google v. Oracle case: the Mountain View company has used Java APIs without being a licensee (and anyway without any authorization) and not to reach interoperability in the meaning of the European Software Directive and Italian copyright law, nor in order to correct errors. Indeed, Google used Java API in order to make its new Android operating system compatible with Java and not vice versa (programs written to run on the Android platform are not fully compatible with the Java platform).

Thus, if the Google v. Oracle case had been decided by an Italian or an European court, Google’s use of Oracle’s Java APIs (assuming they could be qualified as creative works subject to copyright) likely would not have been considered lawful since it did not seem to fall under any of the exceptions to copyright provided for in European legislation.

However, given the importance of the parties involved and the worldwide resonance of the case, it cannot be completely excluded that there will be a future influence of the Supreme Court decision in the Google vs. Oracle case in European courts.

Waiting a possible future decision of the CJEU on this matter, the new landmark case of the Supreme Court might influence (as in the past)²⁴ the interpretation of copyright exceptions and limitations, leading European courts to adopt an extensive interpretation of such exceptions, in order to enhance technological development.