SCOTUS Decision in Google v. Oracle: Distorting ‘Fair Use’ but the Scathing (and Logical) Dissent is the One Saving Grace (Part I)

image from here

On 5th April, the Supreme Court of the United States allowed Google’s appeal and held that Google’s copying of roughly 11,500 lines of code relating to 37 software packages forming part of Sun Java Application Programming Interface (API), owned by Oracle, was protected by ‘fair use’. The majority opinion was delivered by Justice Breyer (joined by 5 other judges), and a dissenting opinion was filed by Justice Thomas (joined by one other judge). One judge (Justice Barrett took no part in the decision).

In this Part I, I will limit myself to introducing the case and summarising the majority view.

Background

In a suit for copyright infringement concerning the aforesaid copying of API, the District Court originally held that the subject matter was not copyrightable. Although there were also claims for patent infringement, this was dropped later. On appeal in 2014, the Federal Circuit reversed and held that there was copyrightable subject matter but remanded the matter back to the District Court for a finding on whether the ‘fair use’ immunity applied in favour of Google. The SCOTUS refused certiorari at that point. In a jury verdict on remand, Google succeeded on the ‘fair use’ defence. The matter was appealed to the Federal Circuit a second time by Oracle, which reversed the jury verdict as a matter of law and held that “fair use” was not established by Google in the present matter.

In the 2^nd round, the Federal Circuit remanded the matter back to the District Court for trial on damages. In the meantime, Google filed a petition for certiorari before the Supreme Court on the Federal Circuit’s determinations regarding both copyrightability and fair use. The SCOTUS granted certiorari and issued its final judgement on 5th April, 2021.

Introducing APIs

I do not want to spend too much introducing APIs – there are tons of resources available, and the judgment provides a decent summary. In simple terms, APIs allows one program to interface with another and adds efficiency to the entire system. For instance, someone may have already written a package/code for performing a specific function (say, multiply x*y). If I came up with an application that, inter alia, performs this same function, rather than rewrite the package/code, I can simply call upon package/code. The API is what enables this. In this example, the package/code that performs this x*y is called the ‘implementing code’. This ‘implementing code’ is identified by or associated with a ‘declaring code’. That declaring code provides the name for each task and the location of each task within the API’s overall organisational system. The ‘declaring code’, thus, is a shortcut for programmers to reach the ‘implementing code’.

Appendix B to the majority opinion (Sl. Op. at pg. 38) provides a nice schematic to demonstrate this. I would encourage readers to consider that drawing. The case was limited to the copying of ‘declaring code’.

Summary of the majority’s ruling

1. No final finding on copyrightability. The judgement is limited only to the ‘fair use’ doctrine (Sl. Op. at pg. 15).
2. Computer programs, like any other copyright protected subject matter, is subject to the applicable limitations in law (Sl. Op. at pg. 18).
3. ‘Fair use’ is a mixed question of law and fact. Therefore, even if there were jury determinations on points of fact, a court is entitled to review the ultimate legal question de novo (Sl. Op. at pg. 20).
4. Fair use is an ‘equitable’ doctrine and not a ‘legal” doctrine (Sl. Op. at pg. 20).
5. Nevertheless, the applicable statutory provision, i.e., 17 U.S.C.107, provides for an inclusive set of 4 factors that “indicates” how a court can apply this equitable doctrine. These 4 factors are (Sl. Op. at pg. 13 – 14):
   1. The purpose and character of the use, including whether it is for commercial purpose or for non-profit educational purposes;
   2. The nature of the copyrighted work;
   3. The amount and substantiality of the portion used in relation to the whole; and
   4. The effect of the use upon the potential market for or value of the copyrighted work

6. On the 2^nd factor (Sl. Op. at pages 23-24):
   1. The “declaring code” is intrinsically far away from the “core of copyright”, i.e. less worthy of copyright protection.
   2. This is because even though it is functional in nature, it is “inherently bound together with uncopyrightable ideas”, and more importantly, the value of such a “declaring code” lies in the investment of time and effort by computer programmers who popularise their use, creating the network effect for their consistent use across platforms.
   3. This was the conclusion despite a finding that the creativity in “declaring code” lay in coming up with names that would prove intuitively easy to remember and thus making it popular for programmers/developers to use them consistently.

7. On the 1^st factor (Sl. Op. at pg. 25 – 28):
   1. Google copies only the minimum amount of API required, precisely.
   2. Google used the copied portion to create new products/expand the use of Android-based smartphones.
   3. Google used the copied portion in a distinct and different computing environment (smartphones) compared to the original creation (desktop and laptop computers).
   4. Thus, Google’s copying was “transformative”.
   5. The commercial gain of Google was not dispositive given that the copying was “transformative”.

8. On the 3^rd factor (Sl. Op. at pg. 28 – 30):
   2. The Sun Java API totalled almost 2.86 million lines, and the “declaring code”/copied portion comprised 11,500 lines, i.e., 0.4% of the total.
   3. Even a small amount of copying may fall outside the scope of “fair use” if it forms the “heart” of the original works created expression.
   4. Google copied them not because of their creativity but because of programmers’ familiarity with the Sun Java API system. To not use them would have been prohibitively expensive for Google to attract programmers to build its Android smartphone system.
   5. Since the copying was “transformative” under the 1^st factor, the case must be viewed in the context of the larger code and thus, there was no “substantiality” in the copying by Google.

9. On the 4^th factor (Sl. Op. at pages 30 – 35):
   1. Sun was failing to succeed in the mobile phone market by itself.
   2. Google’s Android platform catered to a distinct and more advanced market (smartphones) than what Sun/Oracle was catering to (desktops and laptops, “feature” phones).
   3. Sun itself saw benefit from the broader use of the Java language in a new platform like Android.
   4. The source of Android’s profitability was more to do with the programmers’ familiarity with Sun Java API and less to do with Sun’s investment in creating the Sun Java API.
   5. To not allow Google to claim fair use would give Oracle the ability to cause public harm – it will create a lock, limiting future creation of new programs (something similar to the hold-up situation that is referred to in the SEP context).

To be continued in Part II.