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?
There is (copyright) life on the planet of the APIs There is (copyright) life on the planet of the APIs Reviewed by Eleonora Rosati on Saturday, May 10, 2014 Rating: 5

6 comments:

  1. The author intimates and asks:

    "intended as particularly meaningful thresholds to protection, especially considering that APIs are not highly sophisticated software commands."

    The implication is that the threshhold was moved (lowered) - and is an incorrect implication.

    "In more general terms, does this decision imply a re-thinking of both earlier case law on computer programs and the idea/expression dichotomy"

    No. Why would you even think so?

    I am struck with the notion of the author's bias against copyright to software.

    Perhaps I am being a bit too sensitive. Perhaps not.

    ReplyDelete
  2. I'd say API's are like a bolt to which one screws on a nut by means of a wrench. To connect component A to component B for A and B to interact. And it may define distances between bolt X and bolt Y.

    Surely, API's are a bit more sophisticated (I'd say, that is). But the bottom line remains the same, in my opinion.

    Perhaps a little mix with design rights and patent right with this part of copyright may solve the issue: if implementation of an API of component B (Google) to interact with component A (Oracle) would be purely technical defined (design) and the actual implementation of B would be a one-way street given public knowledge, could one argue the implementation of B would not constitute copyright infringement?

    Having said that, if the API were to be novel, inventive and confer a new technical effect, another question not addressed in this case may arise.

    Says a die-hard patent attorney...

    ReplyDelete
  3. Jasper,

    The point of the current ruling from the CAFC on the Oracle v. Google matter is far simpler than what your post addresses.

    Your post leads to the determination of a Fair Use defense.

    That defense may yet still be reached.

    The key to understand is that such is a defense, and that defense is only reached in a case where first one finds that copyright attaches.

    You (just like the lower court), need to adjust your opinion and NOT conflate what CAN be copyrighted (which the CAFC has just clarified) with what should survive an analysis of defensive positions applied against something deemed to be within the realm of copyright.

    As to your "Having said that" last point, please, let's not conflate the topic and muddle patent law into the equation. No need to go there, as it is understood by die-hard patent attorneys (at least the US versions operating under US law) that software has different aspects protectable under the different IP laws.

    ReplyDelete
  4. Interesting to compare and contrast with SAS v World Programming Ltd in the UKCA.

    http://www.bailii.org/ew/cases/EWCA/Civ/2013/1482.html

    I think the EU Software Directive is more strongly against copyright subsisting in the interface (at recital 13) than 102(b) USC. That seems to be at the heart of the divergence.

    If it goes to appeal, I wonder if the supreme court will put any weight on convergence in such an economically significant area of law.

    ReplyDelete
  5. Dave,

    I surely hope that there is NO such untowards impact of "convergence," given that law still very much should respect each nation's sovereignty and that there has been no surrender of sovereignty on this particular legal issue.

    ReplyDelete
  6. Given the idea of a particular interface the syntactic constraints of a programming language leaves very little choice about how that idea can be expressed.

    ReplyDelete

All comments must be moderated by a member of the IPKat team before they appear on the blog. Comments will not be allowed if the contravene the IPKat policy that readers' comments should not be obscene or defamatory; they should not consist of ad hominem attacks on members of the blog team or other comment-posters and they should make a constructive contribution to the discussion of the post on which they purport to comment.

It is also the IPKat policy that comments should not be made completely anonymously, and users should use a consistent name or pseudonym (which should not itself be defamatory or obscene, or that of another real person), either in the "identity" field, or at the beginning of the comment. Current practice is to, however, allow a limited number of comments that contravene this policy, provided that the comment has a high degree of relevance and the comment chain does not become too difficult to follow.

Learn more here: http://ipkitten.blogspot.com/p/want-to-complain.html

Powered by Blogger.