BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Oracle vs. Google: Judge Alsup Reveals he is a Developer as Jury Considers Patent Claims

Oracle vs. Google: Judge Alsup Reveals he is a Developer as Jury Considers Patent Claims

This item in japanese

Bookmarks

The jury in the Oracle vs. Google case is considering its verdict on the two patents. With the mixed verdict they delivered in the copyright phase, where they were unable to agree on whether Google's use of Java constituted fair use, a great deal for Oracle now hinges on the outcome of the patent phase.

The first patent (hereafter 104), was filed in 1992. 104 is essentially a method for a computer system to call upon data stored in memory using a symbolic identifier that dynamically resolves to the correct location, rather than using the specific memory location itself. 104's inventor, James Gosling, himself no great fan of Oracle, has blogged his support for Oracle in the case.

Just because Sun didn't have patent suits in our genetic code doesn't mean we didn't feel wronged. While I have differences with Oracle, in this case they are in the right. Google totally slimed Sun.

The second patent (520) provides a way of using less system resources when a program sets up a static array of values, by simulating the execution of the Java bytecode in question, resulting in less work for the virtual machine.

104 is generally considered to be the more valuable of the two. During closing remarks, Oracle's lead lawyer, Michael Jacobs, told the jury that Google's own engineers - primarily Andy McFadden - had admitted in their testimony that Android's Dalvik virtual machine gets data in a way just like Oracle's patents describe. Google lead lawyer Robert Van Nest told the jury that symbolic references were something that "Android never uses; never". 104 also describes a dynamic system, he argued, whilst dexopt, a Dalvik optimizing program, "is a static operation".

As for the 520 patent, Van Nest described it as a very small feature. The patent describes a way of initializing arrays, which Oracle says is used by the Android "dx tool". Google says what that tool does is "pattern matching", not "simulating execution", as the patent says.

Once the jury returns a verdict, assuming they do, the trial is then due to start looking at damages. Oracle is seeking $1bn (£630m) in damages for copyright infringement, though any potential settlement for the claim of patent violation is expected to be much less. Prior to the case being brought to trial, Google offered to pay $2.8m (£1.75m) in damages on the two patents, covering the period during 2011 in which they were used. Oracle puts their combined value at $4.15m, according to ITworld. For future use, Google offered to pay 0.5% of Android's revenue on one of the patents, until its expiry in December this year. Google also proposed giving Oracle 0.015% of revenues for use of the second patent which is valid until April 2018.

Both Oracle and Google have agreed to delay a decision on damages for the copyright phase until Judge Alsup has ruled on the general copyrightability of programming APIs. If Alsup finds that APIs are copyrightable, then a new jury will hear the case for monetary damages. If Alsup rules that APIs are not copyrightable, both parties have waived their right to a jury trial as far as the damages are concerned. Oracle has had the number of files included in the copyright case extended, from the single nine line rangeCheck function, to cover 8 more files which were used for testing. According to court documents

The evidence at trial showed that Google decompiled eight Java files and copied them each in their entirety. No reasonable jury could find that the copying of entire computer files was de minimis [ed: too small to be concerned with]. The trial record contains the source code for the Java code files (TX 623.2–623.8), decompiled versions of Java code files (TX 896.1–896.8), and corresponding Android code files (TX 1031–40). Professor John Mitchell testified about the decompilation process, how he determined that the eight files were decompiled and how, in a side-by-side comparison he found "that the actual code matches completely" (Tr. at 1259–1260).

In its opposition brief, Google argues that the jury may have found that Google's use of the copied files was de minimis because these copied files were only "test files" that were not shipped on Android phones. This is unpersuasive.

Nevertheless, David Boies, Oracle's attorney, has been trying to pin a great deal on the rangeCheck infringement, suggesting that copying these nine lines of code accelerated Android's time to market. Multiple sources (one, two) suggest Alsup retorted

I have done, and still do, a significant amount of programming in other languages. I’ve written blocks of code like rangeCheck a hundred times before. I could do it; you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There's no way you could say that was speeding them along to the marketplace. You're one of the best lawyers in America, how could you even make that kind of argument?

Google's motion for a mistrial on the basis that the jury was unable to agree on the fair use question, has still not been decided on, and deliberations will start after Judge Alsup has ruled on the API copyrightability issue.

No matter what happens, each side is likely to appeal.

Rate this Article

Adoption
Style

BT