decoration decoration

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

Groklaw Gear

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

Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal

User Functions



Don't have an account yet? Sign up as a New User

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 4, Thursday, Oracle v. Google ~ pj - Updated 7Xs - Reinhold, Lindholm, Bloch
Thursday, April 19 2012 @ 10:55 PM EDT

We had a reporter in the courtroom again today, and we now have part one of his report. The rest will follow as it is transcribed. On the stand this day first was Dr. Mark Reinhold, continuing his testimony from the day before. Also taking the stand today were Tim Lindholm and Joshua Bloch.

I'll repeat something I noticed Reinhold said on Day 3. First Oracle's lawyer Michael Jacobs and then Reinhold said APIs are blueprints, and yet Reinhold said, when asked if APIs can be too big:

Yes. Humans are bad at managing long lists of uncorrelated information.
So, the truth oozed out. APIs are nothing but long lists of uncorrelated information. That's why they should not be copyrightable, any more than a phone book's white pages contents can be. They are just a list, no matter how much work you put into it or how much money you spend getting it done. That's not at all what a blueprint is, is it? Fess up, y'all. APIs, as Google told you, are not blueprints.

And the most interesting ruling of the day is this one by Judge William Alsup, when Oracle requested that it be allowed to introduce "a 1 GB source code download they did from Google's site on Mar 12th". Google raised concern about verifying exactly when it occurred and what was downloaded. Judge Alsup agreed that verification is reasonable, so Oracle will have to prove when it was they downloaded whatever it was they downloaded.

I assume this is about whether or not Google has really removed the few lines of code it said it removed. And you can understand why Google would want some proof that a download that purports to have happened on March 12 really happened on March 12, not some prior date before the date it says it removed the lines of code. I'm sure we'll hear more about that.

Jump To Comments

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

Google seems to be developing a theme, namely that Java is already fragmented. And it asks a lot of questions about others outside of Sun writing and contributing Java APIs. Oracle expresses concern that Google may be challenging ownership. The judge isn't moved to rule on it to suit them, not yet anyway, but I think at a minimum it's more evidence that Oracle hasn't been spending millions on developing APIs if lots of other companies are donating them, including Google. I mean if Google donated an API, can you now sue Google over the API, after you accepted it and incorporated it and everyone else is using it? So it could be important for the judge and jury to understand the unique way that Java is developed, unlike a more typical in-house proprietary software product. The next witness of the day is a man who wrote such donated code, and then the man who Oracle says wrote the email that it seems to be pretending is "evidence" that executives knew they needed a license. That's not what it proves at all, to me, in proper context, so it'll be interesting to read that, all the details, at last.

Here's finsko's report, part 1, the testimony of Dr. Mark Reinhold:

4/19/2012, Courtroom 8

[BTW, the 19th floor of the Federal building has lots of amazing framed historical photos of San Francisco; it would almost be worth a trip just to look at them. It certainly makes the breaks more interesting for someone who doesn't know how to deal with strangers in suits :-) ]

[In the courtroom, emails and other digital evidence are sometimes displayed on monitors; you can see them (but not really read them) from the audience, but each jury member has a monitor.]

[I have done my best to be accurate, but if something seems completely wrong, it's possible that it _is_ wrong :-). In particular, although I am a programmer, I don't know Java.]

7:30 AM: Judge Alsup enters.

Hands out draft of a "special verdict form" (instructions to jurors) to both sides for editing and revision by tomorrow morning. (Also something about "affirmative defenses".)

Reminds lawyers that it is not allowed to read from deposition text about documents which are not in evidence.

Jurors have submitted a few questions; Judge Alsup reads them aloud. Some were regarding Apache and fragmentation; judge says he will not explicitly address these in instructions, but lawyers should keep them in mind during future questioning. One question is about how the two sides know each other's internal secrets; the judge says he'll address this one.

Oracle's requests:

1) We'd like to move some exhibits into evidence; Google doesn't object.

2) Oracle wishes to use as evidence a 1 GB source code download they did from Google's site on Mar 12th. Google doesn't object to anything that was publicly available on their site, but is concerned about verifying exactly when it occurred and what was downloaded. Oracle wants any such verification to be on Google's clock. Judge Alsup agrees that verification is reasonable, refused to commit to whose clock it is, and warns Google that they may be asking for favors at some point too.

Google has no requests.

At some point, Judge Alsup explicitly makes a comment about wanting to have a record for the court of appeals.

7:55 AM, Jury is brought in.

Judge Alsup inquires about sleep, flu, recommends that they keep washing their hands to stay healthy, and commends them for being prompt. Tells them their questions have been passed to the lawyers, and that the answers should show up in the course of the trial, possibly in a few days or a few weeks. Regarding how the companies know each other's internal secrets, he goes into a few minutes of description about how discovery has occurred prior to the actual trial.

Continuation of Oracle direct questioning (from the previous day) of Dr. Mark Reinhold:

Michael Jacobs is the lawyer for Oracle asking the questions.

Q: java.nio.channels: is that something that's in the Java language specification?

A. No, it's in the Java platform API specification.

Q. Does that specification have copyright notices?

A. Yes.

Q. Was it Sun's practice to register copyrights?

A. Yes.

Q. What is the Java programming language?

A. It consists of two parts: 1) syntax, which is sort of like what you did in elementary school when you diagrammed sentences. And 2) semantics, which is what it means. E.g., there is a syntax to a conditional test, and also a meaning.

Q. [Refers to Java Language Specification (JLS), 3rd Edition, Chapter 18, which collects all the syntax rules]
Does this describe the language? What is the relation betwee classes and API's in the JLS?

A. Language does not specify the APIs, but some of the APIs are referred to in the JLS. Chapter 18 specifies all the syntax rules; these would be used by compiler writers. The JLS does not specify the API; that's in the Java Platform Sepcification. The JLS may mention API classes (e.g., error classes), but they are not specified in full detail.

[Oracle hands Judge Alsup a copy of the JLS]

Q. Does mentioning a class in the JLS mean that that class is required?

A. Yes.

[References here to (exhibits?) 1062 and 1063. 1062 is Dr. Reinhold's analysis of references to (API?) classes in the JLS. 1063 is Reinhold's analysis of references to classes in the Java compiler source.]

A. In the compiler source (analysis 1063) there are references to 39 API classes. These are mostly in java.lang, plus some in and java.util. 3 classes are mentioned in the compiler source, but not actually used; that's a bug.

java.lang.object is closely tied to the Java language.

[Simplistic Venn diagram is presented: the Java language is small, the API set is large, and the overlap exists but is very small.]

Judge Alsup: Are the 37 contested APIs in the shaded overlap area?

Reinhold: No.

[I'm not sure from my notes whether it was Jacobs or Judge Alsup asking the next 2 questions.]

Q. What could you do in Java if there were no APIs available?

A. Very little.

Q. What is the minimum API set that you'd need to add to do something?

A. Input and output.

Q. Do people design their own APIs for Java?

A. Yes, they're usually built on top of existing APIs. (Makes a reference to financial trading.)

Q. Do you need the 37 APIs to do that?

A. No.

Q. Why not just put the classes and APIs into the language; why the separation?

A. Engineering considerations. It's useful to have a fixed primitive core. A programmer needs to know the language, but not every API. The Java language is interpreted by the Java virtual machine; it's best if it's small and doesn't change very often. However, APIs can change like wildfire.

Q: Have the 37 APIs at issue changed over time?

A. Yes, based on experience and learning. Improving functionality, fixing bugs. Sun had 500 programmers at one point working on Java, many were working on APIs.

Q. Is Java being actively maintained by Oracle? How many engineers?

A. Yes, about 800.

[Various exhibits entered: DVD's, books, source code on a thumb drive. Some explicit discussion of 10 or so classes, with Reinhold spelling out stuff like Java.ACL.impl for the stenographer).

Q. Here is exhibit 627, some code for a buffer class.

A. [Discusses @author=Mark Reinhold text, description of the comment syntax, and how some comments are for automatic doc generation.]

Q. Is there a copyright notice in this file?

A. Yes, it says "Copyright 2004 Sun Microsystems".

Cross examination of Dr. Mark Reinhold, by Google Attorney Daniel Purcell
Q. Java is an Object-Oriented (OO) language, correct?

A. Yes.

Q. Did Sun invent OO?

A. No.

Q. Is C++ an OO language, and does it use APIs?

A. Yes.

Q. (Repeat same question and answer for Python and Objective C).

Q. Sun didn't invent the concept of APIs did it?

A. No.

Q. Are there language-independent APIs?

A. Yes, but they're not very good.

[Brief mention about the fact that apparently there are other languages which run on the Java virtual machine.]

[Purcell draws a diagram on the flip board which he describes as showing that the Java APIs come in packages; within a package are classes and interfaces; within classes there are methods; exceptions are part of the API design. Apparently Section 8.4 and chapter 9 of the JLS discuss these things. Reinhold distinguishes the API, Purcell shows a brief snippet of Reinhold's video deposition; I'm not sure what the point was.][PJ: When a lawyer asks a question, gets an answer, and then shows that person's deposition video, it means he thinks the witness contradicted himself.]

[Here Purcell messes up the tech, because he starts asking questions about accessing "source code" from an API].

Q. Without APIs, could Java do I/O? Would it be of much use?

A. No.

Q. Some of the Java APIs were done outside of Sun, correct? And Sun doesn't claim copyright on those.

A. Correct.

Q. Some of the copyrighted APIs (e.g., java.nio) were also done in collaboration with groups outside Sun/Oracle, correct?

A. Yes, sometimes there are expert working groups.

Q. Of the 37 APIs, some were done in collaboration with the Java Community Process (JCP), correct?

A. Yes.

Q. Has Google collaborated on some Sun APIs?

A. Yes.

[It's 8:55, Judge Alsup had earlier indicated that he'd need to take an early break to handle a phone call, and Google indicates that this is a good topic break point, so they break.] 9:15, Judge Alsup reenters.

[Google had been pursuing a line of questioning saying that they'd done 20% of the work on some APIs; Oracle expresses concern that Google is going to contest API ownership, and wants Alsup to instruct the jury that Google cannot contest ownership of the APIs. Google objects, and Alsup sides with Google (doesn't mean he agrees, just that he won't instruct the jury at this time).]

Google cross-exam of Dr Reinhold continues:

Q. Back to JLS, p 6. Some classes have a "special relation" to the language proper (e.g., java.lang.reflect). Exhibit 1062 describes the classes and interfaces references in the JLS. Where are the classes mentioned on p6 described in your document?

[Here, Purcell tries to refer to these classes as "fundamental", but Reinhold emphasizes that that's not correct, the term was "special relationship"].

Q. Was "Write Once, Run Anywhere" important to Sun with respect to Java?

A. Yes, it was a major motivation.

Q. There are 4 classes of Java platforms, correct? Java SE, Java EE, Java ME, and Java Card. Do these use different versions of the Java programming language, and different APIs?

A. Yes.

Q. A developer needs to know what flavor they're writing a program for, correct? A program written for one may not work for another?

A. Yes.

Q. JavaME also has different configurations, such as CLBC, correct? And some configurations also have a range of profiles? So an application written for one profile might not run on another profile?

A. It might, or it might not.

Q. How can this be "Write Once, Run Anywhere"?

A. If you have written for a specific platform, then the program should run on any vendor's version of that platform.

Q. Did Sun have a "OneJava" initiative that was supposed to unify SE and the higher levels of ME?

A. Yes?

Q. And Oracle pulled the plug on OneJava, correct?

A. Yes.

[Google is finished for now]

Redirect of Mark Reinhold, by Oracle's Lawyer Michael Jacobs:

Q. Google asked about accessing source code via APIs; you said you couldn't answer because the question was malformed. Why?

A. Discusses source code and object code (binary, zeros and ones); the API libraries are binary, not source.

Q. Back to the issue of packages and methods, and their relation to API.

A. Packages and methods are fundamental tools of the language.

[At this point, both sides are done with Reinhold for now, but Google says they may wish to call him later].

[More of the day's events to come.]


And here's his part 2, with Joshua Bloch on the stand:

Next Oracle witness: Dr. Joshua Bloch
[Dr. Bloch was fairly animated, and tended to face the jury when he spoke.]

Again, Michael Jacobs for Oracle.

Q. Describe your background.

A. Senior Staff Engineer at Sun from August 1996 to July 2004. One of the architects of Java. Hired by Google in 2004. Also a member of the Android team. Has written APIs for many class libraries. [Some discussion of "JSR's"]

Q. You're an API expert right? Here's a presentation you did entitled "How to Design a Good API" (This version from Javaopolis in Antwerp, 2005, but it has been given in many places, and is probably on the web). [PJ: It is indeed, a 2007 version of it.]

Q. Has anyone at Google objected to the ideas in this presentation?

A. No.

Q. You say "APIs can be among a company's greatest assets."

[Discussion of public versus private APIs, and Bloch's contention in his presentation that all developers need to be concerned with API design. Jacobs goes over and summarizes various slides from the presentation; no objections from Google. One issue is (overly) complex APIs].

Q: How do you know when an API is getting too complex?

A: Names are a part of it; a bad name is an indication of a bad design. In addition, good names can help drive the design: if you have a method called "Publish", it tends to make you think about possibly related method possibilities, like "Subscribe".

Q: What about API size?

A: API size may be an indication of complexity, but it's not just reckoned by number of classes, rather, "conceptual weight".

Q. You wrote "Code should read like prose", what does that mean?

[Amusing bit: I think the intent was that code be somewhat self-documenting, but the example Bloch gave was something about a variable which was "speed", and that code that described car.speed as being twice the speed of light would make you expect that you might get attention from a cop. Judge Alsup suggested that he probably meant "speed limit", not speed of light.]

Q. Can API design affect program performance?

A. Yes.

[Discussion of Bloch's Java "collections" API. More references to Bloch's presentation: "API design is a noble and rewarding craft", "API design is tough". And APIs having an aesthetic component.]

Q. There are various Android APIs that "copy" Java APIs.

Q. The rangecheck function: Did you copy the Sun code while working on Android?

A. I did that while working on Timsort, and it was during the period I was employed at Google, but not for Google. It was something I wrote on my own for OpenJDK.

[I had not heard of Timsort before; it's (apparently) a very efficient sort written by Tim Peters for Python (see Wikipedia), and ported by Bloch to Java.]

[Timsort will come up again later. I'm somewhat appalled by how much fuss is being made over the trivial "rangecheck" function.]

Q. Why did you copy the rangecheck function for Timsort?

A. It's good engineering to reuse the same function if possible [The context here was that he expected to fold Timsort into a public version of Java, and at that point it would make sense to call the existing rangecheck function from the new code rather than writing a different one.]

Q. And you included this in Android?

A. Yes, as part of the JDK.

Q. And you made the function signatures identical?

A. Yes.

Q. [Something about the Sun and Android versions of Timsort being virtually identical.]

Q. When you started working with Android, was there any discussion of it being a conflict with your previous work at Sun?

A. No.

Q. Did you know that Sun attached copyright notices?


Google cross-exam of Joshua Bloch

I didn't get the exact lawyer's name: Bruce (?). He was good.[PJ: Probably Bruce Baber.]

Q. What's your educational background.

A. PhD from Carnegie Mellon.

Q. Any other employers besides Sun and Google?

A. Transarc, a distributed systems company. Acquired by IBM in 1994; I left 2 years later to work at Sun. At Transarc I did library design, implementation, specification, and documentation.

Q. When were you first exposed to APIs?

A. 1982, during an internship at IBM, doing assembly language for a parallel 370. [Clarification of "assembly language."]

Q. Did your doctoral dissertation have to do with APIs?

A. Yes, a collections framework for a fault-tolerant distributed system. Similar to the Java API for collections.

Q. Dr. Bloch: How did you learn the Java language?

A: I read "Java in a Nutshell" on the plane on the way to my interview with Sun [your reporter stifled a guffaw here].

Q. You've written a book called "Effective Java". Does it discuss APIs?

A. Yes, how to use them, and how to avoid traps.

Q. How would you define an API?

A. The names and words and set of rules used to access a library. E.g., method names and field names. Rules: a "contract" (defining preconditions/input, and the result). What you have to say to do something, and what the result is.

Q. When you talk to an API, do you have to be precise?

A. Yes, a single letter wrong will break it.

Q. What happens if you break it?

A. If you're lucky, it won't compile [clarification of "compilation"]. Otherwise, it may give an error when you try to run it. Or it may give you a wrong result.

Q. Your presentation ["How to Design a Good API"] describes an API as a "little language"; what does that mean?

Q. You said APIs should be easy to memorize, why?

A. It makes it easier and more automatic to use it when coding; you don't have to keep looking things up.

Q. So that was a goal at Sun: to be able to use APIs without documentation?

A. Yes.

Q. This will seem like a silly question: is an API something you can hold in your hand?

A. No. The API contains the rules to tell a library how to do what you want. It's abstract. The documentation may be concrete. The documentation should provide enough detailed specification to allow an independent implementation.

Q. Is an API like a blueprint?

A. No: a blueprint tells you exactly how to build something. But an API can be built in various different ways.

Q. In the Java language, what determines the implementation/organization of a library?

A. Fully qualified names: e.g, java.lang.math.cosine(), where java.lang is the package, math is the class, and cosine in the method (goes into detail about the periods and the upper/lower case conventions for names).

Q. So 37 packages corresponds to 37 API's?

A. "Number of API's" is a weird concept. A package is part of an API, but so is a class, and so is a method.

[Judge Alsup gets involved here; he wants to understand this.]

Judge: So what is an API? Is it a package, or a class, or what?

A. You can't really answer that. It's like how "City" and "Street" are both parts of your address. The java.util package has list classes, and other classes; it's all API.

Judge: Is an API at the package level: I want an answer of yes, no, or "can't answer".

A. Well, yes...but classes and methods are also the API. [Somewhere in here the judge drops the issue, but not in a satisfied way :-) ]

[Back to Google]

Q. Does the Java language give you a choice in what a fully qualified name is?

Q. Prior to this trial, had you ever heard the phrase "Structure, organization, and sequence" in reference to APIs?

A. No.

[To be continued]

Update 5: This is the rest of Mr. Bloch's testimony, and I think you'll find it fascinating. And yes, I know it's out of order, but that's because we originally jumped ahead to Mr. Lindholm's testimony because these notes are so much longer and it took longer to transcribe them:

Dr. Joshua Bloch, continued cross-exam by Google lawyer Bruce Baber.
[Note Judge Alsup's interest in and awareness of the technical details. I think Mr. Baber is skillfully getting at some very important points].

Q. What is the relation between the Java programming language and the APIs?

A. Various APIs are mentioned directly in the Java Language Specification (JLS), in narrative text, not in examples. These are required in order to implement the Java language. It includes 3 packages, 60 classes, and around 750 methods. Includes java.lang and

Judge Alsup: How many APIs is that?

[My notes don't record the answer, but I expect it wasn't anything definitive :-) ]

Q. Are there other APIs required to implement these 60 required classes?

A. Yes, any class that is used as an argument passed to any of these classes. There may also be other forms of indirect dependencies. All together, at least 175 classes and 2000 methods are required to implement the language.

Q. What was the earliest version of the JLS you saw?

A. Gosling personally handed me a pre-release of the first one.

Q. What was in the first edition?

A. The language specification, plus documentation for the core libraries. About 4 core libraries, including net and util. They were completely specified.

Q. Could you do anything in Java without APIs?

A. You could add two numbers, but couldn't do any I/O. E.g., the simplest program, the first program you write is "Hello world". This isn't doable without an I/O API.

[Q & A about stuff in Bloch's Antwerp presentation. Programming is easier if an API gives you "good words", specifically names of classes and methods. Doing this is adding vocabulary to the language: new words in addition to existing keywords like "while" and "for".]

Q. Is the relation between Java and its APIs similar to the relationship in other object-oriented languages?

A. Yes [references C#].

[Bloch's duties at Sun included writing new APIs and reimplementing/improving existing APIs.]

Q. What is a "method declaration"?

A. What its name is, what are its input parameters (including names), and what does it return.
Example: "public static int max(int arg1, int arg2)"

Judge Alsup: Is "public" preceded by anything like "declare"?

[Did somebody get Judge Alsup a copy of "Java in a Nutshell"?!]

A. No, it's a convention based on location, where it is in the program text. Just like a dictionary doesn't write "Definition".

Judge Alsup: Do you need anything else to make it work?

A. Of course you do. An API is not the implementation; that code is not part of the API.

Judge Alsup: I think the jury would like to see what else you need. Could you tell counsel how to write it? [on the flip chart]

[Bloch tries, and it's the usual mess trying to tell how someone inexperienced to write down syntactically correct code.]

A. Can I just write it myself?

[I can't see it, but Bloch appears to be writing the Java equivalent of:

extern int max(int arg1, int arg2);

extern int max(int arg1, int arg2)
	if (arg1 > arg2)
		return arg1;
		return arg2;

[He also defines "public" and "int", but says "static" is complicated and not relevant here. Also provides an example illustrating "formal parameters". The white board also apparently contains a package declaration of some sort.]

A: The initial declaration is the API. The calculation is an implementation.

Judge Alsup: [Questions about the naming of the method parameters, and the invocation; answer involves the concept of "passing by value", though that terminology isn't used.]

Q. [Google] Is there anything else in the file?

A. Yes, comments.

Judge Alsup: In what you've written, would you indicate what is the name, what is the declaration, and what is the implementation? Use different colors.

A. Declaration, vs signature. Java uses strange terminology; the signature doesn't include the return type.

[Somewhere in all this Bloch is running out of additional colors of magic markers; he's handed a highlight pen by someone, which the Judge tells him won't work.]

Q. [Google] What is an "argument"?

A. What the programmer passes to the method.

Q. What is the "return"?

A. What the method passes back.

Q. OK, back to my question about reimplementing/improving APIs (say, public APIs). Are there constraints on your creativity in reimplementing an API?

A. Yes, severe constraints.

Q. Are there parts of the API you can change? E.g., the package, methods, classes, return types?

A. No, the only thing you can change are the argument names.

Q. Do you have creativity with respect to the implementing code? Does the API limit you or tell you how?

A. There are no limits, you have much more creativity.

Judge Alsup: If you have two different implementations, will they end up with the same 0's and 1's? [object code]

A. Almost certainly not.

Q. While at Sun (before joining Google), did you have experience with independent implementations of existing Java APIs?

A. [References Sun's implementation of Perl regular expressions; this will come up later, but Google is asking a different question.]

Q. What's an example of a reimplementation of a Sun API?

A. One example is Java's BigInteger. I wrote it in 1.1 as a native method in C, because Java itself was too slow. 1.3 was faster and good enough, so Mike McCloskey and I reimplemented BigInteger in Java.

Q. Did you change elements of the declaration when you did that?

A. No, you can't, it would be incompatible.

Q. Do you know of reimplementation of APIs that originated outside of Sun?

A. Yes, regular expressions (RE). We needed RE's in Java, and the Perl RE API was dominant. We wanted to be compatible with it. So we reimplemented the Perl API in Java (java.util.regex). An additional advantage is we could then use the battery of RE tests from Perl to test our implementation.

Q. Other examples involving external work on Java APIs?

A. Sometimes people reimplementing Java APIs would find issues and corner cases that Sun hadn't considered. [He probably says something about Sun incorporating such changes]. My boss knew about it.

Something about "Classpath" reimplementing Sun's "collection".

[Oracle objects to leading. Judge Alsup instructs Google that the objection can be avoided by properly using the phrase "What, if any...".]

A. If a specification is good (precise) enough to write an alternate implementation, it's good enough for a programmer.

[Break: 11:20-11:35]

[At some point, Judge Alsup informs both Google and Oracle how much of their time they've used. I think it was something like 1000 minutes Oracle, 500 minutes Google, but so far it's been Oracle witnesses.]

The witness continues:

Q. You left Sun and joined Google in 2004. What did you do at Google?

A. I ported existing Google infrastructure that was primarily accessible from C++ so that it was accessible to Java. I joined the Android team in December 2008 or January 2009. Android had already been released, and phones were in the market.

Q. When you joined, what was the status of Android's Java run-time libraries?

A. Not as fast as they could be, and there were some bugs.

Q. Did you have any influence on the choice of APIs?

A. No.

Q. Did you ever consult Sun source code or Sun materials?

A. No.

Q. Did you change any of the APIs?

A. No, you can't. It would make it incompatible.

Q. What is Timsort?

A. A way of putting a list in order [somewhere in here there is reference to compatible Timsort (?)].

Q. How big is Timsort (referring to Bloch's Java implementation).

A. 900 lines.

[The rangecheck() function gets mentioned in here.]

Q. Was there a sort API in Java before Timsort?

A. Yes, in the arrays (class? package?).

Q. How did Timsort differ?

A. It was much faster: as much as 20 times, typically somewhere between 2 and 20.

Q. How big is the rangecheck() method? Is it a private or public method?

A. It's a private method, about the same size as max() (so: small).

Q. What does rangecheck() do?

A. It's necessary when you have a sort method and you might be sorting a partial list or a whole list. You need to check that the indices are within range. It would be an error if an index was negative, or the indices are in the wrong order, or are not within range of the list.

Q. Is rangecheck() simple or complex?

A. Very simple. Any high school programmer could write it.

Q. Do you know of the existence of other rangecheck() functions?

A. Yes, there's one in I wrote it. [Timsort: from Tim Peters, and originally in Python. The Java implementation was a port.]

Q. Where did you get the Python version of Timsort? Was it open source [this was 2007, pre-Android]?

A. Yes, Guido [van Rossum] pointed me to it, it's under a permissive open-source license.

Q. What did you want to do with your Java Timsort?

A. Put it into OpenJDK (an open implentation of the SE platform).

Q. Who controlled OpenJDK?

A. Sun.

Q. How does someone contribute to OpenJDK, and had you done it before?

A. Yes. [Discussion about source repositories, and Doug Lee at Oswego, NY].

Q. If you worked for Google, why would you contribute to Sun's JDK?

A. Java is important to me; it's given me a lot.

Q. Why did you use the same rangecheck() function in Timsort as was in

A. It's good software engineering to reuse an existing function.

Q. But why use the exact same code?

A. I copied rangecheck() as a temporary measure, assuming this would be merged into and my version of rangecheck() would go away.

[Discussion of Timsort dates and Android work dates.]

Q. Was Timsort accepted and added into OpenJDK?

A. Yes.

[Something about Java 7.]

Q. Did Sun ever say anything about Timsort?

A. Yes, Mark Reinhold praised it for its speed on his blog.

Q. What else did you contribute to Java 7?

A. ARM Block: Automated Resource Management. Like automatically closing a file. This wasn't just an API, but a language feature. It added to the language itself and changed the grammar.

Q. Is it often that case that the language and the APIs change in tandem?

A. Yes.

Q. Are the 9 lines of rangecheck() currently in Android?

A. No, not in Ice Cream Sandwich; I checked.

Q. Are you still contributing to Java?

A. Lots. I feel a personal responsibility to give back to the Java ecosystem.

Q. Have other people at Google contributed to Java?

A. Yes.

Redirect of Joshua Bloch, by Oracle's Michael Jacobs:
[12 Noon. Jacobs seems pretty harsh, but he's also rushing because of the clock.]

Q. Can you deny that you copied rangecheck() from Sun code?

A. I can't confirm or deny. If I did, it was a mistake.

Q. Did you cast the only vote against the JCP approval of SE7?

A. [Bloch refers to 3 people resigning, Apache Harmony licensing, and TCK license. Some confusion.]

Q. [Referring to the flip chart with max() on it]. Your presentation talks about creativity and artistry in APIs. Is the creativity and artistry in a single declaration, or in the packaging?

A. [No real answer.]

Re-cross by Google:
Q. Please explain your JCP vote against SE7; Oracle didn't give you time to explain.

A. Sun and Apache had a dispute over licensing.

Q. Did you ever hear anyone at Sun say that Apache was violating the license?

A. No.

[Google wants to put the first edition of the JLS into evidence. 300 of the 750 pages were devoted to APIs.]

[Oracle is finished with the witness; Google says they may wish to call him back.]

Update 2:

We're jumping ahead to the last part of the day, Tim Lindholm on the stand, because there is so much interest in him and his email.

: )

Then, we'll come back and finish up the second part of Joshua Bloch's testimony and the discussion among the lawyers and the judge after the jury was dismissed. [Update: Done. See update 5, above, for Bloch and update 6 for the end of the day.

Here's finsko's report on Lindholm's testimony:

Timothy Lindholm
He is a former Sun employee. He seems a little nervous and unsure.

[I think it was David Boies for Oracle, and for Google a female lawyer, but I didn't hear either of their names announced.] [PJ: Perhaps Christa Anderson?]

[Often, Tim does not remember the emails in detail, and doesn't always know who the people referred to are. Given that being cc:ed on a email doesn't necessarily mean you open it, much less read it, and that some of this is 7 years ago, this doesn't surprise me, but it's what's happening in some of the unanswered questions below. Similarly, when asked about the contents of an email, Tim often pointed out that the contents under question were written by somebody else, and Tim himself has no direct knowledge of it.]

Q from Oracle. Background?

A. Bachelor's degree; have written multiple editions of a book on Java virtual machines.

Q. Does Sun hold copyright on these books?

A. [Looks at physical copies of books, and finds copyright notices]. Yes.

Q. Did you meet Andy Rubin when you were at Sun?

A. Yes.

Q. Did you have a discussion about Android using Sun's IP?

Q. When did you leave Sun?

A. Don't remember precisely.

Q. When did you join Google?

A. July, 2005.

Q. And you worked on Android at Google?

A. No.

Q. Here's a document: mail from you to Mr Rubin, Oct 2005. You and Mr Rubin were both at Google at that time.

Q. Is "Alan" someone at Sun?

A. Yes, I think so.

Q. You were aware that Sun was concerned with fragmentation, and that Sun wanted to preserve TCK revenue?

A. (Probably answers per above)

Q. Here's a 2nd email, July 26, 2005, from Andy Rubin, cc:ed to you, re a GPS meeting.

A. I don't recognize it.

Q. Here's a 3rd document, from Andy to Tim, re licensing discussions with Sun. There's a bullet point in this document saying that Google needs a TCK license.

A. I wasn't involved in Sun discussions at this point.

Q. Here's another document, an exchange between Tim and Andy Rubin, Dec, 2005. Andy: "We'll either have to partner with Sun, or take a license". Was that your understanding?

A. It appears to be Andy's understanding.

Q. Here's a 5th document.

Q. Here's another document, from Tim to Andy and others, August 2010, and it references Larry and Sergey. Subject is investigation of technical alternatives to Java for Android and Chrome. "They suck. We need to get a license for Java."

Google: Objection.

Q. Did you mean a license from Sun?

A. No, I wasn't referring to any specific license.

Google cross-exam of Tim Lindholm
Q. Where do you live?

A. I've lived in Palo Alto for 21 years.

Q. Educational background?

Q. What is your job at Google?

A. I work on infrastructure: the data centers.

Q. What did you do at Sun (1994-2005).

A. Also infrastructure: computer utilization. More efficient utilization of computers means you have to buy fewer of them.

Q. Did you have experience with Java at Sun, and do you understand the organization of APIs?

A. Yes.

[Oracle objects that the questions are going out of scope. Judge says Google can call the witness later and then Google can ask whatever they want. Google says there are only a few more (arguably) out-of-scope questions, and it will save having to call the witness back later. It's only 3 questions, so they're allowed.]

Q. Do you have an opionion about whether the organization of the Java API packages is free to use?

A. As a SW engineer, I feel that the organization of software APIs is free to use.

Q. Were you surprised when Google acquired Android?

A. Yes.

Q. Did you do any Android work at Google? Any specs or code, any architectural decisions?

A. No.

Q. Trial exhibit 17: Do you recognize this email? (Mail to Bill Cochran/Koren? re "critical license").

A. Sun and Google were discussing a co-development agreement using Sun source code.

[Sidelight: at some point in here, Oracle objects to Google asking questions about what Tim "thought" was happening back then. Judge Alsup (for a second time; he also did something similar during the Bloch testimony) tells the lawyer how to avoid the objection: use the phrase "At that time": "At that time, did you think...]

Q: Exhibit 318, email notes from Tim to himself titled "Android Notes"

A. At the time, I was surprised by this new project (Android) and was deciding whether I should get involved with it.

Q. Another email, Aug 9, 2005, (1 month after Tim joined Google), discussing possible roles for Tim within Android). Did you ever take those roles?

A. No.

Q. Another email: do you remember who Dave Suboda is?

A. No.

Q. It says something about "Java lawsuits going away", what does that mean?

A. I have/had no idea. There were no Java lawsuits.

Q. Exhibit 330: an email you wrote referring to Microsoft "stealing" Java.

A. Refers back to Sun/Microsoft litigation; concerns about Microsoft taking Java and making an incompatible version: Visual J++.

Q. Let's go to Auguest 2010. Did you ever review Android source code?

[Oracle/Boies objects, objection sustained.]

Oracle redirect of Tim Lindholm
Q: Trial exhibit 12: Did you think Google needed a license re partnership agreement?
[Lindholm is free; no need to return; he looks very relieved]
While we wait for the rest of the pieces, here's a video from Wall Street Journal with a report about the trial. One correction: if you use the Open Source Java code, you don't have to pay. Also, there is no allegation that a lot of code allegedly infringed. Here's Dan Farber's coverage of the day, with pictures of the witnesses for you and a chart showing all the 37 APIs:
Bruce Baber, representing Google, also took Bloch through the "range check" topic. Bloch said "any competent high school programmer could write it," and that he wrote, porting open-source code from the Python language to Java in the middle of 2007, when he was not a part of the Android team. was contributed to the Open JDK by Google under the GNU General Public License version 2 in 2009. "I really feel a personal responsibility to give back to the Java community It made my career," he said.

Baber walked Bloch through a lengthy definition of API. He defined an API as "names or words and a set of rules." ...He added, through Baber's prompting, that an API is not a blueprint that tells you how or to build or implement something....Bloch and Reinhold both said that the Java language is mostly useless without APIs, and other object-based languages have APIs.

Update 3: Some clear coverage of Lindholm's testimony from Chris Mayer at jaxenter in his article, "Google vs Oracle - Google engineer Lindholm says Java licensing email misinterpreted":

The focus shifted towards API copyrighting, which Oracle fervently believe that Java is indeed covered by. Lindholm had a different view saying:
As a software engineer, not a lawyer, it's always been my understanding the organisation of software APIs are free for use by other people.
Later on whilst being cross-examined by Google's counsel Christa Anderson, Lindholm added that he believed that the software Oracle believes is rightfully theirs, is in fact free to use by all. He was also asked about his role at Google, which Lindholm said was working on infrastructure and not substantially on Android itself. Which begs the question, why would he have sent the original email? Lindholm said that because of his background with Java and Sun, he was involved in Java licensing and partnership negotiations between Google and Sun, which of course broke down and never materialised to anything concrete....

Reinhold believes that around 20% of the Java API packages were written by JCP members, so neither Sun or Oracle. Ten of the 37 APIs were indeed created in this manner, free of Oracle/Sun's rule (ie. unpaid).

Update 4: He's getting the rest to us. He doesn't live in San Francisco, so he had to travel. But here's a preview of part two of Bloch's testimony:

[Bloch's duties at Sun included writing new APIs and reimplementing/improving existing APIs.]

Q. What is a "method declaration"?
A. What its name is, what are its input parameters (including names), and what does it return.
Example: "public static int max(int arg1, int arg2)"

Judge Alsup: Is "public" preceded by anything like "declare"?

A. No, it's a convention based on location, where it is in the program text. Just like a dictionary doesn't write "Definition".

Judge Alsup: Do you need anything else to make it work?

A. Of course you do. An API is not the implementation; that code is not part of the API.

Update 6: Here's the final part of the day, from finsko:

1 PM, jury is dismissed.

Oracle requests:

1. Something about wanting to relax requirements regarding expert reports; Google objects.

2. Wants to allow expert to testify about some matters that have come up during trial; Google consents.

3. Something about experts giving technical vs legal opinions.

Google: no requests.

[The next stuff, in retrospect, is probably pretty important, but my notetaking was fading.]

Judge Alsup: The copyrightability of the 37 APIs is my call. But I want more briefing on it. I want you to take a firm position. Could you get a patent on structure, sequence, and organization (SSO)? Say "yes" or "no".

Also, do you know if the copyright office investigates SSO of copyrighted source code? I would guess not.

[Google answers "no", Oracle answers "maybe yes, maybe no"; I'm not sure which question this refers to.]

[Copyright office only gets first 50 lines and final 50 lines of the source for a SW copyright registration, so of course they don't look at SSO.]

Judge Alsup: OK, what about derivative works? Does the plaintiff have to prove that the source work was actually used? What if it was accidental overlap?

Oracle: Proof requires access, plus substantial similarity.

Google: Unauthorized work has to include copyrightable material.

Judge Alsup: When Google did their clean room implementation, did they have access to the English language comments [in Java source]?

Google: Yes, they had the English language prose descriptions of the APIs.

Judge Alsup: Does that make it a derivative work?

Google: No.

Google: The fully-qualified names are the organization.

Judge Alsup. I have to decide on copyrightability, not the jury.

You don't have to do exact copies, e.g., you could use science.sqrt() as your method rather than math.sqrt()

Google: It wouldn't work; existing code wouldn't find it.

Judge Alsup: Is fair use a question for judge or jury?

[1:30 or so, Judge leaves the courtroom]

Oh, my. This is important indeed. The judge has accepted that he's the guy who has to rule on whether or not APIs can be copyrighted. The jury will not make that call.

Update 7: 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 4, Thursday, Oracle v. Google ~ pj - Updated 7Xs - Reinhold, Lindholm, Bloch | 270 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections Thread
Authored by: bugstomper on Thursday, April 19 2012 @ 11:02 PM EDT
Please summarize error->correction or s/error/correction/ in the Title box

[ Reply to This | # ]

Off Topic threads
Authored by: bugstomper on Thursday, April 19 2012 @ 11:03 PM EDT
Please stay off topic here

[ Reply to This | # ]

News Picks Thread
Authored by: bugstomper on Thursday, April 19 2012 @ 11:04 PM EDT
Pick your News here. Please put the title of the News Pick in the Title box and
include a clicky link to the article for when it scrolls off the sidebar.

[ Reply to This | # ]

Comes transcripts here
Authored by: bugstomper on Thursday, April 19 2012 @ 11:08 PM EDT
Please post your transcriptions of Comes exhibits here with full HTML markup but
posted as Plain Old Text to make it easy for PJ to copy and paste.

[ Reply to This | # ]

Day 4, Thursday, Oracle v. Google ~ pj
Authored by: Anonymous on Thursday, April 19 2012 @ 11:13 PM EDT
I don't understand how copyrights can be part of this case. As I understand it,
much of the java specification and core library was released under the GPL2...
which--as microsoft is so fond of saying--is viral. That is, if any one part of
the "system" is put under GPL then the entire quantity has to be under
GPL. That would imply java.lang and any java.* and any API whatever. (The
link/library safe version is the LGPL, which is not what this is licensed

What "line" am I missing that the GPL cannot cross?

[ Reply to This | # ]

A. Packages and methods are fundamental tools of the language.
Authored by: Gringo_ on Thursday, April 19 2012 @ 11:41 PM EDT

Isn't that the smoking gun, right there? "Packages and methods" are part of the API specification. He is saying they are fundamental to the language - ie: the foundation. So if you have a right to use the language without a licence, then you have a right to the API specification, and therefore you could use that to write your own libraries that perform the same function's as Java's libraries.

This was on redirect of Mark Reinhold, by Oracle's Lawyer Michael Jacobs. This is Oracle's witness - telling the world that the API specification is fundamental to the language.

It's late, and I am very tired. Do I have that right?

[ Reply to This | # ]

APIs are not source code
Authored by: Anonymous on Thursday, April 19 2012 @ 11:42 PM EDT
And what I learned is that APIs are not source code. They are ones and zeroes for the computer to use. Correct me if I'm wrong, but how can you copyright ones and zeroes?
PJ, it is all about context when referring to the APIs. (Oracle are doing their best to muddy the waters here by using the term on its own without qualifying whether they mean the documentation, specification, source code, or binaries).

An API has to be developed in a computer language as source code. After that (in the case of Java) it is compiled into byte code and shipped to customers in a library (binary form). The average person coding in Java only needs access to the libraries to produce their programs. Whilst the source code to the APIs might be made available too, it is only there for reference purposes. That is my understanding. It is certainly not essential for developing Java software - only the Java byte code interpreter (JVM) and the libraries containing the APIs in byte code form are needed.

As far as I know, only the API source code can be subject to copyright. I can't imagine that the API libraries output from the Java compiler can also be subject.

[ Reply to This | # ]

APIs are not source code?
Authored by: mschmitz on Thursday, April 19 2012 @ 11:56 PM EDT

"And what I learned is that APIs are not source code. They are ones and
zeroes for the computer to use. Correct me if I'm wrong, but how can you
copyright ones and zeroes?"

I hate to correct you - but the quote was about 'API libaries'. These are, in
fact, binary code. The particular arrangement of these ones and zeroes may be
copyrighted as far as I've understood (as specific machine-readable expression
of the idea 'API'), is that not so?

Jacobs' question (which is what Reinhold answered with above quote about API
libraries) was: "Google asked about accessing source code via APIs" -
this does not seem to be mentioned earlier in the report, and the question does
not make much sense on the face of it. Why would you need to use the Java API to
access some source code? You might need a way to access what version of Java
(ME, SE, EE) the application is running on, but source code??

It again boils down to the question: what is an API? At its most basic, as best
as I can make out, the API is a set of method definitions, describing exactly
how an application can go about invoking methods supplied by the supporting
framework (runtime system, operating system, other software libraries aka
'classes' or 'packages').

The method definitions can be given in plain (?) English, as set of method name,
return type, parameter type(s) and parameter ordering , and a textual
description of the effects and side effects of the method (at least that's how
it works in functional languages; some of this may be different in object
oriented languages).


Method 'print', returns integer (0 for success, -1 for error).
Parameters: format of 'stuff to print' (string), actual stuff to print (number
of parameters and types as described by format).

Effect: stuff to print is sent to the big bit bucket in the sky, formatted
exactly as requested.

Side effects: all variables passed (as 'stuff to print') are destroyed.

Not very useful, maybe, but it is a valid definition of a method 'print' in my

To implement the API, someone at some stage will have to write actual source
code, and compile that into the API library. Sun's source code and library will
differ from Apache's source code and library. Any of this can be copyrighted and
licensed. The question around which this case revolves (as it seems to me) is -
can the API (the set of method definitions) be copyrighted, or is its structure
and arrangement fully dictated by the requirement of compatibility?

To me, at least, that last point is clear: method names, the return types,
parameter types and parameter order for any compliant implementation have to be
the same in order for the implementations to be compatible. Deviating from the
API definition means you're not implementing the same thing. In order to make
use of the API as defined, you have to stick to the definition, to the very
letter. Copyrighting this and still claiming 'everyone is free to use it' seems
pretty dishonest to me. It should not even be possible to copyright the plain

What have I missed? (I'm not actually certain whether the parameter ordering
needs to be matching in Java, or whether parameter naming in addition to typing
is used there. Correct me if I'm wrong.)

So in a way, you are right - APIs are not source code. But they are not ones and
zeroes to be used by the computer either (that would be the API libraries).
Except in the very narrow sense that, in order to store or transmit the API, I
will have to turn them into the ones and zeroes of an e-mail, or HTTP post, or
something. APIs are recipes for writing source code (both that of the API
libraries, and that part of your application making use of the APIs).

Which meaning of API are Oracle and Google talking about?

-- mschmitz

[ Reply to This | # ]

Day 4, Thursday, Oracle v. Google ~ pj
Authored by: Anonymous on Thursday, April 19 2012 @ 11:57 PM EDT
"And what I learned is that APIs are not source code. They
are ones and zeroes for the computer to use. Correct me if
I'm wrong, but how can you copyright ones and zeroes?"

The way that the witness had phrased the answer was really
misleading (per the transcript that is done live and not

Any program can have an API. If you were to write a web
forum in Java, you could have an API that others can use to
interact with your forum.

An API is a function (or functions) with the main purpose of
allowing other programmers or programs to interact with
whatever the API was written for. So in the we forum
analogy, lets say you wanted to allow people to post from
another website to your forum. Instead of making them go to
your forum, the other websites developer would collect the
post from the end user and post it to your forum
automatically using the API.

Most programs in Java are written in source, which means
that they are not compiled into byte code (what the computer
actually deals with) but in human readable code. The java
language interprets the human readable and compiles into
into byte code at run time.

What the witness is saying is that the API's are pre-
compiled into byte code and shipped with Java in a non human
readable format.

The reason for this is byte code does not have to be
compiled on the fly and thus it is quicker to execute.

So saying that API's (in general) are not source code is
incorrect. They are source code at some point in time,
however once they are shipped they are already compiled and
in non human readable format.

[ Reply to This | # ]

Is the jury up to the task and what is a 'matter of law'?
Authored by: Anonymous on Friday, April 20 2012 @ 12:56 AM EDT
Yes. Humans are bad at managing long lists of uncorrelated information.

The problem, as i see it, is that it's the subtleties of this case can easily be lost on the jury as Oracle continues to uses terms inconsistently to describe what was stolen from them. Unless the jury is up to the task and makes appropriate connections, for example to the statement above, then the many many statements by Oracle that their designs (API specifications) are copyrighted by Oracle could win ground.

It's unfortunate that the court considers Oracles view that API's are copyrighted a 'fact' to be resolved by a jury. At what point is someones view of 'a fact' considered by the court to be so skewed from reality that it then becomes 'a matter of law' to be resolve by a judge?

[ Reply to This | # ]

Reinhold is wrong, Bloch is correct
Authored by: bugstomper on Friday, April 20 2012 @ 01:41 AM EDT
PJ, that thing you were led to understand by Reinhold's statement about
"API libraries" being binary is wrong, because there is no such thing
as an "API library". Either Reinhold was wrong or it was
mis-transcribed by the reporter.

The binary files that are installed on any platform that runs Java programs are
called the Java Class libraries, not API libraries.

Joshua Bloch had the more accurate description of what APIs are. Reinhold was
either lying (I assume he does know about APIs and is not just ignorant) or more
likely was saying things that are precisely truthful but phrased in a way to
mislead the non-expert into thinking that he was saying something else, mostly
by conflating the API with the class libraries themselves.

I really like how Bloch is not simply accepting much of the obfuscating
terminology that has been thrown around such as calling the 37 packages 37

I do wish he had had the presence of mind to give a clearer answer to Judge
Alsup's direct question about that. Something like

A library is a collection of software that performs some useful functions and
can be installed on a computer where it is available to be called by application
programs on that computer. Java has several libraries, such as the Java Standard
Library which contains the most generally useful functions that are required by
most applications, the Cryptographic library which contains functions used for
encryption and so on, and others. Each library is organized into packages,
classes, and methods. The API for a library describes how to use it, including
which packages, classes, and methods it contains. If you are talking about
different libraries you might want to talk about different APIs describing how
to use them. The 37 packages are not in 37 different libraries. Many of the 37
packages are sub-packages of another package in the list, clearly belonging to
the same library. And if they are all lumped together in the same runtime
environment you might even call them one library, and therefore one API. There
is no hard and fast way to enumerate them as a certain number of APIs.

[I just though of a monkeywrench to throw into the discussion of "what is
an API?" How would one explain a phrase like "the Collections
API" which does not refer to a single library or even package, but is an
API to use to make use of any class that implements the Collections interface?]

[ Reply to This | # ]

Authored by: Anonymous on Friday, April 20 2012 @ 02:03 AM EDT
If these guys would learn a little bit about the law they could explain these
things better!

API:packages,classes,methods::LAW:laws,common law,precedence

[ Reply to This | # ]

My take on 'What is an API'
Authored by: calris74 on Friday, April 20 2012 @ 02:26 AM EDT
To talk about an 'API' as a tangible thing is completely nonsensical - You need to either talk about the:
  • The Specification - i.e. The documentation
  • The Implementation - i.e. The code
  • The Library - i.e. The compiled implementation stored in a file on disk
  • The Instance - i.e. A copy of the library (in part or in full) in memory
  • The Interface - i.e. The interaction between the programmers compiled code and the instance of the implementation of the API definition

Remember, the I is 'Interface' - A program 'calls' or 'invokes' the API. But there are many ways an interface can be invoked....

Lets so I have an API definition of:
int sum(int a, int b);

That in itself is not enough to actually use the API. Behind the API is what is usually called the ABI (Application Binary Interface). This is usually hidden by the compiler and specifies whether the parameters are passed on the stack (and if the caller or callee removes them from the stack when the function return) or in registers, what registers must be preserved etc.

Digging deeper, how does the users application interact with a library - You start to enter the world of dynamic loading and linking which gets into the Operating System and System Libraries.
That leads you to how the library file which stores the implementation of the functions listed in the API Definition. What is there file-format, where are they located on disk, how are they indexed, accessed etc.

So Google's implementation of java.lang.math.sum is an exact match for the API Definition but under the hood they are probably completely different. And not just in terms of lines of Java code, but also in the way the application interacts with the library files itself (and this is all controlled by Dalvik)

So even if you independently implement 'The Specification' and somehow 'The Specification' is copyrightable (which I doubt) then it could be argued that such copying in itself is de-minimis

Microsoft has already fought and lost the 'Independent implementation of a specification' battle one copyright grounds, but won it on patent grounds (the FAT patent is one case in point)

I cannot see how the 'API' question can be anything but a point of law...

[ Reply to This | # ]

The big download...
Authored by: mtew on Friday, April 20 2012 @ 02:33 AM EDT
This could be a problem.

Consider what would happen if Oracle downloaded the entire source archive, or an
archive copy of one of the older versions of Android that contains the now
removed files.

They could argue that the disputed files have not been removed at all. Since
this is legal issue, they might have a legal point.

Of course one of the HUGE points about Open Source is that you can examine the
history of the code.

I think they are likely to argue that the disputed code has not been removed and
that Google has to pay for keeping copies of it.

Of course this will reek havoc on keeping accurate and transparent records of


[ Reply to This | # ]

An API is...
Authored by: Anonymous on Friday, April 20 2012 @ 03:23 AM EDT
This is my understanding ( for the last 20 years ) of an

A library is a collection of classes/functions that serve a
common purpose to reduce a programmers work, by not
requiring him to implement from scratch features not central
to his program.

For example, a cryptography library allows a programmer to
use cryptography in his code without implementing
cryptographic functions from scratch. A person whose
application needs to communicate with the internet, uses a
networking library instead of hand coding network

An API is exactly what it says it is. It is an interface to
a library that application programmers use. It is a
description of the protocol one needs to follow when
utilizing a library.

[ Reply to This | # ]

  • An API is... - Authored by: Anonymous on Friday, April 20 2012 @ 08:21 PM EDT
  • An API is... - Authored by: Anonymous on Friday, April 20 2012 @ 10:56 PM EDT
API not a concrete thing, it doesn't have a level
Authored by: BitOBear on Friday, April 20 2012 @ 04:05 AM EDT
Where the judge asks if the API is at class level or the package level he is
making an ontological mistake. He is addressing it as if it is a concrete and
distinct thing (like a chair) when it is a metaphysical thing (like "the
proper use of a chair").

So go back and read my stuff about forgetting the first two words Application
and Program, and then ponder the word Interface.


Okay, so say I sell a device like a carburetor for a car, and there are a bunch
of screws on it to tune the mixture and limit the accelerator. There is also a
surface where the carburetor bolts down onto the intake manifold. There is also
a place where the air cleaner housing bolts down on the carburetor. There is the
place where the gas line hooks on and the place where the accelerator cable is
attached. All this constitutes the "physical features" of the

But a skilled mechanic knows that when the carburetor is mounted it will need
gaskets and will likely want to apply at least so much torque and no more than
so much more torque. He'll also know that if the thing is brand new he almost
certainly doesn't want to mess with the mixture screws since they were factory
set. He'll know that the accelerator line needs to pivot freely at the point of
attachment to the arm so he wont over tighten that or he'll use a special dingus
of some sort.

Now the driver may not know from the carburetor even though they use it every
time they move their foot more or less on or off the accelerator.

Now a "gear head" owner may want to go in and tweak the mixture.

So what is the interface?

It's the physical thing's points of interaction with other things but it is
-also- the information about how that interaction will effect the thing, and how
the thing will effect other stuff (like engine intake pressure and engine speed
if you "punch it").

So there are things and there are rules.

Any single API is "one set" of thing and rules that "make
sense" when you lump them together.

If I have two ponds, and I drain one, do I still have two ponds or do I have one
pond and a ditch? Does it matter if the water from was drained into the pond
that still has water.

It's hard to define an API as a thing because it is typically a set of things
that are themselves examples of the thing you are trying to define.

Example: The package is (hopefully) a rational set of things that make
sense together and represents a large API. It encompases a number of smaller API
such as those dealing with "sockets" and those dealing with
"addresses". And of the socket API it has the API for
"server" sockets in a connection, "client" sockets in a
connection, and "peer" sockets in a connectionless transmission (UDP
etc) communication setup. These socket APIs often use or relate to the address
API, which is why its part of a larger API.

Part of the reason the expert was agog is that the lawyers are asking questions
that are kind of metaphysical. The lawyers drew distinctions with a fine line
where the expert knows there is an expanse of shadow and gray.

Now, the API files are discrete for being files, not for the interface part.
Each file is discrete but there is no telling how much of which files constitute
the interface.

In C on linux, for example, if I look up the "connect" verb ("man
connect") from the network API, I am told that I will need to include the
files "sys/types.h" and "sys/socket.h" to be able to use
"connect". If I want to read data from that socket using
"read" I will need the file "unistd.h". This documentation
of these two simple corner of this API don't tell me what all the compiler will
need to do, just what I need to do to get the compiler to do what it needs to


Well those files tell the computer how to find and understand the tidbits, but I
am the one who knows that after I "connect" the socket I will want to
"read" it. The compiler is the one who has been told what makes sense
at one level.

Thin is, I could take the value returned by connect and misuse it (say take its
cosine, or use it as a denominator in some math).

Classes are a feature of an advanced language (like C++ or Java) to help keep
things in useful piles and to help discourage misuse. The C network interface
returns an integer, the interface likely returns an instance object of
a ServerSocket class type or something. When the java machine talks to the
operating system it has to pluck that integer out of the bigger class instance
and call read with it (or whatever) but now the Java Programmer can't make the
cosine misuse.

Additionally a formal API may define that there "shall be" a class
called "ServerSocket" and said class "shall contain" some
particular members. If you go look at that class you may discover that it
contains far more than the formal API defined. You probably don't want to touch
those other things. They are there, you can use them, but they are not part of
the "formal API". There presence makes them part of the "defacto

Lots of people use the defacto API to things to make magic happen. But you
better be a wizard to do it or you may end up with a dead assistant.

Some famous judge said "I cannot define obscenity, but I know it when I see
it." If I were a lawyer I could tell you which one it was.

Well as a professional in the art, I cannot define "an API" or tell
you whether "an API" is at the class or function call level (its at
bother and neither) to a degree that would have a legal meaning, but I can tell
you if the files you give me constitute "at least one" and whether it
"sucks." 8-)

Only the compiler for the language can tell you if the API files are sufficient
to let the compiler make sense of the code. This is why compilers have error
messages about missing files and undefined terms and symbols.

Only the library knows what will happen if you call a given function in that
library with a given piece of data. This is why we have runtime errors.

From the other angle, an API is whatever the API writer says one is. The entire
Lisp language API (e.g. talking to the language not the operating system running
it) consists of a single function call named "eval" that takes a
string. This has been true for decades and whole volumes and bookshelves of
documentation and guides have been created to tell you what to put in that
string argument to get different things to happen.

No I am not joking, and this is not hyperbole.

Look up the game "go" and then ask the question "what is a go

Really. No concrete, universal, legally testable definition of API is possible.

[ Reply to This | # ]

Are APIs really "nothing but long lists of uncorrelated information"?
Authored by: Anonymous on Friday, April 20 2012 @ 05:08 AM EDT
The lead article makes this claim, but I don't understand it, maybe
someone could explain. It also seems to take Reinhold's remarks out of
context. At the time, he is describing the efforts taken to make the API
understandable for its users. The organisation of classes and methods is
anything but uncorrelated or random. I think he was just trying to say, yes
an API can get so big and unwieldy that its useless.

Also, the article goes on to imply that a list of uncorrelated information is
not copyrightable? Surely a list is copyrightable?

I hope there is some other argument against the Oracle position. For
example, wasn't there some argument against the claim that definitions in
C header files couldn't be subject to copyright?

[ Reply to This | # ]

Oh! I'm such a twit. How could I be so stupid!
Authored by: Ian Al on Friday, April 20 2012 @ 05:40 AM EDT
You guys tell me stuff and give me stuff to read and I might as well line my parrot's cage with it (lovely plumage, the Norwegian Blue).

I'm not going to show you the spectacular creative expression in the nine lines of rangeCheck again after your previous hysterical laughter. I will, however, repeat bugstomper's comment,
Note that the three if tests and their throw statements follow the order they are described in the specifications.
In other words (if I have this right) there are three 'if' statements which check for range errors and, if one is found, the relevant call is made to the 'throw' API to return the type of error to the program.

Let me show you the implementation code from the Google slide for the max() API function to decide which is the biggest number. Please forgive the indentation which I could not quite master:
public static float max(float a, float b)
    // this check for NaN, from JLS 15.21.1, saves a method call
      if(a != a)
        return a;

    // no need to check if b is NaN; > will work correctly
    // recall that -0.0 == 0.0, but [+-]0.0 - [+-] 0.0 behaves special
    if (a == 0 && b == 0)
    return a -- b;
    return (a > b) ? a:b;
This is the max() implementation code from GNU Classpath 0.9.8 and not the one from OpenJDK which is shown on the following slide. I suppose GNU were another member of the JCP just like Harmony.

As you read it, you might just miss the point that you are reading it. You can see math going on and the appropriate result being returned to the program calling the max() function API.

The rangeCheck code calls the function 'throw' in another API. We can read it and understand what it is doing because it is written in Java source code and uses the Java API Specification. Now, its no use to man nor beast in source code form. It needs to be compiled in order to be executable. If you are a Harmony or an Android user you are told to download the Oracle JDK complete with the Sun API implementation code and use the compiler that comes with it. That, of course, comes with a full licence to any patents or copyrights necessary to program in the Java language for the Java Runtime Environment.

If the API implementation code is written in Java source code and compiled with the Sun compiler, then the resulting code is Java byte code that only runs on the JRE. Supposing you want more API libraries for use in your programs. Are you permitted to devise additional classes and write the implementation code for the class libraries? Of course you are! In fact, someone reported that the javac series of APIs were not originally in the Java API Specification but were adopted by programmers so quickly that they were hastily cobbled in. Don't forget, you can write any APIs you like using all the Sun Java patents and copyrights. You are fully licensed.

So, Google were just fine in using just the 37 Sun API packages they needed for Dalvik and adding more APIs for their own programs. The problem is that Java is not free speech. Sun made it impossible with the API implementation to bar the APIs that would break a programmer's program. Google had to use the Harmony implementation code and add the remaining Dalvik APIs or else give programmers a list of thousands of classes from the downloaded JDK that they must not use if they are programming for Dalvik.

The additional Dalvik APIs are just fine because the JDK is written to support additional APIs written in Java. Google had to separate the authorised Harmony APIs needed for Dalvik away from the Sun API set, because Java is the language in the iron mask.

Pulling out just the Harmony APIs that were compatible with Android was the only sensible way of stopping Java programmers programming for Android apps using the Sun APIs which were incompatible with Dalvik.

It's not a problem, though, because Google ask Android programmers to download and use the Sun JDK and with that comes a full licence to use all the Java copyrights and all the Java patents. Sun said how happy they were that the Harmony project (part of the JCP) had implemented the APIs and they proposed to Google that they partnered with Sun and used the Harmony code free of charge to write and compile app programs to run on their Android devices. They would also be able to use all the other stuff created by the community and donated to Sun. It's a shame about the possible fragmentation, Sun said in their proposal, but we're cool with that.

So, what are we here for, again?

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

[ Reply to This | # ]

Why Java?
Authored by: arnotsmith on Friday, April 20 2012 @ 05:51 AM EDT
Given all these problems, why is Java used?

There are other languages around; Python was mentioned, for example. Are there
similar licensing difficulties, or are they simply less comprehensive?

I ask as a Fortran IV expert - I know very little about current languages.

[ Reply to This | # ]

  • Why Java? - Authored by: mcinsand on Friday, April 20 2012 @ 08:50 AM EDT
  • Why Java? - Authored by: Anonymous on Friday, April 20 2012 @ 10:00 AM EDT
  • Why Java? - Authored by: TheOldBear on Friday, April 20 2012 @ 10:24 AM EDT
Someone please tell the judge what API stands for
Authored by: Anonymous on Friday, April 20 2012 @ 06:07 AM EDT
API - Application Programming Interface

It is a dictionary of terms that allows pieces of code to have a common syntax
in order to communicate.

Place it in the context of latin in how a well written API will follow rules of
structure and the judge will be able to understand it.

[ Reply to This | # ]

What exactly is an API?
Authored by: Anonymous on Friday, April 20 2012 @ 07:04 AM EDT
What exactly IS an API? And what about it are Oracle trying to claim as copyrightable?

A. ...Sun had 500 programmers at one point working on Java, many were working on APIs.
[Emphasis added] What exactly were these programmers doing with the APIs? Were they writing the function stubs, eg using open(2) from *nix
int open(const char *pathname, int flags, mode_t mode)
and then someone else, NOT working on the API filled in the code of the function between the braces based on what the function has to do; or were they actually employed in filling in the code, ie they were employed in implementing the API and their creative work in this aspect is subject to copyright?

With OO, it is slightly different. The object has defined methods (aka functions) which do stuff to the data held in the object - the point being that the data is abstracted away from the programmer to keep it "safe". The object is a wrapper for the data that tells you what you can do with the data contained within.

So to believe that many hours of work go into designing the wrapper of an object is quite believeable, and each object will have a set of methods which provide the interface for the program to use the object - which would, I presume be the API for the object; and I would guess that some of the programmers were working on what methods the object would need (as in "How do we wrap up this data"?).

So the question of copyrightability of APIs comes down to what exactly of this is copyrightable?

  • Clearly the code implementing the object and its methods ought to be.
  • What about the object itself?
Without the specification of what methods are available and how to use them the object is useless.

Are oracle trying to assert that copyright extends to the wrapper containing the data? But is that wrapper merely an "idea"?

Amazon's one-click idea (sic) was patented, but not copyrighted even though copyright has a much, much, much longer period of protection! The One-click is a wrapper for everything that happens when you use that method of its object (the button). Perhaps Amazon are watching to see if they can also claim copyright on it...I won't hold my breath.

[ Reply to This | # ]

Explanation of Language vs API..
Authored by: ghost on Friday, April 20 2012 @ 07:39 AM EDT
A language, is a set of rules, intended to provide a specific way of writing,
expressing and understanding things, to provide a uniform common platform, that
can interpret and translate the word into a specific meaning, that can be
actioned, and the language itself, defines a certain set of
"primitives", or "core keywords" on top of which everything
else is written and built. No exception.

However complex the code is, it always boils down to these core keywords.

For ANSI C, there are 32 keywords, or fixed words, which is used to build and
define everything else. This list of words is:


Take this example (c):

int a[100] ;
for ( i = 0 ; i < 100 ; i++)
a[i] = argument ;

What this does, is to define an array of 100 memory locations where we can stick
data (numbers), and then goes though each and one of them, sticking the value
of "argument" into that memory location.

In order to make this more practical, we encapsulate this in a "functional
name", making it a function, that performs a specific something, and that
can be called easily and repeatedly.

void AssignValue(int argument)
int a[100] ;
for ( i = 0 ; i < 100 ; i++)
a[i] = argument ;
return ;

What we have done here, is to extend the language of "c", with another
word "AssignValue", which is constructed out of the keywords defined
in C itself, and it takes one argument, which is a numerical value, that will be
written into each memory cell.

If we want to assign 10 to each memory cell, we could now simply say:
AssignValue(10) ;

A class, is made up of a group of functions that performs action on something
that is related, for example mathematical calculations, database operations,
graphical operations etc, and you would give this a name, say
"database", "math", "graphics" and so on.

Assume that we created a class around the common mathematical operations named
In this class, you would stick the functions for each of the
"primitive" mathematical functions, such as plus, minus, multiply,
divide, sine, cosine, pi and so on, and instead of having individual names for
each of these, we group them by the name "math", and refer to them as
"math.add(1,2)", "pi = math.pi()" and so on.

The language is the ground and foundation of everything, the classes, is built
upon the language, and all the classes that supports the language can be grouped
into API's, or a set of functional groups.

Going back to the code example above, this can, once the language is defined,
and we have strict and precice rules for how to interpret it, be converted from
the text form, by breaking down the specific meaning of the into numerical
machine instructions (machine code)

Lets take a stab at it, converting it to mnmonics (which is the individual
machine code instruction numbers (binary numbers) expressed as words, with one
line being equivalent of a single machine instruction - i am using
pseudo-mnemonics to easily follow things)

void AssignValue(int argument)
int a[100] ;
for ( i = 0 ; i < 100 ; i++)
a[i] = argument ;
return ;

AssignValue: # This is the starting address of this function.
ld acc,r4 # Load the argument (register 4) into accumulator.
ld r1,&array # Load register 1 with the location of the array.
ld r2,0 # Load 0 into register 2 (our loop counter)
repeat: # Jump label - we go back here for each iteration.
ld [r1],r4 # Load memory address r1 with contents of r4.
inc r1 # Add 1 to r1 (array index location)
inc r2 # Add 1 to the loop counter.
cmp r2,100 # Compare R2 against 100.
jrz repeat # If the comparison is not true (r2 not equal to 100)
return # Ok, r2 is 100, return.

We have now converted this into machine code, that can be either java bytecode,
or i86 machine code, or any other, depending on what we wanted.

Thinking of the whole concept of languages, api's and functions in another way:

Imagine the earth under a city, with all its roads, town districts, buildings
and everything else in it, being the language.
Earth is earth, regardless of what you decide to call the town or city, and thus
we have the language "earth".

The API (the town or the city), is what is within the defined city or town
border, so, we could have one API called "London", and another one
called "New York". They are both built on the same earth, but both,
while similar in function size, are vastly different in design and layout, yet,
both are called cities (API's).

One API may contain similar or identical names as another one, doing the same
thing, but they are still not the same API (city).

The classes within each api (city), could be compared to city districts that
shares common traits, but may still be very different from another district.

Consider this:

FoodOnPlate = London.CanaryWharf.Subway( "sandwich" ) ;
FoodOnPlate = NewYork.WallStreet.Subway( "sandwich" ) ;

Both describes similar api's, albeit the naming is different, apart from the
last thing, which orders a "sandwich" from the "subway"

London and NewYork being the API's name, CanaryWharf and Wallstreet being the
class names, and "Subway" being the functional name - the one piece of
code that does the work - delivering a sandwich (as requested)

A language defines how you write things.
A function, is a single tool, like a wrench.
It does one specific thing.
A class, is a group of tools, similar in function or use.
A fixed spanner, adjustable spanner, monkey wrench ...
They are stuck in the same group, as they do similar things,
while still having different individual properties.

An API, is the collection of everything above, aka "the toolbox", and
each API, just like a toolbox, may not be the same as another.
A mechanic's toolbox (API) is not made up the same way as a plumbers or a
carpenters, even though some of the tools in each toolbox is exactly the same
for each trade.

You design the API around what it is to be used for, but in the end, it all
boils down to the very same thing - what the tools are made of - the language.
The "iron" and "wood" that the tools are made of.

After all, there's no wonder there are overlaps, or that code can be similar or
even identical in their implementation, as there are cases where there is only
one way of doing certain things.

For a fixed spanner, there's only limited ways of making it, if it is to be
functional (turn the nut), and it would be silly to be able to claim copyright
on the tool's functional design itself, or even part of it (the head of the
spanner, for example, or the arm of the same), as there is only one functional
way you can get something around the nut, if it's an open spanner.

[ Reply to This | # ]

Q. Does that specification have copyright notices?
Authored by: Ian Al on Friday, April 20 2012 @ 09:19 AM EDT

A. No, it's in the Java platform API specification.

Q. Does that specification have copyright notices?

A. Yes.

Q. Was it Sun's practice to register copyrights?

A. Yes.

It was Sun's practice to register the entire Java distribution as a compilation
copyright registration. It was never their practice in all the years of Java
development to register the copyrights on the Java API Specification.

Also, ask yourself where the copyright notices in the Java API Specification
are. Each chunk of implementation code will have a copyright marking, but it is
not possible to mark the alphabetical list of the compilation of the
compilations of individual APIs that is the Java API Specification.

I think my question on cross would have been 'show me'.

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

[ Reply to This | # ]

Easy solution to speed this up
Authored by: Anonymous on Friday, April 20 2012 @ 09:32 AM EDT

I have an easy suggestion to speed this up. Oracle likes to keep pushing the $7.4 Billion dollar figure. And they seem to really want to pound on the 9 lines. So, let's do some basic math:

    $7.4 Billion * (9 lines of allegedly infringed / 15 million lines in Android) = $4,440
So how about Google pay Oracle $4,440 and we call it a day?

Nah... I didn't think Oracle would go for that. Of course, they don't want to have to prove how 9 lines out of 15 Million doesn't fall into de minimus concept of Copyright Law either. Sure must be tough to want to claim billions and not have to actually prove your case.


[ Reply to This | # ]

Some comment on the 9 lines
Authored by: celtic_hackr on Friday, April 20 2012 @ 10:09 AM EDT
Even hearing 9 lines of copying again and again, it doesn't properly put this in
perspective. So here's my attempt to do that.

1) Most computer software lines contain three words,two "nouns" and a
"verb" (eg "x = y" [and sometimes an end of
"sentence" marker like ";"]) . Some lines only contain
"one" of each (eg "writeln([noun])"). Some lines contain
more maybe 4 or 5 or even up to 12. Poorly written code, or highly complex
logic, may fill up more than one 80 character line.

2) Let's assume Java is well written code, because they are awful proud of it.
So on average a line is say 4 words long.

3) This is 36 words of code from over 60,000,000 words, or less than 1 word per
1,500,000 words 1:1,500,000 or less than 0.000067% of Android code. Yes, less
than zero point zero zero zero zero six seven percent.

4) An advanced college level computer science class program might contain 5000
words. So, Oracle's claim is in effect saying if you include just 1 word used in
Java in a 5000 word college class program you are infringing Java.

5) My mind can't help but replay in my head that dumb PS-commercial from the 80s
or 90s. "This is your brain on drugs."

If I were Google, probably my first defense would be to pop up a chart showing
this is all it's ridiculousness, with two stacks of unprinted paper and a copy
of "War and Peace". Then I'd take a printed source code page, tear of
9 lines and lay it on top of the "Android" stack.

That would be my opening defense. I would then continue to eviscerate them on
the rest of their silly copyright suit.
If I were Google's lawyers, but they have better lawyers than my dream of being
one. So, I can't wait to see what entertaining demonstration they bring.

P.S. - PLEASE don't post those 9 lines of code, I don't want to know if any of
my non-Java code infringes. I've easily written 15,000,000 lines of code, and
frequently write code in the ten to hundreds of thousands of lines of code. I'm
sure I've got at least a few lines of the form "x = y;", "x =
f(y);", "if x" + "{ f(y) };", and "f(x);".
So, I've probably got at least five infringing lines of code in almost every
program I've ever written over the past 30 odd years of programming. Hmmm...
maybe some of their code is infringing MY copyrights.

[ Reply to This | # ]

API's and copyrights
Authored by: Anonymous on Friday, April 20 2012 @ 10:16 AM EDT
I agree that the design of an API, taken as a whole, is creative enough that it
should be subject to copyright. On the other hand, I also believe that
Oracle/Sun have publicly said "Java is Open" enough times, and
solicited community involvement in the use and development of "Open"
Java, that they cannot claim proprietary rights to Java and the Java API's.

[ Reply to This | # ]

Reinhold: APIs can change like wildfire.
Authored by: mexaly on Friday, April 20 2012 @ 10:38 AM EDT
This caught my eye; if the API is not fixed, then it's not fixed in a medium.

I felt this got at the concept of an "interface," perhaps in a way
that relates to copyright law, but it went on by without hooking on anything.

IANAL, but I watch actors play lawyers on high-definition television.
Thanks to our hosts and the legal experts that make Groklaw great.

[ Reply to This | # ]

What is an API?
Authored by: swmcd on Friday, April 20 2012 @ 01:55 PM EDT
Judge: So what is an API? Is it a package, or a class, or what? 18 months into this thing and there is not a common understanding of the matter before the court. I don't even want to think about the jury's understanding of this...

[ Reply to This | # ]

  • What is an API? - Authored by: Anonymous on Friday, April 20 2012 @ 04:13 PM EDT
  • What is an API? - Authored by: Anonymous on Monday, April 23 2012 @ 06:33 AM EDT
Info week article
Authored by: jvillain on Friday, April 20 2012 @ 02:31 PM EDT
Information Week has a recap up.

Lin k

On page two we get the following.

At the conclusion of the testimony, the judge said he wanted the two sides to clarify their positions on whether APIs can be patented. He also asked whether the copyright office investigated the structure, sequence, and organization of software submitted for copyright. He said he didn't think the Copyright Office did that and Baber confirmed his assumption. Finally, he asked for arguments about the standards for derivative works.
Why is the judge asking if an API can be patented? To my knowledge that question hadn't been raised by any one. Then again maybe it is a typo and he meant copyright.

The question around the copy right office is interesting. Maybe he is hoping they did some heavy lifting which would save him some work. Then again maybe he is suspicious of Oracles claims that the API can be copyrighted. He has probably seen enough of the good work that the USPTO does that he is also suspicious of the copyright office as well. To the best of my knowledge the copyright office isn't much more than an automated rubber stamp. Some one else may know more of how they work.

[ Reply to This | # ]

  • Because Oracle said ... - Authored by: Anonymous on Friday, April 20 2012 @ 03:34 PM EDT
  • typo? - Authored by: Anonymous on Friday, April 20 2012 @ 04:22 PM EDT
A simplistic answer for "What is an API?"
Authored by: Anonymous on Friday, April 20 2012 @ 02:44 PM EDT
I would use something like this for an analogy about API's
and the language.

Look at the language as a house, with a door. In order to
use the language (get into the house) you have to go through
the door. The API is like the specific lock and key that
opens the door. You have to use a key that is matched
exactly to the tumblers in the lock, or the door won't open.

So, in terms of Java (or any language), if you don't use the
exact syntax that the API requires, then it won't execute
the method, class, or package that you're trying (or won't
execute it in the way that you want).

In the end, it's all about interfacing and implementation.
The API is just the way that you get into the internal
workings of the package, class, method, or object--without
having to know the internal workings or re-write them in
your program.

The only problem that I see with this analogy is that you
can patent locks. At least the internal workings of the
lock. Which might make the jury think that you can/should be
able to patent an API (or copyright it). It needs to be
pointed out that while you can patent the internal workings
of a lock, you can't patent the idea of using a key to
unlock it, or the idea that the key matches the tumblers and
causes them to open.

Have a great day:)

[ Reply to This | # ]

Ten of the 37 APIs ... free of Oracle/Sun's rule (ie. unpaid).
Authored by: Anonymous on Friday, April 20 2012 @ 04:48 PM EDT
This seems strange to me. How could Oracle's lawyers not know better? Did they
not say to the OpenOffice developers who were developing code in this same
manner "Give us your copyrights!" In turn, did not the OpenOffice
developers say, "Not a chance" and put their code to another project
called LibreOffice?

Was this a lame (but failed) attempt by Oracle to try to sue the open source
communities for using code that the open source communities developed in the
first place?

Is this the reason that Oracle sued Google without demanding the copyrights from
the people who actually wrote the APIs? Like maybe their intention was to
obfuscate (while trying to play ignorant at the same time).

I find it very difficult to believe that Oracle (or it's lawyers) did these
things without knowledge of what they were doing... Reminds me a lot of SCO
demanding the copyrights for UNIX from Novel whilst shooting the double-barrel
foot-gun by trying to sue IBM over those same copyrights ("how whack is

If this total lack of common sense is a side effect to some disease, I sure hope
it isn't contagious! People are dumb enough as it is (just sayin')... And
thank the gods for sites like GrokLaw and folk like PJ! :)

[ Reply to This | # ]

Day 4, Thursday, Oracle v. Google ~ pj - Updated 3Xs
Authored by: Anonymous on Friday, April 20 2012 @ 04:54 PM EDT
So, I am gathering that Google desired a license for Sun Java
CODE, so they went to discussions, and when they fell through,
Google went on it's own path, as they required no license for
anything else.

[ Reply to This | # ]

Long lists of uncorrelated information (you misunderstand the witness)
Authored by: SLi on Friday, April 20 2012 @ 08:26 PM EDT

You are misinterpreting the witness. He is very obviously not saying APIs are long lists of uncorrelated information. And I'm sorry to say that APIs most certainly are not long lists of uncorrelated information.

What he is saying is that if you misdesign an API, it can be very hard to use because then it can be essentially a very long list of uncorrelated information. One of the main points of API design is to bring structure to the chaos, to make it not a very long list of uncorrelated information. For example, to put APIs related to network in one package and APIs related to mathematics in another.

The same witness explains further:

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.

That's what he's referring to when he says "a very long list of uncorrelated information" - having everything in the same package. It's like having a single box in your carage where you store "all kinds of" (i.e. uncorrelated) stuff, from tools to car parts to food to books.

[ Reply to This | # ]

Trying to explain APIs (and the Wikipedia API page)
Authored by: SLi on Friday, April 20 2012 @ 09:22 PM EDT

I think Wikipedia has a fairly good page on APIs.

Understanding the meaning of API is hard enough for beginning programmers (and hard enough to explain for experienced ones), so I can see why it baffles non-programmers. A key thing to notice that API is a somewhat abstract creature, like "the way you drive a car". The car API would specify that a car has a steering wheel and pedals, and the abstract notion of what these do when you operate them. The fact that a car has a steering wheel is part of the API; in a sense, the steering wheel itself, the physical object, is not part of the API, but an implementation of the steering wheel is required for any car that wishes to follow this API. The particular implementation of the steering wheel would be the method signature; it's closely tied to the API, and that's why steering wheels are so similar in different cars. Turning the steering wheel mediates an action; the API is the convention that specifies that you can turn a steering wheel, and that it should effect an action that causes the car to turn.

One thing I'm not entirely comfortable with is using the plural form of "APIs" when we're talking about a single system. In a sense, it's not readily countable; you could just as well talk about "the API of the class libraries", referring to all packages, classes and methods as a single API.

Here are some snippets from the Wikipedia article that I consider helpful, interspersed with my comments:

An application programming interface (API) is a source code-based specification intended to be used as an interface by software components to communicate with each other. An API may include specifications for routines, data structures, object classes, and variables. An API specification can take many forms, including an International Standard such as POSIX or vendor documentation such as the Microsoft Windows API, or the libraries of a programming language, e.g. Standard Template Library in C++ or Java API.

This, the first paragraph of the article, is a fairly good summary in my opinion.

The term API may be used to refer to a complete interface, a single function, or even a set of APIs provided by an organization. Thus, the scope of meaning is usually determined by the context of usage.

Under the section title "Detailed explanation":

An API may describe the ways in which a particular task is performed. In procedural languages like C language the action is usually mediated by a function call. Hence the API usually includes a description of all the functions/routines it provides.

Function is more or less the same thing as a method. By convention, they are called methods on object oriented languages and functions on procedural languages. They are snippets of code that do something when invoked or called (they typically either effect a change or fetch some information for the caller). The simplest functions do some very simple calculations, or change the value of a variable. More complex functions can build on top of simpler functions by calling them.

If a car was a class, one method could be "float get_current_speed()" (that is the signature, not the implementation of the method). Calling it would not affect the car in any way, but it would return to the caller the current speed as a number ("floating point number", essentially a decimal number).

Another method could be "void apply_parking_brake()". It would affect the state of the car, namely apply the parking brake. It does not return any information (signified by the "void").

A taxi driver could build on top of these; the API of a taxi driver could have a method named "void drive_to()", which in turn would use the lower level car APIs to accomplish this task.

These method signatures are really not "the API"; they can be said to be part of the API, which is the idea, or specification, of what you can do to get your car to do things, but the API also encompasses the general idea or expectation of what happens if you turn the steering wheel. You can talk about the "car API", but you could subdivide it to "the brake API" and "the steering API" if you wished. See also the example about the manual page of sqrt() in the Wikipedia page. The API is not only the function signatures in that example, but also "the fact" that it computes a square root (but not how it does it).

Hence the API in this case can be interpreted as the collection of the include files used by the C language and its human readable description provided by the man pages.
Many program development environments provide the documentation associated with an API in some digital format, e.g. perl comes with the tool perldoc:

Note "documentation associated with an API". The documentation is not the API; the method signatures are not the API; the API is something intangible, an idea, but with some very concrete details (the method signatures, for example) that cannot really be modified without breaking the API.

As for object oriented languages:

In object-oriented languages, an API usually includes a description of a set of class definitions, with a set of behaviors associated with those classes. A behavior is the set of rules for how an object, derived from that class, will act in a given circumstance. This abstract concept is associated with the real functionalities exposed, or made available, by the classes that are implemented in terms of class methods (or more generally by all its public components hence all public methods, but also possibly including any internal entity made public, like fields, constants, nested objects, enums...).

The API in this case can be conceived as the totality of all the methods publicly exposed by the classes (usually called the class interface). This means that the API prescribes the methods by which one interacts with/handles the objects derived from the class definitions.

More generally, one can see the API as the collection of all the kinds of objects one can derive from the class definitions, and their associated possible behaviors. Again: the use is mediated by the public methods, but in this interpretation, the methods are seen as a technical detail of how the behavior is implemented.

For instance: a class representing a Stack can simply expose publicly two methods push() (to add a new item to the stack), and pop() (to extract the last item, ideally placed on top of the stack).

In this case the API can be interpreted as the two methods pop() and push(), or, more generally, as the idea that one can use an item of type Stack that implements the behavior of a stack: a pile exposing its top to add/remove elements. The second interpretation appears more appropriate in the spirit of object orientation.

The API of a class that implements the stack data structure is the method signatures along with the understanding that invoking those methods causes the effects you would expect from a stack implementation.

In this sense, in object-oriented languages, the API defines a set of object behaviors, possibly mediated by a set of class methods.

This is a concise piece of wisdom; if you understand this, you understand a lot.

An API is usually related to a software library: the API describes and prescribes the expected behavior while the library is an actual implementation of this set of rules. A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface.

[ Reply to This | # ]

Why the API concept is confusing: what an interface is depends on what it is interfacing with
Authored by: clemenstimpler on Friday, April 20 2012 @ 09:59 PM EDT
Oracle can muddle the waters, because an API is an interface. The concept of an
interface is 'relational'. Some interfaces are only for humans, e. g. a GUI
(after all, it's in the name). It should be feasible to put a camera in front of
a monitor, so that it can capture output of the GUI, and to pipe that input into
another computer, so it may execute instructions depending on what is being
displayed on the monitor. This is idiotic, because computers have more efficient
ways to communicate. But it shows, how interfaces are made for particular sorts
of input or output.

The same seems to be true for an API. In fact, or so I guess, there is never
only one of them. The specification is the human readable aspect of the API: It
allows a programmer to grasp what a particular library will do without looking
at code or testing different strategies. It's written, more ore lss, in plain
English or another natural language.

The source code of the library is a different mode of expression of the same
facts. A knowledgeable programmer may get the same information from the code
that is expressed in easily accessible form in the specification, because, after
all, the specification is implemented in code. So the code displays a different
kind of interface, but it is an interface nevertheless - a particular way of
'displaying' expected inputs and outputs.

The binary is an interface for code. It takes quite an amount of work to reverse
engineer it in order to retrieve the information contained in the source code or
the specification. But it is feasible in principle nevertheless.

So there are three ways to 'express' an API: specification, source code, binary
code. The specification is for the unenlightened programmer, the source code is
for the expert, the binary code is for the machine.

So you can either argue that there are three APIs, depending on what the API is
interfacing with (amateur, expert, machine). Or you can say that one and the
same API is 'expressed' in three different ways. If you choose the first
strategy, there are two or three things that can be copyrighted: the
specification, the code, the binary (opinions on the last point differ). Google
does not dispute that. But it copied neither the specifiation nor the code or
the binary.

If you choose the second strategy, there is one thing that can be expressed in
three different ways. When I see a thing that walks like an idea and swims like
an idea and quacks like an ide, I call that thing an idea.

IIRC, Google focused in questioning the witnesses on the 'tangible medium'
aspect of copyright. If you choose the first strategy, there are three 'tangible
media' (a book or a webpage, a source code listing that can be printed out, a
binary that can be burned to a medium). It is more or less uncontested that none
of these were copied by Google. If you choose the second strategy, one and the
same 'thing' could be made available in three different media. Again, if it
walks like and quacks like etc. ....

Oracle's copyright case is a dead duck.

[ 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 )