Ok a couple of disclaimers first, one I was one of the original Java folks and two, I've done expert witness work but not in this case.<p>When Java was still 'Oak' there was an interesting, on-going, low level debate about where the 'language' stopped and the 'system' started. There is a very common analogy in C where C pretty much assumes that there is a 'libc' and in libc are functions for doing things like printf().<p>So it was with Java, with the wart/exception that there was no 'main' as Java was designed to be the entire environment, not something you wrote in and then passed a binary to a different environment. Sort of like Python in interactive mode all the time. And that lead to the question of "what can a programmer assume is true about the environment?" and the answer was eventually some packages were 'core' and had to be present and some where 'optional' and might not me. Frank Yellin and James Gosling's book on the topic was the definitive reference of what was core and what wasn't.<p>When I was at NetApp (which also used Java (licensed) in their filers) there was an interesting debate with Sun about whether or not one had to pass the compatibility suite to be compliant with the license. Since it wasn't an exported language (customers couldn't write Java code to run on the filer) NetApp argued that insuring it could run NetBeans compatibly was unnecessary. Worse (for NetApp) was that they had their own OS and so the port had taken a while and the newer JDK had a lot of changes (none of which were needed) and it became clear the Sun was just operating on a script. Eventually it escalated up to Scott McNealy who quite reasonably understood that if they insisted on that much effort, NetApp would just move to Python or something like it (equivalent internal effort to porting the newest JDK) and voted for 'money' rather than 'no money'. That the question even came up though really brought home how far Java had moved from its roots of the team arguing to release source, to 'the most profitable on a per-unit basis' that Sun was selling in the end times.<p>Looking at the approaches, I think Oracle is going to lose. And I think they are going to lose for the same reason the font guys lost. My fuzzy memory has it as a Letraset vs Apple suit but it may have been Xerox (sad how stuff from 30 yrs ago is so hard to find) which basically concluded you could copyright the <i>name</i> of a font but you could not copyright how it looked. Hence font names like "Chicago" which look like other more well known fonts. And it is also why you get 250 'free' fonts where the 'i' character has the dot hinted slightly higher but is otherwise identical to some Bitstream font. Historically copyright has been offered on the 'end' product, not on the 'intermediate' product. So you can copyright a game that is written in language X, but not language X. For the language you can only copyright the name, and the implementation. If the new implementation is different (or derived cleanly) you don't have an recourse.<p>This defense of a 'clean' implementation of a specification severing rights to the original has been litigated extensively in the 80's BIOS wars where IBM published the source code to its BIOS in their technical manuals and then started trying to sue clone makers who re-used the source. Once the BIOS was implemented in a 'clean room' where team A (who had the BIOS code) provided specifications to team B who didn't, then you could completely sever the rights to the code from IBM.
And for those interested, here are Oracle's slides<p><a href="http://www.oracle.com/us/corporate/features/opening-slides-1592541.pdf" rel="nofollow">http://www.oracle.com/us/corporate/features/opening-slides-1...</a>
The file cabinet analogy is great to explain packages/namespace. Smart.<p>After looking through both opening slides, I have to say Oracle's seemed to make better/stronger arguments. This case is fascinating, I'm glad that resources are being made available.<p>Also, gotta love "Very limited internal expertise to make smart decisions" on slide 69. I wonder if the slide number being that was just coincidence.
On slide 52, which is supposed to demonstrate that the Android and Java source code implementations differ, it's clear that the Android definition did not come from Android: The anotherString parameter is not referenced, and there are no offsets as parameters.<p>I also find it amusing that in Oracle's slides, "Java On Our Computers" is demonstrated with the Java update screen. Sigh.
The quotes from, uh, Larry Ellison, uh, seem to be, uh, primarily there to anger Larry Ellison.<p>...or to make Oracle look like a purchase and litigate company with "limited internal expertise to make smart decisions".<p>Not a very good strategy IMHO, but I would hazard a guess and say Google feels very comfortable about their chances.
Let this be a reminder to be careful about what you say, professionally and personally, in email.<p>I love the Google email asking to "Scrub out a few more J's" and "How aggressive do we scrub the J word?" :)
I thought it was confusing and possibly disingenuous that Oracle isn't contesting that Google stole their JVM, but most of the "smoking gun" quotes they have from Google's leadership are about the need for the Java JVM, or about going ahead anyways without getting Sun's permission to use the JVM.
I find it cute that Google used a screenshot of an early version of our Opera Mini browser rather than one of their own to illustrate Android-based web browsing in slide 29. :)
If we take the law as it is, i think Oracle should win. This is very interesting because it covers the copyright on the API and not software patents. I think this is a legitimate and winning case for Oracle. What were Sun/Oracle's conditions that Google could not do for licensing?
Is the media image on 34 from android or ios? I only ask because it looks like quicktime.<p>This is interesting (funny). I guess learning powerpoint in school is useful if you're entering law.<p>Edit: I love the file cabinet visual analogy they're using. I would assume that it helps non-technical people understand the idea of packages/namepsaces. Those images should be default when teaching those ideas
as far as i understand,<p>both sides agree on:
- you cannot copyright language
- you can copyright implementation.<p>so all comes down to:
- can you copyright APIs ?
did you see they mentioned sun and oracle had tried to build smartphone platform on Java and failed, this can backfire for argument sake as it kind of justifies google did a favor by making android a success.
is the entire Oracle argument, so far, that you can use Java, but can't cut and paste the APIs done by Oracle /Sun engineers? With what I've read, Google sure thought they needed a licensing agreement