Last month, Google asked the Supreme Court to hear its appeal of an appeals court ruling that certain application program interfaces (APIs) are copyrightable.  Oracle’s response is due in December, and the US Government may weigh in, so we may not know until January 2015 whether the Supreme Court will accept the case.  I expect they will, primarily to deal with confusion amongst the various courts around the country on the legal points discussed below.  The results will have significant ramifications on the use of program APIs without a license.

Background

In creating Android, Google copied 37 Java API packages that originated from Sun (now Oracle).  Specifically, Google copied approximately 7000 lines of “declaring code” (the “calls”) for the packages in question.  All the calls follow the same command format.  The actual code of the packages themselves (which you can think of as library code) was rewritten by Google.

The issue under consideration is simply this: are the calls protected by copyright?  In general, copyright protects the expression of ideas, not the ideas themselves.  So for example, in 1879, the Supreme Court ruled that while a ledger book for bookkeeping was copyrightable, the underlying method of accounting enabled by the book was not protected by copyright.  With that as background, is declaring code copyrightable, given that its sole purpose is simply to issue commands to enable the package code? Aren’t such commands “ideas,” not protectable by copyright?

Prior Rulings

In 2012, a federal District Court in California ruled that such calls are NOT copyrightable, primarily because they constitute a “method of operation” of the underlying packages. The District Court based its ruling on the idea that if you want to make calls to the libraries in a manner compatible with Java, you have no choice but to use the exact same sequences of declaring code.  In May 2014, a federal appeals court reversed that ruling, and found the declaring code copyrightable.  Its main rationales were as follows:

• Oracle could have written the sequences of declaring code many different ways;
• The notion that users were “forced” to use the same sequences of declaring code to be compatible with Java is irrelevant to the issue of whether those sequences are protected by copyright.  What matters is whether the creator of code, not the user of code, has few/no choices in how to write it.  As noted above, the appeals court found Oracle could have written the code many different ways.  In view of that finding, the appeals court determined that such code is in fact copyrightable; and
• The most applicable previous court ruling on point (Lotus v. Borland, finding a menu tree of commands for operating the Lotus 1-2-3 spreadsheet program not copyrightable) is distinguishable, and not applicable here.

I think the appeals court decision is weakest on the last point.  These are APIs - elaborate APIs, to be sure, but APIs nonetheless.  Their sole function is to provide sequences of commands to operate the libraries.  That’s all they do.  That should matter in the copyrightability analysis.

Practical Considerations

While we’ll have to wait and see how the Supreme Court responds, here are some practical observations:

• I continue to believe that simple menu commands (e.g., function calls invoking function X by using command Y) are NOT copyrightable, particularly if the name of the command is analogous to the function being invoked.  In the Oracle v. Google case, the APIs are in fact sequences of code used to invoke functions, rather than simple commands.  It seems to me that the more detailed and extensive the “declaring code” is relative to simple “declarative commands,” the more likely it is that such code will be found to be copyrightable, should the Supreme Court uphold the appeals court ruling.
• Also, other information, materials, or code often included in API packages (such as test/verification code, or sample code) is likely to be copyrightable regardless of these recent decisions.  So, it may be wise to first parse through exactly what is being proposed for use and exactly how it will be used, rather than relying on a simple characterization that it is (or is part of a package for) an “API.”
• Given the unsettled state of the law, it may be wise to consult with an attorney before deciding to use APIs,  let alone deciding to use verification or sample code that may be included in API packages.