BT

APIs Cannot be Copyrighted

by Alex Blewitt on Jun 01, 2012 |

In a decisive legal ruling yesterday, the judge in the Oracle vs Google case declared that APIs are not copyrightable, and Oracle cannot claim anything for the SSO – structure, sequence and organisation of those methods, classes and packages. From the summary judgement:

The overall name tree, of course, has creative elements but it is also a precise command structure – a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability…

Contrary to Oracle, copyright law does not confer ownership over any and all ways to implement a function or specification, no matter how creative the copyrighted implementation or specification may be. The Act confers ownership only over the specific way in which the author wrote out his version. Others are free to write their own implementation to accomplish the identical function, for, importantly, ideas, concepts and functions cannot be monopolized by copyright.

This is not only a major victory for common sense, but recently the European Union recently declared that APIs cannot be copyrighted in Europe, as reported earlier by InfoQ. Had the case decision gone the other way, this would have led to a significant rift between what is and isn't copyrightable between the two regions. It would have also prevented the very thing that Sun before it, and Oracle after, that had initially encouraged other runtimes such as the now defunct Apache Harmony project, had Oracle let them pass the TCK as required by the JSPA at that time.

With the complete decimation of Oracle's patent claims against Google, and now the ruling that APIs cannot be copyrighted, the trial is all but over and a complete win for Google. The only remaining aspect of the case is the nine line rangeCheck function, which was admitted as potentially copying from an earlier version of a similar function – even though the copying was likely not intentional and re-created from memory rather than physically copied. The Judge specifically recorded the information, just in case an appeals process is launched by Oracle:

Oracle has made much of nine lines of code that crept into both Android and Java. This circumstance is so innocuous and overblown by Oracle that the actual facts, as found herein by the judge, will be set forth below for the benefit of the court of appeals.

Dr. Joshua Bloch worked at Sun from August 1996 through July 2004, eventually holding the title of distinguished engineer. While working at Sun, Dr. Bloch wrote a nine-line code for a function called “rangeCheck,” which was put into a larger file, “Arrays.java,” which was part of the class library for the 37 API packages at issue. The function of rangeCheck was to check the range of a list of values before sorting the list. This was a very simple function. In 2004, Dr. Bloch left Sun to work at Google, where he came to be the “chief Java architect” and “Java guru.” Around 2007, Dr. Bloch wrote the files, “Timsort.java” and “ComparableTimsort,” both of which included the same rangeCheck function he wrote while at Sun. He wrote the Timsort files in his own spare time and not as part of any Google project. He planned to contribute Timsort and ComparableTimsort back to the Java community by submitting his code to an open implementation of the Java platform, OpenJDK, which was controlled by Sun. Dr. Bloch did, in fact, contribute his Timsort file to OpenJDK and Sun included Timsort as part of its Java J2SE 5.0 release.

In 2009, Dr. Bloch worked on Google’s Android project for approximately one year. While working on the Android team, Dr. Bloch also contributed Timsort and ComparableTimsort to the Android platform. Thus, the nine-line rangeCheck function was copied into Google’s Android. This was how the infringement happened to occur.

When discovered, the rangeCheck lines were taken out of the then-current version of Android over a year ago. The rangeCheck block of code appeared in a class containing 3,179 lines of code. This was an innocent and inconsequential instance of copying in the context of a massive number of lines of code.

The same is also found for the eight decompiled test files, which was treated as a single instance of copying and never found their way into the Android operating system, or any device running it:

Google also copied eight computer files by decompiling the bytecode from eight Java files back into source code and then using the source code. These files were merely used as test files and never found their way into Android or any handset. These eight files have been treated at trial as a single unit.

Line by line, Oracle tested all fifteen million lines of code in Android (and all files used to test along the way leading up to the final Android) and these minor items were the only items copied, save and except for the declarations and calls which, as stated, can only be written in one way to achieve the specified functionality.

The order summary confirms that Oracle's land-grab approach is not the way to protect APIs:

In closing, it is important to step back and take in the breadth of Oracle’s claim. Of the 166 Java packages, 129 were not violated in any way. Of the 37 accused, 97 percent of the Android lines were new from Google and the remaining three percent were freely replicable under the merger and names doctrines. Oracle must resort, therefore, to claiming that it owns, by copyright, the exclusive right to any and all possible implementations of the taxonomy-like command structure for the 166 packages and/or any subpart thereof – even though it copyrighted only one implementation. To accept Oracle’s claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands. No holding has ever endorsed such a sweeping proposition.

Conclusion

This order does not hold that Java API packages are free for all to use without license. It does not hold that the structure, sequence and organization of all computer programs may be stolen. Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act. Therefore, Oracle’s claim based on Google’s copying of the 37 API packages, including their structure, sequence and organization is DISMISSED.

The last part of the trial will be to calculate damages (if any) and close the case. Even if Oracle launch an appeal, the order makes it clear the reasoning behind the decision, and notes "No court of appeals has addressed the copyrightability of APIs, much less their structure, sequence and organization. Nor has any district court." It is very unlikely that they would start now. The trial continues.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

API vs. partial API by Michał Kudła

Very important: FULL API - compatybility
Very BAD: Partial API - fragmentation.

How to fight with it?

Re: API vs. partial API by Shi Kafune

In open source projects don't think it matters, it encourages innovation.
I think only way to prevent is by using strict licensing policy or make it closed source.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT