The following is the second of the three parts of Judge William Alsup’s ruling in Oracle vs Google copyright case.
APPLICATION OF CONTROLLING LAW TO CONTROLLING FACTS
All agree that everyone was and remains free to program in the Java language itself. All agree that Google was free to use the Java language to write its own API.
While Google took care to provide fresh line-by-line implementations (the 97 percent), it generally replicated the overall name organization and functionality of 37 packages in the Java API (the three percent).
The main issue addressed herein is whether this violated the Copyright Act and more fundamentally whether the replicated elements were copyrightable in the first place.
This leads to the first holding central to this order and it concerns the method level. The reader will remember that a method is like a subroutine and over six thousand are in play in this proceeding.
As long as the specific code written to implement a method is different, anyone is free under the Copyright Act to write his or her own method to carry out exactly the same function or specification of any and all methods used in the Java API.
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.
To return to our example, one method in the Java API carries out the function of comparing two numbers and returning the greater. Google — and everyone else in the world — was and remains free to write its own code to carry out the identical function so long as the implementing code in the method body is different from the copyrighted implementation.
This is a simple example, but even if a method resembles higher mathematics, everyone is still free to try their hand at writing a different implementation, meaning that they are free to use the same inputs to derive the same outputs (while throwing the same exceptions) so long as the implementation in between is their own.
The House Report, quoted above, stated in 1976 that “the actual processes or methods embodied in the program are not within the scope of the copyright law.”
Much of Oracle’s evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new output can be creative, even inventive, including the choices of inputs needed and outputs returned.
The same is true for classes. But such inventions — at the concept and functionality level — are protectable only under the Patent Act. The Patent and Trademark Office examines such inventions for validity and if the patent is allowed, it lasts for twenty years. Based on a single implementation, Oracle would bypass this entire patent scheme and claim ownership over any and all ways to carry out methods for 95 years — without any vetting by the Copyright Office of the type required for patents.
This order holds that, under the Copyright Act, no matter how creative or imaginative a Java method specification may be, the entire world is entitled to use the same method specification (inputs, outputs, parameters) so long as the line-by-line implementations are different.
To repeat the Second Circuit’s phrasing, “there might be a myriad of ways in which a programmer may . . . express the idea embodied in a given subroutine.” Computer Associates, 982 F.2d at 708.
The method specification is the idea. The method implementation is the expression. No one may monopolize the idea.To carry out any given function, the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function. The declaration requires precision.
Significantly, when there is only one way to write something, the merger doctrine bars anyone from claiming exclusive copyright ownership of that expression.
Therefore, there can be no copyright violation in using the identical declarations. Nor can there be any copyright violation due to the name given to the method (or to the arguments), for under the law, names and short phrases cannot be copyrighted.
In sum, Google and the public were and remain free to write their own implementations to carry out exactly the same functions of all methods in question, using exactly the same method specifications and names.
Therefore, at the method level — the level where the heavy lifting is done — Google has violated no copyright, it being undisputed that Google’s implementations are different.
As for classes, the rules of the language likewise insist on giving names to classes and the rules insist on strict syntax and punctuation in the lines of code that declare a class. As with methods, for any desired functionality, the declaration line will always read the same (otherwise the functionality would be different) — save only for the name, which cannot be claimed by copyright.
Therefore, under the law, the declaration line cannot be protected by copyright. This analysis is parallel to the analysis for methods. This now accounts for virtually all of the three percent of similar code. Even so, the second major copyright question is whether Google was and remains free to group its methods in the same way as in Java, that is, to organize its Android methods under the same class and package scheme as in Java.
For example, the Math classes in both systems have a method that returns a cosine, another method that returns the larger of two numbers, and yet another method that returns logarithmic values, and so on. As Oracle notes, the rules of Java did not insist that these methods be grouped together in any particular class.
Google could have placed its trigonometric function (or any other function) under a class other than Math class. Oracle is entirely correct that the rules of the Java language did not require that the same grouping pattern (or even that they be grouped at all, for each method could have been placed in a stand-alone class).
Oracle’s best argument, therefore, is that while no single name is copyrightable, Java’s overall system of organized names — covering 37 packages, with over six hundred classes, with over six thousand methods — is a “taxonomy” and, therefore, copyrightable under American Dental Association v. Delta Dental Plans Association.
There was nothing in the rules of the Java language that required that Google replicate the same groupings even if Google was free to replicate the same functionality.
The main answer to this argument is that while the overall scheme of file name organization resembles a taxonomy, it is also a command structure for a system or method of operation of the application programming interface.
The commands are (and must be) in the form java.package.Class.method() and each calls into action a pre-assigned function.
To repeat, Section 102(b) states that “in no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation . . . regardless of the form . . . .” That a system or method of operation has thousands of commands arranged in a creative taxonomy does not change its character as a method of operation.
Yes, it is creative. Yes, it is original. Yes, it resembles a taxonomy. But it is nevertheless a command structure, a system or method of operation — a long hierarchy of over six thousand commands to carry out pre-assigned functions. For that reason, it cannot receive copyright protection — patent protection perhaps — but not copyright protection.
Interoperability sheds further light on the character of the command structure as a system or method of operation. Surely, millions of lines of code had been written in Java before Android arrived.
These programs necessarily used the java.package.Class.method() command format. These programs called on all or some of the specific 37 packages at issue and necessarily used the command structure of names at issue. Such code was owned by the developers themselves, not by Oracle.