If you thought that you could do whatever you needed to do to achieve interoperability and be safe from copyright infringement, think again.  The Federal Circuit’s ruling last Friday in Oracle v. Google puts a finer point on the limits of interoperability as a defense to copyright infringement.

Quick Background (if you know the facts – skip this):

Java API “packages” allow programmers to access pre-written Java functionality.  To invoke that functionality, a programmer must use a string of code called “declaring” code.  The code that actually executes the function is called “implementing” code.  Google tried to get a license to adapt Java for mobile devices, in particular, Android.  Negotiations broke down and the deal was never consummated.  Google then decided to write its own code for the Android system using the Java programming language so that an app written in Java could run on Android.   Google wrote its own implementing code from scratch.  However, Google thought that Java programmers writing for the Android system would want to be able invoke the same functions using the Java declaring code (with which they were familiar).  So, Google copied the Java declaring code for all Java APIs, verbatim.

The key issue on appeal was whether the Java declaring code was copyrightable.  The lower court said that it was not copyrightable.  The lower court, in essence, found that the Java declaring code was not copyrightable because it was functional and it was essential for interoperability.  The appellate court disagreed.

Merger Doctrine

The appellate court ruled that the lower court misapplied the merger doctrine.  Under the merger doctrine, when there are a limited number of ways to express an idea, the idea merges with the expression and is, therefore, unprotectable.  In this case, under the rules of Java, a programmer must use the identical declaring code to invoke the corresponding function.  Since the was only one way for Google to write the declaring code for each function, the lower court ruled that the merger doctrine barred copyright protection.

The reason the lower court got it wrong (according to the appellate court) was that the lower court looked at the issue from the perspective of the options available to Google and not the options available to Sun/Oracle.  The merger doctrine bars copyright protection for code for which there is a limited number of ways to write at the time it is written.  Thus, the proper merger doctrine inquiry would have been whether there were a limited number of ways that Sun/Oracle could have written the declaring code.

Scenes a Faire

The scenes a faire doctrine basically provides that stuff that is standard, stock or common to a topic can’t be copyrightable.  So, where the choice of coding is dictated by external factors, such as widely accepted programming practices or a computers mechanical specifications, then the code written to accommodate those practical/functional things is not subject to copyright protection.  The lower court rejected Google’s argument based on this doctrine and so did the appellate court.  Like the merger doctrine, the scenes a faire doctrine is used to determine whether Sun/Oracle had copyright in Java.  In this context, the inquiry would be not whether Google’s programming was dictated by external factors (i.e., the mandates of the Java platform for the use of declaring code), but rather whether Sun/Oracle’s composition of the declaring code was dictated by external factors.  There was no evidence that such was the case.

Interoperability

Google’s arguments focused largely (and understandably) on the need for interoperability.  But the court emphasized the fact that the interoperability needs of Google do not apply in determining whether Sun/Oracle was entitled to copyright protection.  Rather, it was the interoperability needs of Sun/Oracle that are applicable to whether Java is copyrightable.

The court also discounted Google’s interoperability arguments on the  basis that there was no evidence of the existence of any apps written in Java and running on the Android platform.  Rather, the court emphasized that Google’s desire was to capitalize on the fact that programmers already trained in Java’s APIs in order to accelerate its development process.  The court concluded that while this might be relevant in determining whether Google’s use of the Java declaring code constituted a fair use, it was not relevant for purposes of determining the copyrightability of Java.

Specifically, the court found that, with respect to fair use, because of the nature of computer programs, fair use may be applicable where it is necessary to copy the expressive (copyrightable) elements in order to perform the functions associated with the purely functional (non-copyrightable) elements.  Ultimately, however, the court declined to rule on the fair use issue due to a lack of sufficient factual findings in the lower court.  So, the case was remanded back to the lower court to be decided on the issue of fair use.

“It ain’t over ’til its over.”

- Yogi Berra -