Google v. Oracle: When Innovation Overwhelmed Copyright Law

Desde la barra Análisis Google v. Oracle: When Innovation Overwhelmed Copyright Law
- Advertisment -

What a case, and what a beautiful decision to analyse (Google LLC v. Oracle America, Inc., US Supreme Court, No. 18–956). The case that I am about to analyse is not just about copyright infringement and more than a billion in damages. This story is about changing times, about an era where a constant and voracious pace of innovation is overwhelming legal systems, and in this case, copyright law.


(for those knowledgeable about the case, just skip this part)

On one side, Oracle acquired Sun back in 2010. Sun was the owner of Java SE, an applications programming framework. On the other side, Google acquired Android back in 2005. At the time when both companies started first negotiating attempts for the licensing of Java SE, the latter was developing a mobile operating system which would later on become the most pervasive operating system in the world.

Licensing negotiations failed on the possibility of licensing the entire Java platform (on an interesting definition of ‘platform’ see p2), apparently due to the frictions between the business models of the two software companies (see p3). On the one hand, Google was seeking to build an open source-based platform to create an entire ecosystem by attracting a critical mass of developers. On the other hand, Sun (at the time) was standing for a different conception of ‘openness’, very protective with the Java SE platform and restrictions on interoperability were strict.

Soon after acquiring Sun, Oracle brought a lawsuit before the Court for the Northern District of California claiming that Google’s use of Sun’s Java Application Programming Interface (API) infringed both its copyright and patents. Along with the proceedings, patent infringement was discarded, and the main locus of analysis turned to be on the alleged copyright infringement from Google’s side by copying 37 packages (verbatim copying of 11,500 lines of declaring code) and the related organizational structure (SSO) – see p9ff. The District Court assessed at the time whether: (i) APIs should receive copyright protection; and (ii) whether Google’s use of Oracle’s API infringed the copyright of the latter, and if so, whether a fair use defence should apply. In short, the District Court found Google’s use to be fair use, Google copied only the declaring code and organizational structure that was necessary for Java-trained programmers to activate fa­miliar tasks while writing its own implementing code. Oracle appealed and the Federal Circuit back in 2018 reversed the decision by not finding Google copying of Oracle’s copyright fair use (see all the relevant procedural documents on the case kindly provided by SCOTUSblog here).

Consequently, Google filed a petition for certiorari asking the 2 questions named above: whether Java’s API is copyrightable; (ii) whether Google’s use of the API was a fair use (see p. 14).

Technical preliminary details

According to the Court an API “allows programmers to use (…) prewritten code to build certain functions into their own programs, ra­ther than write their own code to perform those functions from scratch” (p. 7). In other words, an API is a software interface allowing two software systems to communicate with each other – ie exchange data.

Before diving into the fair use conundrum, the Court spends 4 pages explaining the internal structure of Sun’s Java API. It spots 3 main technical features/components:

      • implementing code: code telling the computer how to execute the task the user has asked to perform;
      • method calls: command telling the computer which implementing code to choose (ie which task it should carry out, see p. 4-5);
      • declaring code: the declaring code is the interface between the user and the computer, it connects the method call to the implementing code – ie an internal orchestrator carrying both interface and organizational functions.

In words of the Court: “typing in a method call prompts the API to locate the correct imple­menting code and hand it off to your computer. And im­portantly, to select the dish that you want for your meal, you do not need to know the recipe’s contents, just as a pro­grammer using an API does not need to learn the imple­menting code. In both situations, learning the simple com­mand is enough” (see p. 7).

By taking a modular approach to the analysis of the API, by assessing its internal structure and components, the Court initially swifts from the question of whether APIs should be copyrightable to assess the copyrightability of each of the components of the API: the declaring code and the implementing code. More specifically, the declaring code is the one in which copyrightability is subject to debate. However, to take a modular approach to the assessment of the copyrightability of APIs goes against the holistic approach taken by the very initial question on whether APIs should be copyrightable. To answer the latter question, one would first have to assess the copyrightability of the components of the API in isolation, to then assess them in combination – ie the API (taking into account the specific circumstances of the case).

This modular approach might not come without friction, as the court expresses its dissent with the Congress with regards the copyright protection of software programs: “We are told that no attempt to distinguish among computer code is tenable when considering “the nature of the work,” (…) even though there are important distinctions in the ways that programs are used and designed”; “We do not understand Congress, however, to have shielded computer programs from the ordinary application of copyright’s limiting doctrines in this way. By defining computer programs in §101, Congress chose to place this subject matter within the copyright regime. (…) that also means that exclusive rights in computer programs are limited like any other works. (…) just as fair use takes account of the market in which scripts and paintings are bought and sold, so too must it consider the realities of how technological works are created and disseminated. We do not believe that an approach close to “all or nothing” would be faithful to the Copyright Act’s overall design” (see pp 17-18).

Then, the question of whether APIs are copyrightable has 2 interpretations:

(i) Congress’ code-is-code (holistic and rigid) approach which does not distinguish between computer code (see also Justice Thomas’ dissenting opinion pp 4 and 10 arguing in the same line)

(ii) Supreme Court’s modular approach which disintegrates a given software program to assess the IP protection of each of its components which might then lead to an overall answer on whether the API is copyrightable.

However, the latter goes beyond the decision, as the Court refused to answer the first question (ie APIs copyrightability) to go directly to assess fair use: Given the rapidly changing technological, economic, and business-related circumstances, we believe we should not answer more than is necessary to resolve the parties’ dispute. We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copy- righted. We shall ask instead whether Google’s use of part of that API was a “fair use”.

This choice was criticised by Justice Thomas whose official dissent on the Supreme Courts decision is integrated in the decision (I urge you to take a look, worth the read). In his words: “The Court reaches this unlikely result in large part because it bypasses the antecedent question clearly before us: Is the software code at issue here protected by the Copyright Act? The majority purports to assume, without deciding, that the code is protected. But its fair-use analysis is wholly inconsistent with the substantial protection Congress gave to computer code. (…) Oracle’s code at issue here is copyrightable, and Google’s use of that copyrighted code was anything but fair”.

Fair use: a legal paradigm under tech (and policy) siege

The doctrine of fair use is a limitation framework to exclusive rights conferred by US copyright law. To assess fair use, 4 factors are considered  (See Section 107 US Copyright Act):

      1. The (commercial or not) purpose and (transformative) character of the use;
      2. The nature of the copyrighted work (eg – gradual assessment on functionality);
      3. Amount/substantiality of the portion used in relation to the copyrighted work as a whole;
      4. Effect of the use on the potential market for the copyrighted work.

Before entering to assess each of the factors, the Supreme Court pays an ode to fair use by holding (in a sibylline way) that the latter is the pertinent legal framework to assess not just whether Google’s use of the copyrighted material was fair use, but if the copied declaring code was copyrightable (pp 16-17).

Surprisingly, it does so by altering the order of analysis of the factors. Instead of starting by assessing the purpose and character of the use, the Court starts with the assessment of the nature of the copyrighted work. In other words, strategically, it starts with the factor under which the assessment of the functionality and degree of copyrightability of the code is going to take place. In other words, by altering the order of the factors it subsumes the first question asked by Google which in principle the Court avoids answering for the sake of the rapidly changing technological, economic, and business-related circumstances (ie the question on the copyrightability of the API).

In parallel, in his dissent, Justice Thomas spots the Court’s move, he states:

(…) the majority evaluates the factors neither in sequential order nor in order of importance (at least two factors are more important under our precedent). Instead, it starts with the second factor: the nature of the copyrighted work. It proceeds in this manner in order to create a distinction between declaring and implementing code that renders the former less worthy of protection than the latter(see p 10).

I agree with the majority that Congress did not “shiel[d] computer programs from the ordinary application” of fair use. (…)  By skipping copyrightability, the majority gets the methodology backwards, causing the Court to sidestep a key conclusion that ineluctably affects the fair-use analysis: Congress rejected categorical distinctions between declaring and implementing code. But the majority creates just such a distinction. The result of this distorting analysis is an opinion that makes it difficult to imagine any circumstance in which declaring code will remain protected by copyright(pp 7-8).

Interestingly, from the appeal onwards, it was the Federal Court the only one respecting the order of the 4 factors. Neither the Supreme Court nor Justice Thomas in his dissent respected the traditional chronological order. The strategic alteration of the order of assessment of the fair use factors should not be underestimated.

Factor 1: Nature of the copyrighted work

The Court concludes that the nature of the declaring code points to fair use. To achieve its conclusion, the latter builds its theory on the functional nature of the declaring code by justifying an inextricable link between declaring code and the ideas of division, organization of computing tasks, and method calls.

In the words of the court: “(…) the declaring code (…) Like other computer programs, it is functional in nature. But unlike many other programs, its use is inherently bound together with uncopyrightable ideas (general task division and organization) and new creative expression (Android’s implementing code). (…) the declaring code is, if copyrightable at all, further than are most computer programs (such as the implementing code) from the core of copyright” (pp 23-24). By referring to Android’s implementing code as a “new creative expression” and establishing the “inextricable” link between declaring and implementing code, the Court starts to slightly transition towards the next factor and the decision it will take on it (transformative use).

From his side, Justice Thomas contraries the Courts decision on his dissent: “The Copyright Act expressly protects computer code. (…) and it defines “ ‘computer program’ ” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” §101. That definition clearly covers declaring code—sets of statements that indirectly perform computer functions by triggering prewritten implementing code. (…) Oracle cannot copyright the idea of using declaring code, but it can copyright the specific expression of that idea found in its library(p 4 of the Dissent).

Factor 2: Purpose and character

Within the assessment of this factor, the Court has to analyse the purpose of the use (eg commercial) and whether the use of the copied material is transformative enough so as to recognise the fair use of it. And it does.

Does the copying and use of Java API declaring code from the Java SE platform in Android’s platform have transformative character? The declaring code is copied and used for the same purpose in a different technical environment. For me, that’s not transformative.

However, suddenly the Court does not focus on the declaring code but on the aim to create a new product based on Java API. Of course, if literally compared, the Java SE platform and the Android platform are totally different platforms (these are complements, not substitutes). Thus, the technical composition of both platforms is different. However, the use of the copied declaring code (the expression of it), is exactly the same independently of a new implementing code written by Google. A good argument would have been to depart from the inextricable link between the elements stated in the first factor so as to assess them as a whole and thus, derived from the new implementing code that Google integrated, justify a transformative use of the declaring code (the Court partially points towards this arguments in p 26).

Moreover, the Court states: “To the extent that Google used parts of the Sun Java API to create a new platform that could be readily used by programmers, its use was consistent with that creative “progress” that is the basic constitutional objective of copyright itself. (…) “The primary objective of copyright is not to reward the labor of authors, but ‘[t]o promote the Progress of Science and useful Arts’ ” (quoting U. S. Const., Art. I, §8, cl. 8))”. Nonetheless, apparently, the Court forgot the other half of the provision and the constitutional objective as a whole, the provision reads: “to promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.” (See US Constitution). Henceforth, progress (ie innovation) might be a core objective, but the latter should not be fostered in detriment of exclusive rights (and if so, when?).

Also noteworthy, the Court starts using the term ‘reimplementation’: “the building of a system that repurposes the same words and syntaxes of an existing system” (sounds like a fancy and techy synonym of copying, anyways). Besides, the Court now broadly refers to “reimplementing an interface” and not reimplementing the declaring code (also used for the assessment of market effects in factor 4, eg p 31).

More tellingly, the Court exposes both interoperability, on the one hand (p 26), and antitrust/de facto standards (p 27), on the other hand, within this factor when these arguments should have played a more decisive role in the analysis of the nature of the copyrighted work. Interoperability could have been added to the argument of functionality of declaring code and concluded with a call for caution on de facto standards and the potential of abusive behaviours coming from the abuse of the latter (and the external factor of the existence of the standard).

On his side, Justice Thomas states in his dissent: Now, we are told, “transformative” simply means—at least for computer code—a use that will help others “create new products”. (…) Ultimately, the majority wrongly conflates transformative use with derivative use. To be transformative, a work must do something fundamentally different from the original. A work that simply serves the same purpose in a new context—which the majority concedes is true here—is derivative, not transformative. Congress made clear that Oracle holds “the exclusive rights . . . to prepare derivative works.”

Here, two different interpretations (and scopes) of ‘transformative character’ are at stake. The narrow and rigid one held by Justice Thomas which takes the declaring code in isolation, and a broad one held by the Court focusing on the transformation of the entire product and the features involved. However, the latter might seem counterintuitive as the transformed technical features are other than the declaring code (eg Google’s new implementing code). Anyways, the Court finds fair use here.

Factor 3: Substantiality of the portion used

The question at sight here was whether the 11,500 copied lines of code should be assessed in isolation or should be assessed as part of a “greater whole”. The Court does not clearly explain what is understood by this “greater whole”, it could be the entire Java API, as it states that: the total set of Sun Java API computer code, including implementing code, amounted to 2.86 million lines, of which the copied 11,500 lines were only 0.4 percent”. Or it could be Android’s platform and the small amount that these lines conform compared to the rest.

Thus, while considered in isolation the copied amount may seem considerable, it might happen that the copied amount was not as relevant. As the Court states, in some cases, a small, copied portion at the heart of a work might be far more flagrant than a longer portion in other cases (p 28).

According to the Court: “Several features of Google’s copying suggest that the better way to look at the numbers is to take into account the several million lines that Google did not copy. For one thing, the Sun Java API is inseparably bound to those task- implementing lines. Its purpose is to call them up. For another, Google copied those lines, not because of their creativity, their beauty, or even (in a sense) because of their purpose. It copied them because programmers had already learned to work with the Sun Java API’s system, and it would have been difficult, perhaps prohibitively so, to attract programmers to build its Android smartphone system without them”. Here (and along with the entire decision) this is one of the key arguments that the Court exhibits to justify Google’s fair use of the Java API’s declaring lines. Java SE had become an industry-based (ie de facto) standard at the time, developers were locked in from a ‘know how’ angle (I am not going to enter in the lock-in debate here), thus, according to Google (and the Court) the learning costs for the community of developers to dive into a new set of declaring code was, apparently, prohibitive. Contrarywise, from Justice Thomas side in his dissent, both Microsoft and Apple decided to build their own software, so apparently, it was not as prohibitive (p 4 Dissent).

One might even think that the Court bases its decision on this factor (favouring fair use) more on arguments from the former factor than from this one: “Google’s basic purpose was to create a different task-related system for a different computing environment (smartphones) and to create a platform—the Android platform—that would help achieve and popularize that objective. The “substantiality” factor will generally weigh in favor of fair use where, as here, the amount of copying was tethered to a valid, and transformative, purpose”.

In parallel, Justice Thomas in his dissent writes: “Even if Google’s use were transformative, the majority is wrong to conclude that Google copied only a small portion of the original work. The majority points out that the 11,500 lines of declaring code (…) were just a fraction of the code in the Java platform. But the proper de- nominator is declaring code, not all code. A copied work is quantitatively substantial if it could “serve as a market substitute for the original” work or “potentially licensed derivatives” of that work. Campbell, 510 U. S., at 587. The declaring code is what attracted programmers(p 18).

Factor 4: Market effects

 Not surprisingly, the Court also finds this last factor weighing in favour of fair use. To assess the effects that the copied work might have had on the market for the copyrighted work and/or for the value of the work, the Court states that the amount of the loss is not the most relevant element to analyse (it avoids diving into the monetary losses incurred by Oracle). It sets a balance test between the public benefit and the losses of the copyright holder (p 31). By doing so, the Court stretches the concept of ‘market effects’ so as to ponder not just the protection of the copyright holder but even further, also the protection of the public interest (very sharp move).

When it comes to the targeted market, the Court states that neither Oracle would have succeeded (ie entered) in the market of mobile operating systems (it has not), nor Google has harmed the actual (at the time) or potential market for Java SE. The court here makes a good point by differentiating between Java SE and Android as two separate distinct products with different markets (the former targeting laptops and desktops, the latter targeting smartphones), see reference to Google economic expert at p 32. However, here again, it abstracts itself and avoids to specifically refer to the copied work, the declaring lines.

In contrast, Justice Thomas in his opinion takes a cost-based approach by assessing real facts and not potential ones (at the time) and holds: “before Google released Android, Amazon paid for a license to embed the Java platform in Kindle devices. But after Google released Android, Amazon used the cost-free availability of Android to negotiate a 97.5% dis- count on its license fee with Oracle. Evidence at trial similarly showed that right after Google released Android, Samsung’s contract with Oracle dropped from $40 million to about $1 million” (p 12 Dissent). And: “But whether Oracle could itself enter that market is only half the picture. We look at not only the potential market “that creators of original works would in general develop” but also those potential markets the copyright holder might “license others to develop” (p 13 Dissent).

Finally, the Court comes up with one of the core statements in the decision which underlies the heart of it and what is really at stake, on the interrelation between IP law and innovation: “(…) given programmers’ investment in learning the Sun Java API, to allow enforcement of Oracle’s copyright here would risk harm to the public. Given the costs and difficulties of producing alternative APIs with similar appeal to programmers, allowing enforcement here would make of the Sun Java API’s declaring code a lock limiting the future creativity of new programs. Oracle alone would hold the key. The result could well prove highly profitable to Oracle (or other firms holding a copyright in computer interfaces). But those profits could well flow from creative improvements, new applications, and new uses developed by users who have learned to work with that interface. To that extent, the lock would interfere with, not further, copyright’s basic creativity objectives” (p 34 Decision).

And Justice Thomas argues: “And if companies may now freely copy libraries of declaring code whenever it is more convenient than writing their own, others will likely hesitate to spend the resources Oracle did to create intuitive, well-organized libraries that attract programmers and could compete with Android. If the majority is worried about monopolization, it ought to consider whether Google is the greater threat. (…) By copying Oracle’s work, Google decimated Oracle’s market and created a mobile operating system now in over 2.5 billion actively used devices, earning tens of billions of dollars every year. If these effects on Oracle’s potential market favor Google, something is very wrong with our fair- use analysis” (p 14 Dissent).

Beyond fairness, beyond justice: what is the technological reality telling to IP laws?

And here we are, at the heart of an issue whose fate (or a portion of it) has been placed in the hands of the judge. Are IPRs still innovation incentives? Yes, of course. But, in the other way around, is nowadays’ pace of innovation suffering from the enforcement of IPRs? Also, in some cases and increasingly. Are then IPRs obstacles to innovation? Were they designed in a time where innovation was conceived differently? Are IPRs fostering dynamic competition, or, have they become a static picture of dynamic competition? Oh boy oh boy…

Two different concepts of innovation are balanced. On the one hand, a controlled incremental innovation by an IPR holder whose exclusive rights are linked to a de facto standard (Oracle). On the other hand, a mix between free riding-based incremental innovation closely linked to radical innovation (Android). Do we currently need one of them more than the other?

All in all, the Court concludes that: “We reach the conclusion that in this case, where Google reimplemented a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative program, Google’s copying of the Sun Java API was a fair use of that material as a matter of law. The Federal Circuit’s contrary judgment is reversed” (on a side note, along with the Court’s assessment of this factor, the reader might get the feeling that the Court has progressively shifted from the modular approach initially taken and rightly focusing on the declaring code specifically (the copied work), to a more generic approach now referring to ‘API’ or the ‘Java API’).

Justice Thomas dissents and holds that: “The majority purports to save for another day the question whether declaring code is copyrightable. The only apparent reason for doing so is because the majority cannot square its fundamentally flawed fair-use analysis with a finding that declaring code is copyrightable. The majority has used fair use to eviscerate Congress’ considered policy judgment. I respectfully dissent.” (p 19 Dissent).

To my eyes, the fair use framework has been instrumentalised by a Court in order to force a needed decision in a case in which both sides were equally positioned in terms of arguments. The focus was not on the parties, but on current innovation trends in digital markets and the adaptation of copyright law’s frameworks.

Carlos Muñoz Ferrandis
Abogado e investigador doctoral. Ha realizado toda su investigación en el Max Planck Institute for Innovation and Competition (Múnich) en temas de open source y estándares técnicos. Carlos se enfoca en el sector de la Inteligencia Artificial donde trabaja para Hugging Face en temas de estrategia regulatoria y PI. También es miembro del grupo de expertos en IA de la OCDE, institución con la que colabora actualmente, y de la RAIL Initiative, institución que promueve licencias de uso responsable en IA. Carlos se centra actualmente en open source, estándares técnicos, PI, y regulación de IA/datos.



Por favor ingrese su comentario!
Por favor ingrese su nombre aquí

Time limit is exhausted. Please reload CAPTCHA.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.


Must read

¿Cómo debe comportarse el titular de una Patente Esencial?

El cierre por reforma de nuestro Lvcentinvs durante el...
- Advertisement -

Quizá también te gusteRELACIONADOS
Recomendados para ti