There is (copyright) life on the planet of the APIs

Oh really? Copyright in APIs?
By the time this Kat had already swapped her usual Katfur for her Katkini and her laptop for a more friendly copy of Vogue Italia and was thus ready to sunbathe in her native land, Katfriend Tom Ohta (Bristows) broke the news that yesterday the US Court of Appeals for the Federal Circuit issued its much awaited decision in Oracle v Google, a case concerning copyright in APIs [which, explains Merpel, are not a special type of apes, but is rather an acronym that stands for "application programming interfaces", ie packages of computer source code that specify how some software components should interact with each other].

What was the background to this case?

Oracle wrote a number of API packages in the popular Java programming language, and then licensed them on various terms to third parties. Many software developers use the Java language, as well as Oracle’s API packages, to write applications [also known as "apps", explains again tech-savvy Merpel] for desktop and laptop computers, tablets, smartphones, and other devices.

Oracle found that Google was also using 37 of its APIs without permission, so filed a lawsuit before the US District Court for the Northern District of California, claiming that Google’s Android mobile operating system infringed Oracle’s patents and copyrights.

While the jury found no patent infringement [and the patent claims were not at issue in this appeal], it found that Google had infringed Oracle’s copyrights in the 37 Java packages and a specific computer routine called “rangeCheck” [apparently something that even a high schooler or a Kat could write]. The jury deadlocked on Google’s fair use defence.

After the jury verdict, the district court denied Oracle’s motion for judgment as a matter of law (JMOL) regarding fair use, as well as Google's similar request as regards rangeCheck files [this Kat understands from Wikipedia that JMOL is something that occurs during trial and means that, if there is no evidence to support a reasonable conclusion for the opposing party, judgment is entered by the court and the case is over]
Merpel on a well-deserved break from
writing and "copyrighting" her APIs

In the end, the district court ruled in favour of Google except with respect to the rangeCheck files, and held that the replicated elements of the 37 API packages - including the declaring code and the structure, sequence, and organisation - were not subject to copyright protection at all. This was because there is only one way to write the Java method declarations and remain “interoperable” with Java; and the organisation and structure of the 37 Java API packages is a “command structure” excluded from copyright protection under Section 102(b) of the US Copyright Act.


Of course, both parties appealed. 


Yesterday the Court of Appeals reversed the decision of the district court, and held that the declaring code and the structure, sequence, and organisation of the 37 API packages are entitled to copyright protection. Because the jury deadlocked on fair use, it remanded for further consideration of Google’s fair use defence. The Court also denied Google's motion for JMOL with respect to the rangeCheck function, and remanded for further proceedings.


Here the pieces
fit perfectly
The Court of Appeals recalled what Circuit Judge Boudin said in the 1995 Lotus decision: Applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit.

While this is true, said the Court, the district court failed to distinguish between the threshold question of what is copyrightable [is this term still correct, wonders Merpel, in an age of non-formalities?] -  which presents a low bar - and the scope of conduct that constitutes infringing activity. The court also erred by importing fair use principles, including interoperability concerns, into its copyrightability analysis.

How did the Court of Appeals achieve this outcome, which has been considered surprising by a number of early commentators [here]?

After recalling basic principles like originality and the idea/expression dichotomy, the Court considered copyright in computer programs. 

It recalled that protection extends to both literal [the source code and the object code] and non-literal [eg the program's sequence, structure, and organisation, as well as the program's user interface] elements. The latter are only protected if they qualify as 'expression' of an idea, rather than an 'idea' itself.

Google conceded that it had copied the declaring code [the lines of this embody the structure of each API package, just as the chapter titles and topic sentences represent the structure of a novel] verbatim. According to Oracle, when Google copied the declaring code in these packages it also copied their sequence and organisationOracle also argued that the non-literal elements of the API packages, these being the structure, sequence, and organisation that led naturally to the implementing code Google created, were entitled to protection.

Milly has just been told
that, yes, she has ideas,
but she cannot
quite express them
Both parties agreed that the APIs met the originality requirement. However, what they disagreed upon was whether they were expressions of ideas or just an idea itself, and the interpretation of Article 102(b). This states:

"In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."

According to Google, this provision sets a two-step copyrightability analysis: while Section 102(a) grants copyright protection to original works, Section 102(b) takes it away if the work has a functional component.

The Court of Appeals did not agree with Google's interpretation. Quoting from Mitel, it held that Section 102(a) and 102(b) are to be considered collectively, so that certain expressions are subject to greater scrutiny in order to  separate protectable expression from unprotectable ideas, facts, processes, and methods of operation.

By recalling the famous abstraction-filtration-comparison test which rejected the notion that anything that performs a function is necessarily "uncopyrightable", the Court concluded that, among other things, the district court had erred when it concluded that each line of declaring code cannot be protected because the idea and expression have merged, and found the declaring code non-protectable because it employs short phrases.

For sure this Kat is (1) already sun-burnt; and (2) not an expert on US law. However, from this decision it would seem that neither the originality requirement nor the idea/expression dichotomy are to be intended as particularly meaningful thresholds to protection, especially considering that APIs are not highly sophisticated software commands. In more general terms, does this decision imply a re-thinking of both earlier case law on computer programs and the idea/expression dichotomy, starting with the seminal decision in Baker v SeldenWhat do readers think?