by John R. Harris

On May 31, 2012, Judge William Alsup of the U.S. District Court for the Northern District of California issued an order stating that APIs (application programming interfaces) are not copyrightable  (Oracle America, Inc. v. Google Inc., Case No. 10-03561 WHA, “Order re Copyrightability of Certain Replicated Elements of the Java Application Programming Interface”).

Click here to view the ruling in the case.

The very first sentence of the ruling concisely summarizes the legal issue:

This action was the first of the so-called “smartphone war” cases tried to a jury.  This order includes the findings of fact and conclusions of law on a central question tried simultaneously to the judge, namely the extent to which, if at all, certain replicated elements of the structure, sequence and organization of the Java application programming interface are protected by copyright.

The judge ruled that the command structure of an API is a “system or method of operation under Section 102(b) [of the Copyright Act] and therefore, cannot be copyrighted.”  The judge even provided his own statement as to freedoms of programming:  “So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API.”

Moreover, the names and phrases of the API command structure, such as “java.package.Class.method()” for various methods, classes, and packages, are not copyrightable.  The judge said this was consistent with cases going back at least 20 years.

To a large extent, the arguments propounded by Oracle in the case were a throwback to software copyright cases from the 1990s that held that the “structure, sequence, and organization” (SSO) of computer software is not per se copyrightable.  Oracle seemed to be taking the position that those older cases were not applicable in the context of APIs.  The older cases considering aspects of SSO represented an effort by some developers to extend the nature of copyright infringement to what was called “nonliteral” copying.  In other words, copyright infringement, as it was then unsuccessfully argued, could be found by copying of aspects of the way that software “looks and feels”.  Those efforts were stymied long ago, and Judge Alsup specifically cited a number of those cases as supporting his ruling.

This ruling may not change very much of the current and conventional attitudes as to copyright protection for software.  Yes, software is and remains copyrightable.   However, the ruling makes it difficult to protect aspects of software that are effected or reflected by APIs.  And, the ruling may encourage software developers to create more of what some would call “API-compatible” functionally substitute programs.

In other words, if APIs are not copyrightable, one could argue that people are free to write their own program code that is functionally similar to someone else’s “target” code – provided of course that the target code was not unlawfully copied – and use the same APIs as the target code.  One could arguably even swap out the target code for the substitute code in some circumstances, assuming that the substitute code was independently written and otherwise operatively compatible.  This in effect opens the way for programmers to substitute their API-compatible code for the proprietary code of others and not be at risk of copyright infringement.

But this is not really a new result.  This has been the law for quite some time, until the API copyrightability question was squarely raised in this case.

Copyright in software is still a “good idea” (with qualifications) for a number of reasons.  But the extent to which one can rely on copyright for protection against anything other than almost rote copying of code remains limited — unless and until an appeals court definitively rules otherwise.  That will probably not happen any time soon:  those who espouse anti-protection sentiments regarding software continue to shout loudly above the software protectionist crowd.

In concluding the opinion, the Judge Alsup suggested that his ruling reflected a trajectory in which the enthusiasm for protection of “structure, sequence, and organization” continues to decline, although he did not say it was a dead letter (his words).  He further suggested that the prevalence of software patents since the mid-1990s is a reflection of the limitations of copyright protection for software, quoting from a noted legal commentator:

As software patents gain increasingly broad protection, whatever reasons there once were for broad copyright protection of computer programs disappear. Much of what has been considered the copyrightable “structure, sequence and organization” of a computer program will become a mere incident to the patentable idea of the program or of one of its potentially patentable subroutines.¹ 

It was noted that Oracle and Sun have applied for and received patents that claim aspects of the Java API. See, e.g., U.S. Patents 6,598,093 and 7,006,855.

Accordingly, even though patent protection for software continues to erode under cases like Bilski v. Kappos and Mayo v. Prometheus, patents remain the last best hope for protection of innovations expressed through the computer and networking technologies.

****

¹(Mark Lemley, Convergence in the Law of Software Copyright?, 10 HIGH TECHNOLOGY LAW JOURNAL 1, 26–27 [1995]).