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


Groklaw Gear

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

You won't find me on Facebook


Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

Day 5 - Oracle v. Google Trial ~pj - Updated 5Xs (Lee, Swetland, Morrill, Cizek)
Saturday, April 21 2012 @ 01:48 AM EDT

We have begun to receive the account of the day from our reporter at the Oracle v. Google trial. Friday was day 5, and as usual, the day started with the judge and the parties' lawyers working through any issues before the jury was brought in. Witnesses today were Bob Lee, Core Library Lead at Google for Android; Brian Swetland, System Software Lead at Google for Android, from Danger, Inc.; Dan Morrill, Technical Program Manager for Android at Google; and Leo Cizek, Java Licensing account manager for Sun and then Oracle (on the Google account). Cizek's testimony went on and on, so much so the judge reminded Oracle that they need to think about using up their time wisely.

It was a Friday, and the tone of the day was low stress, lots of good humor, and more of the judge trying to make sure he understands the tech. He indeed expressed that while the patent claims seem clear, the copyright claim is still a bit murky to him, or as he reportedly described it, "it's strange". So more briefs requested.

He then asked the parties, once the jury came in, to speak for ten minutes each, explaining what each side thought had been established so far. And then after the jury was excused for the day and the weekend, the judge significantly said something to the effect that it is one kettle of fish to say you need a license to use their source code; it's another when you say you need a license regardless of whether you've done an independent implementation.

So he's definitely getting the point.

Jump To Comments

[Update 1, Update 2, Update 3,
Update 4, Update 5]

Meanwhile, I'm trying to understand also. I asked a programmer who helped me in the SCO saga by explaining the tech to me to please explain APIs. All the conflicting imagery had me confused, file cabinets, verbs, blueprints. What exactly would he describe them as being like? Here's what he told me:

Essentially, an API is the way to interact with a system, programmatically (that's what the 'P' is for).

Let's say I'm writing a program to analyze a lot of data. I realize I want to compute averages, standard deviations, etc. But I don't want to have to write lots of code. So I go and find a statistics library somewhere that someone has already written. A library is essentially an implementation plus an API. The implementation is the code to do the work, while the API is essentially the way a programmer can activate the library.

Oh, here's a good analogy maybe. A 747, or planes in general. The "API" to a big jet is the control panel. There's a steering wheel. Maybe there are dials to set the altitude. There's a button to turn on autopilot, and to turn it off. The "implementation" is everything that the control panel is connected to. i.e. the engine, the electronics that control the engine, etc.

Now let's say you go to another plane, a 767, or whatever. Maybe it has the exact same control panel. But the "implementation" will be different - there are certainly a different number of engines, and (whatever else differs in planes). But by sharing the control panel / API between the 747 and 767, any pilot that can fly one can fly the other....

Back to the statistics example, more concretely.

Let's talk about averages and mins and maxes.

You could imagine an API for a stats library like e.g.:

Average(number list_of_numbers[]) returns number;
That means: I'm declaring a function named 'Average', which takes 1 parameter (list_of_numbers), and returns a single number. Here "number" would be a special type in the language. (Maybe the language also has "text" as another type.) There should also be a comment like
// This function returns the average of all the numbers in list_of_numbers.
so a programmer knows what the function does.

You might also have:

Max(number list_of_numbers[]) returns number;
Min(number list_of_numbers[]) returns number;
And so on... The API is essentially the set of these declarations.

The reason that programmers are pretty upset about this lawsuit is that sharing APIs is Good and Proper. It's really nice if people can agree on an API, and then lots of people can use it. Back to the Java plane - wouldn't pilots like it if there was a standard control panel, that worked across all airplanes? Programmers are the same way.

I think historically if someone made a new computer language (which typically include as a key component their libraries (and the APIs to those libraries) ), they made money by selling the compiler and/or the operating system. Programmers presumably place most of the value on the implementation, though, not the API.

I believe if Oracle somehow bought C++ (I don't think anyone owns that computer language, so that's probably not plausible, but just pretend), they would claim that anyone that implemented a C++ compiler would be stealing their APIs. So in their world, you either buy their C++ compiler, or you can't program in C++. I have no idea about any legal issues - but this would be bad for the advancement of technology.

So I mulled that over and asked him this:
Well, airplanes are easier for me than file cabinets and blueprints. But it raises a question in my mind. You might read this article or at least the Apple v. Microsoft ruling that is linked to on that page.

Then, this is my question: why wouldn't a menu bar be kind of like an API? Analogies are never perfect, but each item you click on calls up something, some functionality you want. I mean, what is there about 37 APIs or a million of them that isn't just a list that gets your computer to doing something you want it to do?

In other words, what isn't functional about an API? The class libraries would be what, in my menu analogy?

Maybe nothing, if the analogy is wrong, but in Apple v. Microsoft, the judge ruled you can't protect things that need to be more or less the same, so everyone is familiar and so the first to invent it doesn't own the entire market.

And what does this interchange mean about methods, etc.?

Judge: How many methods are in the 37 APIs?

Oracle: 8,693 methods.

Judge: Are these the same as are in the Oracle package [I assume that Judge Alsup is asking about the namespace?] I want to know what differences are there. Are there any additions/subtractions?

Judge: Did Sun develop the methods themselves, or were they developed by some 3rd party?

Judge: I need answers from both sides regarding the "Declaration of API elements". What is this?

Oracle: The first line of the API and the corresponding class libraries.

Judge: When something is considered to be a derivative work…

Google: The derivative work question depends on what is being claimed. The declaration (or method signature) is

a) the name of the method
b) variable type returned
c) order and type of arguments
This is from the trial, Day 2.
He replied:
I think the "37" APIs is essentially like 37 header files - if you remember stuff from the SCO trial. java.awt.font, java.beans, etc. Those each correspond to a "package" in java. The package can have many classes, and each class can have many methods (which are just like functions).

As far as your menu bar analogy - yes, I think that's a pretty reasonable analogy. The menu bar is an interface for humans, while an API is an interface for computer programs.

I would agree that if you protect the Java APIs, then no one else can use Java without Sun giving the OK. Which I think is bad. And I guess the judge in the Apple v. Microsoft case thought it was bad.

I then wrote back that no matter how hard we try to get a good analogy, I'll get three emails telling me my analogy is stupid and wrong.

: )

OK. But here's the deal. If you send me an email like that, you have to offer a *better* analogy. Also, here's a summary of the trial issues, the tech, and the history of Java by Stephen Shankland at CNET. I think he's about the best tech writer in terms of making the complex understandable.

Here's mirror_slap's report, which he'll be adding to as he gets his notes (33 pages) transcribed:

Oracle v. Google, Day 5

[I arrived at the courtroom at 7:20 AM. On my way into San Francisco on the BART, there was a planet rising in the East, brilliantly lit by the sun. Today I decided to try taking notes on my iPad to hopefully avoid the transcription time lag. If it turned out to slow me down, I could just use the trusty notepad. Which is what I ended up doing.

It seems that the demeanor at the Google table is more upbeat. There are even some smiles. At the Oracle table, nobody is smiling, except Michael Jacobs, the lead attorney from Morrison & Foerster. One of the attorneys at the Oracle table appears to be reading the laptop screen of one of the Google attorneys whose back is to him. Or maybe he is staring intently at the water cooler at the side of the courtroom for two minutes or more. They are both seated, back to back, only the Oracle attorney has turned and is facing toward the wall on Google's side. The Oracle attorney is a tall, slim, bespectacled guy with very closely-cropped light brown hair that is thinning on top.]

Judge Alsup comes in.

Judge Alsup: The lawyers seems to be doing pretty well. Usually by now someone would have come down with the flu or something.

Judge Alsup: With regard to the papers I asked for?

Oracle: Regret to inform Your Honor that we did not follow the letter of your order, but I think that we followed the spirit, so as not to subject Your Honor to my handwriting.

Google: We followed your order to the letter Your Honor... [chuckles from everyone.]

Judge Alsup: When you say class libraries, what do you mean by class libraries? Are they in source code form or compiled?

Oracle: I'd like to check with our experts.

Google: We refer to both source code format, as well as the byte-code environment. It's the same code, just in two different forms. The body of code that performs the function that actually does the work when you call it.

Judge Alsup: Is this the implementation?

Google: Yes.

Judge Alsup: Let me give Mr. Jacobs another shot at it.

Oracle: Defers to his client.

Judge Alsup: Next question... to Google. Does Google admit to factually copying the SSO, and declarations of the Java API elements (from the Java documentation)? Explains that this is for the jury to avoid having to explain to the jury about "substantial similarity".

Google: [Mr. Baber] I will answer the premise... there still must be substantial similarity in the work as a whole.

Google: Google did not copy the SSO or declarations. In their cleanroom Google used the names of the elements in the class libraries and the declaration elements. These are elements we all use.

Judge Alsup: Now to the point you were making... What is the concept of the works as a whole?

Google: [Falls back on pleadings.]

Judge Alsup: This came up on summary judgement, the de minimis argument.

Google: The plaintiff has to identify its copyrighted work. Oracle has not placed into exhibit any separate registrations for copyright for their works. Judge Alsup reserved judgement on this.

Judge Alsup: Is it the same work for the purpose of fair use, de minimis?

Judge Alsup: Mr. Jacobs, do you agree with this?

Oracle: [Indicates that each file is copyrighted. There is a lot of law that says that you don't escape copyright law by virtue of the amount that you add.] Judge Alsup: Nobody is arguing that stealing someone's work and adding to it is okay.

Google: What is the accused work?

Judge Alsup: How many lines in the 37?

Google: Maybe 100,000?

Judge Alsup: What is the work as a whole? Is it the 37 APIs? Is this a question for the court or for the jury?

Google: It is probably for the court to decide the scope. Many considerations.

Judge Alsup: It seems a little hard on the judge that the complaint could say... that we would get all the way to the end of the trial and I have to instruct to the jury as to what the scope of the decision is supposed to be.

Google: The works are the two you pleaded and if you [Oracle] need to …

Oracle: We are mixing two issues. 1) Versions of Java covered in this case are 1.4 and 5.0. 2) You are abandoning rights to intervening versions [I don't recall any significant versions between 1.4 and 5. There was a release numbering scheme changed. Was this a red herring? ]

Comparing A:B. This needs to be briefed.

Judge Alsup: Do the brief. It's due Sunday at 3PM [Same time as a previously requested brief is due.]

Judge Alsup: Here are the questions in my mind: Should the plaintiff be held to what they pleaded in the complaint? I find it strange that on the patent side it is really clear what is being infringed. With the copyright side, it's strange.

Yes, Mr. Van Nest? I saw you jump up when I said Sunday by 3PM.

Google's Robert Van Nest: The brief is limited to 10 pages?

Judge Alsup: Use good judgement. If you can express it in fewer than 10 pages, then by all means please do so.

Judge Alsup: Any other issues?

Oracle: We have stipulations [of exhibits that both side agree to be entered into evidence]
Oracle: 748, 749, 751, 752, 753, 2800, 2801, 2802, 3341, 3342, 3343, 3344, 3346, 3348, 3349, 45.1, 45.2, 45.3, 46.20, 46.21, 46.22, 46.23, 46.24, 46.25, 46.26, 46.28, 741, 767, 770, 771, 773, 862, 1030, 1031, 1032, 1033, 1034, 1035, 1036, 1037, 1039, 1039, 1040

Judge Alsup: Any more?

Oracle: No, your honor.

Judge Alsup: Okay, these exhibits are entered into evidence.

Judge Alsup: Didn't I ask for a one-page list of names of the lawyers?

Google: Your Honor, you asked for a one-page "Who's Who".

Judge Alsup: It would just be very helpful for the jury to know who you are and how to spell your names. Mr. Boies isn't here today, but they are spelling his names like "Boys", as in "Boys and Girls". It would help the jury be respectful to the lawyers.

Google: Do you want photos, too?

[Fun exchange between Judge Alsup and Mr. Van Nest about producing baseball cards for the lawyers.]

Google: Do you want our averages? [Big grin… something tells me he wins a lot.]

[Back to business.]

Judge Alsup: Regarding downloading something from a web site, if the download is stipulated, it doesn't follow that the date of the download is stipulated. Only the four corners of the exhibit itself are stipulated. Additional proof would need to be given regarding the date of the download.

Jury is seated.

Judge Alsup: Everyone doing all right? You are all smiling… it must be because it's Friday. We are about 1/3 of the way through the case. We are pretty much on schedule. I am going to do the following now: each lawyer will have 10 minutes to summarize what has been proven or not, where they are going next with the case, etc. It's a useful exercise. Again I remind you that nothing the lawyers say now is to be taken as evidence.

Oracle: [Mr. Jacobs puts up slides.] You've seen CEOs of both companies. "Our commitment is to make this as clear to you as possible". Java is licensed by companies all over the US and the world. There are different types of licenses for different purposes. The different types of Java implementations (standard, enterprise, micro) speak to the scale of the Java implementation. You wouldn't try to run a database on a credit card; there are differences in CPU and memory sizes. Sun/Oracle has IP and that's protected by copyright notices and copyright registration notices. Ref TX475 and TX476. [Missed some points.] You have heard that Google is an outlier [in terms of not taking a license]. You've heard from Larry Ellison that Google didn't take a license, and from Larry Page saying that he couldn't name a single company that hadn't taken a license. There was a licensing scheme that was available to Google. Google knew that they needed a license. Their CEO was repeatedly told that Google needed to take a license. Ref TX 7. Google understood that they had 23 options.

Sun/Oracle wants Google to be a member of the Java community. Google will try to say that this is trivial, that Android is huge. You heard from Eric Serevan that API design is incredibly creative. You heard from Mark Reinhold about how creative API design is. Mr. Bloch at Google said that API design is an incredible craft, a rewarding and noble craft. It involves esthetics; a nice-looking API is easier to use. Mark Reinhold said that the APIs for java.nio took 2 years to design. Both the API and the documentation come from the Java source code files. When we talk about the API, we are talking about the design of the [missed… Java environment? ] Regarding copying, in the next few hours we will see the nature of the copying, and the problem that the Google copying caused [some items including fragmentation], creating a Tower of Babel rather than a consistent programming language.

[Shows slide of relative size of Java language (tiny blip) versus the APIs (huge), with a small overlap. I didn't see any indication as to whether or not it's to scale.]

Apache Harmony did not get a license. Ref TX 326.

Google [Van Nest]: [In a strong, clear, steady, persuasive voice] Thank you (to the jury). We (Google counsel) have been attentive regarding whether you are being attentive, and we really appreciate your being so attentive. [Thanks Judge Alsup, too.] Here is the key evidence that is *not* in dispute: Use of the Java programming language; using the names of class files and methods; the source code in the libraries, comprised of original Google works and Apache Harmony. So what we are down to? -- the Sequence, Structure and Organization, the SSO, which is in the public domain. Apache Harmony and GNU used them and Sun did nothing. Then Google did what they did. Larry Ellison himself said that "Nobody owns the Java language". The APIs have been used for years as a necessary part of the Java language. There has been lots of testimony on this:

1) Waste of time trying to program Java with no APIs --Bloch
2) Google helped with the GNU classpath. Bloch, at Sun, helped GNU with it.
3) Dr. Kurian: Apache Harmony was using the same APIs from 2005-2009. The Apache Harmony license allows using any or all parts of Apache Harmony. Sun did nothing to stop this so long as Apache Harmony was not called Java.
4) Tim Lindholm's testimony: You need a system of organization to be able to use a programming language.
5) Google built their APIs from Open Source software.
6) Larry Ellison at the Java One conference: "We like Android and we know it's using Java.
7) Google's use of the SSO was absolutely fair. Google transformed something that wouldn't work on smartphones to something that would.
8) Larry Ellison knew that Sun had tried and failed to build a Java-based smartphone, and then Oracle tried and failed to build a smartphone.
9) Oracle even tried to build their smartphone on top of Android.
10) Oracle talked with Google, offering a business proposal.
11) Oracle wants to participate in the smartphone market without doing any work.
12) Mark Reinhold said that Write Once, Run Anywhere doesn't mean that there is code fragmentation in the JME, yet Sun launched Project OneJava to solve this very problem. But Oracle killed the OneJava project when they bought Sun.
13) This is all about Oracle trying to get a claim on the smartphone market.
First witness of the day: Brian Swetland
[Mr. Swetland sports a pony tail.]

Oracle: [Fred Norton?] You are employed by Google?

Brian Swetland: Yes.

Oracle: Working on Android?

Brian Swetland: Since 2005.

Oracle: Previously at Danger, Inc?

Brian Swetland: from 2000-2004.

Oracle: You worked with Andy Rubin at Danger, Inc?

Brian Swetland: Yes. Andy was the founder of Danger, Inc.

Oracle: [What smartphone products did Danger Inc produce]?

Brian Swetland: The HipHop, a.k.a. SideKick, which ran Java apps.

Oracle: [Did the HipHop run on a JVM?]

Brian Swetland: At the time that HipHop was released, the VM wasn't a JVM, and it was not compatible with Java.

Oracle: You never had access to Sun's Java source code?

Brian Swetland: No.

Oracle: Was the VM in HipHop incompatible with the JVM specification?

Brian Swetland: Yes.

Oracle: So Danger, Inc. took a license from Sun?

Brian Swetland: Yes.

Oracle: Danger then made the JVM compatible?

Brian Swetland: Yes.

Oracle: You worked with Tim Lindholm, who worked at Sun?

Brian Swetland: Yes.

Update 3: -- Here's Part 2b:

Oracle v. Google, Day 5, Part 2

Continued testimony of Brian Swetland

Oracle: You worked with Tim Lindholm, who worked at Sun?

Brian Swetland: Yes.

Oracle: Tim Lindholm said that Danger, Inc. needed to take a license?

Brian Swetland: [ Yes ]

Oracle: [Do you recall anything about Sun's copyright claims?]

Brian Swetland: I recall that Sun said that the method signatures were copyrighted.

Oracle: (Shows TX14.9 to Brian Swetland, a May 31, 2006 email to Andy Rubin and Dan Borenstein.) Do you recognize this email?

Brian Swetland: Yes.

Oracle: You wrote it to Andy Rubin and Dan Borenstein about Sun?

Brian Swetland: [ Yes ]

Oracle, quoting Brian Swetland: "whatever happened to the bullshit Sun copyright issue?". Did you write that?

Brian Swetland: Yes.

Oracle: [ To the best of your knowledge, ] nothing had changed from what you knew [ in ~2000 to 2006 ] about Sun's claim about copyright of the method signatures?

Brian Swetland: No.

Oracle: Did you start any investigation of Sun's [ current as of 2006 ] copyright claims?

Brian Swetland: That was not my role [ at Google ].

Oracle: [ Asks about employees at Danger who are now at Google working on Android ]

[ missed ]

[ I think that this is going to Oracle's claims about the Google cleanroom implementation? But Andy Rubin apparently got a clause added to the Sun agreement that Danger, Inc signed that specifically said that Danger, Inc. did not get access to Sun's source. ]

Oracle shows TX13, an email from Brian Swetland to Mr. Rubin and Mathias [?] dated 2006 - You wrote this?

Brian Swetland: [ the form of the email seems to confuse Brian Swetland a bit. Not sure what his exact response was, but I think it was, "I think so." ]

Oracle, quoting: "reason to shift to a primarily Java API"

Brian Swetland: There appears to be some other email that I quoted.

Oracle , quoting: "I think that we are pretty set on it…" Did you write that?

Brian Swetland: Yes.

Oracle shows TX123 from Brian Swetland to 3 fellow Google employees, Andy Rubin, _____, and Chris ____ [ missed ].

Oracle shows TX314 from Robert Reasoner to Brian Swetland dated August 2005, asks Brian Swetland to read a specific passage.

Brian Swetland: … a JAVA VM for Android…

[ All the above-mentioned exhibits were entered into evidence without objection. Google has been very judicious (IANAL) regarding which exhibits they object to, perhaps 1/3 (by Judge Alsup: 's count). The reason is that Google effectively uses a lot of the admitted evidence in demonstrating fallacies in Oracle's arguments and making their own arguments that (to me) are more straightforward and sensible. ]

Cross-examination of Brian Swetland by Google counsel Christa Anderson

[ A juror coughed. Judge Alsup asks if the juror would like a cough drop, which the juror gratefully accepts. Judge Alsup is very focused on getting this trial to a successful and timely conclusion, and has stressed his concern for the jury's health and his enthusiastic willingness to eject members of the gallery if they are "hacking or coughing" or are otherwise distracting the jury. This judge is awesome. ]

Google: Before we begin, some introduction [ of the witness to the jury ].

Brian Swetland: [ Lives in Palo Alto, graduated from University of Chicago at Champaign/Urbana. After graduating, worked for 2 years at Be, then at Danger, Inc. for 4.5 years. In late 2004, joined Android, and became a Google employee in July 2005 when Google purchased Android. Brian Swetland is the Systems Software Lead for Android at Google. ]

Google: What was your primary focus [ in your job at Google? ]

Brian Swetland: The kernel and device drivers.

Google: When did you first learn Java?

Brian Swetland: In 1995 at the U of Chicago.

Google: How did you learn to program in Java?

Brian Swetland: By tinkering with it [ more response lost ]

Google: Did you read any books?

Oracle: Objection, leading.

Judge Alsup: Sustained. [ I think in this exchange that Judge Alsup reminded Google to "use the magic words, To What Extent and [missed], to avoid being called for leading. I believe that a response was finally elicited from Brian Swetland regarding the book, The Java Programming Language Specification. ]

Google: What about the Java APIs? Are they free for use?

Brian Swetland: They have to be, otherwise the language would be useless.

Google: Regarding Danger taking a license from Sun, what was your understanding?

Oracle: Objection, hearsay.

Judge Alsup: Sustained.

Google: [ tries again ]

Oracle: Objection.

Judge Alsup: You know that I don't like that question [ when the witness has no direct knowledge ]… [ warns Oracle that they ] will have to live with that rule, too.

[ Different line of questioning ]

Google: Has Tim Lindholm ever been a member of the Android team?

Brian Swetland: No.

Google: What code did Tim Lindholm contribute to Android?

Brian Swetland: None [ to the best of my knowledge ].

Google: What was Tim Lindholm's role for Android?

Brian Swetland: Business development.

Google: Regarding TX149, what is the link in the email?

Brian Swetland: it's a link to Google's webkit. It allows you to convert Java to Javascript, which is a different language.

Google: The last line of the email, "Whatever happened to the bullshit argument over Sun's method signature copyright?". What did you mean by that?

Brian Swetland: I was trying to get at whether this was still an issue. The GNU GCJ, GNU Classpath projects and lots of JVM implementations had been done [ without a license ].

Google: Regarding TX13 [ not sure of this TX number ], in the double-caret-indented section, a portrion of the email that you did not personally write, in paragraph 5, [ do you see that? ]

Brian Swetland: [ Yes ]

Google: It uses the word "bright", yes?

Brian Swetland: It does.

Google: [ And that refers to you? ]

Brian Swetland: [ It appears to. ]

Google: But you didn't write this portion? ]

Brian Swetland: [ No. ] It refers to me in the 3rd person. It would be totally weird for me to write about myself that way.

Google: The reference to "Brian being scarred by the Danger experience", what was that about?

Brian Swetland: My unhappiness with Danger taking a license from Sun for Danger's [ already-implemented ] cleanroom implementation, and that Danger didn't need it [ a license ].

Google: Regarding X314, is this the email exchange in August 2005?

Brian Swetland [ Yes. ]

Google: At the top of the email, it says, "I really cannot comment on the project". The email references a lot of people, Tim Lindholm, Frank Yellin [sp?]. Did any of these people work on the Android project?

Brian Swetland: No.

Google: TX200? [ missed the question ]

Brian Swetland: No

Google: TX409? [ again, missed ]

Brian Swetland: No.

TX33? [ sorry, folks ]

Brian Swetland: No.

Redirect of Brian Swetland, by Mr. Norton for Oracle
Oracle: Whether you were scarred by the Danger experience or not, you know that Danger took a license?

Google: Objection, hearsay.

[ back and forth among Judge Alsup, Oracle and Google regarding this ]

Oracle: Android uses the API method signatures?

Brian Swetland: Yes.

Oracle: Other companies' and the GNU implementations were complete?

[ There is an exchange about what Brian Swetland knows and doesn't know. It boils down to the fact that he has not done a complete code analysis of the systems about which he is being questioned, and so he cannot say either way whether they are complete. ]

Brian Swetland: I don't know. [ Oracle seems to me to be badgering the witness in this string of questions. Brian Swetland, like most techies I know, really doesn't like to say, "I don't know" when he has a pretty good grasp of the subject, but he has been boxed in by the requirement that he can only testify about things about which he has direct personal knowledge. ]

Oracle: Is Android a complete implementation?

Brian Swetland: Based on your assertions [ of requiring direct knowledge ], I don't see how I can answer your question.

ReCross of Brian Swetland
Google: Mr. Swetland, what is your understanding about why Danger took a license?

Brian Swetland: To avoid the expense of litigation [ with Sun ].

End of Brian Swetland testimony.

Judge Alsup to Jury

Judge Alsup: (to jury) As I've told you in the past, there is discovery and pleading (accusations). Sometimes in the trial, something that gets admitted [ is changed from what was plead. ] Example: a traffic accident happens, and in the pleadings it is stated that the light was red. Then at trial, the witness says that the light was almost red. The judge can tell the jury that, in the pleadings the party said that the light was red. [ does Oracle see flashing red lights, I wonder? ]

There are 2 items that Oracle wants admitted as evidence against Google. They are Google's pleadings. Their pleadings are evidence. Not conclusive evidence. You have to use your own judgement in weighing the evidence.

1) Google has said that Sun released the specification for the Java platform, including the JVM, under a free license that allows developers to implement in a cleanroom… Sun would provide a license [ the JLS ].

The only way to prove compatibility is to run the TCK for a particular version of Sun's Java. The TCK is only available from Sun. It is not Open Source software. It is at Sun's discretion whether to provide access to the TCK. Developers could not easily obtain a critical component for [ testing a JVM that they had independently implemented ].

2) While Sun did open source Java, Sun added Field-Of-Use restrictions that precluded running the TCK on mobile device [ JVM's].

Update 4: Here's the testimony of Bob Lee and Dan Morrill:

Witness Bob Lee
Oracle: [Does some introductions… hmmm. it seems that when the witness is considered by Oracle to be helpful to their case that they do the introductions themselves. When the witness is someone that they want to tear apart, they let Google use their time to do the introduction. ]

Bob Lee is the Core Library Lead for Android from 2007-2010, and started working at Google in 2004. He joined the Android team "early, when there were 12 people on it" in 2006.

Oracle: The core libraries included libraries in the Java namespace?

Bob Lee: Package names, yes.

Oracle: Android implements part of the JSE5 APIs but not fully?

Bob Lee: Yes [partially implements].

Oracle plays video deposition page 48 lines 7-16, "Android uses Java APIs? Bob Lee (on video): Yes.

Oracle: Do you like the Java APIs?

Bob Lee: Yes.

Oracle: You consulted on the Java API specifications?

Bob Lee: Yes.

Oracle: [You consulted on the Java API specifications] while you were doing work on Android?

Bob Lee: Yes.

Oracle: You saw the copyright notices?

Bob Lee: Yes.

Oracle: Are you familiar with the TCK?

Bob Lee: Yes.

Oracle: You wanted to run Android's JVM through the TCK?

Bob Lee: Yes, but it was different versions of Java, [somewhere between] JSE, JME.

Bob Lee: "Because I work a lot on what I thought were open Java standards".

Oracle: You worked with an external company, Noser, that was hired by Google to work on implementing the Java class libraries?

Bob Lee: Yes.

Oracle: Ref TX405, email between Bob Lee and Eric Schmidt, May 30, 2008: You wrote to Eric Schmidt about Apache Harmony?

Bob Lee: Yes.

Oracle: In the middle of the paragraph that starts with, "I hope", what do you say about Sun's field-of-use restrictions?

Bob Lee: "Sun puts field-of_use restrictions in the JSE license which inhibit from using the JSE [ on mobile devices ], and "not to mention Android (because that's water under the bridge at this point)."

Bob Lee: There was no TCK available for using on Apache Harmony on Android.

Oracle: "These restrictions prevent Apache Harmony from implementing the JSE [on mobile devices]?

Bob Lee: Yes.

Oracle: Ref TX281- email from you to Hiroshi Lockymer [ sp? ] [ entered into evidence with no objection ]

Judge Alsup: How much longer will you be questioning this witness?

Oracle: About 10 minutes.

Oracle: You worked with Hiroshi Lockymer from 2006?

Bob Lee: Yes.

Oracle: When he became director of Android?

Bob Lee: Yes.

Oracle, quoting from TX281: [ Do you see the part where ] Lockymer says, "I am a little nervous about signing up Noser for further work from a business perspective; those guys (the managers) are pretty shaky."

Bob Lee: Yes.

Oracle: The comments were created in a clean room?

Bob Lee: No.

Oracle: What instructions were given in writing the documentation?

Bob Lee: To paraphrase, in their own words.

Oracle: [Compares taking someone else's work and changing a few words here and there to actually writing in one's own words.]

Google: Objection… notice. The documents were not provided to us with adequate notice. They were provided late last night in two large submissions.

[The witness is dismissed.]

Judge Alsup: What's the issue?

Google: Last night at 10 PM, Oracle identified two very large files of identifying experts and exhibits to use with 3rd party exhibits.

Oracle: Mr. Lee, as the core library lead is...

Judge Alsup: We are going to postpone this witness.

[To Google]: I am not going to tell the plaintiff that they cannot ever bring this up.

[To Oracle]: Have you followed my rules in your handling of the 3rd party exhibits?

Oracle: No, your Honor.

[Oracle has violated Judge Alsup's rules again and has to agree to let the subpoenaed witness step down, to be recalled on Monday, after Google gets a chance to go over the exhibits that Oracle has provided. Oracle has to also provide to Google the exact pieces of the exhibits that they will be using with each witness so that Google can prepare their case adequately. The witness will be recalled for Monday at 7:30AM. This judge is not going to allow a trial-by-ambush.]

Google: Question [to Judge Alsup] About the 3rd party nature of this witness, regarding whether he will actually be available on Monday morning.

Judge Alsup: Do I need to order him to be here?

[Not clear what decision is reached, if any, as to how this will work, but in the end it appears that Mr. Lee will be back on Monday morning.]

9:35AM, Judge Alsup calls a break.

[During the break, the lawyer for Oracle who appeared to be looking at a computer display at the Google table before today's proceedings started is talking with Mr. Jacobs. Mr. Jacobs' smile is still there, but still tight.]

[More smiles at the Oracle table now. Less so for Google.]

10:00 AM.

Witness Dan Morrill

Judge Alsup: Welcome, sir. You okay? [nods]

Oracle (Mr. Norton): You have been with Google since 2006?

Dan Morrill: Yes.

Oracle: Joined the Android team in 2009?

Dan Morrill: Yes, formally. I was working with the Android team informally prior to 2009.

Oracle: And prior to 2007?

Dan Morrill: I was on the Developer Relations team.

Oracle: You became the Technical Program Manager for Android?

Dan Morrill: Yes.

Oracle: What were your primary responsibilities [as Technical Program Manager] ?

Oracle: The Compatibility Definition Document?

Dan Morrill: Yes.

Oracle: Making sure that compatible Android devices can run third party software?

Dan Morrill: I'd say that I defined the criteria under which 3rd party apps would run.

Oracle: Google released the Nexus smartphone, right?

Dan Morrill: That was a co-branding. Google didn't actually make the device. [ some q/a missed ]

Oracle: Familiar with Java class libraries?

Dan Morrill: Yes.

Oracle: You use them [ Java class libraries ], right?

Dan Morrill: Not currently. It has been a while since I have written Java code.

Oracle: Refers to TX 5 [ ? ] This is an API packages listing?

Dan Morrill: Yes, for Android v2.1.

Oracle: On page 4, do you see java.cwp.font, and more packages beginning with java and javax on pages, 5, 6?

Dan Morrill: Yes.

Oracle: All those packages must be implemented on Android devices?

Dan Morrill: Yes.

Oracle: Android ships with implementations of all of these classes using these same names, the same as the Java API?

Dan Morrill: Yes.

Oracle: Not only does the Android API use the same names, it also uses the same form and organization as Java?

Dan Morrill: Yes.

Oracle: (Plays video deposition of Dan Morrill, page 57, lines 1-9, July 12, 2011)

Google: Objection. Mr. Morrill is not an executive or [director ?] at Google.

Oracle: 801 exception.

Judge Alsup: Let me be clear [to the jury , when we say "party admission" under rule 32, there is also an exemption to the hearsay rule. When something comes in as a party admission, it isn't written in stone. It's just a part of the evidence. There is no extra or conclusive value to it. No extra weight is to be given to it [compared to] something that has come into evidence [ via another route ].

Oracle: What you do in your job is to make sure that Android devices are compatible with Android.

Dan Morrill: That seems to be insufficient criteria for what I do.

Oracle: In your own words, then?

Dan Morrill: : [ missed ]

Oracle: A Java app cannot run on Android?

Dan Morrill: Correct, they cannot.

Oracle: Google produces an Android compatibility document that includes binding requirements [ for manufacturers ]?

Dan Morrill: Yes.

Oracle: [Tried to elicit information on how Google keeps OEM's in-line and not changing Android and breaking compatibility.]

Oracle: "Device implementation must not change the APIs for device management, [ missed ], must satisfy requirements in section 3.1?

Dan Morrill: Yes.

Oracle: Page 8, section 3.6, "To ensure 3rd party apps compatibility, device OEM's MUST NOT [ caps emphasized as being in the document ] change package namespaces, including java and javax, and must not change exposed public APIs". Is this correct?

Dan Morrill: Correct.

Oracle: Google has these requirements and [in ?] a compatibility test suite (CTS)?

Dan Morrill: Not all these requirements are testable.

Oracle: Tests for presence of the listed APIs?

Dan Morrill: Yes.

Oracle: Google has something called the "Android Market". What is that?

Dan Morrill: Android Market is a [missed, but to the effect of a program under Google whereby special placement privileges are granted to OEM's whose devices are compatible, or some such.]

Oracle: So in order to request access to the Android Market, a phone must be compatible with Android?

Dan Morrill: We do not have a certification program, but the devices must be compatible.

Oracle: Google prevents incompatible Android phones from accessing the Android Market?

Dan Morrill: I don't know. I am not sure.

Oracle: Motorola makes compatible smartphones?

Dan Morrill: Yes.

Oracle: Samsung?

Dan Morrill: Yes.

Oracle: HTC?

Dan Morrill: Yes.

Oracle: All of these have the Androidd brand?

Dan Morrill: Yes.

Oracle: What is the current number of Android device activations?

Dan Morrill: About 750,000 per day, last time I checked, which was several months ago.

Oracle: Each one has Java APIs?

Dan Morrill: Implementations of those APIs, yes.

Cross-examination of Dan Morrill by Google's Michael Kwan
Google: [Gets introductory information in front of the jury.]

Dan Morrill: BA in physics and CS from Clarkson, MSCS from RPI. Learned to program Java in 1998, self-taught, using online tutorials.

Google: These tutorials included the use of the APIs?

Dan Morrill: Yes.

Google: How long were you a Java programmer?

Dan Morrill: For 12 years.

Google: In that time, did you ever write a Java program that did NOT use the Java APIs?

Dan Morrill: No.

[On to Compatibility Definition Document (CDD)]

Google: Anyone can use the Android code. Why make it comply [ to the CDD ]?

Dan Morrill: To ensure a thriving ecosystem [in which to write and sell apps].

Google: Are there any [major] examples of non-compatible devices?

Dan Morrill: Yes. Amazon Nook and Kindle Fire.

Google: You said that Google doesn't have a certification program. What did you mean?

Dan Morrill: OEM's can make and get phones certified.

Google: Is there any way to determine by running the CTS that OEM's haven't changed the Android code?

Dan Morrill: No.

Google: You said that *you* could tell if they've change the code?

Dan Morrill: If the display looks visibly different, I know the OEM changed the Android code. New hardware (CPU's) can require changes to Android.

Google: Are Android apps written in Java?

Dan Morrill: Yes.

Google: When you said that Android doesn't support Java apps, what did you mean?

Dan Morrill: The Android VM is different than the JVM.

Google: What kind of programming language is used to write Android apps?

Dan Morrill: Java.

Google: Ref TX2301- Do you recognize this?

Dan Morrill: Yes, it's a web page of source code from the Google web site.

Google: (Goes to page 4 and reads title, "Compatibility". What does 'Compatible' Mean?")

Google: Page 5, "Compatibility: Math [ package ] mandatory"

[An explication of what is implied by compatibility ensues.]

Google: How long have you worked on Android?

Dan Morrill: Informally since 2007, formally since 2009.

Google: When was Android announced?

Dan Morrill: [ answered ]

Google: Do you recall reading anything from Sun [ at the time of the Android release ]?

Dan Morrill: Yeah. In fact there was a blog post from their CEO that we thought was pretty remarkable.

Google: You read this in 200? [ year of Android release ]?

Dan Morrill: Yes.

Google: Ref TX2352, the blog post.

Oracle: Objection, 403 and 410(2) [ not sure of 410(2) number ]

Judge Alsup: Overruled.

Google: Who was the author of the blog post?

Dan Morrill: Sun CEO, Jonathan Schwartz.

Google: Please read the first paragraph.

Dan Morrill: [ reads aloud ]

Google: Please read the 4th paragraph.

Dan Morrill: [ reads aloud ]

Google: You said that it was remarkable. Why?

Dan Morrill: I knew of discussions with Sun. The NetBeans [ development environment ] was particularly interesting.

Google: [Tried to get in some things that Oracle objects to… 403.]

[ sidebar ]

[ side note: Mr. Boies is not here today ]

[ sidebar ends. It's 10:45 ]

Google: Referring to the blog post, did you discuss this with other members of the Android team?

Dan Morrill: Yes.

Redirect of Dan Morrill
Oracle: There are approximately 750,000 Android devices activated each day?

Dan Morrill: Yes.

Oracle: That figure doesn't include non-compliant devices like the Kindle Fire?

Dan Morrill: Correct.

Oracle: [Asks a question. Google objects. Judge Alsup asks the witness if he knows the answer to the question, and Dan Morrill says no.]

Judge Alsup: Objection sustained.

Oracle: ref TX2352, is this a license agreement?

Google: Objection, argumentative.

Judge Alsup to Oracle: Arguments are for closing. This is not an argument. Sustained.

Oracle: [Pounces on TX2352.]

Oracle: On May 23, 2008, you were a Google employee?

Dan Morrill: Yes.

Oracle: Working on Android?

Dan Morrill: Yes.

Oracle: ref TX245-- an email that you sent?

Dan Morrill: Yes, the block at the top of the email, in reply to the others.

Oracle: Turn to page 2- a news article that appeared on CNET, May 22, 2006.

Dan Morrill: Yes, that's what it says.

Oracle: On page 4, this is an article about Android?

Dan Morrill: Yes.

Oracle: [Regarding the section about licensing issues, where the article expresses an opinion about Sun expressing concern about Dalvek fragmenting Java.]

Oracle: You forwarded the entire article "to the entire Android PR Group"?

Dan Morrill: Yes.

Oracle: Ref TX2352, dated 5 November 2007, on that day, Google had written most of the Android platform?

Dan Morrill: Not sure.

Oracle: The release of the Android SDK was a week later, right?

Dan Morrill: Yes.

Oracle: The Schwartz blog post was written before the Android SDK was released?

Dan Morrill: Yes.

Oracle: Mr. Kwan showed you an email from 2007, TX 245.

Dan Morrill: "Somebody said that Sun had expressed concern" [ somebody told the the author of the CNET article that Sun was concerned ]. "Sun didn't tell me that they had concerns".

ReCross of Dan Morrill
Google: Ref TX254, what were you forused on?

Dan Morrill: The explicit lines of code [that were claimed to infringe] in the source tree.

Google: On May 23, 2008, what concerns, if any, did you have about Sun's concern about fragmenting Java?

Dan Morrill: None.

Re-redirect of Dan Morrill
Oracle: On page one of TX254, Mr. Rubin got this email?

Dan Morrill: Yes.

Oracle: Mr. Rubin says in the email thread that Dan Morrill was misquoted in the article?

Dan Morrill: Yes.

Oracle: You were quoted in the article on CNET?

Dan Morrill: Yes.

Oracle: You would have read the whole article [ before forwarding it ]?

Google: Objection.

Judge Alsup: Would it have been normal in the course of everyday business for you [Dan Morrill] to have read the whole article before forwarding it?

Dan Morrill: Yes.

Witness dismissed.

Video Deposition

Oracle then played a video deposition of witness Rafael ????. Motorola Mobility Senior Software Director. In the video deposition, the witness has a pronounced accent, he speaks relatively softly, and the microphone is picking up a lot of room echo. In short, it was hard to hear what he said.]

[He has been working on Android since 2009.]

Oracle: What in Android did you work on?

R: Systems software.

Oracle: What did you do to prepare for this deposition?

R: Talked with a Motorola attorney, and [went over materials].

Oracle: Are you familiar with the Android class libraries?

R: Yes.

Oracle: Are the Android class libraries installed on all Android devices ?

R: Yes.

Oracle: What's your understanding of Google's compatibility test (CTS)?

R: You have to meet certain rules so that [Android] apps don't break.

Oracle: Motorola phones pass the Android CTS?

R: Yes.

Oracle: Have there been any failures of Motorola smartphones to pass the Android CTS?

R: Yes.

Oracle: Have all Motorola smartphones provided documentation of APIs per the Google comptibility requirements?

R: Yes.

[ Android version 1.6 specified ]

Oracle: What areas are covered?

R: [ missed item ] Platform API Tests (tests the platform, core libraries, android platform framework). Dalvik VM tests.

Oracle: For Motorola Droid, what version of Android was installed?

R: [ some version specified ]

Oracle: Did you get the Android software from Google?

R: Yes.

Oracle: Did you install it on Motorola smartphones?

R; Yes.

Oracle: Did Motorola make any changes?

R; Yes. We contributed Eclair.

Oracle: Any other changes?

R: No.

Oracle: So the version was entirely the Open Source Software version of Eclair?

R: Yes.

Oracle: All of Motorola's smartphones include all required Android class libraries and APIs?

R: Yes.

Oracle: They include Java and javax APIs?

R: Yes.

End of video deposition playback.

[11:10 -- 15 minute break.]

[11:27 re-convening.]

Oracle: We need to get the video deposition TX number entered into the record.

Judge Alsup: So ordered. It doesn't matter for the jury, just for the court record for appeal.

[ next witness: Leo Cizek ]

Update: Here's more from the day, with witness Leo Cizek on the stand:

Witness Leo Cizek
[The witness is sworn in.]

Oracle: [Introduces witness.] How long have you worked at Oracle?

Leo Cizek: Since 2010, when Oracle bought Sun.

Oracle: How long were you at Sun?

Leo Cizek: Since September 2000.

Oracle: What was your role at Sun?

Leo Cizek: Java Licensing Account Manager.

Oracle: And what is your role at Oracle?

Leo Cizek: Essentially the same.

Oracle: What customers do you work with in your job?

Leo Cizek: Device manufacturers and value-added software companies.

Oracle: Have you ever met Andy Rubin?

Leo Cizek: Yes.

Oracle: When was that?

Leo Cizek: Late fall in 2001.

Oracle: Under what circumstances?

Leo Cizek: Mr. Rubin was the CEO of Danger, Inc. They had implemented Java and needed a license prior to shipping products.

Oracle: [References exhibit TX2016] Who created this document?

Leo Cizek: I did.

Oracle: Why?

Leo Cizek: To summarize my notes over the years.

Oracle: How do you use this document?

Leo Cizek: To remind myself what happened [with various clients].

Google: Objection, relevance and 403b.

Judge Alsup: Overruled. Proceed.

Oracle: When you spoke with Andy Rubin, what was the topic?

Judge Alsup: Needs to be more limited.

Oracle: Why did you call Mr. Rubin in 2001?

Leo Cizek: I called him to tell him that he needed to validate compatibility and also take a Java Commercial License (JCL).

Oracle: Who else [was on the call]?

Leo Cizek: Tim Lindholm.

Oracle: What did Tim Lindholm do?

Leo Cizek: [some answer, missed]

Oracle: What did Danger call their device?

Leo Cizek: HipHop, a.k.a. Sidekick.

Oracle: When was it released?

Leo Cizek: October 2002.

Oracle: Ref TX 2016, bottom of the page…

Oracle: Did Danger have a JCL?

Leo Cizek: No.

Oracle: Had Danger done anything to ensure compatibility?

Leo Cizek: No. They hadn't signed any agreement HipHop?

Leo Cizek: I was disappointed.

Oracle: Did you have any meetings with Danger?

Leo Cizek: Yes.

Oracle: Who was there?

Leo Cizek: Me and Vineet Gupta.

Oracle: And for Danger?

Leo Cizek: Andy Rubin and their in-house counsel.

Oracle: Why did you have the meeting?

Leo Cizek: To let them know that they had to get the TCK and take a JCL. There happened to be a Java CLDC book on the conference table. Vineet Gupta opened it up and showed Andy Rubin and their counsel the copyright notices and the license.

Oracle: Did Danger take a license?

Leo Cizek: Yes, later.

Oracle: At the time that Danger took a license, was Andy Rubin still employed at Danger?

Leo Cizek: Yes.

Google: Objection, hearsay.

Judge Alsup: Overruled.

Oracle: Ref 1026, an internal document of executed Sun Community Source License between Sun and Danger.

Oracle: Move to submit into evidence.

Google: Objection, 403 and relevance.

Judge Alsup: May I see the exhibit? [Reads for a bit.]

Judge Alsup: Possibly counsel is correct. Do not show this exhibit to the jury. It will not yet be entered into evidence. I agree with counsel on 403 objection.

Oracle: To what extent, if any, did the agreement between Sun and Danger address Danger getting access to Sun source code, shown as "original source code" in the agreement?

Leo Cizek: Andy Rubin asked that a section be added to the agreement that stated that Danger had not seen Sun's original code [and did not want access to it]. Section 4, attachment F.

Oracle: To what extent did it address Danger's access to Sun's Java Specification?

Leo Cizek: That's all it granted, given that they didn't want access to it.

Oracle: Ref TX2001, page 2, halfway down, this is an email from Andy Rubin to you?

Leo Cizek: Yes. It was the first email that I had gotten from Andy Rubin since he transitioned to Google on August 4, 2005.

Oracle: Move to submit into evidence.

Judge Alsup: Submitted.

Oracle: Please tell me what it said?

Leo Cizek: It was to me, Tim Lindholm, and Vineet Gupta, and it referenced an internal Google license meeting about the Sun Java Technology for the Wireless Industry (JTWI).

Oracle: Did you meet with Mr. Rubin several times to discuss Java licenses?

Leo Cizek: We met 3 times.

Oracle: Who attended [the first meeting]?

Leo Cizek: Me and Vineet Gupta.

Oracle: And for Google?

Leo Cizek: Tim Lindholm and Andy Rubin.

Oracle: What was discussed regarding Android licensing Java?

Leo Cizek: Which of the two JME technologies would be most appropriate.

Oracle: Where was this meeting held?

Leo Cizek: All 3 meetings were held at Google's headquarters.

Oracle: Who attended meeting two?

Leo Cizek: Me and Vineet Gupta.

Oracle: And for Google?

Leo Cizek: Andy Rubin, Brian Swetland, [missed one attendee for Google].

Oracle: What was discussed?

Leo Cizek: Further discussions of Open Source licensing, regarding whether Sun would [ missed ], and did Google need a JCL.

Oracle: And the third meeting, in December 2005, who attended that?

Leo Cizek: For Sun: Vineet Gupta, Alan Brenner, and me. For Google: Andy Rubin, Brian Swetland, and Borenstein.

Oracle: Why was Brenner there?

Leo Cizek: He led a large part of the discussion regarding [trying to] convince Andy Rubin to 1) use Sun's technology (CDC), and 2) not use Open Source for licensing.

[Missed some, IIRC about royalties aspect of taking a JCL.]

Leo Cizek: The commercial use license specifies royalties.

Oracle: After 2005, were there any further discussions?

Leo Cizek: Yes, in 2009.

Oracle: Who was the Google employee [that initiated the discussion]?

Leo Cizek: Mark Bucholtz.

Oracle: Why were you talking with him?

Leo Cizek: He had contacted a colleague of mine about getting a J2SE license to gain access to some security technology. He was seeking a source code license.

Leo Cizek: [I called him and indicated that] a part would have to be fixed first: the Java license for Android.

Oracle: What did Mr. Bucholtz say?

Leo Cizek: That Google didn't need a license because they'd implemented [Java, or the class libraries] themselves, and that Android was using the Open Source Java specification.

Cross-examination of Leo Cizek, by Christa Anderson for Google
Google: During all your years at Sun and at Oracle, you have been an account manager for licensing?

Leo Cizek: Yes.

Google: For JME and JSE licenses?

Leo Cizek: Yes.

Google: And the JME is for smaller devices?

Leo Cizek: Yes there are 2 configurations of it [the CDC and the CDLC].

Google: One targets feature phones (CDC) and one targets smartphones?

Google: You never had a customer who manufactured smartphones?

[Missed some.]

Leo Cizek: Danger made smartphones.

Google: References video deposition playback [didn't get reference to page or line numbers]

[Playback starts.]

Google: What was the path for promoting the JavaFX platform?

Leo Cizek: Desktop and mobile devices. Virtually every phone that ships on Java is shipping the JME now. "This is a description for the herd…"

Google: TX2001-- email exchange with Vinoy Gupta: This describes Andy Rubin asking to set up a meeting?

Leo Cizek: Yes.

Google: It's an internal response-- Jonathan Schwartz and [ ? missed ] were in discussions about a broader license agreement with Google, regarding a toolbar?

Leo Cizek: Yes.

Google references TX2013, a presentation received from an email from Google. Move to place into evidence.

Judge Alsup: [No objection? None. Accepted.]

Google: This is a "Monetization Proposal" where "Google is seeking partnerships with major manufacturers… and to Open Source their software", right?

Leo Cizek: Yes.

Google: References TX2002 [not sure if this number is correct] -- an email exchange with Mr. Gupta: In this email, Mr. Gupta said that he wanted to change the plan that Andy Rubin had to open source their software. "I want to change this to *my* idea, to have Google ship their apps on J2ME." [Correct]?

Leo Cizek: Yes.

Google: Regarding the three meetings, you don't remember much [about the details], do you?

[No response.]

Google: Isn't it true thet] Andy Rubin said that Google had not yet made a decision regarding which technology to use?

Leo Cizek: Yes. Either CDC or CDLC.

Google: Plus other options?

Leo Cizek: Not mentioned to me.

Google: References TX2004, an internal Sun email that lays out action items after the second meeting.

Google: [Gets 3 items shown to jury]:

1) open source licensing model
2) CLDC-High applicability (vs. G internal implementation)
3) [ missed ]
Google: References TX2006 email including recipients Leo Cizek, Andy Rubin, Vineet Gupta, Ms. Garcia, Cole.

Google: Shows the following:

1st meeting is to talk about the OS
2nd meeting is to talk with Google about the benefits of CDLC
Google: ref. TX2008, a contact report prepared by Leo Cizek at Oracle.

Google: This report relates specifically to Google?

Leo Cizek: Yes.

Google: To Andy Rubin and Android?

Leo Cizek: Yes.

Is there a notation by date?

Leo Cizek: Yes.

Google: 5-25-2006 entry regarding Google communication about Android, would you read that?

Leo Cizek: "After many meetings, including Andy Brenner, we are unable to have a meeting of minds over CLDC-HI"

Google: ref TX2009, an email dated March 2007, Leo Cizek to Gupta.

Google: The email is several pages, based on an article about Google's intent to build a mobile phone, correct?

Leo Cizek: Yes.

Google: You had a discussion with Mr. Gupta about this?

Leo Cizek: Yes.

Google: You wanted to call Google and talk with them, yes?

Leo Cizek: Yes.

Google: And Mr. Gupta asked you to hold off?

Leo Cizek: Yes.

Google: He said that waiting will lead to a larger S&I interest?

Leo Cizek: Yes.

Google: And you followed Mr. Gupta's instructions?

Leo Cizek: Yes.

Google: ref TX2010, an email exchange amongst M. Purcey, Leo Cizek and Mr. Gupta, dated April 2, 2007, a continuation of TX2009.

Google: In this email you followed up with Mr. Gupta, asking if he could contact Google?

Leo Cizek: Yes.

Google: And Mr. Gupta told you to continue waiting?

Leo Cizek: Yes.

Google: You said that you'd hoped to discuss with Andy Rubin about the advantage of going with a Sun Commercial License (JCL), versus going the Open Source software route?

Leo Cizek: Yes.

Google: He was waiting for a "green light" from Rich Green?

Leo Cizek: Yes.

Google: You negotiated with Google the Sun StarOffice deal?

Leo Cizek: Yes.

Google: In fact the biggest deal that you'd ever negotiated with Google over the Google toolbar?

Leo Cizek: Yes.

Google: [What was the nature of that deal from the user's perspective?]

Leo Cizek: When customers downloaded a free version of Java, they'd also get the Google toolbar.

Google: Ref TX2019-- email to M. Lehrbaum [ sp? ], former employee of Sun/Oracle in the PSG Marketing group, from Leo Cizek, in 2009.

Google: At the same time that you were [IIRC, marketing JME to Google], you were marketing other products as well?

Leo Cizek: Yes.

Google: You sent this email because of the upcoming conference call with Google?

Leo Cizek: Yes.

Google: You were seeking to generate revenues for Sun that had nothing to do with JME?

Leo Cizek: Yes.

Google: Ref TX2021, email to Leo Cizek [incl. M. Sandman, Tom Harris ( a Sales Engineer for Sun in the Java Sales Engineering group) ], dated November 2007, regarding APIs.

Google: Page 2 "proposes some ideas that may work."

[ missed the specifics ]

Google: You were the account representative for Google?

Leo Cizek: Yes.

Google: But you represented Sun for other product licensing than JME?

Leo Cizek: Yes.

Google: ref TX2026, an email [ from? ] M. Lehrbaum, in May 2008.

Google: Mr. Lehrbaum says, "G's Android is a potentially dangerous competitor"?

Leo Cizek: Yes.

Google: Each of these conversations [from the TX's that have been entered into evidence] were amongst business people, not lawyers?

Leo Cizek: Correct.

Google: And there were no discussions of copyrights?

Leo Cizek: No.

Redirect of Witness Leo Cizek
Oracle: Back in 2005, in TX2004, paragraph 3, Vineet Gupta's email…

Leo Cizek: I dropped some of the action items.

Oracle ref TX2021- do you see the reference to "open social APIs"?

Leo Cizek: Yes.

Oracle: Do you understand that that had anything to do with Android?

Leo Cizek: It was totally unrelated.

Oracle: Regarding the "Ideas that may work", [ specifically ] "(once we understand the Android distribution (the SDK)…"

Google: Objection.

[Back and forth with Judge Alsup.]

Judge Alsup: Objection sustained.

Oracle: Did you ever tell Mr. Rubin that he could do an independent implementation and *not* get a JCL?

Leo Cizek: No.

Oracle: No further questions, your Honor.

The witness steps down.

Judge Alsup to the jury: I am going to give you a few minutes off.

Reminds jury not to do any research on the case, companies, or lawyers, plus no news, no talking with loved ones about the case.

Jury dismissed 12:43PM.

Judge Alsup: Summary of times used [in minutes]:
Oracle: 560 Google: 329

Judge Alsup: A total of 17 hours was allocated to each side. I don't have a fancy computer, all I have is this [ holds up a single piece of paper with columns visible and a yellow PostIt note sticking to it]. So if you think my numbers are off, by all means, please let me know.

Judge Alsup: [Admonishes Oracle to save some time for their cross-examinations.] Judge Alsup: "I question what that last witness added to this case."

Judge Alsup: "There will be no extensions."

Update 2:

And here's the final part of the day, after the jury has left for the day and the week-end, and the parties' lawyers are discussing issues with the judge:

Oracle v. Google, Day 5, part 6, (final)

[Jury has been dismissed.]

Judge Alsup: I have a question for both parties. I am confused about things… [it has been said that]

1) The source code was built in a cleanroom
2) It was built by Apache
Judge Alsup: Which one is it?

Google: Either. [Part of it was] was written from scratch and [part of it came] from Open Source (Apache).

Judge Alsup: Has anyone vetted that Apache (Harmony) was independently implemented?

Google: Yes, except for the 12 files.

Judge Alsup: Is this true in terms of direct copying, excluding the 37 packages and the SSO?

Oracle: What we have accused of copying and is in the list that you have. In addition, the documentation will be shown to have been substantially copied. Further, we will show that they (Google) really didn't implement a cleanroom in their choice of the people they chose to put in the cleanroom.

Judge Alsup: What about the cleanroom?

Judge Alsup: What if Apache did wrong?

Judge Alsup: What good does it do to have a cleanroom?

Google: Apache (Harmony) has been shown to be a completely independent implementation. The source code was copied by neither Google nor Apache.

Google: Google licensed the Apache code under the Apache License.

Google: Sun knew that Apache (Harmony) was (freely) distributed for 7 years [and did nothing to stop it].

Google: "The issues over APIs is just something that Oracle has made up after the fact."

Judge Alsup: I am understanding that there is a cloud over Apache (Harmony). What is the nature of that (cloud)?

Google: The fight was over Apache wanting to say that Harmony is Java. They wanted that right. Sun didn't want to give Apache that. (It's the) same with Android. "If you don't want to call it Java, fine." Everyone knew who was using what APIs.

Google: "The copyright claim is a little crazy."

Google: "None of the engineers talked about that" [an API copyright].

Google: "None of the business people ever talked about that."

Judge Alsup: That's what you argue. Even if you are right… will let the decision on SSO go to the jury. [Not clear to me that Judge Alsup has made a decision on this or is just mulling it out loud.]

Judge Alsup: What is the comparison made against?

Judge Alsup: What is the copyrighted work?

Oracle: There was a cloud over Apache (Harmony). Google did step into their (Apache's) shoes [when they chose to license Apache Harmony].

Judge Alsup: Was the cloud the 37 API's, or was it the trademarked name [Java]?

Oracle: Very much the former. "We recognize that the specifications are copyrighted."

Oracle: Mr. Rubin said that he knew the APIs are copyrighted.

Judge Alsup: Was the fight that you cannot use Sun's source or Sun's API definitions?

Oracle: The second. "Enter Oracle, exercising more energetic leadership."

Google: Oracle is trying to shut down the JCP. Now that they are the owner, they are trying to shut down the Open Source.

Google: Our main point about Apache is that it gives us [ missed ]

Google: Once it was clear to Sun that Google was going OSS, Sun moved on and tried to sell Google other things.

Judge Alsup: About next week, who is your [Oracle's] last witness?

Oracle: Dr. Mitchell.

Judge Alsup: How much time will you need for him?

Oracle: about 1.5 hours.

Judge Alsup to Google: [Similar inquiry regarding time usage.]

Judge Alsup: [Reminded by Google counsel] We will start with Bob Lee on Monday morning.

Judge Alsup: Some final thoughts: About 2/3 of the case could be stipulated with 1/3 in controversy on the copyright part.

Judge Alsup: Think of ways to help the jury understand specifically what is controverted."

Judge Alsup: "It is one kettle of fish to say you need a license to use their source code; it's another when you say you need a license regardless of whether you've done an independent implementation".

Judge Alsup: "Go home, or back to their hotel rooms and have a double." [Hilarity ensues… the double becomes a double of single malt scotch, and someone suggested that it would be nice if the Judge *ordered* them to do his... and as the good judge stepped through the door to his chambers, he said, "so ordered".]

End of day 5. Bob Lee will be recalled to the stand on Monday.

[One of Google's main points today was that Sun/Oracle was trying to force Google to buy something that Google clearly did not want or believe that they needed. It seems clear to me that Oracle is going to spend a lot of effort trying to prove that Google extensively copied their documentation; that's about all they seem to have a chance at, at this point.]

Update 5: All the trial exhibits are now available as PDFs here. Some are also done as text. Look for the date nearest the day, as they are listed by the date they were entered, which could be a day or so after the date of their use in the courtroom.


Day 5 - Oracle v. Google Trial ~pj - Updated 5Xs (Lee, Swetland, Morrill, Cizek) | 237 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Day 5 - Oracle v. Google Trial ~pj
Authored by: Anonymous on Saturday, April 21 2012 @ 02:34 AM EDT
I like to think about APIS as the way a programmer can make a software to do
something without knowing how to do it.

A person asks a waiter to bring him some wine, the waiter needs more information
about what the person really wants so he needs to know things like: what kind of
wine does he wants or the color and the amount of wine he wants, once with that
information the waiter goes to another room where the customer can't see and
later the waiter brings the wine in the same way the customer asked.

The API is the set of words that made a conversation between the customer and
the waiter that made the waiter to do something that the customer asked. And the
implementation is what the waiter did once the customer asked him to bring

API = Set of words used by someone to make a program to do something.
Implementation = Set of code that makes a program to do something.

I thought that the reason why Microsoft virtual machine was not accepted by SUN
was because it was marketed as "JAVA compatible" using the JAVA-logo
but they implemented things that were not portable over other machines to make
it faster plus added more functions that didn't existed in the JMV and enforced
deprecation of JAVA functions, so a program made using the MS-VM could not run
on SUN's JAVA Virtual machines.

[ Reply to This | # ]

Authored by: Kilz on Saturday, April 21 2012 @ 02:46 AM EDT
Please mention the mistake in the title of your post.

[ Reply to This | # ]

Off Topic
Authored by: Kilz on Saturday, April 21 2012 @ 02:47 AM EDT
For all posts that are not on topic.

[ Reply to This | # ]

Authored by: Kilz on Saturday, April 21 2012 @ 02:48 AM EDT
Please mention the news story's name in the title of the top

[ Reply to This | # ]

Authored by: Kilz on Saturday, April 21 2012 @ 02:50 AM EDT
Please post transcriptions of Comes exhibits here for PJ to
find. Please post them as HTML with the post mode of Plain

[ Reply to This | # ]

Day 5 - Oracle v. Google Trial ~pj: Books
Authored by: tom_markus on Saturday, April 21 2012 @ 02:50 AM EDT
Well there is a book analogy too. A publisher creates
a series of science books (37) covering all college subject matter. Google then
scans and publishes the table of contents of each book. Say one page per book.

In the planning of a book the global organization is the most difficult and
important part of the subject. It would be easy to then take this set of
outlines and use them as the basis of a new series. Is this legal?

Indeed friends who write books tell me you submit the table of contents plus a
few pages as the initial project to a publisher. It is clearly highly skilled
and crucial in the success of the whole project.

[ Reply to This | # ]

The menu bar is a great analogy
Authored by: jbb on Saturday, April 21 2012 @ 03:23 AM EDT
The reason a menu bar is a great analogy is because in Lotus v. Borland Borland copied the menu structure from Lotus-1-2-3. They said the reason they copied it was because the menu structure was also used to implement user programmed macros and only by implementing the menu structure could Borland make their spreadsheet program compatible with the user macros written for Lotus-1-2-3.

As far as Oracle v. Google is concerned, the key thing is that Oracle (Jacobs I believe) admitted that the Lotus v. Borland decision said APIs were not copyrightable! The macro programming language (which was identical to the menu structure) was considered by Oracle to be an API. That case was decided in 1995. The Supreme court took it up but was deadlocked in 1996 so the lower court ruling prevailed without getting a seal of approval from the Supreme court.

Oracle told Judge Alsup that they believe the case law has changed since 1996 and APIs are now copyrightable. I have seen no evidence for this extraordinary claim. I know Oracle wrote at length about Lotus v. Borland. They said the ruling was wrong and also said that it did not apply to this case. Why would they waste valuable time and space with those arguments if, as they claim, there is new case law that supports their position and supersedes Lotus v. Borland?

Days (weeks?) after making that extraordinary claim, Oracle backed off a little and admitted that they were actually asking this judge to make the new [case] law they had said already existed. I realize officers of the court are not held to the same standards of logic and sensibility required of most other human beings, but it seems rather outrageous that Oracle can base almost their entire copyright case on the unsubstantiated claim that there was a 180 degree change in the case law since 1996 without one shred of evidence for this extraordinary event. Even worse, it seems Oracle had to back off from that untenable position and (tacitly) admit to this judge that they were fibbing before about the 180 degree about-face in case law and they were now asking Judge Alsup to make the 180 degree about-face all by his lonesome with absolutely no supporting precedents.

Why are we wasting all this time in front of the jury on the copyright issue when Oracle already admitted APIs were not copyrightable in 1996 and then tacitly admitted they had fibbed about there being subsequent case law that reversed Lotus v. Borland? How can arguing the facts of this case in front of a jury help convince Judge Alsup to make new case law to suit Oracle's current whims and fancies?

Our job is to remind ourselves that there are more contexts than the one we’re in now — the one that we think is reality.
-- Alan Kay

[ Reply to This | # ]

[what is being infringed] With the copyright side, it's strange.
Authored by: SilverWave on Saturday, April 21 2012 @ 03:24 AM EDT
I find it strange that on the patent side it is really clear what is being infringed. With the copyright side, it's strange.

Dead in the water. Oracle is.


RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | # ]

Car Analogy
Authored by: brong on Saturday, April 21 2012 @ 03:26 AM EDT
Since everyone loves a good car analogy.

API is like the layout of the drivers' area in a car. The location and function
of the pedals, the direction you turn the steering wheel and the action that

You can get an electric car, or a diesel car. You can have a giant truck, or
even a little go-cart where the pedals aren't the same (Java SE anyone? - low
powered devices) but the steering wheel still works mostly the same. It's a cut
down implementation of the same API without all the features.

On some of the fancier new cars, the steering wheel might make all 4 wheels turn
rather than just the front two. That's an implementation detail too. The API
contract is "turn this wheel, the car turns in that direction"

[ Reply to This | # ]

  • Car Analogy - Authored by: Doghouse on Saturday, April 21 2012 @ 05:04 AM EDT
  • Car Analogy - Authored by: Anonymous on Saturday, April 21 2012 @ 09:20 AM EDT
    • Car Analogy - Authored by: Anonymous on Saturday, April 21 2012 @ 11:01 AM EDT
    • Car Analogy - Authored by: eachus on Saturday, April 21 2012 @ 11:18 PM EDT
Calculator analogy - API
Authored by: SilverWave on Saturday, April 21 2012 @ 03:36 AM EDT
If I want the calculator to add 42 and 42 I need to follow the rules.

I need to input the first number then hit the "+" then the next number
and then the "=" key.

There are different rules if you want to divide or multiply and in complex
calculations order matters.

I could change the "+" and rename it to "#" or even
"-" but that would cause confusion.

The implementation that processes these key strokes is going to be very similar
no matter who does it.

RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | # ]

What's important in an API
Authored by: Ian Al on Saturday, April 21 2012 @ 03:37 AM EDT
Mark Reinhold: [From the point of view of the computer], very little API organization is required by the VM. We could have given them completely random names and put them into one huge package. The design goal was that API's should be easy to learn and easy to use. Other considerations:

1) performance is important

2) Portability is important [wouldn't want to define an API that is specific to Windows].

Oracle: When you launch the API design process, what do you do?

Mark Reinhold: Collect use cases, define the problem/solution space, general requirements. Important to get quick to a high-level summary [ of the design ] to share with others. Sketching, writing code snippets. Then you start writing code for the methods. It's important to work on the implementation at the same time as the API specification to find bugs in the specification.

Oracle: How long does it take to design a package?

Mark Reinhold: 2 years, working half-time on it, with additional experts and engineers working on it simultaneously.
So putting them in packages and giving them names which are seen as easy and logical by the users of the functionality defined in the Specification are important. We know that Judge Alsup has declared the names and short phrases unprotectable by copyright. If ease of use of the functionality is that the functional ideas are well devised, then he found that the functionality is not protectable, either. That is even if the devising of that functionality is very creative, skilful and difficult.

A specification does not have a performance. The implementation of the ideas expressed in the specification will have a performance. Ideas in a document are not protected by copyright.

The Specification works for the Windows operating system. What in the Specification makes it portable to other platforms? Is it copyrightable, or is it more about the functionality and the units chosen in the definition?

Google do not provide copies of the Java API Specification to Android developers. They have to get a copy from Oracle. The SSO is not perceivable by the programmer in the byte code compiled class libraries. 'Mark Reinhold: [From the point of view of the computer], very little API organization is required by the VM. We could have given them completely random names and put them into one huge package.' It is only available by reading the Oracle Java API Specification.

Harmony would have used the SSO of the Specification during their clean-room implementation. Where is the copy of the medium they saw that had the SSO fixated in it?

It is not the Oracle website, because the Specification cannot be downloaded from there. Harmony would not have copied each html document by clicking on all the hyperlinks. Anyway, that website was only made available as part of the opening of the Java language and that happened after Harmony created their implementation. They must have been freely given a complete copy by Sun with the understanding that the Harmony would use the SSO to implement the API Specification. Where is that accused copyright document amongst the evidence? That is the one that has the protectable creative expression, including the SSO, fixated in it. Where is the copyright notice and special licence terms offered to Harmony from Sun, at the time?

Google concede that by copying the Harmony compiled bytecode class libraries that they copied the SSO used by Harmony to create them. However, Google cannot perceive or read the SSO from the Harmony libraries. The SSO is not fixated in the libraries. It is only the derivation of the libraries from the SSO fixated in the original Specification document medium that is the SSO copying done by Google.

Again, it is vital to Oracle's case that the document that had the protected creative expression fixated in it and that was given by Sun to Harmony and the licence conditions expressed or implied are entered into evidence. Otherwise, it is not possible to determine whether the SSO copied by Google was protectable SSO under the law.

Ian Al
Software Patents: It's the disclosed functions in the patent, stupid!

[ Reply to This | # ]

Copied documentation?
Authored by: Anonymous on Saturday, April 21 2012 @ 03:50 AM EDT
It seems clear to me that Oracle is going to spend a lot of effort trying to prove that Google extensively copied their documentation; that's about all they seem to have a chance at, at this point.
This could get interesting, since a lot of the documentation is generated from the structure of the code, and the previous API comparison examples showed the short English language descriptions as being different to the Oracle ones. I wonder if some of the more detailed online docs and code examples are too similar? could be worth looking into. Even if Oracle could get a win on this issue, it seems like it would be trivial for Google to fix it, by either removing the docs for the 37 APIs and referring developers to the Oracle docs, or by rewriting a few bits. I'd guess a win here would be very much a consolation prize.

[ Reply to This | # ]

Killer - Here is the key evidence that is *not* in dispute:
Authored by: SilverWave on Saturday, April 21 2012 @ 03:58 AM EDT
Here is the key evidence that is *not* in dispute: Use of the Java programming language; using the names of class files and methods; the source code in the libraries, comprised of original Google works and Apache Harmony. So what we are down to? -- the Sequence, Structure and Organization, the SSO, which is in the public domain. Apache Harmony and GNU used them and Sun did nothing. Then Google did what they did. Larry Ellison himself said that "Nobody owns the Java language". The APIs have been used for years as a necessary part of the Java language.

RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | # ]

Michael Jacobs - professional to the end.
Authored by: SilverWave on Saturday, April 21 2012 @ 04:02 AM EDT
It seems that the demeanour at the Google table is more upbeat. There are even
some smiles. At the Oracle table, nobody is smiling, except Michael Jacobs, the
lead attorney from Morrison & Foerster

RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | # ]

Judge Alsup Gets It
Authored by: sproggit on Saturday, April 21 2012 @ 04:04 AM EDT
In the transcript we see the following statement:-
Judge Alsup: "It seems a little hard on the judge that the complaint could say... that we would get all the way to the end of the trial and I have to instruct to the jury as to what the scope of the decision is supposed to be."

The penny has dropped.

There is a good reason that Oracle are not being clear and forthright about this: they are making it as hard as possible for Google to defend against the "killer blow" that they are going to pull out of the bag in front of the jury.

With the patents, it was impossible for Oracle to be evasive. They had to quote the patent numbers, and once they had done this, Google were free to search the USPTO web site for the relevant documentation. For the copyright claims, Oracle are relying on the implied license that is automatically granted when something is produced. Because of this, they have not been required to stipulate exactly, to the letter, where their complaint lies.

For anyone who followed the SCO vs. IBM complaint, this will be eerily familiar.

Sadly, in the case of the Google complaint, Google have not done quite such a thorough job of forcing the point until the Judge can see that BSF/Oracle are dancing.

I can only hope that when BSF/Oracle pull their little stunt that the Court will uphold Google's inevitable complaint as to trial-by-ambush.

[ Reply to This | # ]

A better API analogy
Authored by: Anonymous on Saturday, April 21 2012 @ 04:11 AM EDT
The flight controls are nice as an analogy, but they have the disadvantage that one side is human, and can adapt.

I think a better analogy is socket wiring. Take something like the Europe Card Bus specification. If you create a card adhering to those specifications, you can plug it into a system and get components to interact that have been developed independently. I have picked this example because it shows a number of things:

  • An API does not need to make sense in every respect to be successfully employed: this bus system has been more or less the industry standard for a certain class of computing systems, and the layout of connections is chaotic. I think I remember that it was related to minimizing plane connectors on the original processor card or something like that.
  • You have some obvious components required for the task at hand (like the address A0-A15 and data lines D0-D7 for accessing memory), there are `obvious' extensions (like A16-A19, signals not even available on the processors for which this has been designed), and there is stuff that is unique to the design (like +5VBAT).
There are also specifications of how much current any card must be able to provide on its connectors.

A card obeying this specifications can be used in a number of different computing systems, partly even with different processors.

Now this example was an example for a bus system, and that means that every socket on the system is wired in the same way. The case of computer APIs is more like the old mainframe computers where even the processor was distributed over dozen of cards wired with one another, with connecting sockets having more individual layouts.

Connections running over sockets are more expensive than connections on cards. The analogy for APIs is that passing data across function call boundaries (functions are the basic entities processing data: they have data for input, they have data for output, and they internally have their own temporary variables and data needed for the processing they do) is more expensive than working on internal data.

And even more expensive is passing responsibility: if the other end of the socket is designed by a different department, you need to agree on what kind of information and signals you need to interchange, and how to best transfer them through the socket.

Analyzing and boiling down a system into logical components with a concise and logical number of interconnections is system design. As Oracle correctly states, this is totally crucial to everything.

Like with a hardware bus system that needs to match actual electric and logic characteristics of existing processors close enough to be useful (even though it may be useful for more than one processor family), APIs for libraries and the libraries itself need to be a reasonably good match to the individual programming language's way of working with data.

There are programming languages like Modula and Ada where APIs are essentially split into `interface' and `implementation' parts of declarations, namely declarations that are necessary for talking to a library, and declarations that are necessary for the library to work internally.

This clean distinction at the language level comes at a cost in overall complexity and performance. Languages like C (and also Java) don't really have it. As a result, the computer readable forms of APIs tend to be a mixture of requirements for both interfaces to the library, as well as exposing internal workings or at least the inner structure of a library.

Now the better a job the system designers do creating APIs that reflect the function rather than the internals of a library, the less actually copyrightable content will be connected with it.

You can try patenting some parts of the design, but that is also shaky.

So with API design you have the situation that the best work is the one least likely to be `protectable', at least by copyright. This is hardly surprising since the essence of an API is to enable interaction by providing abstract interfaces to functionality. The better the designer does his job, the better the abstraction will be, and the better the separation between the (copyrightable) implementation at the other end of the API is from the uses of the API.

The worse an API does its job of abstraction, the more it will dictate the choice of algorithms you have to use in order to implement the API's functionality. Part of the fault may lie with the computer language used, part may lie with the designers' capabilities, part may be a tradeoff between efficiency, convenience, complexity, again influenced by the capabilities of language and designer.

The unsavory part of this case is that Oracle tries to invent legal protection for the good parts of API design (those that are created for interoperability _without_ needing to mix copyrightable domains of code) by basing the protection on those aspects of an API where the abstraction falls down, making a `cleanroom design' structurally similar to the original implementation because too many details of the implementation leaked into the API design.

If you call something an API and pass it off as one, capitalizing on those aspects where it actually fails being an API seems in bad taste and a violation of the takers' expectations.

[ Reply to This | # ]

Menu bar anology
Authored by: mschmitz on Saturday, April 21 2012 @ 04:13 AM EDT

the menu bar anology, even though not perfect from a programmer's point of view,
is probably perfect from a legal point of view - it has been used before and has
been decided in a court of law. It's too far-fetched for us programmers but the
judge may be able to relate to that.

As far as trying to understand the technology goes: don't worry. I think you're
doing fine - you ask the right questions, and come up with 'legal' analogies
that a tech person would not think are relevant. We can draw a line in the sand
from what we know makes good technical sense, you help us see where that same
line may be drawn in the legal arena. So far, it doesn't look too bad to me.

-- mschmitz

[ Reply to This | # ]

UI as in menu bar is a great analogy
Authored by: bugstomper on Saturday, April 21 2012 @ 04:25 AM EDT
In a comment to the previous article, BitOBear made the same analogy (although in a more complex discussion so you might not have noticed), and in this comment I agreed with that being a great analogy.

jbb pointed out that the analogy supports applying Lotus v. Borland to this case. I agree. Right now I don't see any significant difference that would make the analogy break down.

[ Reply to This | # ]

Aircraft Analogy
Authored by: AH1 on Saturday, April 21 2012 @ 04:36 AM EDT
Given the fact that I am an aerospace engineer and I work with flight software I would like to correct a misconception related to the flight display analogy. There is an industry convention that dictates the layout of cockpit gauges in "the T arrangement" (Ref Flight Instruments ) this is not a standard, but rather a "best practice." (Other Aerospace folks correct me if I am wrong but I can not find an FAA mandate that specifies this configuration.) What is important here is the layout of the gauges. Aircraft manufacturers do not deviate from this 'convention" because doing so would cause confusion among pilots who have been trained to scan their instrument panels according to "the accepted layout". This "best practice" was adopted by the manufacturers of "Glass Cockpits" as well. In other words, when we removed the analog gauges from in front of the pilots we kept the arrangement of the information the same. This way pilots did not have to change their scan pattern when they moved from an analog to a glass cockpit. (Note: Glass cockpits are software driven, analog cockpits are electrically driven.) The important distinction here is the assumption that you are "automatically certified" to transition from an analog cockpit to a glass cockpit. This is not the case. This being said the API analogy is correct. Given a specific application (computing language) a set of conventions/best practices are identified and documented (API's). These API's have nothing to do with the specific system implementation but rather, implement a "best practice" that users of a given system are used to seeing. This DOES NOT mean that adherence to "an accepted" convention automatically guarantees interoperability without additional work, but rather, that the operator (coder) has an idea of where to go to go and what to do with the information they collect. Now from a software analogy, API's are the convention. The actual implementation is the software. As much as I dislike software copyrights and patents I will argue that the specific cockpit layout & displays are unique. As an example the Boeing 757 and 767 implemented nearly identical cockpits. This way a pilot who received certification on one was automatically certified on the other. (OK aerospace folks don't abuse me for what happened in reality.) So to correct the aircraft analogy. API's are analogous to the cockpit gauge layout. Adherence to that layout (API) does not guarantee interoperability, but it does give you the ability to gather the data you need to interact with the system. So unless Oracle can prove they invented the concept of the API they are going to have a tough time proving that Android/Harmony (API's) violate their IP.... That is until they try an argue that Java, as a language, is their sole IP.

[ Reply to This | # ]

command line
Authored by: xtifr on Saturday, April 21 2012 @ 04:52 AM EDT

How about a command line analogy? If you have a linux system, you have ready access to the command line, and it's even called an interface.

First thing to understand is that in Java, the APIs are grouped together in sets. This is analogous to the way that programs are grouped together in directories. For example, java.math.sqrt() means that the sqrt() API is inside of a math group, which is inside of the java group.

At your command-line, you can type /bin/ls, which means that the ls command is inside of the bin group (directory). Another command, man, can be typed as /usr/bin/man. In this case, the bin group is not the same as the previous bin group. It's a subgroup of the usr group. In the case of /usr/games/nethack, the usr group is the same one referred to in /usr/bin/man, but the games group is a new one; a sibling of /usr/bin.

If you're at all familiar with the layout of your linux filesystem, that all should make a certain amount of sense.

Now at this point, you may begin to suspect that the famous "37 APIs" really refers to 37 groups of APIs. That's exactly right! The groups contain things called functions and classes, which are similar to programs--similar enough for this analogy, anyway.

A function is very much like a little program. A class is--well, technically, a class defines a group of functions, called "methods", that are automatically associated with a particular instance of the class--an object. But for the sake of this analogy, let's think of a class as a program that has switches, like the "-l" switch to the /bin/ls command. The switch is--very loosely--like a method of the /bin/ls program.

Now, even if that left you a little confused, don't worry. Here's the important bit. On any Unix-like system, Linux, BSD, Solaris, or even MacOS, you can use the same commands, like /bin/ls or "/bin/ls -l", and get the same results. The names of the commands, and the switches, are like the API. The actual programs that run are very different between, say, Linux and MacOS, but the results you get from those commands, using the command-line interface, are the same. You can write a script--a list of commands--for Linux, and, as long as you stick to standard commands and switches, that script will run exactly the same way on BSD or Solaris or MacOS.

So, yes, an API is just a list of names! The implementation (the part Google didn't copy) is like the programs behind the names. The Linux /bin/ls refers to a completely different program from the MacOS /bin/ls, just like Google's java.math.sqrt() refers to a completely different subroutine than Oracle's java.math.sqrt(). But the interface is the same. And that's what Oracle is complaining about. Google copied a large set of names.

Do not meddle in the affairs of Wizards, for it makes them soggy and hard to light.

[ Reply to This | # ]

A Simple API Analogy
Authored by: TJ on Saturday, April 21 2012 @ 05:15 AM EDT

Let's design a new car.

It'll be built using our new patented ultra-light ultra-strong alloy (patentabsurbium) and have 5 road wheels, 2 steering wheels (for back-seat drivers), a fuel filler in the middle of the roof, a gear-shift in the trunk and pedals under the rear seat.

Cool huh!?

Or how about we design it to the car industry's Vehicle API?

After all, every other Vehicle API implementation has 4 road wheels, just 1 steering wheel, fuel filler on the side or rear for easy access, gear shift close to the driver's hand and pedals under the driver's feet.

We can still build the car using our patentabsurbium alloy.

Now when potential customers consider buying our car they are already familiar with and know how to operate the vehicle because they know the Vehicle API.

Our vehicle is just one of many independent implementations of the Vehicle API. The API itself is simply the description of how we Interface with the implementation.

If the driver chooses they can switch to a different implementation (drive another make of car) but they will still use the same Vehicle API to operate it.

Each manufacturer owns copyright in their vehicle manuals which describe how to use the Vehicle API in their vehicle but they cannot copyright the Vehicle API itself.

If Ford or General Motors were to claim copyright over the Vehicle API itself, rather than their particular implementation of it, we would have to learn a different API for every brand of vehicle we drove.

[ Reply to This | # ]

@pj the light bulb analogy
Authored by: Anonymous on Saturday, April 21 2012 @ 05:42 AM EDT
The simplest analogy I know is the lightbulb

The API is arrangemebnt of the socket

The library is the bulb itself and the controlling code has to interface to the
bulb through the socket.

The lightbulb simply has to provide the correct set og contacts etc to conform
to the api specification, then the bulb and the socket will fit together, and
when the volts are applied light comes out. It is up to the lightbulb how it
manages that .. it could be one of those new LED ones, an energy-efficient
flourescent one, an old tungsten one ... but. providing the bulb provides the
the right sort of pins and base shape, standard stuff can connect to it.

Think of any two bits of electrical gear ... say, your car and its electronic
engine gontroller ... the API is the plug between the two (including the
specification for the physical pins, and what they do, what signals they get and
what outputs they give) ... if your control unit is faulty .. if you can find
another controller that conforms to the same API, you should be able to plug it
right in. Inside the controller, it may be different code ... it may use a
different processor, or punch tape, or elves .. but, providing the API
definition is maintained and the connecotrs and signals are the same .. it will
fit right in.

APIs are the plugs and soclets between bits of code.

[ Reply to This | # ]

Day 5 - Oracle v. Google Trial ~pj
Authored by: Anonymous on Saturday, April 21 2012 @ 05:46 AM EDT
How about a telephone analogy.

I was looking for an interface which must not change and is
somehow abstract.

A few years (decades?) ago we were able to do additional
stuff we our phones by dialing special numbers.

The operator would recognize those numbers, and for instance
initiate a wake-up call.

You wouldn't care how the operator implemented those
operations (if they wanted they could hire people to
recognize those sequences and call you in the morning).
That would be the implementation.

Some operators had additional "special" numbers, but the
important numbers were always the same (at least here in
europe) (At least that's what I remember. I am not that

[ Reply to This | # ]

The analogy is not bad, its incomplete.
Authored by: BitOBear on Saturday, April 21 2012 @ 05:54 AM EDT
Lets just look at one element of your example:

Min(list_of_numbers[]) returns number;

Things in the computer that fit into "numbers" worth of memory might
not be numbers at all. What is five devided by zero? It's an error. It may
produce the not-a-number value, e.g. a special pattern of bits inside the
"number"'s worth of memory that says "this thing here is not
really a number". This is the "this is not data" data.

So when the API is defined for Min([]) it -may- include a purely semantic rule
that NaN values are ignored. Or it may include the semantic rule that if any
values are NaN then the function will return NaN instead of the smallest legal
number found.

It will also need to tell you what "number" you will get back if the
list_of_numbers thingy contains zero numbers, e.g. no number at all.

ASIDE: exceptions exist to handle cases like this. It is easier to just have a
illegal_nan_encountered exception, and a no_values_in_list exception, than it is
to have to have every entry of every function have things that every user has to
look for on every use.

So the API for 747 cockpit as used by Pilot includes non-mechanical aspects like
"don't try to lift the landing gear while parked on the ground" and
also what will happen if you do that (You get scolded by a warning light and a
buzzer, but the weight-on-wheels sensor will prevent the hydraulics from trying
to fold up the gear, if anybody cares)

So any way, part of the problem is that API is philosophy.

To use a hopefully lawyerly analogy for the problem of understanding APIs....

Q: What is a "strict constitutional literalist" and why can you get a
room full of them together and have them all end up arguing about interpretation
of something if they are "literalists"?

A: Each literalist has something that he -wants- "constitutional
literalism" to mean. And each has what they believe to be an exact
denotation and definition for everything in the constitution that they have
studied. But none have come to grips with the fact that these strict definitions
are all personal and when they don't match an argument ensues.

So for APIs we have people here who beleive that the fact of the declarations is
the API. I will call these people API literalists.

And we have people like myself who consider that the API must include the
should(s) and shouldn't(s), and I will call my ilk the API semanticists.

It doesn't matter which of us are correct, and it doesn't matter if we change
our positions on the topic minute-by-minute or API-by-API...

The fact that the whole thing *is* subject to argument here in this forum should
be ample indication that the term is *not* well defined.

You might as well ask the court to narrowly define counter

The definition itself is declaratory. Its an API if someone says it is. It's
only -not- and API if everyone says it is not one.

You are not wrong or weak or unduly confused by not "getting it" on
this topic. This is the "obscenity" of the computational domain. Once
you know the topic well enough, you know an API when you see one.

API has no -strict- technical definition.

If the court gives API a strict legal definition it will, by definition, be

[ Reply to This | # ]

Oracle caught in another lie?
Authored by: jbb on Saturday, April 21 2012 @ 05:59 AM EDT
Recently Oracle told the judge that you don't need a license in order write applications that use their APIs. They seem to say the exact opposite on their web site:
When you license the Java Platform, Standard Edition, you can write applications to its specifications.
I admit this is not a direct contradiction. Perhaps they told the judge the truth and are just trying to mislead everyone who goes to their licensing page into thinking that a license is required in order to write Java applications. They are certainly implying that you need to buy a license in order to make use of Java's "write once, run anywhere" feature.

Perhaps the simplest explanation, which PJ mentioned a while back, is that despite all the promises they made to the regulators before they bought Sun, Oracle has decided to drastically change the licensing terms of the Java language in order to squeeze as much money out of it as possible. Perhaps they will eventually use it as a cudgel to beat on the heads of their competitors who were foolish enough to keep using Java after Oracle got their greedy mitts on it.

Our job is to remind ourselves that there are more contexts than the one we’re in now — the one that we think is reality.
-- Alan Kay

[ Reply to This | # ]

The plane analogy
Authored by: The Cornishman on Saturday, April 21 2012 @ 06:11 AM EDT
This works quite well, especially because since before WWII there has been a
standard for layout of the most basic aircraft instruments: the Basic T. The
three dials across the top of the T are airspeed, artificial horizon and
altimeter, with heading (compass or gyro) centrally below them.

OK, we're in the realm of human factors and interfaces, but it's really
important for a pilot in any plane to be able quickly to find and recognise
these instruments, and beginning pilots are trained to scan them in a set
To stretch the API analogy to its limit, you don't want the main program (the
pilot!) to take action based on a return value which it thinks is altitude, when
in fact it's airspeed, nor yet to get units confused, which is why aircraft
still fly thousands of feet up, and not metres. Get this wrong, and Bad Things

(c) assigned to PJ

[ Reply to This | # ]

Day 5 - Oracle v. Google Trial ~pj
Authored by: Anonymous on Saturday, April 21 2012 @ 07:10 AM EDT
this is my attempt at an analogy

i have 2 numbers 2,3
i want to transform them

i type 2,3 and then a function key into my (rather old hp) calculator
i see 8

the calculator is my api and the function key is a method.
there is a place where i can enter arguments, there is a place where i choose
the function and there is a place where i see the answer

another one
webster was the api and method i used that summarised and explained
what is going on

[ Reply to This | # ]

The coast and the shore: a API koan
Authored by: swmcd on Saturday, April 21 2012 @ 07:27 AM EDT
Sez You (a radio show) asks
What is the difference between the coast and the shore?
The coast is the boundary of the land; the shore is the boundary of the water.
So we will say that
  • the application is the land
  • the library is the water
  • the API lies between the coast and the shore

[ Reply to This | # ]

Aircraft analogy - a few additions
Authored by: Anonymous on Saturday, April 21 2012 @ 07:27 AM EDT
I also think the aircraft cockpit is a great analogy, but there is an important
point to keep in mind:

humans are intelligent beings, the computers are not. Humans can adapt
themselves, computers - can't.

It is fundamental to understand this to be able to "get" this

To put it into perspective, let's assume for the moment, our pilots are blind
(so they can't adapt) but have very precise hands, so they can still find all
the buttons at the defined spots.

Such cockpit should be identical to the last button or it would be useless. If
747 has push button and 767 has a flip switch located 5cm further, then our
blind pilot trained on 747 would not be able to use it at all. Where a human
would barely notice the difference.

The same goes for API's. They absolutely need to be *exactly the same* to the
last dot or they are totally useless as far as interoperability goes.

While you can describe the same thing in a million different copyrighted ways
and any human would still understand, you can't offer compatible/interoperable
API's without offering an identical "selection and structure". This is

This is where the human understanding of copyrights brings us to the fabulous
world of Alice in Wonderland.

[ Reply to This | # ]

It's also the names of the APIs
Authored by: jjs on Saturday, April 21 2012 @ 07:40 AM EDT
In the example he gave:

average(list of numbers) return number

Note the name - average. As a result, the comment was redundent - those type of
comments SHOULD be. Programmers should choose names that reflect what the API
does. For example, java.lang - that tells me the API is related directly to
Java (it's core or very vital, can be checked by the TCK), and it's something to
do with the language itself. So it's not just that it's a header file, but
every element is essentially functional. If everything is functional, how much
creativity is there on each level of API to let it be copyrightable? Possibly
the whole, huge collection - but is each element? My answer (IANAL) would be

(Note IANAL, I don't play one on TV, etc, consult a practicing attorney, etc,

[ Reply to This | # ]

java.nio isn't a really bad example - no literal copying even possible
Authored by: Anonymous on Saturday, April 21 2012 @ 08:01 AM EDT
I don't understand why Oracle takes java.nio as an example of a creative API. It
is almost completely generated because it isn't actually creative at all. It
follows almost completely from the requirements that you want to do input/output
on various data types in a buffer. So much so that in OpenJDK the classes and
methods in the package are almost totally generated by a simple script!

Lets take a look at the java.nio package:

It has some classes for different Input/Output Buffers, some exceptions in case
things go wrong with the input/output (nio is short for New Input Output), etc.

And if you "zoom in" on one of the classes you see these classes have
several methods to manipulate the input/output Buffers. For example take the
IntBuffer, which Oracle used as an example in one of their slides:

(BTW. I took the liberty to reference the GNU and IBM documents for these,
because they have their own "copyright notices" which claim the
copyright holder is the FSF and IBM respectively. It is funny to think all these
people put a copyright notice on unprotected elements.)

It defines what kind of Buffer it is (an Int for Integer), and what operations
(methods) one could do on it, etc.

Oracle uses the class definition in there slides as an example of literal

public abstract class IntBuffer
extends Buffer
implements Comparable<IntBuffer>

That just says there is a class we call IntBuffer, it is a specialized version
of a Buffer which can be Compared to another IntBuffer. And Int is an
abbrevation of an Integer, a way to represent a number in the java programming
language. The package contains several such Buffer classes for different data
types (Byte, Char, Double, Float, Long, Short).

Since there is no real creativity involved at all one can just write a script to
generate all these classes. Which is what OpenJDK for example does (in fact
these templates were written by Mark Reinhold, one of Oracle's witnesses):

So, the above "creative" API statement is generated from the following
template in that file:

public abstract class $Type$Buffer
extends Buffer
implements Comparable<$Type$Buffer>

Note how $Type and $Buffer are written. They are just "variables" that
will be replaced by in this case "Int" and "Buffer" (there
are also different kinds of buffers). There is just one template source file
that you run to generate lots of classes. There is no source code even for any
individual data type Buffer class mentioned in the API.

So there is literally no way Google could have copied the Oracle Java
implementation of this package. Because Oracle's source code doesn't actually
contain this API in its source code!

It also shows that this API isn't at all creative since it is almost totally
generated from some template files (there are other templates in the OpenJDK
source tree to generate the exceptions for example). So all one does is look up
the names of the basic types of the java programming language and run the script
and TADA another new API...

The resulting API names (in Oracle's java, GNU Classpath, IBM's or
Android/Harmony) just look the same. But that is not because the source code
describes the API, in this package it literally doesn't. That is because the API
is all the mundane, non-creative constants/names that fall out of having a
package that does buffered input/output.

[ Reply to This | # ]

Day 5 - Oracle v. Google Trial ~pj
Authored by: Anonymous on Saturday, April 21 2012 @ 08:04 AM EDT
Google knew what changes to Java were needed to make it work on a
cell phone platform. Sun / Oracle wouldn't agree to the changes. I
really wonder who is forcing a fork?

[ Reply to This | # ]

API: not analogy, but attempt at definition
Authored by: Anonymous on Saturday, April 21 2012 @ 08:07 AM EDT
API: Application Programmer Interface

An API is an *interface* for a *programmer* to use to implement an

Application: is probably clear: some code which runs on some system. The system
is here represented by the Java Virtual Machine and the Java libraries.

Programmer: the Dude!

Interface: From Miriam-Webster:
1: a surface forming a common boundary of two bodies, spaces, or phases <an
oil-water interface>
2a: the place at which independent and often unrelated systems meet and act on
or communicate with each other <the man-machine interface>
2b: the means by which interaction or communication is achieved at an interface

2a is the one most suitable for the topic at hand: API is a (well defined) thing
which forms the boundary between the application code and the system code.

That is really all there is.

FWIW: an API *definition* is a description of the interface: how the programmer
can use it, what is the system functionality the interface provides access to
(exposes). The better that exposed functionality matches what the application
needs, the easier it is to code: that is why a well designed interface is

HtH, Andre.

PS.: I am working on API design, standardization, implementation. Its fun :-)

PPS.: I am not a Java guy, but some of the APIs I am working on are also
rendered in Java (by others).

[ Reply to This | # ]

Van Nest's point 6
Authored by: Anonymous on Saturday, April 21 2012 @ 09:08 AM EDT
Ellison says Harmony is Java? Davlik is Java? Both?

[ Reply to This | # ]

Simpleton's attempt at API Analogy
Authored by: HappyDude on Saturday, April 21 2012 @ 09:22 AM EDT

I will simplify the thought and let anyone extrapolate and pick it apart.

How about a check?

The check itself tells me what data I need enter.

I have no idea why it is arranged like it is, but it seems like they're all the

If I don't include some data, it probably won't work, but I don't know why.

I have no idea what happens after I write the check and the cashier scans it
through some contraption, or sends it to the bank. All I know is the outcome.

How does it work? I don't know and I don't really want to ... I just want the
transaction to occur (without bouncing).

It's a shot.

Cheers, All.


[ Reply to This | # ]

An imperfect analogy (that's all there are)
Authored by: om1er on Saturday, April 21 2012 @ 09:36 AM EDT
An "Application" is a task to which a computer is applied.

"Programming" is the activity of entering sensical, executable, instructions into a computer as well as comments and interface specifications.

A "routine" is a part of a program that accomplishes a programming task. Some routines will be used over and over again. They can be grouped together, and the collection called a library or a package.

The "Interface" is between two distinct routines. It describes how those two program routines interact, using agreed upon terms, and names which (and this is where the creative part comes in) describe accurately the activity being performed.

In order for a computer program to make use of the routines in a package or library, the program's source code has to use the correct routine and variable names and to use the correct variable types (such as a number or a letter) to match the routines in that library or package.

There are at least two ways to know what those names and values need to be: one is with a written API specification, the other is to look at the source code for the routines and variables in the library or package.

If a proprietary vendor does not provide the source code for their library or package then the vendor needs to provide the written API specification or nobody will know what is there or how to use it.


The analogy:

Let's say one day you feel like working a puzzle, say a puzzle that when properly put together is a picture of a cat.

You don't want to create your own puzzle from scratch, so you go buy one. As you put the pieces together, it dawns on you that the shapes of the edges are in computer terms an "interface." If one piece's edges do not fit with another piece's edges, the puzzle will not go together. This is in hard physical reality what an Application Programming Interface, API, is in computer programs. An API describes how the pieces fit together, and is used to make one program routine fit together with another program routine.

You work and work, getting all the interfaces matching, and your application (the complete picture) is taking shape, but you find that the manufacturer left out a piece. What to do? Well, the interface is well defined - it is specified right there where the hole is. So, you "reverse engineer" that missing piece to complete the puzzle, and your application. You fill in the missing space, following the interface, and a knowledge of what the completed picture has to look like. (There's some artistry involved.)

But, the puzzle manufacturer sues you because you used their interface specification. They claim the shape of each puzzle piece (and there are lots of pieces) are copyrighted, so you cannot create your own piece without a license from them.

Your mind boggles, much as it boggles with software patents and Oracle v. Google.

March 23, 2010 - Judgement day.

[ Reply to This | # ]

What does API mean?
Authored by: Anonymous on Saturday, April 21 2012 @ 09:46 AM EDT

I think it's crucially important in this trial to understand that 'API' means two things, and the Oracle team are trying hard to conflate and confuse the meanings.

The original use Applications Programming Interface, meaning it's a list of things that can be called on by a program to achieve particular jobs, without worrying how those jobs are done as a result.

The Applications part means that it's about handing the opportunity of use from one program/system to another. It's not restricted to an operating system, or a language. Microsoft Word for instance has API's that let other programs make use of Word functionality.

The Programming part should be obvious - it's about letting one program use the functionality that another has.

And Interface means that you don't need to worry about the implementation: all you need to know is how to call on the functionality the API provides.

In the original meaning, the promise of the Interface part means that you can replace the implementation of the API with another. So if you were writing a program that used functionality provided by Microsoft Word, you could switch out Word, and insert LibreOffice provided the Interfaces offered by both were the same. You'd want to do this if you found that the LibreOffice implementation was superior. Or if you discovered you weren't bound in what you could do by the licence of LibreOffice, whereas with Word you can't use it in your nuclear power plant for processing safety- critical data.

But what tends to happen is that programmers come to depend upon a particular implementation of the API, and at then 'API' is used to mean the particular implementation.

This happens when somebody writes a really good implementation of the functionality in the API. Or programmers come to depend on implementation side-effects which are not well documented. Or the API spec is not clear and one implementation does one thing while another does something else. Or a company who provides the API builds in hidden parts which are necessary but unavailable for general use. Or a particular implementation becomes so embedded that replacing it is fraught with danger and difficulty. Or the licencing requirements mean it's impossible to replace an implementation. Each of those have real-life examples.

In this trial it's in Oracle's interests to conflate the two related ideas because the promise of an API _is_ the replaceability of the implementation. And that replaceability depends upon the Interface for the implementations being exactly the same in all ways which would affect implementation.

Now we get to Java. What follows differs according to the language.

In Java, a method in an API:

public float Divide(float a, float b)

is replaceable if the name of the method is the same ('Divide'), and the types of the parameters are the same, and in the same order.

So, I could replace the method above with another implementation with this definition:

public float Divide(float x, float y)

I could not replace it with

public float Division(float a, float b)
because the method name has changed.

Nor could I replace it with

public float Divide(int a, float b)
because one of the parameters has changed type.

And neither could I replace it with

public int Divide(float a, float b)
because one of the return type has changed.

All of the above is to do with the ability to change syntax. There's also semantics. As a matter of interoperability I can't change what a and b mean. If a is the nominator and b is the denominator in the Divide function, then an implementation intended to replace the existing implementation cannot reverse the order of the two because any calls to the Divide method will have been written expecting the original order: 4 divided by 2 is very different from 2 divided by 4.

It goes further... The method Divide must be located in a class. Say it's

public class Division

As a matter of interoperability, I can't change the name that the class has because programmers making calls on Divide will expect Divide to be part of Division.

If the Division class has two methods - Divide and IntegerDivide, then the order in which the two appear in the class is something that can change between implementations.

That is, this:

public class Division {

public float Divide(float a, float b) {
//Some stuff would be here, but it's irrelevant to this example

public int IntegerDivide(int a, int b) {
//Some stuff would be here, but it's irrelevant to this example


is equivalent to this:
public class Division {

public int IntegerDivide(int a, int b) {
//Some stuff would be here, but it's irrelevant to this example

public float Divide(float a, float b) {
//Some stuff would be here, but it's irrelevant to this example


Oracle are claiming that the order is indicative of copyrightability. In the same way that the creative order of the words in this sentence means that the unique snowflake that is this sentence enjoys copyright protection.

But it goes further.

Classes are grouped together in packages.

For instance an API developer might group the classes Division and Multiplication together in a package called Maths.

As with methods in classes, the order in packages is immaterial to interoperability, but the fact that Division and Multiplication are in Maths is important for interoperability if I want to replace the Maths package.

And so is the name 'Maths'. I can't change that name when replacing the implementation, just as I can't change the names of classes or methods.

HOWEVER.... All of the above is to do with the specific rules of _Java_. Other languages have other rules. APIs provided by other systems have other requirements on replaceability. Order does matter sometimes. The names of parameters matter sometimes. And so on.

[ Reply to This | # ]

Lego is almost the perfect analogy
Authored by: Anonymous on Saturday, April 21 2012 @ 09:59 AM EDT
Lego and programming are very similar...

You get blocks which let you make models of pretty much
anything. The blocks are the basic statements of the
programming language.

But if you want to make a model which works - say a model of
an engine, then you have a problem: to make an engine you
need gearing, axles, and ways to mount the axle. In the
basic Lego universe, these don't exist.

This is equivalent to the situation where you want to do
something that the language is not equipped to handle. I/O
in Java is an example.

You can:

- Design some new things that you'll manufacture from
scratch yourself. You'll have to cut them out of wood, or
have a plastic injection moulding kit, or something. This is
the equivalent of building some add-on to the language, from
scratch. In PHP you'd do this by writing some C code with
functionality you want to add to PHP. Similarly in Python.
This is the equivalent of building your own API. By choosing
this option, you are going down your own road: your gearing
system is unlikely to interoperate with the 'official' Lego
gearing, more on which later. To interoperate you'd need to
make a special piece which has both sets of gearing mounted
on one axle, and then you'd need to make sure your model was
designed to take account of the need for both gearing. Just
as you would in a computer program if you were using your

- Or you can adapt what you have. For Lego, if you scale up
your model, you might be able to make gears. You are working
around a problem here. But it's not a great way forward.
Your model is going to have to be really big for this to
work properly. In programming you see this when you force a
language or a system to do something it wasn't designed for.
You end up with strangeness, which is caused by trying to
work around fundamental problems: like your model is going
to be bigger than the engine it models.

- Or you can depend on the manufacturers of Lego. They came
up with Lego Technic which includes gears and axles. And
they designed a new kind of brick with holes, so that you
could mount the axles. This collection of elements is
equivalent to an API. You use their parts instead of
manufacturing your own. And you get enormous benefits from
using their standardised parts: you don't have to spend time
making your own, and you don't have to try to work around
the problem of not having gears. You can make models the
size you want. And you can still make your own gears if you
want - but by making to them to the design of the Lego
gears, you are able to interoperate. Maybe you'd want to do
this if you want to use metal gears instead of plastic.

[ Reply to This | # ]

Way way too complicated...
Authored by: Anonymous on Saturday, April 21 2012 @ 10:03 AM EDT

The Essence:

A Library is a tool box.
An API is a list of the tools in the box.

That's it. That's all. QED Fini. The End.

Yes, there is more in the details, and in the elaborations etc. But the essence
of what an API is, is 'A list of tools in the box'.

More complex analogies lose the central point in the details.

Keep in mind that has to be presented verbally in real time in open court. It
has to be bare-bones simple for people to grasp as they hear it. No going back
to the top of the paragraph and rereading it (5 times); or parsing phrase by
phrase. What the jurors' ears hear and they catch on the fly is what they are
gonna get.

A Library is a toolbox.
An API is a list of the tools in the box.

(Lawyer pulls out a socket wrench and a screwdriver.)

Not a mechanic either

[ Reply to This | # ]

Improving the Plane Analogy
Authored by: Magpie on Saturday, April 21 2012 @ 10:22 AM EDT
I don't think that an API is equivalent to the control panel. Rather its a user
guide that lists all the button and gauges on the control panel, and possibly a
picture or two, along with an explanation of how it works.

What Google have done is built their own aircraft with a control panel that has
on one part of the panel the same 37 buttons and/or gauges, in the same place,
using the document as a guide. But the material used to build the control panel
is different and the plane around it is completely different.

As a pilot you can nearly fly Google's aircraft had you been trained had you
been trained on a 747 or 767, but the performance of the aircraft is different
and you have to take that into account.

[ Reply to This | # ]

APIs and mathematical languages (not an allegory)
Authored by: reiisi on Saturday, April 21 2012 @ 10:23 AM EDT
Went in to the other room to make my daughter's bed with this thought ringing in
my head: An API is an abstact language for commanding the abstract machine that
is the program. And pretty soon copyrights look like patents and physical
machines look like abstract machines, and the bases of property law disappear in
a puff of smoke as everything becomes a metaphysical tangle of maths.

Let's fix that.

An automaton is an abstract mathematical machine. Some automata are models of
real-world machines. Models of real-world machines vary in the degree to which
they match the thing being modeled.

In theory, a really good model could be substituted for the actual real-world

Programs are models of real-world machines and processes. When they work well,
they are the poster children of the above principle, that a model can be
substituted for the real thing.

An abstract mathematical machine is equivalent to a mathematical language. Well,
maybe to a language plus the semantic mappings of the elements.

A mathematical language consists of vocabulary and grammar. (Natural languages
differ from mathematical languages in that both vocabulary and grammar are
fluid. In mathematical languages, The vocabulary and the grammar are fixed.)

A computer program is (the implementation of) a mathematical language, plus the
semantics. This includes both (compilers for) programming languages and the
programs written in those languages. In the case of a program to add two
numbers, the numbers are vocbulary, as is the addition command. The sequence in
which the numbers and the command are entered is the grammar. The semantic is
the function of addition, and is somewhat independent of the language itself.

(There is a corollary to the principle of linguistics, that words have no
inherent meaning, here.)

The language doesn't care about the output other than that the output shows
(recognizes) whether the combination of vocabulary and grammar was valid or

In the functional (mathematical) model, the numbers and the addition instruction
are inputs, the addition operation, or transform, is (part of) the semantics,
and the sum is the output.

An API is the set of inputs, with a specification of the expected operation or
transform. Ergo, it is an abstract description of the language and its

In many cases, the API of real programs is not fully rendered in human readable
form, thus the expression, "The code is the documentation." (Okay, in
most cases, actually.) This is similar to the specifications of a physical
machine not usually being fully exhaustive (especially in terms of error and/or
exceptional conditions).

We'd usually rather just get on with using the machine, you see.

So, when you dig down this far, you suddenly see all the frayed edges of all
sorts of social artifacts, including the legal bases of property, itself. (Oh,
nuts. Let's just get real and quote the preacher: "Vanity, vanity, all is
vanity, and there is nothing new under the sun.")

The architects of the Constitution and the original laws about patent and
copyright understood the above, and that's why there was not supposed to be any
intellectual property under the US Constitution. We modern, excited with our
actual implementations of maths in machines, have lost sight of the forest for
the trees.

If we get rid of the boundaries between the intangible temporary liens on pieces
of the market which copyright, patent, and trademark were intended to be, we
find ourselves eroding the very principle of law, and shortly without any
protection left against either tyranny or the anarchy which tyranny hides.

(Came together better than it has in the past, guess I'm going to copy this to
my reiisi blog and then try to refine it a bit on my defining computers blog.
Not yet though, I have a deadline hanging over me on a "real" job.)

[ Reply to This | # ]

library = "black box", API = how to use black box
Authored by: Anonymous on Saturday, April 21 2012 @ 10:24 AM EDT
I say forget trying to find an analogy for APIs. Libraries are black boxes.
You do not know what is inside, and nor do you care. APIs are the list of
functions that are being made available to you, and the instructions on how to
use them. The API is only used by the programmer developing an application.
The application, when it is compiled does not use the API, but accesses the
library directly.

Consider the Windows .dll file (dynamically linked library). If you are
provided the .dll file alone, there is no way to determine what is inside it.
You might be able to us a hex editor to see the names of the functions, but that
is IT. You have to be told what the functions are, and what they are expecting.
That is the API.

Thing is, APIs are not limited to libraries. Any program that is making a
function available to someone else has to provide an API, or that functionality
cannot be used. Take for instance, FTP. We know that when you connect up to an
FTP server, you can use "cd <directory>" to change to a
directory, "ls" to list the contents of a directory, "get
<filename>" to retrieve a file, and "put <filename>"
to send a file to the server. These commands are the API provided by the FTP
server. I could write another program that uses the same set of commands as
FTP, but instead, it accesses a database and adds or retrieves table records.

[ Reply to This | # ]

API are like connectors
Authored by: Anonymous on Saturday, April 21 2012 @ 10:44 AM EDT
The API are like sockets/connectors/buses: in the same way two devices can
comunicate through a connector, the program and a library implementation
interact through an API.

I guess real world connector reproduction (like the iPod/iPhone/iPad connector,

camera lens connectors etc) is somehow protected.

So I guess API should be protected in the same way/by the same law.

Every computer programmer would like connectors were not protectable, as
every photographer would like camera lens connectors would; so don't trust us
for being unbiased on this topic.

[ Reply to This | # ]

What is an API? Well, it varies...
Authored by: Anonymous on Saturday, April 21 2012 @ 10:45 AM EDT
This wikipedia article describes several flavors of API, skimming that might give you an idea.

The reason "API" is so nebulous is that it describes a very high-level concept that programmers find useful in many different situations, ranging from correctly re-using a single function that someone else wrote, to re-using an entire class or collection of related functions, to re-using a complete library containing dozens or hundreds of those things. It can also cover situations where you break a large program into smaller pieces so that different groups of programmers can work on each piece; each piece then becomes a "library" or "component" or "subsystem" or something like that, and each one needs APIs so the other pieces can interact and interoperate with it.

So the precise embodiment of the "API idea" will be different in each of those situations, what they have in common is the high-level concept. Even in a single scenario (say, plugging a 3rd-party image-loading library into an image-viewing program you are writing) the overloaded term "API" can mean several distinct things, depending on the context of the conversation. The image-loading library probably contains a bunch of functions and/or classes, and small groups of those (or even single ones) are "APIs" if just that small group of things can be sensibly used together. But the collection of these smaller "APIs" in the whole library, is also called an "API" -- its the API of the entire library, as opposed to the API for just one piece.

Let's take Java as an example. Java contains a "class" called, and this class has methods with names like exists() and length() and lastModified(). The way this works is that you construct a with a filename, and then you can call methods on that object to find out things about that vacation.txt file on your filesystem: myFile = new"C:\documents\vacation.txt");
if (myFile.exists())
// ... okay, the file exists! Do stuff with it here!

So here, the exists() method is part of the public API of the class. That means it is meant for use by programmers who use this class (as opposed to some private implementation detail that is only meant for the author of the package to use). You can't really use by itself, because you first have to create a object to call it on. So exists() by itself should not be thought of as an API, but all of the public methods of the class together, do make up an API, because a program can use those methods together in order to get something done.

So "the public methods and fields of the class" constitute an API. But there are lots of other classes in the package, and most of those also constitute APIs, for similar reasons. And then when you look at a group of classes that are meant to be used together, you might think of them as collectively being an API. It gets murky though, so the easiest way to think about it is to just consider the entire package as being an API. But this is a shorthand for saying "take all of the public classes in the package, and get the public API from each one, and merge all of those together". The result can be thought of as "the public API of the entire package". If you repeat this process at a higher level, you can merge the API's of all of the standard Java packages together and end up with something you might call "the Java standard library API".

Going back to the 747 analogy, saying "this function/method is an API" is like saying "this single button or knob, is an interface allowing me to control 1 very low-level detail of the plane".

When you say "all of the public methods in the class together, make up an API" that is like saying "this 2x4 inch area of the control panel, which contains 12 different buttons and knobs, is an API for controlling the plane's flaps". Several related controls, that are used together to accomplish a slightly higher-level task.

Then when you say "all of the public class APIs from the package combined together, make up the API of the package" that's like saying "this 8 inch by 8 inch panel of controls, plus this giant throttle stick, plus these two visual displays, are all related to airspeed and elevation". So its a higher-level grouping of functionality, and it contains many smaller APIs because the pilot needs to manage many lower-level things in order to accomplish the higher-level goal of seeing and adjusting the plane's airspeed and elevation.

Then when you say "the entire Java standard library API" with its hundreds of packages, you're now talking about the entire cockpit combined; every display screen, button, stick and knob is part of a giant interface that the pilot uses to fly the plane. "The entire Java standard library" with all of its rich functionality (files, strings, network connections, compression, XML, graphics, layout, UI controls, and many many more things) is like the entire plane--it has hundreds of thousands of implementation parts, but the "interface" to the pilot is only a few thousand controls and displays, through which he makes the plane do what he wants. Same thing with the Java library (and other libraries, in any programming language). The "API" part is the "interface", that you use to tell the library what to do. But usually most of the library's code is the "implementation" code, which has the job of actually doing it.

[ Reply to This | # ]

ISO standards and copyright
Authored by: Anonymous on Saturday, April 21 2012 @ 11:46 AM EDT
The C programming language and it's standard library functions are covered in
the ISO/IEC 9899. All ISO standards are copyrighted, and the ability to use the
standard to develop a conforming implementation is not explicitly granted. In
particular, ISO has a brochure on copyright, and they don't even let one quote
the standard in the book without negotiating a royalty. Fair use is not
mentioned in the brochure, so presumably that depends on the country laws and
practices as to what fair use implies. In theory, it means that ISO (or the
respective country standards bodies) could go after people implementing
programing languages, or even the programmers as making derived works of the
header files that derive from the standard. Obviously, that would not be good
for the programming community (or people using the programs).

As the Oracle-Google case is being brought in the US, US laws govern what is
considered expressive or abstract. But, copyright laws are only uniform to the
extent that copyright conventions are uniformly transferred into national laws,
and still differ based on how laws are interpreted. A victory in US courts for
programmer freedom does not necessarily translate into a victory everywhere. Are
programing languages going to be sucked into the morass of FRAND? I certainly
hope not. And I hope Judge Alsup understands the stakes of his decision outside
the confines of just this case.

[ Reply to This | # ]

Is the API a list?
Authored by: Anonymous on Saturday, April 21 2012 @ 12:41 PM EDT
Computers are very precise about 'what' to do, but have no concept for 'why'
they are supposed to do anything.

The API has a human-readable form which states the purpose of each function in
the library. A user wanting to find the average of a group of numbers would
search for a description that matches his need. This is much like searching a
thesaurus or dictionary to find a good match for the description a writer needs.
Copyrights certainly apply to the descriptions of each word in a dictionary,
because they could be arbitrarily useful or difficult, but they don't apply to
the list of words themselves.

With normal human language, the smallest nugget of information is a single
word being listed. In API's, the smallest nuggets are individual methods for
the classes. Human words are arbitrary combinations of syllables and spellings
that are unique. API methods are arbitrary combinations of names, class paths,
inputs, and outputs that are unique. Just as there are well known rules of
language that are visible in language, there are well known rules that are
visible in API's. In english, a noun ending in 's' is referring to a plural of
that noun. In java, a class path ending in a method 'toString' is referring to
changing something into text output.
We use such conventions and rules to make it easier for humans to learn how to
use a language or API. The computer could care less if something named
'toString' returns text, erases data, or freezes the system. All it cares about
is that there is only one possible sequences of class path and method that is
being referenced so it knows what implementation to run.

Google was careful not to make a direct copy of the descriptions of methods or
the implementation of methods in their code, but did follow the same rules java
uses for resolving class path and method definitions. Trying to force a change
in the accepted rules would force the user to use a different language entirely.
It would be like saying 'box' will refer to kittens and 'boxes' will be a
lightbulb. You could do it, but no human being would want to learn such
arbitrary rule-less nonsense.

As a result, the documents produced by automatic tools to map the definitions
will make the google API look extremely similar, simply because they are using
the same rules and unique definitions. Only the text describing what it does is
likely to be different, just as a dictionary entry will vary by publisher.
Sometimes the text will be the same, just like some dictionary definitions will
be the same between books. If you follow the rules and get the same
understanding, this is a natural consequence.

We don't allow copyright on these minimal nuggets of information, because it
is like copyrighting oxygen and telling nobody else to use it. It adds a
bewildering arbitrary character that harms everyone. Only when you start
chaining these minimal nuggets to do larger works, do we allow copyright to
apply. In the end an API is a list. An arbitrary, boring, minimal list.

[ Reply to This | # ]

No analogy needed: it's the math
Authored by: Anonymous on Saturday, April 21 2012 @ 01:00 PM EDT

As discussed here so often, computer programs are, at base, mathematical algorithms.

Discrete mathematics, the branch of math upon which computer science is based, is a system of logic. That logic system consists of a set of concepts and methods for their application, which anyone who employs discrete math must use in order to obtain reliable results. If you don't follow the rules that define the methods, you cannot be certain that your calculations are correct. Those rules are, in effect, the API of mathematics.

What are the rules? Let's look at a key mathematical component that is implemented literally in computer programs: the function. (Hint to lawyers: the name function suggests that its purpose is, well, functional). The defining characteristic of a function is that it takes input values and maps them to discrete output values, and in doing so it guarantees that, for each discrete set of input values, it will always return the same output value.

Here is a math function definition:

G(x) = x + 1

It defines a name (G), an input (the variable named x) and an output mapping (x + 1). It is understood from the underlying definition of functions that x is a number and x+1 also will be a number. In API terms, everything to the left of the equals sign is the definition, to the right is the implementation.

Mathematicians live in a world of one-letter names, but programmers have the luxury of using descriptive names. So, a programmer who wanted to use the function to increment a number might write it as:

increment(x) = x + 1

In a real programming language, C, it might look like this:

int increment(int x) { return(x + 1); }

Here, the definition precedes the first curly brace, the implementation is contained within the braces. The definition is what a programmer would see in an API specification, while the implementation likely would be compiled into binary. Here also, the definition explicitly states that the input must be an integer and that the returned value will be an integer.

The thing to note is that the implementation can be changed in any way, so long as it produces the same result guaranteed by the definition. In this case, it could be { return(X + 2 -1); }, and it would still work (though not as efficiently).

In practice, an API specification may contain, in addition to functions, things such as constants, signals, slots, etc. They may or may not be proper functions, but they are related in the sense that they are a guarantee that, if used properly in a program per the interface definition, they will obtain the specified results, and only the specified results. [Note: I'm not a C programmer, so please forgive me any syntax errors.]

Although Oracle tries very hard to engender confusion about what an API is, the key is contained within the acronym itself: the I is for Interface, not for Implementation.

[ Reply to This | # ]

A simple API
Authored by: Anonymous on Saturday, April 21 2012 @ 01:28 PM EDT
Cars have batteries. Sometimes, batteries go dead, and need to be charged.

There are many different cars, and many different batteries to accomodate them.
There are also many kinds of battery chargers. How do they all work together?

There is an API. it specifies that each battery will have a positive and a
negative terminal, and that those terminals will be labelled with a
"+" or a "-" to distinguish them. Each charger likewise has
two leads, color coded red for positive and black for negative.

A user does not need to know what kind of battery they have, nor what kind of
charger. Neither do they need to know anything about the inner workings of the
battery or the charger. As long as they follow the API it will work.

[ Reply to This | # ]

  • A simple API - Authored by: Anonymous on Monday, April 23 2012 @ 04:16 AM EDT
API example - the PC BIOS
Authored by: mosborne on Saturday, April 21 2012 @ 02:31 PM EDT
As I started reading this article, it occurred to me that the BIOS (Basic Input
Output System) used by practically all IBM-compatible (that term itself refers
an alternate API implementation) PCs.

It was the implementation of the IBM BIOS API by another company (Columbia Data
Products) that ushered in the personal PC era that we know of and enabled the
explosion of different PC hardware. If the APIs had been copyrightable, then
there would have been no Compaq, no Dell, no Gateway, no Acer, no countless

[ Reply to This | # ]

An API analogy related to Baker vs Selden
Authored by: mosborne on Saturday, April 21 2012 @ 03:28 PM EDT
The US Supreme Court’s 1880 decision in Baker v. Selden said that the blank
forms used by Selden in his book were not copyrightable. An API is to a
programming library what Selden's blank forms were to his accounting method.
Each individual blank form served a particular purpose just like a particular
API. The blanks on the forms serve the same purpose as the parameters of an API,
i.e., they provide a means for the person *using* the API/form to customize the

In fact, each of Selden's blank forms could be trivially represented by a
program API, one API for each form, with every blank a parameter. The result of
the calling each API with the desired parameters would an identical paper form
to that that could be filled in by hand.

[ Reply to This | # ]

Why not run a database on a credit card?
Authored by: greed on Saturday, April 21 2012 @ 03:49 PM EDT

Or, at least, something the size and shape of a credit card.

One of my assignments in University was exactly that: a simple database to run on a smartcard. (JavaCard was still in the future at that point.) The idea was, you could plug the smartcard into a point-of-sale terminal, the terminal would deduct from your balance and ask the smartcard to record the receipt items.

So you'd never need a paper receipt; you could then plug the smartcard into your home computer (smartphones were still in the future at that point...) if you wanted to check.

(Obviously, this was just to make the assignment a little more interesting; actually implementing a system that way would be a massive security failure.)

Apple, actually, is so sure you DO want a database on something the size of a smartphone that iOS comes with several "persistent data stores" built right in, including "SQLite+".

Programmers can do amazing things when you stay out of their way; that's part of why no-one (I know) ever cared for JavaME.

[ Reply to This | # ]

An API is an interface standard meant for programmers...
Authored by: Anonymous on Saturday, April 21 2012 @ 04:16 PM EDT
An ABI is an interface standard used to communicate between compilers and
linker/loader Operating System routines. An API/ABI bridges the compile time and
runtime environments: programmer, compiler, and runtime OS/VM.

Any analogy opens the door to catastrophic misinterpretation and the end of
FLOSS in the US. Fools tread there! APIs and ABIs are a tar pit for foolish
lawyers. Ask SCOx.

APIs/ABIs are local communication standards meant to be obeyed by modularly
written programs, drivers, and utilities. APIs are ALWAYS necessary for
programmers, to get their program to work with the larger runtime environment.
Similarly, ABIs are ALWAYS necessary for running routines for linking and
loading the proper modules correctly, with some guarantees of operational

Finishing with APIs, programmers search perhaps multiple APIs for those
interfaces optimally supporting extensions to their custom application code.
Good programmers do not reinvent if their community already provides the

[ Reply to This | # ]

Purely Semantic API
Authored by: BitOBear on Saturday, April 21 2012 @ 05:57 PM EDT
Woke up with a thought. This is an example of a fully conceptual API (one with
no concrete calls) that includes by implication one of several API's of your
choice. This API is entirely "rules" and contains no "API
Files" at all.


I hereby declare The Arbitrary Execution Web Server API:

Overview: The service supplier shall set up a web server that accepts the source
code for a program in the desired languages, and the the web server shall
respond withe the output of the program and any error messages in a mime
multi-part response.


(1) The client shall send an HTTP GET request to the server as
/exec/language_name, where language_name is any supported language offered by
the server such as C, TCL, Java, Listp etc.

(2) The body of the get message shall be either

(2a) The unadorned program source.

(2b) A multi-part mime message, the first part of which shall be the source code
and the second part shall be the data the program needs supplied. The data shall
be provided to the program on its standard input file descriptor.

(3) The server shall respond with zero or more HTTP CONTINUE messages, at least
one every 30 seconds, for the duration of the compile and execution phase. If
the connection is lost the program shall be terminated immediately and the
results discarded.

(4) The web server will end the session with an HTTP OK message that contains
any compiler messages including errors, followed by the output of the program.


Okay, so here is an API I just invented. It is -purely- semantic. It doesn't
tell you, or offer you, any details about how you will create, send, or decode
the HTML messages. It doesn't provide you with any procedural calls that or
files that the code you are writing will or will be passed directly to any

This is still an API, it is just completely language agnostic. It is also
completely semantic and, since I haven't written any code, it is completely

At this moment I could start writing the server while you start writing the
client. So this API is also a specification.

If everybody agreed that we were going to do this very thing, then the API would
become a Standard.

[ Reply to This | # ]

Day 5 - APIs
Authored by: Anonymous on Saturday, April 21 2012 @ 06:46 PM EDT
There is also the issue to consider that an API is essential
to the use of the language. In the case of the menu bar, the
company that first made it was not encouraging everyone to
use their menu bar.
Here SUN has been encouraging everyone to use JAVA (because
it benefited them.) They wanted people to use JAVA.
They had no problem with people building things in JAVA and
selling the results.
Sun would make money selling the OS that the JAVA app would
run on, or would make money licensing their version of the
JVM etc.
To now turn around and claim that the API's are proprietary
and cant be used without a license goes against all that SUN
have been pushing since JAVA was invented.

[ Reply to This | # ]

"API" - the scope of the term.
Authored by: DMF on Saturday, April 21 2012 @ 07:08 PM EDT
I don't believe that anyone (even pj ;)) is having a problem understanding what elements comprise an API: it is a list of classes and their public attributes.

What seems to be throwing everyone a curve ball is that there is no particular *scope* implied by the term. The scope in usage is indefinite and contextual. As a user, when I'm writing a program and I refer to "the API I need" to write the program, it is the program that defines the scope of the API. It may be 40 packages, or only System.out.println().

Or the scope - from the point of view of the provider - may be the set of all possible API elements, or a purpose-directed subset thereof.

In either case, to refer to "the 37 APIs" is a misuse. One should refer to "the 37 packages" comprising the API for the Java Class Libraries (or whatever the technical term is for the grouping). If Judge Alsup understood that, I think the matter would become clearer for him.

Hope this helps.

[ Reply to This | # ]

  • "the 37 APIs" - Authored by: Anonymous on Saturday, April 21 2012 @ 09:29 PM EDT
Observation on API Analogies
Authored by: kenryan on Saturday, April 21 2012 @ 11:57 PM EDT
I don't really have a point to this post, I just wanted to
make an observation. (note I'm a technical person, but in
hardware with some low-level software. I stay far away from
application programming).

Reading Groklaw over the last few days seems really to have
emphasized something.

The whole concept of APIs seems to be very poorly thought
out, in the sense that nobody can seem to decide on exactly
how it should be defined!

In other situations a couple people cook up a few analogies
to explain something, and those with expertise in the field
generally end up agreeing on one that illustrates whatever
point they want to make.

In following this case there has been post after post with
API analogies, all over the map. There doesn't seem to be
any convergence on just how an API should be thought about.

How on earth will a jury of laypersons ever be able to
understand what an API is well enough to make sensible
decisions about it when experts can't agree?

(speaking only for myself, IANAL)

[ Reply to This | # ]

You know your case isn't going well when ...
Authored by: jvillain on Sunday, April 22 2012 @ 04:14 PM EDT
The judge is saying things like this.

Judge Alsup: "I question what that last witness added to this case."

Ouch. Maybe it all comes clear after the next witness but I suspect he was put on the stand purley to muddy the water. I am still waiting for some of from Oracle to say in no uncertain terms that Google was told they couldn't do what they did with out a license and this (the account manager) would have been the most likely guy to do it.

If I was in the jury what I got out of it was that Google was willing to take a licence when they needed it and didn't take one when they thought they didn't need it.

I am really starting to question Bois's rock star lawyer status.Sure he won the MS trial but that case made it's self. Google hasn't even really started to tell their side of the story yet and this is already looking bad for Oracle.

[ Reply to This | # ]

Sick it to The Man
Authored by: Anonymous on Sunday, April 22 2012 @ 05:53 PM EDT
The biggest High Tech case in years. Two industry heavyweights.
Highly abstract legal argument on computer programming language.
The judge announces from the bench:

> I don't have a fancy computer, all I have is this
> [ holds up a single piece of paper with columns visible and
> a yellow PostIt note sticking to it].


[ Reply to This | # ]

Day 5 - Oracle v. Google Trial ~pj - Updated 4Xs
Authored by: iraskygazer on Monday, April 23 2012 @ 03:43 PM EDT
What about a very basic analogy.

A TOC is to a book like an API is to a software library, aka. Java. The main
difference is the fact that you can read/use a book without a TOC but you will
have a very difficult time using a software library without an API.

Unless of course, you are the creator of the library and have access to the
internals of the software library. Thus, the main purpose of an API is to
release information to allow software programmers to use your software library.
The programmer, who isn't the creator of the library, doesn't have to know what
goes on inside your library as long as you publish what goes in and what comes
out; aka. a black-box version of an API is made public so your software library
can be used by the public without caring how you manipulate input to get the
desired output.

[ Reply to This | # ]

A better analogy
Authored by: Anonymous on Tuesday, April 24 2012 @ 10:48 AM EDT
Imagine there was a delivery company that would deliver whatever a business
needed. The business would fill out a paper form, fax it to the business and
then the business would deliver whatever they had asked for. The form might
contain labels, like "Name" or "Address", and maybe there'd
be a set of
instructions on the back, written as tersely as possible, describing what the
business should write in each of these fields.

The businesses, being clever, develop rubber stamps that fill in the info that's

always the same so they don't have to write it out every day. When a new
competitor delivery company starts they lay out their form in the same way as
the existing form, so that the businesses can use the same rubber stamp.
They write their own set of instructions, but there's only so many ways you
can describe how to fill in an address or an item number, so the descriptions
use many of the same words.

Assume that if you couldn't lay out the form the same way no one would use
the new delivery business, and that it is super-extra-useful to be able to swap

between the two businesses (they both deliver to areas the other one doesn't,
even if they overlap some.)

If that form would be copyrightable I suspect APIs should be copyrightable. If

not, then not.

[ Reply to This | # ]

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 )