decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
Oracle v. Google - Oracle's MSJ Opposition on Copyright - Some Interesting Nuggets
Thursday, September 15 2011 @ 08:00 AM EDT

When we did our earlier article on Oracle's opposition to Google's motion for summary judgment on the copyright issue, we didn't provide the Roman Swopes declaration [343, PDF] in text or its associated exhibits because most of those exhibits had been heavily redacted. Now the exhibits have been made available unredacted, and they contain some very interesting nuggets of information taken from the depositions and documents of various individuals at Google.

What is interesting about these nuggets is that they actually support Google's theory and evidence the continuing lack of understanding of the relationship of copyright to software on the part of Oracle (or at least on the part of legal counsel representing Oracle) and the continued distortion of actions by Google.

For example, there is the whole issue (raised in part by the later Lindholm emails) about Google's decision to develop Dalvik as opposed to using JAVA. As Andy Rubin makes clear in both his deposition testimony (Exhibit 5, page 3 [PDF]) and an email to Sergey Brin (Exhibit 13), Rubin clearly believed Google was getting close to a strategic partnership between Google and Sun with respect to an open source version of JAVA. The terms of that proposed deal can be found in Exhibit 12 [PDF]. Of course, that didn't work out, but this gives some insight into what Google was thinking at the time. And, of course, it was later that year (2006) that Sun made its historic announcement about making Java open source under the GPL.

And that JAVA documentation to which Google referred when building their API's, didn't they have to license it? Well, no, it was available for free to view on the web. (See, Bob Lee deposition transcript, Exhibit 3 [PDF], page 10).

This goes back to the whole issue of how far the copyright on a software specification extends. I would argue it protects the actual specification document from being copied. Oracle wants to argue that the copyright extends to what you learn from that specification, including building an implementation from that specification. This belief is also manifested in the questions put to Daniel Bornstein (Exhibit 2 [PDF]) As I have mentioned before, this was part of the underlying IP protection structure that Sun used, and I have never been clear on what, if any, legal underpinnings it has. This could be an interesting test case.

None of these nuggets is going to decide this case, but they do give us a little better understanding of Google's motivations and positions, and seeming distortions of the same by Oracle's legal counsel.



Exhibit 1

Exhibit 1

Highly Confidential - Attorneys' Eyes Only













Videotaped Deposition of JOSHUA BLOCH, at 333 Twin Dolphin Drive, Suite 400, Redwood Shores, California, commencing at 9:34 a.m., Friday, July 8, 2011, before Leslie Rockwood, RPR, CSR No. 3462.

PAGES 1 - 246


were big programs written in Java. Java was one of the three main languages we used.

Q. And when you say three main languages were used, again, you're referring to use as a development language for Google's services?

A. Precisely.

Q. Now, when you started at Google, what was your title?

A. There are many different kinds of titles at Google.

Q. What was on your business card?

A. Software engineer.

Q. And then did you get an additional business card titles or different business card titles as time went on?

A. Yes.

Q. What was that progression?

A. I had one other title on a business card, and that was chief Java architect.

Q. And you used the past tense for that. Is that still true?

A. I'm out of business cards.

Q. I'm sorry?

A. I'm out of business cards. Q. Did you -- did that title change?

Page 38


A. We'll know when I order my next set of business cards. It's pretty much up to me.

Q. And so what is your -- you are still employed by Google as of today?

A. I am.

Q. And what titles do you have at Google?

A. I am a -- I believe they call it senior staff engineer. I don't -- I don't -- or senior staff software engineer, and I use the courtesy title of chief Java architect occasionally.

Q. Then you continue to serve as Google's representative at the JCP; correct?

A. Yes.

Q. And then -- and you have a role at the Open Source Programs Office up through today; is that correct?

A. Yes.

Q. And at some point you were a quote, member, unquote of the Android team?

A. That is correct.

Q. And so from 2008 to the present, have you had any other roles of that level of definition?

MR. PURCELL: Object to the form.

MS. MC GLONE: Object to the form.

THE WITNESS: Object. I can't object.

What do you mean by "that level of

Page 39


definition"? The point is that serving on the JCP EC is not the same thing as, you know -- in one case you're talking about the manager to whom I report; right? So I -- tell me what question you actually want me to answer.

Q. BY MR. JACOBS: Fair enough.

From 2008 to the present, what role at Google has taken the majority of your time?

A. From the beginning of 2008 to the present? I -- I do not know. That's a very hard question to. Answer without an accounting for all my hours, I simply can't answer that question.


THE WITNESS: Sorry about that. Did you lose a cable you need?


THE WITNESS: All right.

Q. BY MR. JACOBS: When you joined the Android team, did you give up some duties?

A. Yes.

Q. What did you give up?

A. Well, I was no longer working on the team that had been decommissioned, for lack of a better word. That is the Java infrastructure team. So I needed to find a new place to work, and that was what I found.

Page 40


develop will be happier, they'll be more productive, and the API you know, good APls are good for the companies that wrote the APIs, they're good for the companies that use the APIs; correspondingly, bad ones are bad for you.

And this talk told you a bunch of what it takes to write good APIs. But it is a craft. It's not a science. And so I kind of tell people go forth and practice the craft proudly. Oh, and "don't expect to achieve perfection because it's pretty much impossible, you know, by its nature. You don't find out until years later if you did it right.

Q. As you reviewed the presentation today, did anything in it that you would change if you were this presentation now?

MS. MC GLONE: Object to the form of the question.


THE WITNESS: That said, yes, because I've given it many times since 2005 and I have changed things. You know, I've come up with better examples for some of the points. I've removed slides that I felt didn't necessarily pay for themselves. And, you know, so there are certainly small changes that I would make. But generally speaking, the talk -- not generally speaking. The talk has received very favorable reviews every time

Page 91


I've given it, you know, even in its earliest form.

Q. BY MR. JACOBS: All right. Perhaps I should have asked a slightly more precise question. Is there anything in the slides that we've discussed that you regard now as inaccurate?

A. My gosh.

Q. The ones we've discussed.

A. Almost certainly, but nothing that comes to mind immediately. I could look at all of them and read all the bullets and, you know, see. If there's any particular that you wonder whether I find inaccurate, feel free to can ask me.

Q. All right. I'm going to ask you about the conclusion slide.

A. Ah, all right. That's right where we were. Well, I still feel that it's noble and rewarding. When I say rewarding, you know, I'm not talking about remunerative. I'm saying in a deeper, philosophical sense, I find it very rewarding to design great APIs and have people come to me years later and say, wow, you know, the collections framework changed my life. Basically there's no higher compliment that you can pay to an API designer.

I do believe that well-designed APIs improve the lot of programmers, end-users, and companies -- you

Page 92


know, I don't know why I picked on companies. I think it would be better to say organizations. One of the things that happened sort of between then and now is that non-company organizations have become more important in software due to the Open Source movement. So that's not something wrong, but it's an omission.

Certainly this talk did cover some of the heuristics of the craft. Certainly I don't want you have to adhere to them slavishly, but I do want you to think about it each time you violate one. I still believe that API design is tough. I still believe that it's not a solitary activity. You have to bounce your APIs off of other people to find out if they really will achieve what you want them to achieve, and I certainly believe that accepting trivial case perfection is unachievable. So no, I still believe these conclusions.

Q. Now, you refer to the feedback you've gotten on the talk.

A. Uh-huh.

Q. Favorable feedback.

A. Uh-huh.

Q. Any critical feedback?

A. You can't please all the people all the time, but I can't actually remember any critical feedback. If you want to see what kind of feedback the talk got, I

Page 93


Q. And then you go down to number 5, mobile. Do you see there are 40 developers in mobile in that entry?

A. I see the number 40, but it's unclear to me that it refers to -- oh, yes, it says with associated number of developers. Yes.

Q. And what was your understanding of what mobile was referring to?

MS. MC GLONE: Object to the form of the question.


THE WITNESS: I had no understanding. Don't even know if I read that line.

Q. BY MR. JACOBS: Who was Pablo Bellver in relation to you?

A. Pablo Bellver was a member of my team. He wrote various pieces of the Java infrastructure.

Q. So he was part of the Java engineering infrastructure group?

A. Java infrastructure group, yes.

Q. Sorry. Pablo Bellver was part of the Java infrastructure engineering group?

A. Did we have an engineering in our title? I don't think we did. I think we were just the Java infrastructure group.

Q. He was part of that group?

Page 118


A. He was.

MR. JACOBS: Would you like to break for lunch?


MS. MC GLONE: Sounds good.

THE VIDEOGRAPHER: The time is now 12:41 p.m., and we're going off the record. (Lunch recess.)

THE VIDEOGRAPHER: The time is now 1:38 p.m. We are back on the record.

MR. JACOBS: Next. (Exhibit 200 was marked for identification.)

Q. BY MR. JACOBS: Exhibit 200 is an email string which ends with an email from Ed Cobb dated August 14th, 2007.

Do you see that?

A. I do.

Q. Take a minute to read this email string regarding Sun OpenJDK derivative TCK license conference call update re discussions with Sun on Apache Sun dispute.


A. Pretty much.

One thing that's missing from here is Ed Cobb's email address. Could you provide that, or his

Page 119


affiliation at least?

Q. I'll try and do that. That was actually my first question to you is: Who is Ed Cobb?

A. Well, some guy who was on the JCP at the time, but I forget who he represented.

Q. So this email string, Sun OpenJDK derivative TCK license, went to Ed Cobb's email dated August 14th, 2007. That was sent to you because you were on the JCP; is that correct?

A. Yes. In fact, it was sent to probably -- that is an interesting question, actually. I cannot say with certainty, and the more I look at it, the more I think that is not why it was sent to me.

Q. Why do you think it was sent to you?

MS. MC GLONE: Object to the form of the question.

THE WITNESS: I believe it was sent to me in connection with -- let me look at the date before I answer this. I cannot say with certainty, but I could speculate.

Q. BY MR. JACOBS: Do you see that it starts with an email from your collaborator, Doug Lea, at the bottom?

A. Uh-huh. Q. And he reports on the news that has -- that

Page 120


then prompts this email string. Do you see that?


Q. And then there is an exchange among the the participants on this email address list about the Sun announcement.

You saw that?

A. Uh-huh.

Q. You saw that exchange. "Yes"?

A. Yes.

Q. So what was your understanding in August of the dispute that is the subject of this email string?

MS. Me GLONE: Object to the form of the question.

MR. PURCELL: I'll join.

THE WITNESS: There was a longstanding dispute between Apache and Sun concerning Sun's promise to grant Apache a license to implement Java SE as consistent with the JSPA.

Q. BY MR. JACOBS: Let's break that down. Who is Apache?

A. Apache is the Apache Software Foundation, and they were involved in producing, and in fact, I think still are, involved in producing an Open Source

Page 121


implementation of Java SE and were promised that they would get a TCK license from Sun to do this. But Sun had not made good on that promise at the time this letter was written, and that was the nature of the dispute.

Q. When you say they had not made good on the promise, what do you mean?

A. I mean that no license was forthcoming. No license had been granted.

Q. And the -- there's a reference in this email string to a field-of-use issue. Do you recall what the field-of-use issue was?

A. Yes. Field of use is a license that restricts the field of use in which a work may be used, basically grants the license only so long as the work is not used in some particular area. And this was not acceptable to Apache, and according to substantially every member of the JCP, notably including Oracle and Google, not consistent with the JSPA.

Q. And the JSPA, what is that?

A. The JSPA is the set of agreements that constitute the JCP. JCP isn't really an organization per se, but was an agreement called the JSPA that its members signed.

Q. And so the nature of the dispute that's described in this email string from August 14th, 2007 is

Page 122


that Sun's TCK offer to Apache has this field-of-use limitation in it; correct?

A. Near as I can tell, that may be an oversimplification. According to Doug, an OpenJDK TCK license was made available, but that license, since it says OpenJDK, presumably has nothing to do with Apache. So there's not enough context for me to figure it all out from this email.

Q. So OpenJDK, in the last email, "Wayne, as I'm sure you know, the JSPA has no standing when it comes to OpenJDK, which is Sun's own OSS" -- Open Source software; right?

A. (Witness nods head.)

Q. "Which is Sun's own OSS playground. IMO, " that's "in my opinion"; right?

A. Yes.

Q. "The whole reason for the GPL is to protect Sun's licensing business." Now, you understood that what was being referred to was the application of the GPL to OpenJDK; correct?

A. Probably not. I don't even know if I even read this paragraph.

Q. Probably not, you didn't understand it at the time or you don't understand it?

Page 123


MS. MC GLONE: Object to the form of the question.


THE WITNESS: I can't read their mind, but there appears to be something there.

Q. BY MR. JACOBS: Well, somebody wrote this paragraph. You can't be sure whether it was you or Bob; right?

A. Uh-huh.

Q. When you saw it in this email exchange, did you go to yourself, no, no, no, that's not what Sun is thinking at all?

MS. MCGLONE: Object to the form of the question.

THE WITNESS: No, I did not do that.

Q. BY MR. JACOBS: And the -- again, the Pablo whose writing back to you is?

A. Bellver.

(Exhibit 207 was marked for identification.)

Q. BY MR. JACOBS: 207 is an email string ending with an email from you dated December 16, 2008, to Andrew Rubin re meeting. Do you see that?

A. Y es.

Q. I want to ask you a couple of questions about

Page 161


this email string between you and others under the re line meeting. Steve Horowitz, was Steve on the Android team?

A. Presumably so. I don't remember him.

Q. And of course, Andy Rubin was leading the Android team; correct?

A. Yes.

Q. And you write to Steve: "PS, I am currently working on a drop-in replacement for Harmony's sort function, which has demonstrated a huge up to 20X performance improvements on G1 hardware. This will be my first contribution to Android."

Do you see that?

A.I do.

Q. What is the -- what's the name of that drop-in replacement?

A. TimSort.

Q. And what was the project that you were doing that led to your developing this TimSort drop-in replacement?

A. I undertook it personally a couple years earlier after a conversation with Guido van Rossum. TimSort is Python's system sort. He told me about it. He said it's really fast. I said, oh, wow, I wonder if we can make it work in the Java programming language and

Page 162


contribute it to all the platforms.

Q. And so when you say you undertook it personally, in what way did it fit into your job duties?

A. My job duties are moderately flexible, and if I see something that, you know, I think could be beneficial to Google and to the broader Java ecosystem, and my manager doesn't object, I do it.

Q. What was G1 hardware?

A. That was the earliest Android hardware. I had tried it out at about that time. That is towards the end of 2008 on Android hardware and found that it provided a good speed boost.

Q. And when you said a 20X performance improvement, how were you measuring that performance improvement?

A. Probably using a small micro-benchmarking framework that I wrote for myself many years ago, and I tend to use for micro-benchmarks.

Q. When you say "micro-benchmark," what do you mean?

A. I mean a small benchmark of an individual functional library as opposed to a benchmark of an entire system.

Q. So when you were referring to 20X performance improvement, you were referring to 20X performance of the

Page 163


particular functionality you were working on?

A. Yeah, sorting an array of a certain size. You know, I don't know whether it was a -- probably was not a -- sorry. Just sorting an array of elements. That's good enough.

Q. What -- and did you have in your mind what implication that would have for ultimate performance improvement in an end-user context?


Q. Would it be trivial?

A. It depends on the application.

Q. What kind of application would matter?

A. You know, if there were an application that sorted a lot of data, it could make it significantly faster.

Q. And by "significantly faster," you mean something that would bear on the -- that would bear on the user experience in running that application?

A. It's not beyond the realm of reason.

Q. That sounds very cautious, not beyond --

A. You have to be very cautious when you're about talking about micro-benchmarking. You're testing one small function, and it is often the case that you make one small function way faster, and then you try it in the context of a larger application, but it turns out it was

Page 164


function and you invoke it at the beginning of every other function. So any function that takes an array and a start position and an end position, you know, you want to check that the start and end are in balance. So you'll do that by calling a function, a method to validate the arguments, and that would appear to be the purpose of this RangeCheck function.

Q. The RangeCheck function that we're looking at on page Google 551599 did not come from Tim Peters' list sort for Python; correct?

A. C does not have exceptions. So it most certainly did not.

Q. And the RangeCheck at 551599 in TimSort is the same code as the RangeCheck for comparable TimSort at 551226; correct?

A. Probably so because the two files are copies of one another, and it's a judgment call under those circumstances whether you want to copy this identical code. Assume -- yeah, it's identical. So, you know, your choices are to either copy the code or to make the function package private instead of private and call it from one file to the other. Lesser of two evils. And in this case, given that one file is a copy of the other, copy the whole thing.

(Exhibit 210 was marked for identification.)

Page 173


Q. BY MR. JACOBS: Exhibit 210 is a printout of, copyright 2004, Sun Microsystems. Do you see that?

A. I do.

Q. And you are listed there as an author along with Neal Gafter. Do you see that?

A. I do.

Q. And so you had worked actually with Neal at Sun and then later together at Google; correct?

A. Correct. And for the record, Neal did not write this file. He generified it. I wrote it.

Q. And by "generified," what do you mean?

A. When generics were added to the platform, he added the generic typed parameters to the method declarations that allow this to be used with the type safety of generics.

Q. Did you write it around 2004?

A. No.

Q. So you see it says there's a version 1.59 around 2004. What's the version history of your work?

A. This was part of the original collections framework, and the bulk of it was written in 1997.

Q. And does it have a -- it does not have TimSort?

Page 174


A. Now it does. Well, it -- it -- yeah, as of today or yesterday, Oracle did a release candidate for 1.7, and that caused TimSort.

Q. What do you mean "a release candidate"?

A. Release candidate is beyond a beta release. It is what will become the release if no more bugs are discovered in it.

Q. And by 1.7 you mean Java SE?

A. Seven.

Q. So if you turn to the 24th page of this document to --

A. Is this document page numbered?

Q. It is not. And you look at -- and look for RangeCheck.

A. I'm not finding it.

Q. It is --

A. Can you tell me something else on the same page?

Q. Yes. Searching.

A. Oh, you've got it? Excellent.

Q. So in this Sun code,, you wrote the RangeCheck function; correct?

A. Yes.

Q. And you wrote it while you were employed by Sun?

15 : 3 7 : 1 7
Page 175


did the integration to simply be able to drop the TimSort function in and have the calls to RangeCheck simply match up.

So I may have copied that signature basically as a favor to the people who were integrating it into OpenJDK and then rewritten the comment and the body. I don't know. I'm speculating.

Q. BY MR. JACOBS: So that's actually what I'm asking you. What is -- you are sitting here and inferring from the similarity of the two that that may have happened?

A. Yes. Q. My question to you is: What happened? What did you do? And if the answer is you have no recollection, then that's the best testimony that that would be the answer to that question.

A. Y es.

MR. PURCELL: Object to the form.

You can answer.

THE WITNESS: Excuse me?

MR. PURCELL: You can answer.

THE WITNESS: All right. So, you know, I do not recall precisely what I did, but just knowing my habits as a software engineer, I do believe that I would have gone and looked at the

Page 180


signature of this function.

Q. BY MR. JACOBS: Why this -- well, but as you sit here today, you do not have a recollection of doing so, is that correct?

MR. PURCELL: Object to the form.

THE WITNESS: I do not.

Q. BY MR. JACOBS: Do you have a recollection of accessing Sun code while you were working on TimSort?

A. I don't have a recollection, but I'm perfectly willing to believe that I did. You know, I think the similarity of the signature, the fact that, you know, the three arguments are in the same order and have the same name, you know, is a strong indication that it is likely that I did.

Q. And were there other cases in which you were working on signature similarity where the similarity of the signature was important as -- in your work on TimSort?

A. None that I'm aware of, and it seems unlikely that there are any.

Q. So why would RangeCheck be the one that requires the signature to be similar?

A. Because it is the only piece of functionality that TimSort shares with the remainder of arrays, java.util.arrays. TimSort is a 700 and -- you know, it's

Page 181


a big long file, and the only functionality that it shares is this little function here, and it is very much in the interest of the users of the new sort that it behave exactly like the old sort. You want it to throw exactly the same exception. You want it to actually emit the same prose. You want that text to be the same. So, you know, it's the one where it makes sense to do it. Everything else derives from Tim Peters' implementation. And, you know, here is a little piece of the interface that is specific to Java that doesn't exist in C.

MR. JACOBS: Let me ask you to look at something I prepared and see if you quarrel with it.

(Exhibit 211 was marked for identification.)

Q. BY MR. JACOBS: 211 is a top over bottom of the code we were looking at from the 2004 Sun copyright date -- printout of And the code we were just looking at, which is in Android and which is, in particular, the RangeCheck function in both cases. Do you see that?

A: Uh-huh.

Q: Are they identical?

A. No.

Q. What are the differences?

Page 182


design there, and I know it's something really close to your heart, something you've been working a lot on. So why is it so important? Why are clean APls so important and what is your philosophy behind creating?"

And he was right about that. APIs are something that's close to your heart; right?

A. Uh-huh.

Q. And you went through in that talk some of the things you went through in your presentation earlier, such as amplify the power of programmers?

A. Uh-huh.

Q. That's a "yes"?

A. Yes.

Q. "We don't have to waste time, you know, reinventing the wheel. We can devote our limited resources to actually solving the problems that we have to solve."

You said that in that interview; correct?

A. I did.

Q. And then you talked about bad APIs and how they can be an unending source of pain and --

A. Quick question for you, by the way. I don't have a copy of this thing in front of me so I find it a little harder to say yes when I can't see the transcript.

MR. JACOBS: This is a copy we prepared

Page 233


(indicating) from the video.

THE WITNESS: Thank you.

Q. BY MR. JACOBS: So I'm on page 5 of this.

A. Okay. All right. Continue. Reinventing the wheel?

Q. Yes. And so I want to focus you on the middle of page 7 and just confirm that you said this. You talk on the bottom of page 6 about the importance of names?

A. Uh-huh.

Q. And then you say: "It's written once and read and maintained for years so you want to make it easy to read."

This is the easy-to-read point that you were getting at, right?

A. Yep.

Q. "It contains a grammar for the new integer literals which allow you to separate groups with underscores."

What are you referring to there?

A. This would be the language changes in Java 7.

Q. And you said: "I pointed out that unless we change the names of these non-terminals, the grammar is just going to confuse people."

Do you see that?

Page 234


A. Uh-huh.

Q. And Jeremy says: "Right."

And then you said: "Yes, you know, generally speaking, these aesthetic matters are not just being prissy. They have real dividends if you get them right in terms of, you know, productivity on down the line. If you get them wrong, there is real losses in terms of bugs caused by misunderstandings."

Do you see that?

A. Yep.

Q. And you believe that to be true; correct?

A. Yes, for APIs; probably not for non-terminal symbols in grammar. Perhaps I was just being prissy that day.

Q. But in general, for application programming interfaces --

A. Yes.

Q. -- you believe these aesthetic matters are not just being prissy; they have real dividends?

A. Absolutely.

Q. Just to tie down a few tent flaps here, you had this email exchange with Bob Lee, which was exhibit --

A. 220.

Q. Thank you. Did you talk with anyone else

Page 235


about the Oracle lawsuit, other than Mr. Hwang?

A. I probably talked to my wife about it.

Q. I won't ask you about that.

A. Okay. And I talked on lists where Mr. Hwang was one participant and there were other participants.

Q. What lists? What lists are those?

A. I recall shortly after the lawsuit, we had to decide whether it was possible for us to appear at JavaOne or not, and the lawsuit was discussed in that context.

Q. The -- what's the name of that list?

A. It doesn't have a name. It was ad hoc. It was just a number of employees.

Q. Were you given instructions at any time about how to refer to the Java aspects of Android?

MR. PURCELL: And Mr. Bloch, I'd like to caution you not to reveal anything that you might have been instructed to do by counsel. So to the extent that the answer is "yes" with respect to people other than counsel, you can say "yes."

THE WITNESS: Okay. The answer is not that I recall.

Q. BY MR. JACOBS: Did you at some point understand that Java was a "J word," that Java was referred to as "the J word" on the Android team?

Page 236




I, LESLIE ROCKWOOD, CSR No. 3462, do hereby certify:

That the foregoing deposition testimony was taken before me at the time and place therein set forth and at which time the witness was administered the oath;

That testimony of the witness and all objections made by counsel at the time of the examination were recorded stenographically by me, and were thereafter transcribed under my direction and supervision, and that the foregoing pages contain a full, true and accurate record of all proceedings and testimony to the best of my skill and ability.

I further certify that I am neither counsel for any party to said action, nor am I related to any, party to said action, nor am I in any way interested in the outcome thereof.

IN WITNESS WHEREOF, I have subscribed my name this 13th day of July, 2011.


Page 243

Exhibit 2:


Highly Confidential - Attorneys' Eyes Only













Videotaped Deposition of DANIEL BORNSTEIN, at 333 Twin Dolphin Drive, Suite 400, Redwood Shores, California, commencing at 9:39 a.m., Monday, May 16, 2011, before Ashley Soevyn, CSR No. 12019.

PAGES 1 - 239


think there was -- basically, that was part of the contract.

Q. Other than the contractual obligation that put Google put in with this contract with Noser, what other steps did Noser -- sorry.

Other than the contractual obligation in the Google Noser contract, what other steps did Google take to ensure Noser did not use Sun proprietary information to develop the work -- to develop Java libraries?

A. I don't know what all -- what else was done offhand.

Q. Did Noser ever use any Sun proprietary information in implementing libraries?

A. I don't know.

Q. Did Noser consult any version of the J2SE 1.5 to develop its Java libraries for Google?

A. I don't know. I mean, I know what the contract says and I know what our intent was, but I wasn't sitting over their shoulders while that was all happening.

Q. Did Google consult any J2SE 1.5 documentation to evaluate the work it got from Noser?

A. So we -- 1.5, I'm not 100 percent sure. I

Page 160


know we had -- again, we had the printed materials, we had some amount of Javadoc, and we also had sort of the evidence of, say, what, for example, the classpath, what other implementations did.

Q. What Sun origin materials did the Android team have with respect to J2SE 1.5?

A. So again, I think there's, like, the printed books, Javadoc. I don't -- I don't know that there was anything else.

Q. You know that the Javadoc is copyrighted?

A. I understand it was copyrighted.

Q. Why would you use the Javadoc copyright to develop the Dalvik core libraries?

MR. BABER: I would object to the witness not to include in his answer any understanding he may have as a result of conversation with counsel.

THE WITNESS: I'm not a lawyer, but the understanding that I had at the time was that that was reasonable documentation to use to gain understanding about the idea of an API.


Q. At the time, referring to, say, in early 2007, what was the source of your understanding that it was that you could use documentation to gain understanding of the idea of an API?

Page 161


A. I don't know specifically.

Q. At the time, did you have -- receive any advice of counsel about what materials you could or could not look at to develop Android?

A. So I have had discussions with lawyers on and off throughout my career. I don't know how much I can say about the content of those.

MR. BABER: Instruct the witness to not say anything about the content of discussions.



Q. Did you see the -- were you ever advised by counsel that it was permissible to use a Javadoc to develop Android?

MR. BABER: Object and instruct the witness not to answer the question on the grounds of privilege.


Q. Will you follow your counsel's instruction?

A. I will follow my counsel's instructions.

Q. Besides -- other than potential advice of counsel, what other sources of understanding did you have about using Sun documentation to develop Android?

Page 162




I, ASHLEY SOEVYN, CSR No. 12019, do hereby certify:

That the foregoing deposition testimony was taken before me at the time and place therein set forth and at which time the witness was administered the oath;

That the testimony of the witness and all objections made by counsel at the time of the examination were recorded stenographically by me, and were thereafter transcribed under my direction and supervision, and that the foregoing pages contain a full, true and accurate record of all proceedings and testimony to the best of my skill and ability.

I further certify that I am neither counsel for any party to said action, nor am I related to any party to said action, nor am I in any way interested in the outcome thereof.

IN THE WITNESS WHEREOF, I have transcribed my name this 19th day of May, 2011.


Page 230


Exhibit 3:

Exhibit 3

Highly Confidential - Attorneys' Eyes Only












No. CV 10-03561 WHA



Videotaped Deposition of BOB LEE, at 110 Fifth Street, Suite 400, San Francisco, California, commencing at 9:35 a.m., Wednesday, April 3, 2011, before Leslie Rockwood, RPR, CSR No. 3462.

PAGES 1 - 82


in them, and the libraries are implementations of those 2 APIs.

Q. When you worked at Google on the Android team and as the head of core libraries, did you ever refer to those implementations of the Java and javax APIs as interoperability libraries?

MR. PURCELL: Object to the form.

THE WITNESS: I don't recall. It's quite possible.

Q. BY MR. PETERS: Did anyone else at Google refer to those as implementations of the Java and javax APIs as the interoperability libraries?

MR. PURCELL: Object to the form.

THE WITNESS: I don't recall the exact terms.

Q. BY MR. PETERS: But in your 2008 self-evaluation, you refer to them as the Java-ish libraries; correct?

MR. PURCELL: Object to the form.


Q. BY MR. PETERS: When you wrote that you build heavily on the Harmony class library, what were you referring to?

A. So Harmony is an Apache Project. They're creating a free and -- their goal was to create a free Open Source implementation of the Java libraries under

Page 12


the Apache license. The Apache license enables you to use that source code pretty much however you wish. It's very permissive compared to a license like the GPL, which has considerably more restrictions. For example, you have to Open Source any changes that you make.

So the Harmony libraries were an independently created and Apache-licensed implementation of the Java APIs, the Java SE APIs.

Q. You also wrote that you'd much rather be designing APIs than reimplementing them. Do you see that? What -- what APIs have you designed when at Google?

A. Oh, lots of them. For example, I implemented Google -- created Google Guice, which is a dependency injection framework, and that actually inspired and turned into JSR 330, which is dependency injection for Java, which is -- I led that JSR which contributed those APIs to the Java platform. And it was actually the fastest executing JSR in the history of the JCP.

Beyond that, I also contributed to the Google Collections now called Guava, which is a set of collections implemented in the Java programming language, can be run on Java -- like -- and for that, you know, I implemented several of those, like a class called MapMaker and various things like that.

Page 13


There are several other ones, but I don't know how much detail you want me to go into.

Q. Would you say that designing APIs is a creative activity?

MR. PURCELL: Object to the form.

THE WITNESS: Yes, absolutely.

Q. BY MR. PETERS: When you are referring to reimplementing them, are you referring to the work that you did with Noser to implement core libraries according to Java APIs?

A. I am.

Q. If I can ask you to turn to the second page of your self-evaluation.

A. Yes.

Q. In the fourth paragraph there, you have a description that begins: "Most recently I set my sights on our class preloading code."

Do you see that?

A. Yes.

Q. All right. With your work on the class preloading code, was it the case before your work that the list of classes that would be preloaded by Android would be manually managed?

A. Yes, that was the case.

Q. And you wrote that you added hooks to Dalvik

Page 14


so we can record class load and initialization times. Can you describe generally what that work involved?

A. Yes. So I mean, basically as you would execute apps, it would performance profile class loading, and it would like time both the loading of a class, which just means really like loading an executable code. And it would also independently measure the initialization time of the class. So when you initialize a class, it runs some kind of code.

And then it would -- so it would record that information, and then I wrote another tool that would -- I mean, this was quite a bit of information. It would mine all of this information that was gathered from running popular apps -- and there's dozens of apps -- and it would mine that information and prioritize and figure out which were the most important classes to preload and have like hot and ready to go into memory. So classes that were already loaded whenever an app started.

Q. So the ultimate output of your tool would be a list of classes and -- that should be preloaded and the order in which they should be preloaded?

A. Correct.

MR. PURCELL: Object to the form.

Q. BY MR. PETERS: And your tool calculated the

Page 15


does or --

Q. Yes.

A. -- the implementation of it?

I don't have a deep understanding. I know it's a -- so there's different types of just-in-time compilers. So, for example, some -- like, Sun's VM, like, compile individual methods. Dalvik is different in that it uses what we call a trace-based JIT, which means it doesn't care about the structure. It optimizes things at a lower level, like the actual extremes of code. And this is more comparable to all the stuff that Bill had done previously and also comparable to stuff that like I forget what you call it -- SpiderMonkey or something, on Mozilla -- Mozilla's jump strips, just-in-time compiler.

Q. SO -- so on a trace-based JIT, it could compile part of a method instead of doing things on an entire method base?

A. Yeah. A code that crosses multiple methods. It doesn't really care about methods. It cares about what code is being actually executed. It's, like, a level down.

Q. As you did your work to re-implement the Java APIs for Android --

A. Uh-huh.

Page 63


Q. did you do anything to investigate whether your work would infringe any of Sun's intellectual property?

MR. PURCELL: Object to the form.

THE WITNESS: I didn't know that there was any. So I wouldn't have done that work. I mean, I didn't read the source code, for example.

Q. BY MR. PETERS: How did -- how did -- how did you know that the Android code correctly implemented the Java APIs?

A. There were a number of ways. We read the specification, and like it describes, the span of the implementations. And wrote tests for that specification. And we took Open Source projects and ran their test suites on top of the Android. And that caught a lot of issues.

And then also, people would file bugs when they tried to run their Java code, like previously existing Java code, on Android. And we would address those issues.

Q. BY MR. PETERS: So how did the Open Source tests manage to test for correct behavior? Were they written to the spec as well?>{? A. Well --

MR. PURCELL: Object to the form.

Page 64


Go ahead.

THE WITNESS: So the Open Source tests, I mean, they use the Java programming language and the Java APIs. And they exercise in various ways. I mean, especially, like, when you have big Open Source projects. And if those tests did not pass on Android, that would indicate that there was something that we didn't support.

Q. BY MR. PETERS: For the -- it's the -- it's the API specification that defines the function and behaviors that the API is -- implementation source performs; is that correct?

MR. PURCELL: Object to the form.

THE WITNESS: The API specification defines the function, yes.

Q. BY MR. PETERS: I guess what I'm really getting at is, you know, you you know, Google was developing an implementation of a Java API.

A. Uh-huh.

Q. And in order to know whether it behaves correctly, it would have to know what the behavior is supposed to be; isn't that right?

A. Yes.

Q. And the description of the behavior is in the API specification.

A. Right. The Java docs, yes. Uh-huh.


Q. Did you consult the Java docs when doing your work on the API implementations for Android? docs?

A. Yes.

Q. Okay. And where did you obtain those Java docs?

A. They're posted for free on Sun's website.

Q. Okay. So you consulted Sun's website for the API specifications when doing the work for Google?

A. Yes.

Q. Who else did?

A. I'm not sure.

Q. Did the Noser team consult Sun's specification?

MR. PURCELL: Object to the form.

THE WITNESS: I would -- I don't have any specific knowledge of it, but I would assume so.

Q. BY MR. PETERS: Did you observe any copyright notices on the specifications?

A. Yes.

Q. And what did the copyright notices on Sun's API specifications say?

A. I didn't -- I don't recall.

Q. Did you consult with an attorney about implementing Sun's Java APIs?

MR. PURCELL: You can answer that question

Page 66


"yes" or "no".


Q. BY MR. PETERS: Why not?

A. I didn't see a need to. I mean, it wasn't copying the Java docs.

Q. Before the first commercial release of Android in a mobile device, do you know if anyone at Google consulted with an attorney regarding the Java API implementations in Android?

A. I don't have knowledge of that.

Q. Do you know if anyone at Google investigated Sun's patent portfolio before the first commercial release of Android in a mobile device?

A. No.

Q. Did you have discussions on the Android team about Sun's intellectual property rights?

A. No.

Q. Earlier today you mentioned that Dan Bornstein had been working on the Java API implementations before you joined up.

A. Correct.

Q. What resources did Mr. Bornstein do in his work on the Java API implementations?

MR. PURCELL: Object to the form.

THE WITNESS: Actually, I do want to go back

Page 67


in -- to your previous question. I mean, you mentioned intellectual property. So obviously the trademark is intellectual property. I knew that -- yeah, I did discuss getting that Java stamp of approval.

Q. BY MR. PETERS: So those were discussions about not being able to call things Java, because they had not passed the TCKs; is that right?

A. Correct. Yeah.

Q. What resources did Mr. Bornstein use in his work on implementing the Java API specifications?

MR. PURCELL: Object to the form.

THE WITNESS: I'm not sure.

Q. BY MR. PETERS: Did Mr. Bornstein consult Javadoc, to your knowledge?

MR. PURCELL: Object to the form.

THE WITNESS: I'm not sure.

Q. BY MR. PETERS: You had -- turn back to Apache and Apache Harmony for a minute.

A. To what? I'm sorry.

Q. To Apache Harmony. Not any specific document.

A. Oh, okay.

Q. But you had mentioned that Sun was putting on a field of use -- trying to put on field of use restrictions onto Apache that would prevent the use of

Page 68




I, LESLIE ROCKWOOD, CSR No. 3462, do hereby certify:

That the foregoing deposition testimony was taken before me at the time and place therein set forth and at which time the witness was administered the oath;

That testimony of the witness and all objections made by counsel at the time of the examination were recorded stenographically by me, and were thereafter transcribed under my direction and supervision, and that the foregoing pages contain a full, true and accurate record of all proceedings and testimony to the best of my skill and ability.

I further certify that I am neither counsel for any party to said action, nor am I related to any party to said action, nor am I in any way interested in the outcome thereof.

IN WITNESS WHEREOF, I have subscribed my name this 4th day of August, 2011.


Page 79


Exhibit 5:


Highly Confidential - Attorneys' Eyes Only












No. CV 10-03561 WHA



Videotaped Deposition of ANDREW E. RUBIN, at 333 Twin Dolphin Drive, Suite 400, Redwood Shores, California, commencing at 9:31 a.m., Tuesday, April 5, 2011, before Leslie Rockwood, RPR, CSR No. 3462.

PAGES 1 - 149


Q. Okay. Not even -- not even what you read in the last paragraph? Any of the --

A. No, it was absolutely not implemented.

Q. It's your testimony today that Java is not central to your solution?

A. Again, this was a proposal to make Java central to the solution. You go through phases. You decide on a strategy and then you implement the strategy. The tactics are the actual implementation and writing code of the strategy. And we're in partnership discussions with Sun because we hadn't yet decided on our strategy.

Q. Okay. But the question I asked you was: Is testimony as you sit here today that Java is not central to the Android solution?

A. In October of 2005, it was not central to the solution.

Q. And today is it true?

A. Java as a programming language, the Android application framework is written in the Java programming language.

Q. Are there any other respects as of today that Java is central to the Android solution?

MR. BABER: Object to form.

THE WITNESS: Not that I know of.

Page 36


Q. BY MR. HOLTZMAN: Okay. If you could turn to the second page of Oracle Exhibit 4, could you read what you wrote at the top of the page?

A. Yes. "If Sun doesn't want to work with us, we have two options: Abandon our work and adopt a Microsoft CLRVM and C Sharp programming language or to do Java anyway and defend our decision, perhaps making enemies along the way."

Q. And could you keep reading, please.

A. Next paragraph. "As you can see, the alternatives are suboptimal so I'd like you to stop in our Alan meeting and essentially be the good cop. Let them know that we love Sun and we want to find a way to do this open source thing."

Q. If you would just read the rest of the message.

A. Next paragraph: "I first looked at Eustas to help me, but he was out of the office, then Sergey. He was out also." Then I asked Larry if he had any thoughts.

Q. Now, you have a reference here in this message to two options if Sun doesn't want to work with Google, correct?

A. Correct. And that -- and the email basically details -- you know, an email is basically a snapshot in


time, October 11th, 2005. And at that time, these were the two options being considered. That doesn't mean they're the exhaustive set of options.

Q. Well, you didn't describe any other options email; correct?

A. Not at that time.

Q. Okay. And you're writing to Mr. Page; correct?

A. Yes.

Q. And Mr. Page is one of the founders of Google; correct?

A. Yes, he is.

Q. Now you described those two alternatives as, in your words, suboptimal. What did you mean by that?

A. I would rather build a partnership than go it alone. As I stated before, the reason you do a partnership is to accelerate your whole effort.

Q. And why did you want to accelerate your effort?

A. Why did I want to get to market faster?

Q. Yes.

A. Because I think it's a competitive advantage to market as quickly as possible.

Q. And you referred to a partnership, it's better to do a partnership. Is that a fair description


of what you just told me?

A. Yes.

Q. Okay. What partnership are you referring to there?

A. The partnership between Google and Sun. On the top of the second page, if Sun doesn't want to work with us, we have two options. Working with us was a co-development of the next generation of Java.

Q. And that would be a co-development with Sun; correct?

A. Correct. That's the definition of partnership.

Q. And so why did you want Larry Page to get involved in a discussion with Alan? And that's Alan Brenner; correct?

A. Correct.

Q. I'm sorry, why did you want Larry Page to get involved in that discussion?

A. Well, they were coming here, and I thought it would be nice for one of the founders of Google to show him some love. And I say that in the actual email. And that means, you know, giving Sun a high-level support of our partnership within Google I think would have been a very good message to send at the time.

Q. Why is that?




I, LESLIE ROCKWOOD, CSR No. 3462, do hereby certify:

That the foregoing deposition testimony was taken before me at the time and place therein set forth and at which time the witness was administered the oath;

That testim0ny of the witness and all objections made by counsel at the time of the examination were recorded stenographically by me, and were thereafter transcribed under my direction and supervision, and that the foregoing pages contain a full, true and accurate record of all proceedings and testimony to the best of my skill and ability.

I further certify that I am neither counsel for any party to said action, nor am I related to any party to said action, nor am I in any way interested in the outcome thereof.

IN WITNESS WHEREOF, I have subscribed my name this 12th day of April, 2011.



Exhibit 8:

Exhibit 8

From: Tracey Cole
To: [-] Jenifer; Andy Rubin
Sent: 10/11/2005 8:32 PM
CC: [-] LSA
Bcc: [-]
Subject: RE Sun meeting.

thank you


From: Jenifer []
Sent: Tuesday, October 11, 2005 7:39 PM
To: Andy Rubin
Cc: LSA; Tracey Cole
Subject: Re: Sun meeting

Larry is going to try to stop by the end of the meeting on Thurs, but he doesn't need to meet in advance to prep.

Deepest condolences,

On 10/11/05, Andy Rubin [email] wrote:

Begin forwarded message:

From: Andy Rubin [email]
Date: October 11, 2005 2:30:52 PM PDT
To: Larry Page [email]
Subject: Sun meeting


We have been having discussions with Sun regarding Android's Open Source VM strategy. Alen Brenner, who owns the P&L for J2ME @ Sun is coming over to basically tell us II believe) that Sun doesn't want to work with us. Alan's big concern is that by open sourcing our J2ME VM we will make licensing "enforceability" impossible for Sun -- and he will lose revenue.

My proposal is that we take a license that specifically grants the right for us to Open Source our product. We'll pay Sun for the license and the TCK. Before we release our product to the open source community we'll make sure our JVM passes all TCK certification tests so that we don't create fragmentation. Before a product gets brought to market a manufacturer will have to be a Sun licensee, pay appropriate royalties, and pass the TCK again.

Sun has already permitted open source VM projects in non mobile areas -- areas where they didn't have a well defined revenue stream. Apache is an example.

Android is building a Java OS. We are making Java central to our solution because a) Java, as a programming language, has some advantages because it's the #1 choice for mobile development b) There exists documentation and tools c) carriers require managed code d) Java has a suitable security framework


If Sun doesn't want to work with us, we have two options:

1) Abandon our work and adopt MSFT CLR VM and C# language

- or -

2) Do Java anyway and defend our decision, perhaps making enemies along the way

As you can see, the alternatives are sub-optimal, so I'd like you to stop in our Alan meeting and essentially be the good cop. Let him know we love Sun, and want to find a way to do this Open Source thing.

I first looked to Eustace to help me, but he was out of office. Then Sergey -- out also.


- andy

Jenifer Austin Office of the Founders. Google, Inc. office [phone]


Exhibit 9:

Exhibit 9

From: Rich Miner
To: Andy Rubin
Sent: 10/12/2005 8:35 AM
CC: [-]
Bcc: [-]
Subject: RE: Response.

Andy, sorry - wish you had called. Went back to my hotel to crash early. Had network problems but thought the email got out.

The only sentence I don't like at the moment is "Assuming Android will take two years to develop and deploy, it will be hard to argue that we should embark on another platform that has similar timing."

I am just wondering if we should be using the term 1-2 years and telling people if they stop trying to do two things and help us decide how to ship sooner then their are solutions (like acquisitions) that can get our delivery in shorter.

.. Rich



Here are the Android team responses to Eric's questions:

(1) Are we missing anything from the basic strategy of search, apps, and monetization? How will we get wide distribution?

It's worth looking at both product portfolio and distribution & business model.

The sky team has a good jump at improving web search and delivery of other services with a few sophisticated clients (mobile maps, gmail, etc). There are still a few gaps:

(a) Photo - most new phones have built in camera's - more cameras are being sold in phones than as stand along digital cameras. Few carriers have launched compelling photo services and most users don't even known how to get photo's off their phones. With the best-in-class brand Google has in Picassa and the launch of lighthouse we have a chance to deliver a combined client and server side solution to make a seamless experience of taking, storing, sharing and printing mobile photo's.

(b) Complete Mobile Portfolio - We have the ability to do services in a broad set of application areas: search, blogging, photo, email, IM, VOIP, Local & Maps. While we have to be careful to not make the carriers feel we are trying to take over their portal we should have a vision pitch which shows these as an integrated set of services. Powered-by-Google can be much broader than just search.

(c) Link Existing Google Services to Mobile - the quickest way to get Google services on mobile devices is to enable existing desktop Google, Froogle, Local, etc. to send search results to mobile phone via SMS, WAP push, etc. How many times does a Google user look something up on Froogle or Google Local, write it on a post-it note and stick it in their pocket. Today we could mobile enable these existing sites without any need to put clients on people's handsets.

Distribution and business model (or value chain) are intrinsically linked. Carriers are the primary channel to deliver our products with handset manufactures as a secondary channel. This has several key impacts on our ability to link


in services and distribute our applications:

For online services:

1. Carriers have a say on the look & feel of the applications
2. Traffic will be dependant on how we are featured on their portal and/or where we are placed in their default WAP stack
3. it will be a fight initially to get carriers to support search of non-portal content even though it benefits the user

For Embedded Applications:

1. users will not download app's so they need to be installed & shipped with the devices
2. both carriers and handset manufacturers need to support the installation and distribution of such client app's
3. the development, testing and support of app's even on a "standard" platform like Java when you do cross platform, cross manufacturer, cross carrier, cross country is huge.

Revenue from Advertisers not Users

For the reasons stated above it is key to get strong carrier support. While our technical leadership in search should be a huge advantage, it is considered a threat by many of the carriers. The quickest way to defuse this issue is to accelerate the advertising marketplace concept with contractual partnerships with carriers based on rev-share. Demonstrate to them the ARPU upside for our top 3 applications (search, gmail, maps/local). Model their bandwidth costs and provide to them a spreadsheet that shows them net upside. Our biggest selling point will be to show them how our advertiser network will enable them to increase data ARPU without cannibalizing existing voice revenue. The best way to do this is increase subscriber revenue through 3rd party advertisers. None of the search competitors (especially startups) have the story that Google has.

(2) Open source handset solution (aka Android) is some ways away. What can we do in the meantime? Should we consider launching an MVNO (from Larry)? Other?

Google has multiple interests in an open handset:

1. provide an open, application friendly platform for the delivery of services (Google and others)
2. provide a platform that can deliver the best integrated Google mobile experience
3. deliver a platform which will be adopted by both handset manufacturers and carriers due to its openness, completeness and ability to be customized.

It is widely believed by that if an open platform is not introduced in the next few years then Microsoft will own the programmable handset platform: Palm is dying, RIM is a one-trick pony, and while Symbian is growing market share it's becoming a Nokia only solution.

Shannon proposed an alternate solution to Android that seemed to be as large in scope and time. More important, we do not think it answers Eric's main question, which asked if there was something we could do in the interim. Assuming Android will take two years to develop and deploy, it will be hard to argue that we should embark on another platform that has similar timing. I'm also skeptical that Google should be building a platform within a platform. I have seen this many times, and the result is usually least common denominator across many handset platforms aka wxWidgest, Java, MIDP.


Finally, the matrix to support multiple embedded (most proprietary) platforms on multiple and diverse hardware technologies for multiple carriers, each with their own constraints and limitations is a huge, complex understaking. We should think very carefully about such a technology-heavy strategy because in the end, if the carriers don't like our apps, then nothing is getting deployed (see Eric's #1 question).

We have had a number of direct conversations with Larry on the fundamental problems with mobile phones. These problems can not be addressed by placing some middleware on a variety of inherently limited handset platforms. Android solves Larry's long term goal and vision.

What was being asked by the executive team is what can we do between now and a two year horizon. There are two solutons:

1. Accelerate the delivery of true Google handset experience based on Android.
2. Deliver an interim Google Application Handset based on an existing platform with a collection of Google applications -- would need to be done in 6 months time.

As far as point (1) goes we are making good progress on how to accelerate the delivery of an Android handset. We have the core team assembled and they are all people who have built such a platform before: App's, GUI, middleware, telephony, etc. We have just learned that Nokia plans to open source a KHTML based browser that should accelerate one complex module of the system. We are currently looking at options around the critical path items in the system. We could also significantly reduce the delivery time via additional acquisitions. There are several deployed OS companies that could speed up our schedule by many months. Savaje, SkyMobileMedia, Core Mobility, even Danger.

While the only way to truly address Larry's usability concerns with mobile phones it to deliver a complete platform such as Android, we could perhaps address Eric's concern by delivering a phone with a collection of Google applications sooner. This phone should probably be built to be sold direct by Google or by 3rd party channels such as Car Phone Warehouse as a Google Phone. This will enable us to control the applications versus having protracted debates with carriers. The idea would be to take an existing roadmapped handset from a single supplier, such as a Nolia Series 60 phone, and deliver a Google branded experience at the top level along with top-level access to Google applications including:

- Google Local Map's & integrated search

- GMail client

- Mobile Picassa (tied into light-house)

- Mobile Blogger (or at least streamlined interface to post images & comments to blogger)

Most of these applications are already under development. They could be tweaked for consistent look and feel without a significant investment in middleware. Such an ensemble could be integrated in a 6-month time frame with other Google look & feel, background images, ring-tones, etc. configured on the handset. This would not imply that we need to be an MVNO. Plenty of channels, BestBuy, CarPhone Warehouse, etc., would be willing to inventory Google Phones and sell them with other carrier SIM's and service plans. Even Google could partner to direct sell the phones via the WEB with other carrier SIMS. This allows us to have a Google phone without the overhead of being an MVNO. It could also be pitched as a carrier friendly strategy. Most important, it allows us to start taking more control of the interface with will become completely unified in Android.

To summarize:


Let's not embark on a multi-year development effort without sponsorship and business model validation from the gatekeepers. Let's not be wasteful; let's not duplicate effort. Let's balance our long term strategy requiring time and commitment with short term wins and business models that are complimentary. That's what it takes to win.


Exhibit 11:

Exhibit 11

From: Andy Rubin
To: [-] Dan Bornstein
Sent: 4/13/2006 3:41 PM
CC: [-] Steve Horowitz
Bcc: [-]
Subject: RE: What are we doing?

Obvious question - please define:

"the currently-envisioned time frame"?
"the currently-targeted amount"

On April 13, 2006, at 3:35 PM, Dan Bornstein wrote:

>> We need to provide an alternative to MSFT, and we need to do it in
>> such a way as we don't fragment 3rd party developers. See the next
>> slide in the deck for fragmentation: Java has very little
>> fragmentation, and it's adoptable. If we play our cards right, we
>> can also leverage not only existing developers, but applications as
>> well.
> That sounds like an argument for adopting the MIDP model for
> third-party apps, not developing a new app model.
>> Since we are Open Source, and the cost for our platform is close to
>> zero, we lower the total BOM by about 10%. That savings and some
>> careful choices in hardware specs helped us create our slogin:
>> "Smartphone features at featurephone prices".
>> BTW, my definition of smartphone is a phone that has an open API for
>> 3rd party developers and whose own applications use that same API.
> OK, even conceding the point about BOM, I do not believe we can make a
> smartphone by your definition in the currently-envisioned time frame,
> with the scope of development as currently outlined in the PRD, and
> have it be one that can be good enough to sell the currently-targetted
> amount. In the currrent nominal plan, there is too much that is new to
> expect everything to totally fall into place in an 1.0 release.
> Something still has to give. >
>> I've cc'd android-team.
> I think you forgot to; please go ahead.
> -dan


Exhibit 12:

Exhibit 12

[Editor: This is a 12-page slide presentation on the pros and cons of the proposed co-development deal with Sun then being considered.]

Slide 1:

Open Handset Alliance
Andy Rubin and the Android team

Slide 2:

Project Android - Google

We are building the world's first Open Source handset solution with built-in Google applications.

We are forming an alliance with interested parties to make this free platform the de facto standard for modern handsets.

Slide 3:

Partner Overview - Sun Microsystems

Who Are They? Why Do the Deal?
  • Products and services for network computing

    - Java dominates wireless industry

    - Carriers require Java in their terminal
    terminal specifications

  • Statistics

    - Not profitable

    - $15.4B Market Cap

    - $11.6B revenue

    - $469M EBITDA

    - $2.45B cash

  • Market Presence

    - xxx Java embedded handsets

    - xxx carrier relationships

  • Size

    - xx offices worldwide

    - xxx employees

  • Critical to our open source handset strategy

  • Dramatically accelerates our schedule

  • Form an industry alliance to block MSFT

  • Create value for wireless stakeholders

Slide 4:


  • Discussions started as a result of our last GPS

  • Alliance consists of key players of the wireless industry, including
    handset OEMs and wireless carriers

  • Sun becomes founding partner in alliance

  • Companies engage in a co-development relationship

Slide 5:

Proposed Deal Terms

Client - * Sun Microsystems

Term - * 3 years
* Co-development partnership

Proposal - *Sun makes Java Open Source as part of Android platform
* Companies work together to bring Android platform to market

Exclusivity - * Exclusive

Data Use/
Restrictions - * See detailed slides

Fee - * $35-50M
* To be negotiated potential rev share on platform-enabled mobile ads

Attribution - * N/A

Other Issues - * N/A

Slide 6:


  • Sun will open source CDC JavaME by "m/m/m" date

  • Google and Sun will produce the "Open Source Java Linux Mobile
    platform" by "n/n/n" date

    - Sun to govern the CDC codebase with partial governance by Google

    - Google to govern the Linux codebase with partial governance by Sun

  • Sun to provide a commercial implementation of the "Open Source
    Java Linux Mobile platform"

    - Google to provide backline support for the "Linux Mobile platform"

  • Google agrees NOT to offer commercial implementations of the
    "Open Source Java Linux Mobile platform" or similar stack except as
    necessary for initial launch

Slide 7:

Terms (cont'd)

  • Sun agrees to adopt certain key Google enablers
    (JavaScript, others tbd) in CDC and Google agrees to
    adopt appropriate Sun enablers in Linux stack

  • Google provides Sun with all Google owned handset
    technologies, un-encumbered rights, from day one. Sun
    can only ship this technology commercially after it has been
    open sourced

  • Sun provides Google with all Sun owned CDC JavaME
    technologies, un-encumbered rights, from day one. Google
    can only ship this technology commercially after it has been
    open sourced

  • Sun and Google to promote the Java Brand for mobile

  • Google to certify their applications on Sun's commercial

Slide 8:

  • Sun and Google will jointly engage in recruiting OEMs and
    Service Providers

  • Sun intends to monetize the commercial implementation of the
    "Open Source Java Linux Mobile Platform" Stack and services
    around it (support, ES, updates/upgrades, customizations + IP
    value add) in the following areas. This list is not intended to be
    comprehensive and does not restrict Google from providing
    underlying technology:
    - Device management

    - Security upgrades/ Patch management

    - User interface customization for OEMs, MVNOs, carriers

    - Enterprise level synchronization

    - Network quality monitoring

    - User experience customization based on device usage

Slide 9:

Terms (cont'd)

  • Google agrees to adopt and promote NetBeans and Sun Java
    Wireless Tool Kit (WTK) along with its tools. Where appropriate,
    companies will merge their tools

  • Where appropriate, Mobile client apps provided by Google to
    work with Sun backend

  • Google Open Source License to be ASF2.0

  • Sun Open Source License to be decided with the goal:
    - Non viral

    - Non discriminatory/ equal access

    - No field of use restrictions

    - Freely distributed

    - Compatible with an existing license

    Slide 10:

    Financial compensation

    • Google compensates Sun for current business risk

      - Estimated cost: $25-50M

    • If Google recognizes $s from services running on "Open Source Java
      Linux Mobile platform" or derivatives, Google will revenue share with Sun

    Slide 11:

    Key Asks

    [graphic of phone]

    • Approve joint development

    • Approve to proceed to contract

    • Approve spend ranges

    • Approve to enter into multi-party discussions
    Exhibit 13:

    Exhibit 13

    From: Andy Rubin
    To: [-] sergey at
    Sent: 1/13/2006 8:01 PM
    CC: [-] Larry Page; LSA; Alan Eustace.
    Bcc: [-]
    Subject: Sun Microsoft


    When Android first arrived I did a GPS that explained the importance of Java in our solution.

    Since then I've been working with Sun and pushing them to open source Java. Initially this was a foreign concept to them and took some educating. Now we're at a point where they have conceptually agreed to open java and additionally they desire to broaden their relationship and become a customer of the Android system and Google. Their desire is to create a "distribution" of the Android system ala Redhat. It will be an industry changing partnership. Sun is prepared to walk away from a $100M annual J2ME licensing business into an open source business model that we together crafted. This is a huge step for Sun, and very important for Android and Google.

    Soon I will give a detailed presentation to EMG. I'm writing this email tonight to give you a heads up that you may receive a phone call from Jonathan Schwartz. Alan Brenner (Sun VP) briefed him today and Jonathan was excited and immediately wanted to pickup the phone to call you. He doesn't know any of the details of the discussions, but apparently his team has armed him with some basic concepts of the Android project which you are familiar with.

    I'm available via by cell phone if you need to reach me: [phone]

    - andy


      View Printable Version

    Groklaw © Copyright 2003-2013 Pamela Jones.
    All trademarks and copyrights on this page are owned by their respective owners.
    Comments are owned by the individual posters.

    PJ's articles are licensed under a Creative Commons License. ( Details )