Google's opening slides in the trial v. Oracle | Hacker News Reader

Google's opening slides in the trial v. Oracle

groklaw.net

125 pointsexperiment086 comments

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.

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().

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.

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.

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 name 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.

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

http://www.oracle.com/us/corporate/features/opening-slides-1...

The rangeCheck slide is somewhat cringeworthy. What are they supposed to do, not throw exceptions when it's outside the range?

It really is, does that imply that we must obscure things just to be on the safe side, even though it is the most common-sensical thing?

I thought so, too, at first, but rangeCheck is a private method. It's used in implementing a public API. Calling a non-API method "rangeCheck" and using the same variable names is clear evidence of a non-clean-room implementation, in my opinion. And in the next slide, the engineer even refers to referencing the Sun code.

It's also quite possibly from Sun's open-source code, which they surely couldn't be held liable for.

That depends entirely on the license.

Oracle's stack talks about all of the companies that DO "license java" for their HW. I assume that all of those companies are licensing the "JVM" but Google wrote their own VM instead of licensing the JVM? Which makes the contention from Oracle that the license is really for the API & the JVM and google's position is they would only need a license if they hadn't written their own VM?

I have no opinion on who's right, something better left to lawyers, I'm just trying to have a clear understanding of the positions of each of them.

I may not be correct here, but from what I can see the major point of contention is page 33 of the Oracle slides.

"When is license necessary:

1. Write applications on Java - No

2. Write classes that implement Java API - Yes

3. Download Java software components - Yes"

I think the stance from Google is that the answer to 2 is NO. And that 3 does not matter since they wrote their own Java software.

Notice how they conveniently left out Classpath and Harmony from their slides? They both violate #2 and Sun didn't care to sue them.

Deciding who to sue is up to them though, right? Just because they can doesn't mean they have to. Or does it for this to hold up?

IANAL, but I read that you have to sue to protect your property (copyright, brand name, etc). If you don't, you are waiving your rights on it, which is why Google may be using Classpath and Harmony as examples.

The requirement to defend ones IP generally only applies to trademark law, not copyrights or patents.

I don't think you're obligated to sue all infringers, and spend money chasing those those who don't harm your business and don't have the money to pay you should you win.

The graphical design in there is quite horrible. And the combo of the poor design choices and the dark style seems to scream "evil".

The file cabinet analogy is great to explain packages/namespace. Smart.

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.

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.

Not sure why you'd say that. I think Oracle's arguments are completely ridiculous. They're arguing that it's illegal to clone an API, something that has been done repeatedly by every player in the tech world imaginable over four decades now and has enriched us all. It's obscene.

That said, I think it's true that Oracle's slides have the better evidence. There are all sort of (admittedly out of context) incriminating statement from the Google people which indicate that Google really wanted a Sun license and tried really hard to get one. That certainly looks bad, but again I don't think it speaks to the underlying law.

Edit: I should point out there's a flip side here too. The fact that Sun wasn't willing to deal despite Google's attempts can be an argument that they weren't negotiating in good faith. If that was the case, then there are no damages to award. Obviously we don't have any juicy emails or quotes from discovery in Google's slides, so there's no way to know.

Ah, I'm thinking along the lines of a layman sitting in the jury box, not as a software engineer. Presentation of potentially self-incriminating emails that clearly called out the need to license Java and the desire to cleanup the 'J word' work differently on the average person, compared to arguing about how ludicrous the expectation to not clone API is in the real world. Maybe I should have used evidence instead of arguments though - thanks for that.

I think there's enough merit in both sides' arguments, at least enough to make me unsure about which way the decision will go. It's sad that lawyers/judges and non-technical folks will decide, but maybe that is the fairest way to deal with such things?

Really? Google's slides include numerous direct quotes from people at Sun and Oracle saying that everything Google did was fine and basically reiterating Google's core arguments, which seems pretty damning to Oracle's case. On the other hand, I don't see how the fact that Google would have liked a partnership with Sun but couldn't work out a deal demonstrates any wrongdoing.

Not so much wrongdoing as bad faith. If Google offered Sun a good financial deal (they might have: certainly they had a lot of cash) but Sun walked away anyway (because they wanted to preserve control of the platform, say), then that puts a pretty firm cap on the damages Oracle can be awarded. If Sun represented to Google internally that a deal was likely, and then yanked the rug out at the last minute, then that's straight up bad faith.

here's the problem:

"numerous direct quotes from people at Sun and Oracle"

are not legally binding contracts.

Well, yeah, but is that really necessary? They demonstrate intent, they support the accuracy of Google's view of the situation, and I'm pretty sure they'll make it harder for Oracle to paint Google's actions as tortious. It's similar to how you'd have a hard time suing somebody for injuring you if you admitted you jumped in front of their car to get money out of them — that's not a contract either, but it won't help your case. If even Oracle believes that what Google is doing is OK and doesn't constitute infringement, then that paints them as rent-seekers rather than an injured party.

-Google has to prove and convince the jury that they obtained a license or a legally binding agreement to use Java. So they need to present evidence that they have those. Any statement from an employee, even from the CEO, is useless if there are no legally binding contract or license.

-Oracle only has to prove and convince the jury that Google willfully and knowingly ignored required licensing agreements. So they can present emails and quotes from employees and executives and the emails alone can do a lot of damage.

> Google has to prove and convince the jury that they obtained a license or a legally binding agreement to use Java

Their contention is that they don't need one. Besides, they don't use Java- They use Dalvik and a JVM bytecode-to-Dalvik translator.

>Their contention is that they don't need one. Besides, they don't use Java- They use Dalvik and a JVM bytecode-to-Dalvik translator.

Google's lawyers are going to have a hard time convincing the jury.

Check out Oracle's slides.

http://www.oracle.com/us/corporate/features/opening-slides-1...

slide 90:

What Google Said Before Lawsuit

Jul 26, 2005: “Must take license from Sun”

Oct 11, 2005: “We’ll pay Sun for the license and the TCK” “We are making Java central to our solution”

Feb 10, 2006: “helping negotiate with my old team at Sun for a critical license”

Mar 24, 2006: “Java.lang api’s are copyrighted”

Sept 28, 2006: “Leverage Java for its existing base of developers”

Nov 6, 2007: “Is Android Java compatible?...No.”

Nov 17, 2007: “Scrub out a few more J’s”

Mar 24, 2008: “Please don’t demonstrate to any sun employees or lawyers”

Aug 5, 2009: “How aggressive do we scrub the J word?”

Aug 6, 2010: “technical alternatives…to Java for Android…suck” “we need to negotiate a license for Java under the terms we need”

Oct 13, 2011: “Android is hugely profitable”

Juries decide on facts, though, not laws. They can determine whether or not Google thought a license was required, but it's the judge (or more likely an appellate court) who will decide whether it actually was.

Well - obviously, if there was anything even close to resembling legally binding contracts, we wouldn't be having this court case.

Both sides deal only with "we were under the impression of X" and back up their claims with industry numbers and quotes.

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.

I also find it amusing that in Oracle's slides, "Java On Our Computers" is demonstrated with the Java update screen. Sigh.

> I also find it amusing that in Oracle's slides, "Java On Our Computers" is demonstrated with the Java update screen. Sigh.

Is the Java Updater even written in Java? That would be an even funnier example of "Java On Our Computers." :)

The controls in it have a strange, non-native feel, so I'd hazard that it might be.

It is however possibly the only obviously 'Java' experience that most non-techinal people have had.

If you're trying to prove to them that Java is everywhere, this is what's going to make them think "Oh yeah, it's on my computer too"

here are Oracle's slides. I hate to say, Oracle's evidence are much more convincing.

http://www.oracle.com/us/corporate/features/opening-slides-1...

...Or they would be if they hadn't used a PDF generator that managed to completely befuddle Safari. I believe this is the first time I've ever seen a PDF that Safari can't render.

Ironically, it's quite legible in Chrome.

The quotes from, uh, Larry Ellison, uh, seem to be, uh, primarily there to anger Larry Ellison.

...or to make Oracle look like a purchase and litigate company with "limited internal expertise to make smart decisions".

Not a very good strategy IMHO, but I would hazard a guess and say Google feels very comfortable about their chances.

Thank you, for uh, writing this comment. I was, uh, thinking the same thing, uh, myself and how tacky that was.

I'm sure it was intended, as perhaps a "low blow", since it's very easy to quote someone without all the damn "uh"s.

Not very classy IMO.

Let this be a reminder to be careful about what you say, professionally and personally, in email.

I love the Google email asking to "Scrub out a few more J's" and "How aggressive do we scrub the J word?" :)

On the other hand, he sort of had a point. The Dalvik Virtual Machine might be a java virtual machine, but its not the Java Virtual Machine so calling it a JVM is probably wrong.

It's not a java virtual machine; a java virtual machine executes a specific instruction set. It's a VM that runs the dalvick bytecode, and a Java source to dalvick compiler.

Scrubbing the Java name is just obeying trademark law (only Sun can allow you to use that name, and you'll have to licence the TCK and manage to pass it). I don't see what trademark law has to do with the case, except that Oracle wants to leave a certain impression of Google in the minds of the jurors.

how about slide 52.

Dick Wall: Can we demonstrate the tooling, emulator, dev environment, etc.?

Andy Rubin: Yes, one-on-one only please, where you know exactly who you are talking to. Please don’t demonstrate to any sun employees or lawyers.

yikes.

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.

Did not know that lawyers could use slides in court.

Learn something new everyday.

One of my friends makes a living creating graphical assets for court presentation: http://www.linkedin.com/pub/april-tishler/18/162/94b

http://www.capitalnovus.com/divisions/novus-trial-consulting

http://www.a2lc.com/

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. :)

Except... isn't Chrome written in C?

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?

I can certainly see how you could argue that the APIs should be covered by copyright, but I'm not sure how you could say that invoking them in your code is ok but that implementing them isn't - at least baring specific language in some contract the user signed.

I can see that argument if you consider the API design to be a significant intellectual contribution which Oracle can prove considering the popularity of Java and it's ecosystem.

I'm not sure I see what you mean there. If the API design is a significant intellectual contribution, and I'm inclined to say it is, that would be that the API is copyrighted. But that would mean that the API is copyrighted, not that its copyrighted for some purposes and not for others. Oracle seems to be saying that the API is only copyrighted for the purposes of implementing them, not invoking them, and I can't see what basis they're using to make that distinction. There may be something I'm missing, though.

I think that argues more for patentability of APIs, though.

One of Oracle's slides quotes the licence statement in the Java Specification (http://docs.oracle.com/javase/specs/jls/se7/html/jls-0-legal...). It states that you are allowed to use it for developing applications, but not for developing "non-compliant" implementations. So I guess their position is that Google's implementation is an infringing copy of part of the specification (namely the type signatures).

I could have a line in my license statement for my book that it's legal for you to buy my book, but not loan it to a friend.

That doesn't mean that any court would find fault with you, if you bought my book and then loaned it to a friend. That's totally fair use.

Just an analogy to show that just because a company tries to make you believe they have the right to limit what you can legally do, doesn't mean you are legally limited.

As long as the book in question isn't an ebook, sadly. In that case, the book is licensed, not sold, and the license agreement has teeth.

...so I loan you my whole Kindle. :)

Finally got around to reading the slides from both sides... wow Google slides are so weak. Their four points:

- Sun gave Java language to the public

They basically just say APIs and programming languages are the same thing, and Ellison said the programming language is free for everybody, therefore the APIs are too. Their quoting an expert saying that an API is like a technical paper is bizarre, since technical papers are clearly copyrightable... Google basically agreed (slide 12) that an API is copyrightable.

- Google built Android using free and open technologies

Basically saying other people did it and Sun didn't sue, so it's ok for us to do it. Also another defense that, ok maybe they did what Oracle claims, but even so it's no big deal. The 'me too' and 'meh' defenses.

- Sun publicly approved Android's use of Java

The defense is that Sun approved the announcement of Android as a Java-based platform, which Google says it isn't. So Sun didn't approve of Android.

- Google made fair use of the Java language APIs in Android

The defense is that Sun was incompetent so Google had the right to go it alone without Sun's approval or license. Seriously?! Their quote to support this from Ellison even talks about licensing Java to phone carriers -- why would they do this if Java was free? Their own evidence presented undermines their argument.

Meanwhile the Oracle presentation is chock full of damning quotes and evidence from Google's own people. Google better have some serious kung-fu in the trial part, because the opening statements are a disaster for them.

Alright; you're now allowed to read and write English, but you can't use any of the words in the Oxford English Dictionary, as they are a copyrighted API.

I know that you can't copy the OED as a whole, or in significant parts. You have to purchase it. Similarly, you could copy and use parts of the Java API in your programs but not the whole API.

I'm not a lawyer so I don't know if Google's case is solid legally, but putting myself as a juror the Oracle opening statement I think would be very convincing compared to Google's.

But my reading of the slides is probably colored though by my personal opinion that the Java API should be copyrightable. It's a substantial creative work and no two people would create the same APIs even containing the same ideas and concepts (.NET for example).

APIs should be copyrightable? So..

- Microsoft should be able to shut-down clean-room re-implementations of Windows? Like WINE and Sun's Wabi?

- IBM should have been able to crush Compaq over their reverse-engineered BIOS?

- Digital Research should have been able to crush Microsoft for including system calls that enabled CP/M compatibility for some programs in DOS?

- ...

APIs such as Java's are original, creative works of authorship that no two people would create the same way. But they shouldn't be copyrightable because 'history would be different'... great argument there, genius.

Your description of "the law as it is", would be surprising to Microsoft (CP/M), Compaq (BIOS), Oracle (SQL), Sun (Windows (via Wabi)) and those are just some of the more prominent/embarrassing (for Oracle) examples I can think of.

Is the media image on 34 from android or ios? I only ask because it looks like quicktime.

This is interesting (funny). I guess learning powerpoint in school is useful if you're entering law.

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,

both sides agree on: - you cannot copyright language - you can copyright implementation.

so all comes down to: - can you copyright APIs ?

Standard APIs that are shipped with the programming language, are part of the language ... just like English words are part of English, the language.

Oracle tries to draw a boundary between the language and the APIs, but there is no boundary to be drawn.

Google's slide said that the API is just using nouns and verbs. I think this is not a good defense, the book I wrote is just nouns and verbs, and we know you can't copy it.

but Google can write a different book with using the same nouns and verbs, which they did

Oracle will say it's the same book, there are always grey areas. You can't copyright a love story between a boy and a girl, but you can copyright a particular book on it. So if the API is copyrightable, then even though it was implemented differently, isn't it using their property?

No, Microsoft wrote a 'different book' -- .NET

What Google did was remove a chapter here and there and add a couple of their own chapters -- in this book analogy, clearly copyright infringement.

The actual quotes used in the slides is "you form an API using those parts of speech in the same way I'd write a technical paper using, you know, nouns, verbs, objects, so on." In other words, you couldn't copyright java.lang package name itself (an adjective say) but you could copyright the collection of everything in it (as like technical paper).

I'm astounded that this is in Google's slides. Slide 12 basically says the Java API, taken as a whole, is copyrightable.

The analogy is better if you use dictionary.

The language must have words with meaning (API specification).

A dictionary is a book of words and their definition (API implementation). You can have two different dictionaries from the same language. They both have their copyrights, and they don't infringe each other copyrights.

Harmony's Java API implementation (used in Android) and JDK's Java API implementation are just two different dictionaries for the same language (Java API specification).

You will use a dictionary (API implementation) of a language - its symbols and words and the rules between them - (programming Language and API specification) to write a book (programs).

Both dictionary and book are subject to copyright. The language is not.

if a software engineer ended up on the jury of this trial would they be percluded from ever working for google or oracle?

No way any engineer would end up on the jury. Voir dire would clear out anyone tech savvy.

Quite a few people who were familiar with software (one works at HP, one at Cisco) were excused from the jury, because they would already have her own interpretation of the law — opinions you cannot set aside, as the judge put it.

Here's a lot more detail about the jury selection; five people were excused by the judge, then three more by each party: http://www.groklaw.net/article.php?story=20120416085550303

I was rather surprised by the demographics, there were a lot of engineers and lawyers, and for some reason I though jury duty was a statistically unbiased sample of major citizens. I guess I should be glad the trial takes place in San Francisco rather than East Texas: http://www.thejuryexpert.com/2010/03/east-texas-jurors-and-p...

I find it odd that Google would use Angry Birds to describe High Performance Graphics. lol.

Jurors. All about the jurors. Average, non-fuckin-HN-reader jurors, and they know what Angry Birds is. If they had used something more representative like SHADOWGUN, no one would know what they were talking about.

ORACLE WILL WIN - Software Engineer at Oracle Corp

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.

I loved the "FAILED" stamps on Oracle's mobile phone docs.

fU, I work at Oracle!

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

I thought part of the fallout of the ancient AT&T vs BSD case was that APIs are not copyrightable.

Additionally, GNU Classpath seems to have always been considered A-OK by Sun and Oracle, and they have no license.

You'd need a license to use Sun/Oracle source code. You'd need a different license to get the compatibility test kit so you could call your stuff Java(TM). If you thought there was patent liability, you ought to license that.

AT&T vs. Berkeley never went to court, it was dropped once Solaris/SysV took off and it was clear BSD wasn't a threat to commercial Unix anymore.

Jurors are going to see a list of companies that license java, almost every name out there. And then Google emails and communications how they need a license, can't do without Java, maybe shouldn't get it now, or whatever. Either way it was a boneheaded move to invest billions (?) on Android without a relatively cheap Java license.

Maybe it was a boneheaded move to use Java, the programming language, in the first place.

If they used C/C++ they wouldn't have had any problems and considering how awesome Qt is, you can clearly make the development experience enjoyable. Then they could have introduced Google Go in the mix and/or Javascript, to appeal to the younger generation.

Ironically, they could have used the ECMA parts of .NET and get away with it.

Why didn't they? They could have avoided being sued, this again goes to Oracle favor for this lawsuit, they wanted Java's advantages as a virtual machine implementation and not bare metal programming like C/C++.

Of course, they wrote their own virtual machine, that is totally different from the JVM, so it's unclear to me that they got any advantage from Java's VM implementation.

What they really got for free was much of the Java tooling and ecosystem. Which isn't nothing.

What advantages does Java on Android have compared to Objective-C on iOS?

Reply on news.ycombinator.com