Oracle/Google ‘Java’ patents lawsuit
At the technical level the Oracle ‘Java’ lawsuit against Google is not really about Java at all. The patents cited in the lawsuit (5,966,702, 6,061,520, 6,125,447, 6,192,476, RE38,104, 6,910,205 and 7,426,720) involve a variety of techniques that might be used in the implementation of a virtual machine supporting JIT compilation for software written in any language; Oracle does not get into the specifics of which parts of Android make use of these patented techniques (Google has not released the Dalvik source code). With regard to the claimed copyright infringement, I have no idea what Oracle claim has been copied; as I understand it Android uses Apache’s Harmony code for its Dalvik VM runtime library, but there is a possibility that it might have used some of Oracle’s gpl’ed code.
No doubt Google’s lawyers will be asking for specific details and once these are provided they have three options: 1) find prior art that invalidates the patent, 2) recode the implementation so it does not infringe the patent or 3) negotiate a license with Oracle.
My only experience in searching for prior art was as an adviser to the Monitoring Trustee appointed by the European Commission in the EU/Microsoft competition court case; Microsoft’s existing patents were handled by a patent lawyer and I looked at some of the non-patented innovations being claimed by Microsoft.
The obvious tool to use in a search for prior art is Google and this worked well for me provided the information was created after the mid to late 1990s. The cut-off date for historical searches seemed to be around 1993 (this all happened before Google Books was released). Other sources of information included old books (I had not moved in 15 years and my book collection had not been culled), computer manuals and one advisor found what he was looking for in some old computer magazines bought on e-bay.
Some claimed innovations appeared so blindingly obvious that it was difficult to believe that anybody would bother mentioning it in a print. Oracle’s patent 6,910,205
“Interpreting functions utilizing a hybrid of virtual and native machine instructions” (actually a continuation of 6,513,156, filed five years earlier in 1997) describes an obvious method of handling the interface between interpreted and JIT compiled code.
My only implementation experience in this area does predate the Oracle patent (I wrote a native code generator for the UCSD Pascal p-code machine in the mid-80s) but the translation occurred before program execution and so is not appropriate prior art. Virtual machines fell out of favor in the late 80s and when they were revived by Java 10 years later I was no longer working on compilers
Fans of Lisp are always claiming that everything was first done by the Lisp community and there were certainly Lisp compilers around in the 1980s, but I’m not sure if any of them worked during program execution.
Of course Groklaw have started following this case. Kodak has shown that it is possible to win in court over Java related patents. The SunOracle/Microsoft Java lawsuit in the late 1990s was a contract dispute and not about patents/copyright, but still about money/control.
I’m not aware of any previous language implementation patent lawsuits that have gone to court. It will be interesting to see how much success Google have in finding prior art and whether it is possible to implement a JVM that does not make use of any of the techniques specified in the Oracle patents (I suspect that they have a few more that they have not yet cited).
Lisp compilers have been in use since the early 1960s.
Many Lisp compilers also can and could work during program execution. But all I have seen was that these compilers were invoked from the program code. Imagine a computer algebra program that simplifies a mathematical expression and the compiles the result to machine code. That’s common. VMs also were widely in use. For example InterLisp had something like a VM. I have not seen compiling VM instructions transparently into machine code at runtime. In the Lisp world there were two main approaches to speed: a) compile directly to machine code and make the compiler available to the user and his/her programs b) build the VM in hardware.
What I can imagine that there were Lisp interpreters that do some kind of compilation at runtime, but I could not point at one and I would not think that this is JIT.
This article by Andrew Tridgell does a great job of explaining what needs to be done. Prior art is not the best solution, by far. There are other things that Google can do that are far more effective and easier to prove.
http://news.swpat.org/2010/03/transcript-tridgell-patents/
TemporalBeing, thanks for the link to such an interesting talk.
I primarily talked about prior art because this is the only professional experience I have had with patents and I highlighted one patent because working around it could have such a large runtime penalty that JIT compilation would not be worthwhile on Dalvik.
Overwriting the byte code corresponding to the start of machine code execution means there is no execution overhead on other instructions. One workaround to this patent would be to have a table of byte code instructions that had been compiled to machine code; this table being checked prior to interpreting every instruction, an overhead on every instruction that could add up to an unacceptable total overhead.
There might be other workarounds that were minor, but significant enough, variations on the patented techniques. I will let Google scratch their heads over this.
Instead of being a patent troll, Oracle should try to improve its horrible database product. I estimate that working with Oracle inflicts a 25% toll on my productivity, compared to SQL-Server.