|
Oracle v. Google - Google's Expert Report and a Jury Issue |
|
Friday, September 09 2011 @ 09:00 AM EDT
|
In our article from September 2nd on the Oracle/Google copyright issues, we included a number of declarations, including that of Prof. Owen Astrachan of Duke University. There were two exhibits identified in the Astrachan declaration, but neither of the exhibits were available at that time. Now Exhibit 3, Astrachan's Rebuttal Expert Report
391 [PDF] is available in redacted form, and we have reproduced it below.
Prof. Astrachan's rebuttal is impressive for two reasons: (1) he addresses the technical/copyright merits of the Oracle expert; and (2) he does so in a manner that is intended to convey the story to both the judge (who by his own admission is no expert on software) and the jury. In other words, Astrachan has prepared his rebuttal in plain English, and he uses a number of anecdotes to help the non-technical understand his points.
One example, where Prof. Astrachan is explaining API's:
An API implementation that uses only the necessary API components, but does not repeat
the underlying implementation, is an “independent” implementation. A Ford and a
Chevy are, in this sense, independent implementations of a car — while they both provide
drivers with the same gas pedal and steering interface to the underlying functionality,
Chevy engineers likely did not photocopy Ford blueprints in order to build the Chevy’s
engine and steering mechanism. Similarly, the fact that virtually every modern computer
application supports common keyboard commands like Ctl+C, Ctl+V, and Ctl+P does not
prove that the programmers used each other’s implementation source code. Instead, they
have each re-implemented the functionality in a way that makes sense for their
circumstances, reusing only the “interface” of the keyboard commands.
By the way, I know Prof. Astrachan and have been a guest speaker in one of his classes at Duke University (the largest enrollment class at Duke for several years running). This ability to explain the technical in non-technical terms is a gift he has, and it is evident in the classroom, as well.
The other item we take note of is Google's objection
392 [PDF] to Judge Alsup's proposed rollover of the remaining jury pool from the second criminal trial scheduled for October, if that trial does not occur. Google points out that the pool of jurors that would be available will have been narrowed significantly, and not along the lines that either party would likely narrow it. Google is asking Judge Alsup to work from a new jury pool.
*************
Docket
391 – Filed and Effective: 09/06/2011
ORDER
Document Text: ORDER REGARDING EXHIBITS re 371 Declaration in Support, Exhibit 3 to Reply Declaration of Owen Astrachan in Support of Defendant Google Inc.'s Motion for Summary Judgment on Count VIII of Plaintiff Oracle America's Amended Complaint – Publicly Filed Version – Redacted filed by Google Inc. (Related document(s) 371) (Kwun, Michael) (Filed on 9/6/2011) (Entered: 9/6/2011)
392 – Filed and Effective: 09/06/2011
ORDER
Document Text: OBJECTIONS to re 371 Order, Google Inc's Objections to Order Clarifying Order Regarding Jury Selection by Google Inc. (Van Nest, Robert) (Filed on 9/6/2011) (Entered: 9/06/2011)
***************
Documents
391:
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION
ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.
______________________
Case No. 3:10-cv-03561-WHA
EXHIBIT 3 TO REPLY DECLARATION
OF OWEN ASTRACHAN IN SUPPORT
OF DEFENDANT GOOGLE INC.’S
MOTION FOR SUMMARY JUDGMENT
ON COUNT VIII OF PLAINTIFF
ORACLE AMERICA’S AMENDED COMPLAINT
Judge: Hon. William Alsup
Hearing: 2:00 p.m., September 15, 2011
PUBLICLY FILED VERSION
REDACTED
EXHIBIT 3
[list of lawyers for Google]
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION
ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.
______________________
Case No. 3:10-cv-03561-WHA
Honorable Judge William Alsup
REBUTTAL EXPERT REPORT OF DR.
OWEN ASTRACHAN
CONFIDENTIAL PURSUANT TO
PROTECTIVE ORDER - HIGHLY
CONFIDENTIAL - SOURCE
CODE
I. INTRODUCTION .................... 2
II. DOCUMENTS AND INFORMATION CONSIDERED ............. 2
III. BRIEF SUMMARY OF MY OPINIONS ............... 3
IV. THE DISTINCTION BETWEEN AN API AND ITS
IMPLEMENTATION ................. 3
V. GOOGLE’S IMPLEMENTATION OF THE APIs AT ISSUE
IS NOT VIRTUALLY IDENTICAL OR SUBSTANTIALLY
SIMILAR TO ORACLE’S IMPLEMENTATION ................. 14
VI. THE VARIOUS JAVA VERSIONS THAT ORACLE
ALLEGES WERE INFRINGED CONTAIN THE SAME
APIs AS EARLIER VERSIONS OR VERSIONS FOR
OTHER OPERATING SYSTEMS ................. 18
VII. PARAMETER NAMES ARE FUNCTIONAL AND NOT
CREATIVE .................. 19
VIII. THE ORGANIZATION OF PACKAGES IS FUNCTIONAL
AND DOES NOT CONTAIN CREATIVE EXPRESSION .............. 20
IX. C#, LIKE JAVA, IS UNPROTECTABLE, AND IS ALSO
AVAILABLE AS AN OPEN SPECIFICATION AND
IMPLEMENTATION ................... 22
X. ORACLE’S ANALYSIS OF THE FILES AT ISSUE DOES
NOT DISCUSS THEIR QUALITATIVE OR
QUANTITATIVE IMPORTANCE, WITH ONE
EXCEPTION THAT IS INCORRECT ................. 23
EXHIBIT F: COMPARISON OF ANDROID AND ORACLE
ZIPFILE.GETINPUTSTREAM
EXHIBIT G: PUBLICPRIVATEANALYZER.PY SOURCE CODE
1
I. INTRODUCTION
1. I have been asked by Google to review the expert reports of John C. Mitchell, Marc
Visnick, and Alan Purdy and, in addition to those opinions offered in my July 29, 2011
Opening Expert Report (“Opening Report”), to opine on the conclusions set forth in those
reports, and whether Oracle’s allegedly copyrighted works relating to the Android
platform are virtually identical or substantially similar to the Java platform.
2. My qualifications, set forth in my Opening Report, are incorporated herein by reference.
3. I understand that I may be asked by Google to review further submissions related to
copyright issues from Oracle’s experts, and to provide my opinions on issues raised by
any such submissions.
4. I understand that I may be called upon to testify in this case regarding my opinions and
analyses set forth in this report. If called upon to testify, I may use various
demonstratives, including tables or drawings, to assist in presenting my testimony.
5. As set forth in my Opening Report, my compensation does not depend in any way on the
outcome of this litigation.
II. DOCUMENTS AND INFORMATION CONSIDERED
6. My opinions are based on my relevant knowledge and experience, the documents
identified in Exhibit B to my Opening Report, as well as review of the following
documents and information:
a. Opening Expert Report of John C. Mitchell Regarding Copyright, Opening Expert
Report of Alan Purdy Regarding Copyright, and Opening Expert Report of Marc
Visnick Regarding Copyright, all dated July 29, 2011.
b. “Design Patterns: Elements of Reusable Object-Oriented Software,” by Erich
Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
c. Mono Website page on ECMA, available at http://www.monoproject.
com/ECMA; Microsoft Open Specifications, available at
http://www.microsoft.com/openspecifications/en/
us/programs/communitypromise/
covered-specifications/default.aspx
2
d. “Q&A with Tim Bray,” November 13, 2006, available at
http://www.zdnet.com/blog/burnette/
q-a-with-tim-bray/200?pg=3
III. BRIEF SUMMARY OF MY OPINIONS
7. Based upon my review of the material set forth in Section II, I disagree with Prof.
Mitchell’s conclusion regarding whether elements of the Java API specifications contain
copyrightable expression. I also disagree with Prof. Mitchell’s conclusion that the
Android source code is substantially similar to Oracle’s copyrighted source code. It is
my opinion that Google’s implementation of the APIs at issue is neither virtually
identical nor substantially similar to Oracle’s implementation.
IV. THE DISTINCTION BETWEEN AN API AND ITS IMPLEMENTATION
8. As discussed in paragraph 52 of my Opening Report, every API, including the Java APIs
at issue in this case, exists in two forms: the method declaration of the API (comprised of
those elements — name, arguments, and return — described in paragraphs 40-47 of my
Opening Report) and the implementation of the API. The implementation is the actual
underlying source code that implements the API and allows the API to function. Any
two implementations of the same API will contain some similar portions, because each
implementation must include exactly the same method declaration, including all the
elements of the declaration, such as the arguments and return values, in order to be
compatible. However, the overall source code may — and indeed does — differ
significantly from implementation to implementation. Even if only a small fraction of the
source code of two implementations is identical, the remaining code may appear similar
to the untrained eye, both because certain key lines (the method, package, and class
declarations) must be the same, and because practical considerations will constrain the
expression of the code implementing the functionality. For example, there may be both
efficient and inefficient ways to implement a given method, but programmers will
typically choose the most efficient way. Similarly, coding standards relating to
indentation, punctuation, and formatting will also constrain how code is written. In
addition, because many programmers have learned by studying and reading source code
3
written by others, they typically write code in a similar style. Returning to the car
analogy that is set forth in my Opening Report, there may be unusual ways to power a car
(hydrogen, rotary engines, etc.), but in most cases the solutions will end up looking
similar to other implementations for practical reasons due to standard design practices,
and not because the car manufacturers were copying from each other.
9. An API implementation that uses only the necessary API components, but does not repeat
the underlying implementation, is an “independent” implementation. A Ford and a
Chevy are, in this sense, independent implementations of a car — while they both provide
drivers with the same gas pedal and steering interface to the underlying functionality,
Chevy engineers likely did not photocopy Ford blueprints in order to build the Chevy’s
engine and steering mechanism. Similarly, the fact that virtually every modern computer
application supports common keyboard commands like Ctl+C, Ctl+V, and Ctl+P does not
prove that the programmers used each other’s implementation source code. Instead, they
have each re-implemented the functionality in a way that makes sense for their
circumstances, reusing only the “interface” of the keyboard commands.
10. To illustrate how an API must be identical across Java implementations, even while the
implementations differ, I will use three examples. Before doing that, it is first useful to
provide an analogy that will help to explain the source code being discussed here. In
particular, the different implementations of APIs are similar to different sets of driving
directions that take someone from point A to point B. In this analogy, the starting point,
A, is like an argument, and the ending point, B, is like a return value. Like an API
implementation that is constrained by the method declaration, every set of directions that
goes from point A to point B will begin and end the same way (“leave the parking lot at
point A,” “enter the parking lot at point B”); however, there may be many other
variations between the directions. For example, one set of directions might take the
highway, while another might take back roads. One set of directions might prioritize
giving directions in the fewest number of turns, while another set of directions might take
more turns, but use those extra steps to avoid an area of high traffic. Another pair of
4
directions might be identical, except that one adds special steps to be taken during rush
hour.
11. Of course, directions, like computer programs, are subject to practical constraints because
they are process-driven expressions. You could write directions from San Jose to San
Francisco that go by way of New York, but those directions would be so inefficient that,
while possible, they are not a realistic option in practice. And in some cases, there will
be so few options for how to get from point A to point B that in fact there is only one way
to write the directions.
12. The source code discussed in the following examples is similar. Each implementation
tells the underlying computer how to get to a particular result, but as I will explain, the
Android “directions” generally are different from the Oracle “directions.” Although they
get the same result — starting from the inputs and ending at the return values — they
take different steps to get there.
BEGIN ORACLE SOURCE CODE - HIGHLY CONFIDENTIAL
13. The first example is one I have used earlier: the Math.abs function. As discussed in
paragraphs 57-60 of my Opening Report, the absolute value of an integer is essentially
the magnitude of the integer, i.e., the distance of the integer from zero. Similarly,
paragraph 60 of my Opening Report states that the declaration of the method (the
function name, return type, and parameter type) is specified as part of the Math.abs API
and must be the same in any compatible implementation of the Math.abs API. The
following chart (from paragraph 61 of my Opening Report) shows the various identical
method declarations for abs from the various implementations of Java:
Java: public static int abs(int a)
Harmony: public static int abs(int i)
GNU Classpath: public static int abs(int i)
Android: public static int abs(int i)
(As I explain in paragraph 15, below, the variable name chosen for the parameter in the
parentheses need not be the same, and, in fact, the variable name in the Android
5
implementation is different than in Oracle’s implementation.)
14. Not surprisingly, because the concept is so simple (“if the number is negative, give the
positive version of it”) the implementations are very brief— all it takes is one line for the
declaration, and one line for the actual functionality. Despite this simplicity and brevity,
Oracle and Android’s implementations of Java are different. The table below shows the
Android source code that implements the Math.abs function in the java.lang.Math class
compared to the source code that implements JDK1.5 code.
15. As required by the API, the first line of the method — the function name, return type, and
parameter type— are essentially identical in both implementations. The name of the
parameter— a for the JDK1.5 implementation and i in the Android implementation — is
the only thing different. The parameter name can be different because the name of the
parameter is not part of the API. The parameter type, int, on the other hand, must be the
same if the two implementations are to be compatible.
16. The actual implementation of the method — the second line, shown in blue— is how the
absolute value is calculated. Each of these lines of code is different, but nevertheless
correct. Put into English, the line of code from the Android implementation translates to
“if the parameter i is greater than or equal to zero, return i, otherwise return i’s negation.”
In the JDK1.5 implementation the code translates to English as “if the parameter a is less
than zero, return a’s negation, otherwise return a.” While these implementations must
capture the same functionality, and bear some similarity because of the requirement that
the method name and arguments be the same, they capture the functionality with different
implementations.
17. The second example I will use to illustrate how the functionality expressed by an API is
implemented differently is the java.lang.String class method String.compareTo. In
6
programming, a “string” is a sequence of characters, such as a word or sentence. The
compareTo method compares two strings, in order to determine whether one string is less
than, equal to, or greater than another string. In programming, a string that is “less than”
another string is alphabetized first. For example, if “compareTo” was used to compare
“apple” to “cat,” the method would indicate that “apple” is less than “cat.”
18. Below is the Android and Oracle JDK 1.5 source code that implements the compareTo
method.
19. As noted in a comment on line 2 of the Android implementation (on the left), the Android
implementation of compareTo is adapted and based on code from “K&R,” a reference to
“The C Programming Language,” a book written by the C language’s principal authors,
7
Brian Kernighan and Dennis Ritchie. The K&R book, and the code contained within it,
were published long before the Java language existed. The body of the function — that is
the code between and including the function’s curly braces (i.e., the “{” and “}” that
mark the beginning and end of the source code for a function)— is 11 lines long.
20. In the Oracle JDK 1.5 implementation on the right, the first part of the first line of the
implementation is the same as the Android implementation on the left — “public int
compareTo(String”. Again, this similarity is required for compatibility. Use of the
same parameter name, however, is not required for compatibility, and so the parameter
named string in the Android implementation is instead anotherString in the Oracle JDK
1.5 implementation. The Oracle implementation is also 31 lines, instead of the Android
implementation’s 15, indicating again that different algorithms and language features
were used to reach the same result. The longer Oracle implementation is like a set of
driving directions that takes complicated, twisty back roads in hopes of avoiding traffic
on the big intersections, making it longer in miles, but possibly more scenic or shorter in
time— in other words, possibly more efficient in other ways.
21. These two implementations are functionally identical — they compare the corresponding
characters of two strings — but the actual code is very different. For example, in
comparing the string “catastrophe” to “catalog” the code scans the first four characters,
and finds that they are the same. It then determines the relative order of the strings by
comparing the fifth characters — s in catastrophe and l in catalog. In the Android
implementation the two characters compared are captured by the expressions
value[o1++] and target[o2++] whereas in the JDK1.5 implementation these
characters are stored in variables c1 and c2 and are captured by the expressions
v1[i++] and v2[j++] in one part of the code and v1[k] and v2[k] in a different
part of the code. In both versions of the code, once a difference in characters is detected
(i.e., s and l in the catastrophe and catalog example), the code need not compare further
characters to determine the relative order of the strings. For example, in comparing “ant”
and “bee” comparisons stop after the first characters have been examined, but when
8
comparing “distance” and “distant” the function can only determine the relative order
after examining the seventh character of each string (c and t). Despite the similar
functionality, the code that performs these comparisons and looks at the corresponding
characters of each string is very different.
22. To further illustrate how the same compareTo API can be implemented in various ways,
the GNU Classpath implementation of the String.compareTo method is shown in the
following table, and is different from both the Android and Oracle JDK 1.5
implementations. Again, all of these sets of source code implement the same underlying
functionality — they compare two strings of characters by examining each individual
character until corresponding characters are different. The method name, return type, and
parameter type (“public int compareTo (String”) are again identical, as they
must be for compatibility and interoperability. However, the way these sets of source
code actually achieve this functionality differs significantly. For example, the Android
implementation uses variable names o1 and o2 whereas the Classpath implementation
uses variables x and y. The Android and Classpath implementations (unlike the Oracle
implementation) both use a concept called a “while” loop that repeats a given operation
“while” a particular condition is true, but the loop in the Android implementation uses the
condition while (o1 > end) whereas the
loop in the Classpath implementation uses
the condition while (--i > 0). And again, like the Android and Oracle
implementations, these implementations are of different length, though the difference is
much smaller. Although the logic used in the Android and Classpath implementations is
the same, the implementations are very different.
9
23. The final example that I will use to compare implementations is the class ZipFile from
the package java.util.zip. This class manipulates “zip” files, which are files that contain
one or more other files, so that those files can be easily emailed, stored, and otherwise
moved around. Because zip files are archival, they allow many files or folders to be
packaged together as a single zip file. In addition, zip files are “compressed” — that is to
say, a zip file is usually smaller than the sum of the sizes of the files contained in the zip
file. Each of the files stored in a zip file is referred to as an “entry” in the zip file.
24. The Java API package java.util.zip contains several classes for creating, reading, writing,
and manipulating zip files and the files (“entries”) stored within them. In particular, I
will focus on the class ZipFile and the method getInputStream from that class in order to
compare and contrast an API with its implementation.
25. Among the public methods in ZipFile is one called getInputStream, which is used to
“read” a zip file — i.e., to access the archived and compressed contents stored in a given
zip file. The getInputStream method does this by creating an “InputStream,” which is a
standard way for Java programmers to access files and other data sources. An
InputStream is essentially a representation of a steady stream of information. Programs
written in the Java language can act on these streams in a variety of ways, such as reading
the next piece of data in the stream, skipping ahead to another part of the stream, and
finding out how much of the stream is still available to be read. When a program written
in the Java language opens, closes, and reads documents or other files, the program is
using an input stream.
26. This functionality — both the ZipFile class generally and the getInputStream method
specifically — can be implemented in a variety of ways. As I will discuss in more detail
in paragraph 35, the implementation of a class can contain both “public” methods — or
10
methods that can be used by any programmer when writing programs — and “private”
methods — or methods that can only be used by the code implementing the class, and
used only for the purpose of implementing other parts of the class. “Public” and
“private” methods can also be thought of as “external” and “internal” methods,
respectively — public methods can be used from outside of the program, while private
methods are “internal” to the program and can only be used by that program, not by other
programs. For one class to be compatible and interoperable with another class, both must
have the same public methods, but they may have different private methods and still be
compatible. The Android implementation of ZipFile contains two private methods used
to help implement the public methods. The Oracle JDK 1.5 implementation of ZipFile,
in contrast, contains 20 private methods. The GNU Classpath ZipFile.java
implementation contains seven private methods. This significant difference in the
number of private methods illustrates that although the public methods of the API are
similar, as they must be, the internal implementations of these methods and the class
ZipFile are very different. It might be helpful to think of the Oracle implementation,
which contains many private methods, as a pasta recipe that, in turn, refers to 20 other
recipes — the pasta dough recipe, the pasta sauce recipe, a salad recipe to be served
alongside, etc. The Android “recipe” for ZipFile, in contrast, refers only to two other
recipes, incorporating the other components into the main recipe. Both the Android and
Oracle recipes, in the end, create pasta, but use different processes to get there.
27. Just as the ZipFile classes in these two implementations as a whole are different, the
getInputStream method in each is also different. Both the Oracle and Android
implementations of the getInputStream method accomplish the same task: when given a
“ZipEntry” object (i.e., a reference to one of the files or directories in a zip file), return
an input stream that allows the program to read that entry. However, the source code that
implements Oracle JDK 1.5 method ZipFile.getInputStream, including the private helper
methods and classes it uses, is 275 lines of code. Android’s implementation of the same
method, including its private classes and methods, is 120 lines of code. (Because of their
11
length, the table with this code is attached as Exhibit F.)
1 This is a very large difference
in how the methods are implemented.
28. However, it is not just the length of the two implementations that distinguish them. They
are also structurally different, which can be seen by analyzing the “private” methods and
classes used in the implementations. Both the Android and JDK 1.5 methods use private
classes to represent the input stream that corresponds to the file or directory being read.
Android’s implementation uses two internal classes, named RAFstream and
ZipInflaterInputStream.2 These classes “extend” (i.e., are based on and add new
functionality to) other classes — InputStream and InflaterInputStream, respectively. The
Oracle JDK 1.5 implementation of ZipFile.getInputStream. [REDACTED]. In the Java code there are three private methods (highlighted in
the table below in blue) whereas there are none in the Android implementation. Again,
the usage of structurally different private methods and classes indicates, in my opinion,
that the implementation of these specific methods are very different, and more generally,
shows how analysis of private methods can be used to help understand whether or not
two given implementations are similar.
29. The methods in the source code that implements the complex task of creating the
InputStream differs, but that is not the only difference — a more detailed analysis shows
that even the relatively simple programming task of ensuring that the ZipFile has a name
is implemented differently. The fragment of the ZipFile.getInputStream source code that
implements this simple functionality is shown in the table below. The Oracle JDK 1.5
implementation [REDACTED]
__________________________
1 For ease of reference, in this rebuttal report I will not reuse exhibit labels used in my Opening Report.
2 Technically these are not private - they can be used by other parts of the API package. However, the classes are
only used within the ZipFile.java file, and can’t be used by external programs, so they are effectively private.
12
[REDACTED]
30. The Android version has several key differences. First, it does not use a helper function
— it does the work itself. Second, if the FileEntry has no name, the Android code simply
returns “null” — i.e., an empty value — [REDACTED]. Third, the Android source code finds the name of the Entry in a
different way from the Oracle code — [REDACTED] —
represented in the Android code by entry.getName. While this difference may look
subtle (only three characters), the approach used by the Oracle code is generally
considered bad style; [REDACTED].
31. By looking closely at ZipFile.getInputStream, I have shown that the same, compatible,
13
interoperable functionality can differ in many ways — overall, by simply comparing the
length of the two implementations; at an intermediate level, by showing that there are
different names and numbers of private methods and classes used to implement the
functionality; and at a granular level, by showing that one particular subtask is
implemented in different ways.
END ORACLE SOURCE CODE - HIGHLY CONFIDENTIAL
32. In each of these three methods examined in this section, I have shown that the
programmatic logic used to implement a particular method can be very different, with
only one small portion — the method name and argument types — being the same.
These files are typical of all Android and Oracle JDK 1.5 files that I have inspected —
one small portion, which is required to be the same for purposes of compatibility and
interoperability, is the same, and the rest of the file is different. As a result, I disagree
with Prof. Mitchell’s conclusion that the Android source code is substantially similar to
Oracle’s copyrighted source code. Instead, it is my opinion that Google’s
implementation of the APIs at issue is not virtually identical or substantially similar to
Oracle’s implementation.
V. GOOGLE’S IMPLEMENTATION OF THE APIS AT ISSUE IS NOT
VIRTUALLY IDENTICAL OR SUBSTANTIALLY SIMILAR TO ORACLE’S
IMPLEMENTATION
33. I understand from the Visnick and Purdy reports that, with the exception of portions of a
dozen files, Oracle does not allege that Google has copied Oracle’s implementation of the
Java APIs. Instead, Oracle only alleges that the classes, interfaces (including fields,
constructors, and method signatures), and exceptions are similar in both platforms. In
other words, except for 12 files identified by Visnick out of the 9,479 files in Oracle’s
implementation of Java 1.5, Oracle does not allege that Google copied source code from
Oracle. As explained in Section V.Q (paragraph 129) of my Opening Report, the names
and parameters of the APIs must be the same for interoperability and efficiency reasons.
14
While the Android software is compatible with and provided the functionality of the Java
language APIs at issue, and necessarily uses the same API names and organization in
order to do so, my opinion, after my review of the Android and Oracle source code, is
that Android’s underlying implementation (or source code) of the APIs is substantially
different from Oracle’s implementation. Put another way, Android is written in the Java
language and compatible with programs that use the Java language APIs at issue, so that
developers can reuse their existing code in the Java language on both the Android and
Java platforms, but the Android source code was not copied from the source code in
Oracle’s Java platform. Rather, leaving aside the 12 files identified by Mr. Visnick and
addressed in paragraphs 150-177 of my Opening Report, Android includes an
independent implementation of the Java language APIs at issue, created without copying
the Java platform’s source code.
34. Besides the kind of line-by-line analysis done from paragraphs 12-15, we can analyze the
differences in the implementations of the APIs by examining the names of the private
methods of each implementation. In my opinion, the different names for these private
methods show that the Android source code was not copied from the Oracle JDK 1.5
source code.
35. As explained above in paragraph 24, “public methods” are the methods that are made
available for use by programmers who use an API to write applications. These must be
the same if the two implementations are to be compatible. In contrast, “private methods”
help to implement the API but are not visible or available for use by software developers
building their own software. The classes that are at issue in this case have public
methods that must be implemented in order to be compatible with the API, e.g., Math.abs
and Math.sqrt in the java.lang package. However, the API does not dictate how the
methods are implemented. I demonstrated in paragraph 24’s analysis of getInputStream
that private, helper functions are often used in implementing the public methods required
by the APIs. Differences in the private methods reflect differences in the
implementations. For example, a simple way to see the differences in the
15
implementations above is to list the names of the private methods, and compare the two.
If the names and quantity of the private methods in the two implementations are different,
then the implementations themselves are also different. For example, the getInputStream
method is implemented using different private methods and private classes in the
different implementations — the Android implementation uses three private methods and
two private classes, whereas the Oracle JDK 1.5 implementation uses two private classes
but no private methods. This difference in the number of the private methods and classes
(and in many places, also the type and name of the internal structures) indicates that the
two implementations have very different underlying structures and therefore are not
similar. This is akin to two very different tables of contents for two books that are on the
same topic — differences between the two tables strongly suggests that the underlying
content will also be different.
36. Using software I developed to analyze the classes examined in this report, I detected
large differences in how public and private methods are used across the Android, GNU
Classpath, and Oracle JDK 1.5 implementations. I used the program (attached as Exhibit
G) to examine the accused packages, and created the table below to summarize the data
for the 740 public classes and interfaces in common between the Android and Java
implementations of the 37 accused packages. For comparison, I have also provided
information on the GNU Classpath implementation of the same materials.
37. The column labeled “Total Methods” provides the total number of methods (including
constructors) found across all classes. The column labeled “Total Private Methods”
shows how many of these methods are labeled as private, and hence not accessible to
programmers but used to implement the public methods. As I discussed in the example
of the getInputStream method in the java.util.zip class, sometimes private methods are
used to implement the public methods, but they are not part of a class’s API because
programmers using the class cannot access the private methods. The column labeled
“Percent Private” provides one estimate of how often private methods are used across all
classes. Each of these classes contributes a percentage between zero and one hundred to
16
a running total. If all methods in a class are private, the percent private for that class is
100%. If all methods are public and none are private, the percent private is 0%. The
percentage shown in the column is the average of these per-class percentages across all
classes. The significant difference between the Android and Oracle implementations in
this metric shows that the Android classes use, on average, fewer private methods than
the other Java implementations. In my opinion, this indicates that the implementations
are significantly structurally different. The structural difference between the
implementations is also indicated by the total number of methods that differ across the
implementations. Methods can be public, private, or package access, and it is possible to
add public methods that are not part of the API. The differences between the total number
of methods across the implementations is a further indication that the implementations of
the APIs are very different.
38. The substantially different numbers of classes and methods, and the different ratio of
public to private methods, strongly suggests that each of the implementations measured is
substantially different from the other. In particular, recall from paragraphs 24 and 35 that
to achieve compatibility and interoperability, private methods, unlike public methods, are
not required to be the same. As a result, the very different number of total private
methods in the implementations of the allegedly infringed packages leads me to conclude
that, when the authors of the three pieces of software were not constrained by
compatibility, they took very different routes to implement the functionality. My direct
inspection of a cross-section of the files at issue confirms the results of this numerical
approach. As expected from a review of the overall numbers, in the individual classes,
the number of private methods and classes, and their underlying implementation, also
17
vary substantially between the two implementations.
39. As a result of this analysis, it is my opinion that the Android and Oracle JDK
implementations are not virtually identical or substantially similar. The only meaningful
similarities I have observed are between elements that — as discussed in my Opening
Report (section V.J to V.R, paragraphs 90-139) — are necessary for compatibility and
interoperability.
VI. THE VARIOUS JAVA VERSIONS THAT ORACLE ALLEGES WERE
INFRINGED CONTAIN THE SAME APIS AS EARLIER VERSIONS OR
VERSIONS FOR OTHER OPERATING SYSTEMS
40. It is my understanding that Oracle first asserted on July 29, 2011 that Google allegedly
infringed its copyright in Java 6. Java 6, like the other allegedly infringed Java versions,
contains all the APIs that were contained in previous versions of Java. This is because it
is Java’s stated policy, for purposes of compatibility, to keep versions of Java as similar
as possible to previous versions. When new versions are released, API elements are
essentially never changed or removed, only added. This is known as “upwards”
compatibility, as referenced in the Java SE Compatibility Policy (available at
http://java.sun.com/j2se/1.5.0/
compatibility.html.) As a result of this policy, the APIs in
Java 1.1 are also present, in their entirety, in Java 1.2; all Java 1.1 and any new APIs
added in Java 1.2 are present in Java 1.3; all Java 1.2 APIs and any new APIs added in
Java 1.3 are present in Java 1.4; and so on.
41. Similarly, it is my understanding that some of the allegedly copied works are Java 1.2 for
Windows, Java 1.2 for Linux, Java 1.2 for Mac, Java 1.2 for Solaris, and the same set of
platforms for Java 1.3. These works contain deliberately contain the same APIs and API
packages. If their APIs were different, it would defeat Java’s stated purpose of “write
once, run anywhere.” The API implementations for each operating system differ,
however, so that they will work with the specific operating system. For example, the
lastModified method in the java.io.File class asks the underlying operating system when a
file was last modified, and returns that time to the program. This method’s name,
18
parameters, and return value (in other words, its API) are the same in Java 1.2 for
Windows, Java 1.2 for Mac, as well as Android. The source code that implements the
lastModified functionality for Java 1.2 for Windows (the function
Java_java_io_Win32FileSystem_getLastModifiedTime contained in the file
Win32FileSyste_md.c) is different from the source code for lastModified in Java 1.2 for
Solaris (the function Java_java_io_UnixFileSystem_getLastModifiedTime contained in
the file UnixFileSystem_md.c). This is necessary, because the different operating
systems, and their file systems, tell time differently, and so this source code must
“translate” the underlying operating system’s time information into the standard Java
time system. In fact, because Java’s time-keeping system is heavily inspired by Solaris’s
system, the Unix code for this purpose is roughly 1/3rd the length of the Windows code
— less “translation” work is required. Despite these differences in the underlying
implementation, as a result of this deliberate goal of making APIs available and
compatible across different operating systems, these different works necessarily contain
the same groups of APIs.
VII. PARAMETER NAMES ARE FUNCTIONAL AND NOT CREATIVE
42. Prof. Mitchell’s report asserts that parameter names are particularly creative, purportedly
because they are not reused by programmers. It is correct that the parameter names need
not be reused by programmers, who choose their own names when interacting with a
method. However, these parameter names still play a functional role because they serve
to inform programmers what kind of information the method expects. Like the other
components discussed in Section V.L (paragraph 102) of my Opening Report, this
functional requirement creates practical restraints on the developer’s choice of how to
convey information. So, for example, the creators of an API do have the flexibility to
call the integer value used by the “abs” function “a,” “i,” “x,” or “Steve.” However, if
the value is named “Steve,” that will still make the documentation and specification of
the method unnecessarily confusing to developers who are trying to understand the API.
43. It may be helpful to think about the “creativity” involved in choosing parameter names
19
(and other named elements in an API) as analogous to the creation of a recipe. In writing
down a recipe for cooking a steak, there are a variety of different choices a cook could
make in describing a given ingredient. The main ingredient could be called a “steak,” the
“beef,” or even something more unusual like the “cut of cow.” That said, practical
constraints (such as consumer expectations about ingredient names in recipes) will limit
the reasonable choices for the ingredient name. As one extreme example, a cook
certainly could choose to call the steak “flubber,” and explain to the reader that “flubber”
is meant to refer to the cut of meat being cooked, but this would make it difficult for the
typical reader to process the instructions in the recipe. Calling the steak “flubber” is thus,
as a practical matter, not a reasonable option.
44. A stated in paragraph 112 of my Opening Report, it is my opinion that there is no
meaningful expressive creativity in short, fragmentary words and phrases. All the
parameters in the Java APIs at issue are names and fragmentary phrases, and so they
similarly lack expressive creativity. For example, many methods use parameters that are
single letters (such as a) that reflect the parameter’s roots in algebra. Others are simply
abbreviations; for example, at least 41 parameters in Oracle’s implementation of Java 1.5
are integers called “i” (“i” being a commonly used abbreviation by programmers for
integer variables since long before the Java programming language was created) and at
least 23 are characters called “c” (again, “c” being a well-known abbreviation of
character). Many others are simple names that reflect the underlying idea being
manipulated; e.g., the single parameter name for the method JarEntry is named, simply,
“name,” and the single parameter taken by the method “setSize” is called, appropriately,
“size.”
VIII. THE ORGANIZATION OF PACKAGES IS FUNCTIONAL AND DOES NOT
CONTAIN CREATIVE EXPRESSION
45. As I discussed in section V.N, paragraph 118 of my Opening Report, the organization of
packages in Java is not creative expression. Professor Mitchell also addresses this point,
but I disagree with his conclusions. For example, in paragraph 180, Prof. Mitchell states
20
that the streams “ByteArray-,” “File-,” “Filter-,” and “Piped” could have been grouped
together and then divided into Input and Output classes without affecting the
functionality of the classes. This is incorrect. In fact, the organization of the base classes
InputStream and OutputStream, the hierarchy shown in Professor Mitchell’s report, and
the Reader classes and subclasses he does not mention, are all based on the “Decorator”
design pattern from the classic computer science textbook “Design Patterns,” by Gamma,
Helm, Johnson, and Vlissides. This book is so commonly assigned to undergraduate
computer science students that it has a nickname in the computer science profession —
the “Gang of Four” book. The “design patterns” described in the textbook are common
methods of organizing computer code, and are widely used in the industry as templates
— i.e., “patterns” — that sophisticated professional developers should use when
organizing their own code. Use of these patterns is not merely a good idea; the patterns
help dictate how APIs are designed, because in order for APIs to be accepted and used by
developers, it is important to use design rules and guidelines (like the patterns in Design
Patterns) that the developer community views as accepted and well-understood. Prof.
Mitchell’s focus on a design that is simply appealing aesthetically is not necessarily a
good indication that the design is good from a functional perspective. Instead, reliance
on established patterns of organization — like Decorator — is usually a more reliable
way of building software.
46. In this case, use of the Decorator design pattern helps to ensure that new types of
InputStreams or OutputStreams can be easily added to the hierarchy. Use of the
Decorator pattern also facilitates interactions between InputStreams and Reader classes,
an important aspect of the java.io package that helps move between streams and files of
characters (e.g., the characters of various alphabets) and streams and files of bytes (a
lower level kind of data than a character). Although it may be true that a different design
could yield the same functionality in terms of reading files or other streams, an API
designer must also, for example, ensure that new classes can be added to solve problems
that were not anticipated when the API is designed, and the Decorator design pattern used
21
here is designed to do that. A different design — one using a different design pattern, or
not using an established design pattern at all — might make it difficult to add new
functionality, or use existing classes together in novel ways. Use of the vetted and
established Decorator pattern from the Design Patterns text helps to avoid these
problems. In this way, the choices in the design of java.io referenced by Professor
Mitchell are still highly constrained by the software’s functionality. This is not to say
that the resulting functionality is not aesthetically pleasing, but Prof. Mitchell,
unfortunately, has made the mistake of confusing an aesthetically pleasing outcome with
creative expression. In this case, creative expression was not required; like a knife that
has been well-sharpened by skillful hands, logical application of consistent, basic design
rules created a beautiful outcome without necessarily implying significant creative
expression.
IX. C#, LIKE JAVA, IS UNPROTECTABLE, AND IS ALSO AVAILABLE AS AN
OPEN SPECIFICATION AND IMPLEMENTATION
47. In paragraph 121, Prof. Mitchell claims that “C# and .Net are proprietary products of
Microsoft Corporation and Google Android would have had to negotiate terms with
Microsoft.” (emphasis mine). Prof. Mitchell does not define “proprietary” or otherwise
substantiate this claim. It is my opinion that C# and .Net have very similar characteristics
to Java, and so Prof. Mitchell’s implicit claim that use of C# and .Net would have
imposed a different or more significant legal burden than Java because they are
purportedly proprietary is incorrect.
48. C# is a programming language, and .Net is the collection of libraries that form C#’s
platform, similar to the role the Java Class Libraries play in the Java platform ecosystem.
C# and .Net have APIs. Like the Java APIs, the C# and .Net APIs are functional methods
of operations that are constrained by a variety of requirements. As explained in my
Opening Report, APIs with these characteristics may not be protectable under copyright
law, so it is incorrect to refer to C# and .Net as “proprietary” without detailed analysis of
the C# and .Net APIs. Certain aspects of C# and .Net may be protectable, but (as with
22
Java) other aspects may not be, and it would appear premature to characterize C# as
“proprietary” or assume that Google could not use it without doing more analysis than
Prof. Mitchell appears to have done.
49. More concretely, C# and .Net are also not proprietary (as the word is commonly used) in
at least two significant respects. First, significant components of C# and .Net have been
made available by Microsoft through the international standards body ECMA as open
standards that can be implemented by anyone. (See, e.g., http://www.ecmainternational.org/
publications/standards/Ecma-334.htm and http://
www.monoproject.com/ECMA.) The patents associated with these standards have been made
available to the public for anyone to implement under Microsoft’s “Community Promise”
for specifications. (See
http://www.microsoft.com/openspecifications/
en/us/programs/communitypromise/
covered-specifications/default.aspx.) Second, a third-party version of C# and
.Net, called “Mono,” is available in part under a permissive license that allows anyone
(including Google and Android, should it so desire) to reuse the code. (See
http://www.mono-project.com/FAQ:_Licensing.) Again, these two facts (Microsoft’s
publication of a standard, and the existence of a permissively licensed implementation
not authored by Microsoft) suggest that Prof. Mitchell’s claim that C# and .Net are
proprietary is not correct.
X. ORACLE’S ANALYSIS OF THE FILES AT ISSUE DOES NOT DISCUSS THEIR
QUALITATIVE OR QUANTITATIVE IMPORTANCE, WITH ONE
EXCEPTION THAT IS INCORRECT
50. The Mitchell and Visnick reports discuss the dozen files which I also address in my
Opening Report. However, they do not address the qualitative or quantitative importance
of these files, glossing over the fact that (as I discussed at length in my Opening Report)
these files constitute an incredibly small percentage of the two works at issue — less than
0.13% of Oracle’s implementation of Java 1.5 when measured by number of files, less
than 0.03% of Oracle’s implementation of Java 1.5 when measured by lines of code, and
23
less than 0.02% of Android by number of files and less than 0.005% of Android by lines
of code.
51. Visnick's report states that 12 Android source code files are copied. These are the same
12 files that I discussed in my opening report. I have not confirmed his methodology, but
if he is correct, he admits that at most 12 files out of 57,076 files in Android (0.02%) and
9,479 files in Oracle’s implementation of Java 1.5 (0.13%) were copied. When the lines
of code that Mr. Visnick alleges are similar are compared, the numbers are even smaller
— 0.03% of Oracle’s implementation and 0.005% of Android. Thus, assuming that his
methodology is correct, all Mr. Visnick’s report does is confirm that a very small number
and percentage of allegedly copied files are at issue, and Mr. Visnick in fact proves my
point in paragraph 150 of my Opening Report that these files represent a quantitatively
very small portion of the works at issue.
52. Mr. Visnick’s report makes no attempt at explaining why these 12 files might be
qualitatively important to Java or Android.
53. In comparing the Android APIs to the Java APIs in paragraphs 200-208, outside of the
names and organization that is necessary for compatibility and interoperability, Prof.
Mitchell never identifies any Android source code that implements these APIs and is
identical or even substantially similar to any Oracle source code. Similarly, when
discussing use of the method signatures in paragraphs 212-213, he again focuses on one
line in each method (the signature) and does not discuss or analyze the source code that
implements these methods. As I have shown in paragraphs 13-32 and 34-39, the source
code that implements these methods in Android is not substantially similar to any Oracle
source code. In fact the method signatures are a tiny percentage of the works at issue;
each method signature is typically one line of source code, so the 8190 public methods in
the 37 packages at issue constitute less than 0.3% of the 2.8 million lines of code in Java
1.5. Prof. Mitchell glosses over this by saying that there are "hundreds" of files which
contain these method signatures, but neither his discussions nor Exhibit Copyright-G
actually compare the Oracle implementation to the Google implementation. Actually
24
doing this comparison, as I have done, shows that the signatures are a very small part of
the source code, and that the other components of the source code are not substantially
similar.
54. Prof. Mitchell’s comparison of the Android source code files to the APIs, without doing
an analysis of the Oracle source code, is at odds with public statements made by Sun. In
2006, Tim Bray, who was then Director of Web Technologies at Sun, stated that in Sun's
view, an alternative implementation of the Java APIs would only infringe Sun's rights if
there was “a direct and substantial copying of code.” He also stated that in Sun's view
there was “no issue” with GNU Classpath’s implementation of the Java APIs. (See
“Q&A with Tim Bray,” available at http://www.zdnet.com/blog/
burnette/q-a-with-timbray/200?pg=3.) As I have shown, GNU Classpath, like Android, is an independent
implementation of the Java APIs, with no “direct and substantial copying of code,” so if
GNU Classpath raises no issues, then Android’s use of the Java language API
specifications should also raise no issues.
55. Prof. Mitchell’s report does state briefly in paragraph 235 that, despite constituting only
0.28% by lines of code of the file Arrays.java, “[n]evertheless, rangeCheck is
qualitatively significant to arrays.java, as it is called nine times by other methods in the
class.” Prof. Mitchell’s reliance on frequency of use to assess qualitative significance is
misplaced, for several reasons.
56. First, frequency of use is a poor proxy for qualitative significance. For example, in
building a car, one designer might choose to use hundreds of 9 mm bolts, while another
might choose 3/8 inch bolts. The fact that hundreds of these bolts were used does not
mean that the decision to use 9 mm bolts was qualitatively significant to the car’s design.
Just as the 9 mm bolts perform a mundane function, so too does the rangeCheck method,
for the reasons I explained in my Opening Report in paragraphs 153-156.
57. Second, as a general matter, reuse of a function may or may not be indicative of its
qualitative importance; it may indicate simply that something is simple and frequently
reused, or perhaps that it is used inefficiently. In fact, while rangeCheck is used nine
25
times in Oracle’s Arrays.java, it is used only once in Android’s TimSort.java, and only
once in Android’s Comparable TimSort.java.
58. Third, in this specific case, the function is reused multiple times in the Oracle code
largely because the programming of Arrays.java is inefficient as a result of constraints
imposed by the Java language. A comment in the file indicates that:
/*
* The code for each of the seven primitive types is largely
identical.
* C'est la vie.
*/
This repetition of identical code is often a sign that code has been repeated needlessly,
and in this case, the “c’est la vie” comment from the original programmer seems to
perhaps acknowledge that he regretted the “largely identical” code. The code is identical,
and reused seven times, because the Java language does not support a feature called
“generic functions for primitive types.” If the Arrays.java functionality were
implemented in a different language that supported this feature, such as C++ or C#, there
would be only one copy of rangeCheck, not seven. Thus the metric of number of calls is
not a measure of the importance of rangeCheck, but rather of the inadequacies imposed
by the Java language. These seven sets of “largely identical” code explain seven of the
nine uses of rangeCheck. The other two uses are similar in that they are also called prior
to sorting arrays, but for sorting arrays of Objects rather than primitive types. As a result,
it is incorrect to say that the mere numerical use of rangeCheck makes the function
qualitatively significant; instead, a more plausible interpretation is that the nine uses of
rangeCheck in Arrays.java justify a conclusion that the file was written to cope with
inadequacies of the Java language, incorrectly inflating any alleged importance of
rangeCheck. (TimSort.java and ComparableTimSort.java do not have to cope with this
inadequacy because they do not operate on the so-called primitive types.)
59. Finally, it should be noted that Arrays.java, TimSort.java, and ComparableTimSort.java
all provide the functionality of sorting arrays. As noted in my Opening Report, at the
time Oracle was first made aware of TimSort.java and ComparableTimSort.java, Oracle’s
26
reaction was not to complain of any alleged “copying,” but rather to accept TimSort.java
and ComparableTimSort.java as contributions to Java to be distributed to every single
user of Java, and to praise the author’s contribution as significantly increasing the speed
and performance of Java. That this one, very brief segment of these two files is similar to
code in Arrays.java should strongly suggest (even to someone untrained in programming)
that the important part of the TimSort.java and ComparableTimSort.java files are the over
900 lines that are completely different (as opposed to the allegedly similar 9 lines of
code), since it is this different part that had such a significant impact on the functionality
and efficiency of the software. As a result of these four points, and in agreement with the
analysis in my Opening Report, it is my opinion that this method is not qualitatively
significant, either to the file Arrays.java or to the infringed work as a whole.
60. I reserve the right to update and refine my opinions and analyses based on any additional
materials or information that may come to my attention in the future, including additional
contentions by Oracle as well as any rulings issued by the Court in this case. I also
reserve the right to supplement my opinions and analyses as set forth in this report in
light of any expert reports submitted by Oracle and in light of any deposition or trial
testimony of Oracle’s experts.
DATED: August 12, 2011
[signature]
Owen Astrachan, Ph.D.
27
Exhibit F: Comparison of Android and Oracle ZipFile.getInputStream
BEGIN ORACLE SOURCE CODE - HIGHLY CONFIDENTIAL
1
2
3
4
5
6
END ORACLE SOURCE CODE - HIGHLY CONFIDENTIAL
7
Exhibit G: PublicPrivateAnalyzer.py Source Code
1
Printed by Owen L. Astrachan
Friday August 12, 2011 - PublicPrivateAnalyzer.py - 1/4
Printed by Owen L. Astrachan
Friday August 12, 2011 - PublicPrivateAnalyzer.py - 2/4
Printed by Owen L. Astrachan
Friday August 12, 2011 - PublicPrivateAnalyzer.py - 3/4
Printed by Owen L. Astrachan
Friday August 12, 2011 - PublicPrivateAnalyzer.py - 4/4
**********************************
**********************************
392:
KEKER & VAN NEST LLP
ROBERT A. VAN NEST - #84065 .
[email]
CHRISTA M. ANDERSON - #184325
[email]
[address, phone, fax]
KING & SPALDING LLP
SCOTT T. WEINGAERTNER (Pro Hac Vice)
[email]
ROBERT F. PERRY
[email]
BRUCE W. BABER (Pro Hac Vice)
[address, phone, fax]
KING & SPALDING LLP
DONALD F. ZIMMER, JR. - #112279
[email]
CHERYL A. SABNIS - #224323
[email]
[address, phone, fax]
IAN C. BALLON - #141819
[email]
HEATHER MEEKER - #172148
GREENBERG TRAURIG, LLP
Attorneys for Defendant
GOOGLE INC.
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN FRANCISCO DIVISION
_________________
ORACLE AMERICA, INC.,
Plaintiff,
v.
GOOGLE INC.,
Defendant.
___________________
Case No. 3:10-cv-03561-WHA
GOOGLE INC’S OBJECTIONS TO
ORDER CLARIFYING ORDER
REGARDING JURY SELECTION
Judge: Hon. William H. Alsup
Date Comp. Filed: October 27, 2010
Trial Date: October 31, 2011
REQUESTED RELIEF
Pursuant to the Court’s Order Clarifying Order Regarding Jury Selection, dated August 30, 2011 (“Order”), defendant Google, Inc. (“Google”) respectfully submits the following objections. Specifically, Google objects to the Court’s tentative plan to use a pre-cleared venire for a scheduled criminal trial as the venire for trial of this case. Google respectfully requests that the jury selection process in this case begin with the broader venire that typically would be used in a civil case in this District, rather than the pre-cleared venire described in the Order.
OBJECTIONS
On August 29, 2011, the Court issued an Order Regarding Jury Selection, informing the parties that it had a “second large criminal trial” scheduled to begin on October 17, 2011, and that, if the criminal trial “does not begin as scheduled on October 17, then jury selection in the instant civil action shall occur on October 19 and the opening day of trial will remain October 31.” Order Regarding Jury Selection, Docket No. 366, at 1:16-18. The following day, in the Order Appointing Rule 706 Expert and Counsel, the Court noted that there was uncertainty as to whether the lengthy criminal trial would begin on October 17 as currently scheduled. Order Appointing Rule 706 Expert and Counsel, Docket No. 374, at 2:6. Accordingly, the Court explained that, if the criminal trial were continued, trial in this case would begin as scheduled on October 31 but would be bifurcated into liability and damages phases. Id. at 1:25-2:8. On the same day, the Court issued an Order clarifying its Order Regarding Jury Selection, stating that it would use a pre-clearance procedure for the criminal trial venire, which would then serve as the venire in this civil case, in the event the criminal trial is continued:
To be clear, the Court is pre-clearing a large number of venire persons for a multi-month trial in the criminal case and these same venire persons would be used, though many less, for this civil case in the event the criminal trial had to be postponed. If any party objects to using this pre-cleared pool for this civil case, objections must be filed by NOON on SEPTEMBER 6, 2011.
Order at 1:16-19 (emphases in original).
Google respectfully objects to the use in this case of the criminal trial’s pre-cleared group
of prospective jurors, because that group necessarily would constitute a significantly less diverse pool of potential jurors than would otherwise be available for jury selection. The policy of
1
providing all litigants in federal courts with juries selected at random from a “fair cross section” of the community is well-established in United States law and fundamental to providing fair trials. See http://www.cand.uscourts.gov/
juryselection (quoting 28 U.S.C. § 1861). The Court’s proposed procedure—using only the group of potential jurors pre-cleared for a multi-month criminal proceeding—is less likely to provide a fair cross section of the community than the usual venire available in patent-infringement cases such as this one. As a practical matter, most potential jurors who ordinarily would be available to serve on a three-week civil trial will have significant personal or professional commitments that may make them ineligible to serve in a multi-month criminal trial. Accordingly, the pre-cleared group will be smaller, less diverse, and less representative than the broader group that would otherwise be available for selection. See United States v. Warner, 506 F.3d 517, 524 (7th Cir. 2007) (analyzing a study comparing jurors in long and short federal trials and finding “a number of disquieting differences”).
By contrast, the group of prospective jurors who could serve for the duration of a fifteen-day trial will be significantly larger and more diverse, especially where those fifteen trial days will be bifurcated into two smaller phases separated by several weeks. To maximize the size and diversity of the venire, enhance the qualify of the jury-selection process, and increase the likelihood that the jury eventually selected will provide the parties with a fair cross section of the community, Google respectfully requests that the Court not use the pre-clearance process described in the Order. Instead, Google asks that the Court employ the venire and jury-selection process that the Court ordinarily would use for a three-week trial in a civil case of this nature.
Dated: September 6, 2011
KEKER & VAN NEST LLP
By: /s/ Robert A. Van Nest
ROBERT A. VAN NEST
Attorneys for Defendant
GOOGLE INC.
2
|
|
Authored by: hardmath on Friday, September 09 2011 @ 09:05 AM EDT |
Please indicate the nature of the correction in the subject
line.
---
At the moment CLIB is more suited for theorem provers, less useful for games.
This will change as soon as the game potential of theorem provers is recognized.[ Reply to This | # ]
|
|
Authored by: hardmath on Friday, September 09 2011 @ 09:07 AM EDT |
Post a link to the story itself when starting a discussion
thread...
---
At the moment CLIB is more suited for theorem provers, less useful for games.
This will change as soon as the game potential of theorem provers is recognized.[ Reply to This | # ]
|
- Judge Alsup wants to see some Larry on Larry action in mediation - Authored by: Anonymous on Friday, September 09 2011 @ 03:55 PM EDT
- Where the design really came from - Authored by: Anonymous on Friday, September 09 2011 @ 09:03 PM EDT
- U.S. Court of Appeals Upholds Lower Court Decision - Authored by: tiger99 on Saturday, September 10 2011 @ 08:06 AM EDT
- U.S. Court of Appeals Upholds Lower Court Decision - Authored by: Anonymous on Saturday, September 10 2011 @ 08:16 AM EDT
- German Court Upholds Injunction Against Galaxy Tab 10.1 - Authored by: Anonymous on Saturday, September 10 2011 @ 12:47 PM EDT
- Eight False Promises of the Internet - Authored by: Kilz on Saturday, September 10 2011 @ 02:53 PM EDT
- Barnes & Noble's Nook revenue up 140 percent - Authored by: JamesK on Sunday, September 11 2011 @ 12:43 PM EDT
- Google files motion for partial summary judgment - Authored by: Anonymous on Monday, September 12 2011 @ 12:10 AM EDT
- Rambus Patents Invalid - The Consequences - Authored by: sproggit on Monday, September 12 2011 @ 01:42 AM EDT
- Righthaven: We Might Have To Declare Bankruptcy - Authored by: JamesK on Monday, September 12 2011 @ 05:57 AM EDT
|
Authored by: hardmath on Friday, September 09 2011 @ 09:09 AM EDT |
Anything related to Groklaw readers interests, which pretty
much covers the universe of ideas.
Except the current article, of course.
---
At the moment CLIB is more suited for theorem provers, less useful for games.
This will change as soon as the game potential of theorem provers is recognized.[ Reply to This | # ]
|
- What was the question? - Authored by: BJ on Friday, September 09 2011 @ 10:12 AM EDT
- Forbes patent advice to CEOs... - Authored by: Anonymous on Friday, September 09 2011 @ 02:46 PM EDT
- Off Topic - Authored by: Anonymous on Friday, September 09 2011 @ 05:04 PM EDT
- StringCompareTo code question - Authored by: YurtGuppy on Friday, September 09 2011 @ 06:57 PM EDT
- Former SAP subsidiary TomorrowNow will plead guilty to downloading software from Oracle - Authored by: IMANAL_TOO on Saturday, September 10 2011 @ 09:31 AM EDT
- USPO Strike again! - Authored by: Anonymous on Saturday, September 10 2011 @ 06:11 PM EDT
- USPO Strike again! - Authored by: Anonymous on Saturday, September 10 2011 @ 06:54 PM EDT
- USPO Strikes Out! - Authored by: Anonymous on Saturday, September 10 2011 @ 09:25 PM EDT
- Locker File Sharing Suits Come North - Authored by: emacsuser on Saturday, September 10 2011 @ 07:50 PM EDT
- International Rugby Board using Silverlight - Authored by: Anonymous on Sunday, September 11 2011 @ 06:08 AM EDT
- Pick your brains (US only) - What would be best in-flight Android data plan? - Authored by: Anonymous on Sunday, September 11 2011 @ 09:03 AM EDT
- September 12 hearing Cancelled/rescheduled -- SCO bankruptcy - Authored by: Anonymous on Sunday, September 11 2011 @ 11:17 AM EDT
- Linux 3.1 goes back to 1997 -> pic - Authored by: Anonymous on Sunday, September 11 2011 @ 04:46 PM EDT
- Judge: copyright troll showed “staggering chutzpah” in sending its own subpoenas to ISPs - Authored by: Anonymous on Monday, September 12 2011 @ 07:30 AM EDT
|
Authored by: hardmath on Friday, September 09 2011 @ 09:10 AM EDT |
Please post the HTML in Plain Old Text, if you know what I
mean.
---
At the moment CLIB is more suited for theorem provers, less useful for games.
This will change as soon as the game potential of theorem provers is recognized.[ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, September 09 2011 @ 10:40 AM EDT |
Think back to a time before Oracle aquired Sun.
Remember a standalone company called BEA? They had a nice web application stack
called Weblogic.
However, if you'll recall, they also had their own Java implementation called
JRockit. This product still exists.
It was jvm/api compatible down to the core.
You could port applications from Sun's JAVA environment to the JRockit
environment with little or no changes.
This was Java infringement (if you take Oracle's stance today) in the grandest
scale. They called it Java, they made no qualms about it. Sun encouraged it.
Oracle bought Weblogic, gaining JRockit. They still have it available today on
their website. You can download it right now if you'd like.
So to me, this would seem to preclude their ability to sue anyone for making
something that is API compatible with Java, as they themselves once
sold/distributed/made available the same kind of product while another company
held all the rights to JAVA.
Nuff said.[ Reply to This | # ]
|
|
Authored by: Barbie on Friday, September 09 2011 @ 11:28 AM EDT |
> As one extreme example, a cook certainly could choose to
> call the steak “flubber,” and explain to the reader that
> “flubber” is meant to refer to the cut of meat being
> cooked, but this would make it difficult for the typical
> reader to process the instructions in the recipe. Calling
> the steak “flubber” is thus, as a practical matter, not a
> reasonable option.
On the other hand, I may have eaten at a restaurant that *should* have called
their steak "flubber."
---
First you innovate,
Then they litigate,
Thus we all lose.[ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, September 09 2011 @ 12:08 PM EDT |
I'm not sure why the Oracle Java code is redacted. I thought that that the
source of Java was publicly available but maybe I'm wrong. If it is available
then what's the point of redacting it?
Some ideas:
- Maybe there are significant security errors in the Oracle code?
- Maybe it was copied from somewhere else? Shades of SCO.
- Perhaps lawyers are scared of showing code? It might bite.
- The copyright to the code belongs to someone who won't give permission for it
to be public?
- Oracle is insisting on a license to view the code?
Can anyone explain?[ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, September 09 2011 @ 12:09 PM EDT |
I wonder how many similarities are based on both parties having used the same
3rd party as a reference?
Tufty
[ Reply to This | # ]
|
|
Authored by: YurtGuppy on Friday, September 09 2011 @ 12:53 PM EDT |
I assume that Oracle people were involved in the redaction process.
By allowing the Android code to be shown, are they not then affirming that the
Android code is substantially different from the Oracle code?
---
a small fish in an even smaller pond[ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, September 09 2011 @ 03:44 PM EDT |
The docket shows that Judge Alsup has apparently overruled Google's
objections to the proposed jury pool for a fall trial.
Oracle America, Inc. v. Google Inc.
400 ORDER OVERRULING
OBJECTIONS TO JURY SELECTION ,
PROCEDURE re 392 Objection filed by Google
Inc.. Signed
by Judge Alsup on September 7, 2011. (whalc1, COURT
STAFF) (Filed on 9/7/2011)
--bystander1313 [ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, September 09 2011 @ 04:22 PM EDT |
I particularly like Note 10 explaining how implementations can be different.
Are the expert reports that Prof. Astrachan is rebutting available? It would be
so interesting to see what Mitchell, Visnick, and Purdy had written. You always
have to wonder when the report is not 'visible' what they are trying to hide.
<I suspect snorts of derision>
Jane (not logged in and unsure if I have an account)[ Reply to This | # ]
|
|
Authored by: BJ on Friday, September 09 2011 @ 04:49 PM EDT |
Love it!
bjd
[ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, September 09 2011 @ 06:35 PM EDT |
This case shows more dangers from the constantly expanding grip that
copyright law has on the lives of nearly everyone. For people that say that
copyright is the right or only way to protect software, beware of what you wish
for.
A good background on the subject is given in a document mentioned
before on Groklaw, and found in its LEGAL
RESEARCH page under Copyright Law.
The Strange Odyssey of Software Interfaces and Intellectual
Property Law
What the author describes is an evolution in the way
courts have ruled on the protections offered to software through copyright and
patent laws. Before 1980, it was unclear whether either copyright or patent law
offered much protection to software. A recommendation from the CONTU commission
and a subsequent change in copyright law in response in 1980 did the
trick.
CONTU expressed confidence that copyright law could
evolve to make appropriate distinctions between program ideas (which of course
would not be protectable) and program expression (which would be).31 Perhaps
because the CONTU Commissioners were mostly copyright lawyers who knew very
little about computer programs, the Report did not meaningfully address
important scope of protection issues, including the protectability (or not) of
program interfaces.32 In 1980, Congress amended copyright law, as CONTU
recommended.33
That confidence would be put to the test in
later years, all the way up to where we are today. The article goes on to
explain that the apparent scope of copyright protection for software interfaces
was dramatically weakened over time, particularly by two cases: Computer Associates Intern., Inc. v.
Altai, Inc. in the Second Circuit and Sega Enterprises,
Ltd. v. Accolade, Inc. in the Ninth Circuit.
Altai and
Sega contributed to the eventual shift away from reliance on copyright
protection for program SSO and interface innovations and toward reliance on
patent protection. But developments on the patent side also made this form of
protection for program SSO more plausible than in the 1970’s. Especially
important was the Supreme Court’s 5-4 decision Diamond v. Diehr in 1981, which
signaled a new receptivity to patenting computer program-related
inventions.
The drive to move more towards patent protection
in software was driven in part by the decreased protection offered by copyright
given various court decisions.
Oracle's claims in this case can be seen
as an attempt to start changing course and make copyright a stronger form of
protection for a wider scope of software material than is currently allowed.
There's some real danger that this may succeed in part, if not here then perhaps
at some later time.
One of the problems I see with advocates of
abolishing all software patents is considering what happens were such a policy
change to actually happen. It's not as though proponents of IP protection for
software would simply leave things in a vacuum. Instead, they would likely move
to strenthen protection in other ways, just as they did when copyright
protections were weakened in the 1990's and they moved to stronger patent
protection. Given the power of the pro-copyright lobbyists to keep U.S. and
foreign governments expanding the scope and reach of copyright laws to curtail
otherwise common and lawful activities of ordinary citizens over the years, it's
not a reach to think that lawmakers could be convinced to codify even stronger
copyright law concerning software into the law. This would be a stronger
likelihood if copyright advocates could argue that software had no other form of
protection available to it.
I think this would be a terrible result. As
bad as patent law might seem, putting software strictly under copyright law
could be far worse. Copyright protection would lack the limitations of patents
such as shorter fixed periods of enforcement, requirements for publication,
requirements and mechanisms for formal approval before granting a monopoly, and
formal procedures for overturning an improperly granted monopoly. What's worse,
governments are increasingly granting private parties the authority to enforce
claims of copyright infringement outside the legal system. In some cases,
material may be barred from distribution, and citizens may be denied to even
have access to the internet, over mere claims of copyright infringement before
such claims are fully proven. Unlike patent law, which lately seems more
directed to constraining some of the power of patent owners, recent copyright
law changes and proposed changes have all tended to favor increasing the power
of copyright owners.
We shouldn't feel too secure that court precedents
in some Federal Circuits have disfavored the copyrightability of software
interfaces. Those decisions could be wiped away with a change in copyright law
from a copyright-friendly Congress. Or court precedents could be altered or
weakened by alternative rulings from other courts. Oracle appears to be seeking
such a ruling in this case at the district level, perhaps hoping to have it
eventually sent to a Ninth Circuit Court of Appeals to revisit earlier decisions
and perhaps reach a different outcome. That's a really troublesome possibility
for many software developers in the future, particularly Open Source and Free
Software advocates.
--bystander1313 [ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, September 09 2011 @ 07:18 PM EDT |
In reading Paragraph 45, I realized that I've been attending
the wrong colleges, when I was a Computer Science (or other
branding) major.
"45. As I discussed in section V.N, paragraph 118 of my
Opening Report, the organization of packages in Java is not
creative expression. Professor Mitchell also addresses this
point, but I disagree with his conclusions. For example, in
paragraph 180, Prof. Mitchell states
20
that the streams “ByteArray-,” “File-,” “Filter-,” and
“Piped” could have been grouped together and then divided
into Input and Output classes without affecting the
functionality of the classes. This is incorrect. In fact,
the organization of the base classes InputStream and
OutputStream, the hierarchy shown in Professor Mitchell’s
report, and the Reader classes and subclasses he does not
mention, are all based on the “Decorator” design pattern
from the classic computer science textbook “Design
Patterns,” by Gamma, Helm, Johnson, and Vlissides. This book
is so commonly assigned to undergraduate computer science
students that it has a nickname in the computer science
profession — the “Gang of Four” book. The “design patterns”
described in the textbook are common methods of organizing
computer code, and are widely used in the industry as
templates — i.e., “patterns” — that sophisticated
professional developers should use when organizing their own
code. Use of these patterns is not merely a good idea; the
patterns help dictate how APIs are designed, because in
order for APIs to be accepted and used by developers, it is
important to use design rules and guidelines (like the
patterns in Design Patterns) that the developer community
views as accepted and well-understood. Prof. Mitchell’s
focus on a design that is simply appealing aesthetically is
not necessarily a good indication that the design is good
from a functional perspective. Instead, reliance on
established patterns of organization — like Decorator — is
usually a more reliable way of building software."
I'd never heard of the "Gang of Four" book. Although now,
I'm going to look for it on Amazon or Barnes and Noble, and
potentially buy it. Odd how you learn what needs to be read
in your (hopeful) profession, by reading lawsuits....
Have a great weekend. :)
Patrick.[ Reply to This | # ]
|
|
Authored by: Ian Al on Saturday, September 10 2011 @ 05:56 AM EDT |
But, did the Prof. use a much bigger knife than he needed to? It seems to me
that he not only turned Oracle's steak into ground beef, but also managed to
skewer Oracle's Patent 702.
Here's
what Google said.
Google seeks to rely on Oracle's JavaOS
product as anticipating the claims of the '702 patent. Oracle stated in its
infringement contentions that its "JavaOS" product implements the '702 patent,
and it is undisputed that JavaOS was publicly released and licensed more than a
year before the filing date of the '702 patent, invalidating the '702 patent
under 35 U.S.C. § 102 ("§ 102"). However, Oracle did not produce any JavaOS
source code until May 2011, and has still not produced the JavaOS source code
that predates the '702 patent by a year. In view of Google's persistence on this
subject, Oracle just sent Google a letter trying to amend its infringement
contentions without leave of the Court, and argue that its identification of
JavaOS 1.0 as a product practicing the patent was "in error." (See Ex. M.) Thus,
Google's difficulty in understanding and charting the relevant JavaOS
information is a direct result of Oracle's own discovery abuse, as Oracle
desperately tries to keep its own invalidating product out of the
case.
I'm just going over my notes from my last lecture from PoIR
and I think that each API represents a math function and the implementation of
the API refers to the associated math algorithm used. The algorithm cannot be
patent protected in law but the function may be protectable if it leaps the
patent hurdles.
What is the chance that the APIs in JavaOS 1.0 are
functionally identical to the Java version that the Prof. studied?
The
Prof. said, This is because it is Java’s stated policy, for
purposes of compatibility, to keep versions of Java as similar as possible to
previous versions. When new versions are released, API elements are essentially
never changed or removed, only added. This is known as “upwards” compatibility,
as referenced in the Java SE Compatibility Policy (available at
http://java.sun.com/j2se/1.5.0/ compatibility.html.) As a result of this policy,
the APIs in Java 1.1 are also present, in their entirety, in Java 1.2; all Java
1.1 and any new APIs added in Java 1.2 are present in Java 1.3; all Java 1.2
APIs and any new APIs added in Java 1.3 are present in Java 1.4; and so
on.
Since the APIs are a schedule of the available functions in
Java, if any of those functions have a patent date more than a year after Java
1.1 (or, is that Java 1.0?) then they are invalidated by the prior art in the
published Java. Only if the patented invention API is published for the first
time less than a year after the patent award could it not be invalidated by
prior art.
So, Oracle, which of those APIs contain which alleged patent
infringements by Google and when were they first published?
Mind you,
JavaOS may be nothing to do with the Java APIs that the Prof. studied. However,
Oracle are desperate to avoid study of JavaOS1.0 and so, if not in the language,
why would JavaOS have any patentable function similarities to Dalvik and the
Android OS?
I think this is an attempt to convince a jury that Dalvik
and Android is Java, but under a different name. Thus, if they can show that the
patented math functions were in Java then they must also be in Android. However,
the patented inventions being in Java is an irrelevancy.
The only
legal question is whether the patented inventions are in Android. In other
words, it is not the three shell game that Oracle are trying to play, but a
one-shell game in which you have to prove the pea is under the shell. The pea is
so small and the shell is so large. It's not a trivial
task!--- Regards
Ian Al
I_An Algorithm is free speech. [ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, September 10 2011 @ 10:52 AM EDT |
If I understand correctly, Oracle's position is that it is the API itself
whose copyright is being infringed, not necessarily just the implementation
of
that API. I am far from convinced that an API is purely functional, which
seems
to be the crux of this report.
Anyone who has had to design an API
for a
non-trivial library can tell you that it is pretty hard, and IMO, is as
creative
a form of expression as any code is. A file system API is a poor
example
because it is tightly tied to the file system API provided by the OS,
and
most OS's largely provide the same basic functions. But for more complex
things like security,
generic IO, or GUI programming, it is not as
straightforward. As an
example, there as many different APIs as there are GUI
frameworks, each
with a different approach, which would not have been the case
if it was
purely functional. Languge differences aside, the approach in Qt is
different from AWT is different from Flash is
different from HTML (although
they are all converging to a similar
approach in
QtQuick/JavaFX/Flex/HTML5.)
Although I don't agree with this
professor's position on this matter, I am
not sure how it should affect the
copyrightabilty of APIs, so I am not sure I
agree with Oracle's position
either.
[ Reply to This | # ]
|
- Is API design purely functional? - Authored by: Anonymous on Saturday, September 10 2011 @ 11:03 AM EDT
- His functional/creative argument is really weird - Authored by: Anonymous on Saturday, September 10 2011 @ 11:28 AM EDT
- API compliance is functional, API design may be creative - Authored by: Anonymous on Saturday, September 10 2011 @ 12:34 PM EDT
- The API may be functional, but in _implementing_ it those creative choices are moot - Authored by: Anonymous on Saturday, September 10 2011 @ 01:05 PM EDT
- Is API design purely functional? - Authored by: Anonymous on Saturday, September 10 2011 @ 01:07 PM EDT
- Is API design purely functional? - Authored by: Anonymous on Saturday, September 10 2011 @ 01:52 PM EDT
- Is API design purely functional? - Authored by: PJ on Sunday, September 11 2011 @ 12:14 PM EDT
- No it is not hard - Authored by: Anonymous on Sunday, September 11 2011 @ 06:30 PM EDT
- No it is not hard - Authored by: Anonymous on Sunday, September 11 2011 @ 06:33 PM EDT
- No it is not hard - Authored by: Anonymous on Sunday, September 11 2011 @ 07:07 PM EDT
- No it is not hard - Authored by: Anonymous on Monday, September 12 2011 @ 12:42 AM EDT
- No it is not hard - Authored by: Anonymous on Monday, September 12 2011 @ 05:18 AM EDT
- Something the "Gang of Four" said - Authored by: Anonymous on Monday, September 12 2011 @ 01:39 AM EDT
|
Authored by: artp on Sunday, September 11 2011 @ 11:42 PM EDT |
Spell it out.
API means Application Programming Interface. If it isn't
being used with someone else's program, then it isn't being
interfaced, so what's the point?
It is far too easy for judges and juries (as with anyone
else) to forget what the meaning of the acronym is. The only
purpose of an API is to allow someone else to write a
program using that API in order to interact with your own
program. If that isn't necessary, then you don't need to
PUBLISH an API. Once you open up to interaction, you also
open up to reusing the API in another manner, too, but
that's the price of freedom, is it not?
---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?[ Reply to This | # ]
|
|
Authored by: complex_number on Monday, September 12 2011 @ 08:18 AM EDT |
<a
href="http://www.theregister.co.uk/2011/09/12/larry_versus_larry_google_ver
sus_oracle/">[www.theregister.co.uk]</a><P>
To quote:<br>
<blockquote>
The Larrys must show up on September 19 at 9am Pacific time, a US magistrate has
said in a written court order. The Oracle and Google chief executives must also
be prepared for further appearances between September 20 and 30, the magistrate
has ordered here and picked up here.
</blockquote>
Lets see how the lawyers (on both sides) try to wriggle out of this one...
<P>
---
Ubuntu & 'apt-get' are not the answer to Life, The Universe & Everything which
is of course, "42" or is it 1.618?
[ Reply to This | # ]
|
|
|
|
|