21 June 2012

Oracle v Google: an Australian perspective

Posted by Nicholas Liau  ● Partner: Paul Kallenbach

The US case of Oracle v Google (Case 10-03561 of 2012) was recently handed down. As part of the development of its Android mobile operating system, Google wanted to include compatibility for programs written in the programming language Java, copyright in which is owned by Oracle. Google wrote its own code emulating the function of Java. There was no issue that Google had independently written this code, and it is well established in US copyright law that Google was allowed to emulate the function of Java if it wished.

The issue in the case revolved a part of the programming language known as the Application Programming Interface (API). Java APIs consist of many methods which allow programmers to undertake certain functions. These methods are similar to macros (see our previous post on copyright in macros) in that they are small portions of code which bring together lower level instructions to achieve a higher level function. In order to achieve compatibility with Java, Google had to name the methods of its (independently coded) APIs in exactly the same way as they are named in Java. If Google had used a different naming system for its own APIs, programs designed to run with Java would not function with the Android operating system.

In both the US and Australia, copying the function of a computer program does not constitute a copyright infringement. If a software vendor wishes to protect function, they must rely on the patent system. The relevant question pertaining to copyright protection for computer programs is whether the form of the program has been copied. In dealing with the grey area between form and function, the US and Australian approaches diverge.

In the US, it was held by the District Court that the names of the API methods were not protected by copyright because anybody else wanting to replicate Java's functionality and retain compatibility would have to name their own API methods in exactly the same way. In effect, the form (the name) and the function of the API methods had "merged". Oracle could not rely on copyright in the names of the API methods because this would deny anybody else the ability to make a program with the same functionality.

In the US, this is known as the "merger doctrine", a doctrine which specifically denies copyright protection for expression where that expression is the only way to convey a particular idea. This is an exception to copyright protection, such that even works that would otherwise be protected by copyright are excluded from copyright protection where the doctrine applies. For instance, if a particular function could only be achieved with one particular piece of code, then that code would not be copyrightable no matter that it was original and otherwise met the requirements for copyright protection.

The District Court also considered the "taxonomy" of the APIs – that is, the way that the names of the different APIs were arranged in a particular logical structure so that the right API for any situation could be easily identified. The Court quickly held that any infringement here would also be nullified by the merger doctrine.

The Australian approach

But how would Google have fared in Australia? In out previous blog post, we asked how far an Australian court would be willing to allow textual copying to the extent that it is required for a piece of software to function.

In Australia, the merger doctrine has been specifically rejected. The only relevant consideration is whether the alleged infringer has taken a substantial part of the original copyright work. The fact that that original work may have been the only way of expressing a particular idea is irrelevant.

The difference between Australian and US law is evident in the High Court case of Data Access v Powerflex (1999) 202 CLR 1. In a similar fashion to Google, Powerflex was trying to emulate the function of software belonging to Data Access. A piece of code known as the Huffman compression table was copied. The compression table had to be an exact copy of the version in the Data Access software for Powerflex's software to be compatible. The High Court held that this was an irrelevant factor, and the fact a substantial part of the original work had been copied was enough to support a finding of copyright infringement. Nonetheless, the fact that form and expression were merged was irrelevant in Data Access. The High Court acknowledged that the ruling would limit the creation of software that can interoperate with existing software, but that this was a problem for the legislature to remedy if need be. 

The legislature did subsequently address the issue of interoperability in 2000 by introducing a limited exception to infringement under section 47D of the Copyright Act.  But putting that exception aside for present purposes, it seems entirely possible that Google would have lost this case had it been heard in Australia, at least given the principles outlined in Data Access. The lack of a merger doctrine would likely mean that Google would have been found to have infringed copyright in either the names of the API methods, or alternatively, the overall naming structure used for the methods. Of course, there would still be the issue of determining whether either of these things still constituted a substantial part of the Java program – but this would be the primary consideration, rather than any merger doctrine.

The EU

Interestingly, a similar issue was raised in the EU in the recent case of SAS v World Programming (Case C‑406/10 of 2011). In that case, the European Court of Justice held that the functionality of a computer program or programming language was an idea not subject to copyright in and of itself. However, like Australia, there was no mention by the Court of any type of merger doctrine. This means that if an author had copied a form of expression because it was the only way to produce the desired functionality, this could still constitute copyright infringement.

IceTV – a limited doctrine of merger?

In IceTV v Nine Network (2009) 239 CLR 458, IceTV created its own TV guide which copied the TV schedules of Channel Nine. The High Court held that this was not an infringement of copyright. French CJ, Crennan and Kiefel JJ held that "[the] expression was essentially dictated by the nature of the information". In copying the TV guide, IceTV did not infringe copyright because it was presenting the information in virtually the only logical way possible – there are very few ways to logically present TV schedule information aside from grouping shows in a table describing channel and time.

It seems as if this may be a shift towards the Australian acceptance of some sort of merger doctrine. The High Court seems to accept that the level of copyright afforded to a particular expression of an idea is governed to some extent by the number of possible expressions of that idea. So where there are very few ways of expressing an idea (or only one way), then only very 'thin' copyright protection will be available. 

The operation of this doctrine, if it does exist at all, is different from its operation in the US. In the US, a work could fulfil the requirements for subsistence of copyright, but may still be denied protection because of the operation of the merger doctrine. Conversely, in IceTV the High Court held that the degree of 'merger' goes towards the originality inherent in the expression of an idea. In other words, it impacts upon whether copyright subsists in the first place.

It is difficult to say exactly what effect IceTV would have on a case like Google if it were heard in Australia today (again, putting aside the interoperability exception under section 47D of the Copyright Act). On the one hand, the selection of a naming regime for an API arguably requires more creativity than simply arranging TV shows into a table, differentiating a Google type scenario significantly from that in IceTV. But on the other hand, whichever naming regime is chosen by the developers, it must be used by all others subsequently to achieve the same functionality.