An update on Oracle v. Google

After over a year and a half of legal proceedings, Oracle and Google will go to trial on April 16 in front of the United States District Court for the Northern District of California, to determine whether or not Google's Android software infringes Oracle's copyrights on Java, as well as some of its patents. If the parties don't settle, this trial is expected to take eight weeks.

A lot has happened since the litigation started. In August 2010, several months after acquiring Sun Microsystems, which developed Java and held the copyrights, Oracle launched a lawsuit against Google, claiming that Android's use of Java infringed seven of Oracle's patents, as well as the Java copyrights Oracle holds. The complaint demands an injunction against Google from continuing with its allegedly infringing activity, that "all copies made or used in violation of Oracle America's copyrights [...] be impounded and destroyed or otherwise reasonably disposed of", and that Oracle receive damages. Essentially, Oracle is formally seeking to stop Google's use of Java in Android, and wants compensation for that use.

The FSF has argued that if Google had used an available GPL-licensed version of Java, such as IcedTea, as part of Android, it would have avoided this litigation. This may be true; Sun (now Oracle) distributes Java under GPLv2 with a linking exception, which is what IcedTea is based off of. The GPLv2 implicit patent language, contained in sections 6 and 7 of the license, effectively gives users of Sun/Oracle's distribution of Java a royalty-free patent license that covers standard free software practices: the right to use, modify, and redistribute the software, including modified versions. With the linking exception, permissively licensed software and proprietary software that links to IcedTea could be developed without being licensed under GPLv2; thus, the app repository Google Play (formerly known as Android Market), with its proprietary apps as well as free software apps, would have still been possible.

However, this argument ignores the fact that the Android project started before Sun licensed Java under the GPL. Android, Inc. was founded in 2003 and acquired by Google in 2005; the relicensing of Java happened in November, 2006. When Android started, if a non-Sun programmer or development project wanted to make an open-source version of Java while minimizing the threat of copyright infringement, the only practical way to do this was to rely on clean room reverse engineering; this is what Google claims to have done. But clean room reverse engineering is not a helpful defense in patent litigation, which is why Google's way of implementing Java in Android - including basing Dalvik off of the Apache Harmony project, and not Sun/Oracle's GPL'd Java - exposes it to patent lawsuits from Oracle, assuming Oracle has any valid patents that read on Google's Java implementation.

So if you're Google, and you get sued by Oracle, one of the best things you can do to defend from the patent infringement claims is to get the patents reexamined and hope that they get rejected. This has been a very successful tactic; Google's request for USPTO patent reexaminations has, over time, left Oracle with only two patents left to litigate against Google. The reexamined claims in the '205 and '702 patents were rejected due to prior art, as were the reexamined claims in the '720 patent, the '447 patent, and the '476 patent. The '447 patent covered the concept of restricting access to objects based on where a specific program came from. The '720 patent claimed the novel concept of loading classes into a parent process before calling fork() so they would already be present for child processes. The '702 patent claimed the concept of coalescing duplicated objects (constants, for example) in a class file. The '476 patent is about determining access permissions depending on the calling sequence that led to a specific class method. Finally, the '205 patent claims the concept of a just-in-time compiler.

The only remaining patents are the '520 and the '104 patents.:

• The '104 patent, reissued in 2003, claims a "method and apparatus for resolving data references in generated code"; the method describes generating and interpreting executable code, and changing symbolic references in the code to numerical references when the code is interpreted. Cameron McKenzie of TheServerSide.com aptly characterized this as claiming the very basic idea that "if you rid your code of symbolic references, and replace them with direct references, things are more efficient".

• The '520 patent claims a "method and system for performing static initialization". Essentially, the virtual machine replaces a bunch of instructions initializing an array with a copy of the resulting array, speeding the initialization process.

With only these two patents left to litigate, Oracle is left hoping that it can claim a relatively low sum of damages from Google for alleged patent infringement.

What exactly has Oracle alleged in its copyright infringement claim? Oracle claimed [PDF] infringement of "(a) 37 Java API design specifications and implementations and (b) 11 Java software code files". Google's defense here looks strong, and there are indications that the court agrees. For example, a recent court order [PDF] asked Oracle to explain how Baker v. Selden applies to its copyright claims. In that case, the Supreme Court clearly established that one cannot use copyright to stop people from using the ideas contained in an expressive work; one can only use copyright to restrict use of the particular expressive work itself. Even though the same court order asked Google to address Sun's limitations on permitted uses of Apache Harmony APIs, it appears that the judge might view Baker as implying that one cannot use copyright to restrict API reimplementations in the way that Oracle is claiming in this case.

With regards to the allegedly infringing Java code files, Oracle specified [PDF] them as:

This claim is weak; although these files had previously been in Android, they are no longer part of Android, and had never been distributed as part of an Android device.

At the end of March, Google made a settlement offer that Oracle rejected. The settlement involved donating a fraction of a percentage of total Android revenues until April 2018, but only if Oracle can demonstrate that the '520 and '104 patents had been infringed. Some might interpret this settlement offer as indicating that Google feels Oracle has a decent case, but Google might simply want this litigation to not drag on any longer; litigation is expensive and time-consuming.

How should the free software and open source community react to this litigation? As the proceedings have shown, Oracle has become far less threatening than it may have appeared in the summer of 2010. Most of Oracle's patents have been rejected. As Groklaw has noted, Oracle's copyright claims on its APIs look weak, with Google's defense that the complaint refers to functional, and therefore non-copyrightable, subject matter looking strong. As well, Sun's praise of Android, doesn't really help Oracle's case. Although it is far too early to tell how the case will turn out, what ruling Judge Alsup will give, and whether or not Android will face the need to change its relationship with Java, it is clear that Oracle's case is much, much weaker than it initially seemed in the summer of 2010. It is entirely possible that Android's current implementation of Java will be in excellent legal shape following this case.

It is important to remember that this lawsuit is only one instance of several examples of legal pressure being applied against Android. Apple has launched many patent lawsuits against several Android device manufacturers, with many of them retaliating against Apple with patent lawsuits of their own. Another example is Microsoft's pressuring of Android device makers into patent licensing agreements. Last year, the non-practicing entity Lodsys sued, among others, Android app developers. So, regardless of how Oracle v. Google is resolved, Android, and free software in general, will remain under significant threat from software patents.