ORDER OVERRULING SPOON-FEEDING OBJECTION TO KEMERER EXPERT TESTIMONY
WILLIAM ALSUP, District Judge.
This order answers the question left open in the earlier order concerning Dr. Chris F. Kemerer (Dkt. No. 1806).
* * *
Google raises five challenges to Dr. Chris F. Kemerer's methodology following the recent deposition of Rohit Chatterjee, who collaborated with Kemerer in performing his "stability" and "centrality" analyses in his expert report. First, Kemerer worked with Chatterjee and the rest of the Keystone research team for the first time to prepare his expert report in this case. Second, Kemerer did not attach the Python scripts used by the Keystone team to his report. Third, Kemerer decided which tests to use based on Chatterjee's and the Keystone team's recommendations, which typically consisted of only one option with no suggested alternatives. Fourth, neither Kemerer nor Chatterjee could answer Google's questions about the API package names found in the test scripts. Fifth, Google alleges various substantive flaws in Kemerer's analysis, as discussed below.
1. NO PRIOR COLLABORATION.
Google notes that Kemerer and Chatterjee had never worked with each other prior to this case, and that Chatterjee and the Keystone research team have worked with other Oracle experts over the course of this litigation. Google does not articulate what the point of this observation is, or explain why this arrangement between Oracle's experts and Keystone is a basis for exclusion.
Nonetheless, Oracle is incorrect in claiming Google's argument is irrelevant to the admissibility of Kemerer's report and testimony. The circumstances of Oracle's collaborations with Keystone at least exacerbate the risk that biased, client-prepared, and litigation-driven tests were spoon-fed to experts to pass off as "facts." See Therasense, Inc. v. Becton, Dickinson and Co., Nos. C 04-02123 WHA, C 04-03327 WHA, C 04-03732 WHA, C 05-03117 WHA, 2008 WL 2323856, at *2 (N.D. Cal. May 22, 2008). The methodology Kemerer relied on must therefore "be subjected to heightened scrutiny such that it would be reasonable for a truly independent professional in the field of endeavor to base an important decision on it." Ibid.
2. THE PYTHON SCRIPTS MISSING FROM KEMERER'S REPORT.
Google complains that although many of the scripts used by Keystone were "provided in hard copy form" with Kemerer's report, certain Python scripts used by Chatterjee as inputs to Kemerer's centrality analysis were not provided with Kemerer's report. Google claims Chatterjee "conceded that the Python scripts were inputs to his use of the Understand and NetworkX tools," and also conceded "that Understand has settings that can be varied," but does not explain the significance of either concession. Moreover, Chatterjee explained in deposition that he used the Python scripts to invoke the Understand and NetworkX tools, and that he used the default settings for the Understand tool (Chatterjee Dep. at 136-41, 154). Google dismisses these explanations, claiming they do not matter because Chatterjee could have used other Understand settings, and "Kemerer's description of the use of the Understand program for purposes of the `centrality' analysis is so cursory that one could not discern what settings were purportedly used from a review of his report."
Again, it is unclear what Google's point about admissibility is here. Even if Google could not at first identify the Understand settings used in the centrality analysis based on Kemerer's report, Google now has that information because Chatterjee explained that he used Understand's default settings (id. at 154). Moreover, as Oracle points out, Google does not claim that any use of these Python scripts or Understand settings undermined the methodology or reliability of Kemerer's centrality analysis. Kemerer's report explained that he used Understand to process and analyze Java source files "in order the extract the dependency structure of the app's source code," and that "[t]he output of this dependency analysis was subsequently processed" using a Python script "to quantify the app's dependency on the 37 copied Java API packages" (Kemerer Rpt. ¶ 133 & accompanying footnotes). Chatterjee then clarified in deposition that he used Understand's default settings (Chatterjee Dep. at 154). Nothing in these explanations indicates Kemerer's methodology was opaque or improper, and Google has shown no reason why Kemerer's analysis should be excluded as unreliable based on its use of — or his report's failure to produce — the intermediate Python scripts.
3. ADOPTION OF CHATTERJEE'S RECOMMENDATIONS.
Google also claims that Chatterjee typically gave Kemerer a single option as to which tests to use, without suggesting alternatives, and that Kemerer "approved the Keystone-selected option." Google's point seems to be that Kemerer did not actually direct the tests, but merely rubber-stamped the professional judgment of Chatterjee and the Keystone team as to which tests to use. Google cites two examples of this alleged rubber-stamping: the choice to use different methods to gather data from Android and Java, and the choice to use Understand.
Google misrepresents Chatterjee's testimony in claiming that Kemerer did not actually make a "choice" to use different data-collection methods for Android and Java. Chatterjee clearly stated that he did not "make that choice," but just "pointed [Kemerer] towards what [he] found" in Android's source code (Chatterjee Dep. at 226). Chatterjee also explained that Kemerer "pointed [him] to the source code," and that Kemerer "made the choice" to use the particular API documentation files that Chatterjee found (ibid.). Kemerer and Chatterjee have consistently claimed that Kemerer directed Chatterjee to find raw data on Android's source code, Chatterjee found Android's API documentation files in plain text and XML, and Kemerer chose to use the files that Chatterjee found (see Kemerer Rpt. ¶ 96-99; Chatterjee Dep. at 226). Google has identified no basis for disbelieving this explanation.
The real point of Google's argument seems to be that Chatterjee should have found Android's API documentation files in Java instead of plain text and XML; Chatterjee should have offered Kemerer the choice to use the Java files instead; and Kemerer should have used the Java files. The merit of this argument, insofar as it alleges a substantial flaw in Kemerer's methodology, is addressed below. However, to the extent that Google tries to spin this as a rubber-stamping problem by insinuating that Chatterjee, not Kemerer, made the meaningful choice to use plain text and XML files instead of Java files, the argument is meritless. This order disagrees with Google's tortured reasoning that an expert's choice is necessarily "rubber-stamping" unless the expert was explicitly presented with multiple options, even for such mundane "choices" as acceptance of raw data which the expert himself had directed assistants to collect. Chatterjee described finding the raw data that Kemerer had requested, asking Kemerer if the files were "ok" to use, and getting Kemerer's permission to parse the files (Chatterjee Dep. at 166). Under these circumstances, even if Kemerer's choice was not a particularly complex one (and Google has not identified any reason why it should have been), there is no support for the proposition that anyone other than Kemerer — let alone Chatterjee, who acted only according to Kemerer's instructions and with his permission — "directed" the test.
Google's second example of alleged rubber-stamping is that "Chatterjee effectively chose" to use Understand without Kemerer's "supervision or substantive technical input." Google cherry-picks from Chatterjee's deposition to suggest Kemerer played no significant part in the decision to use Understand. Reading the relevant part of Chatterjee's deposition as a whole, however, yields a different story. Google asked, "[Y]ou said, Dr. Kemerer, here is the default schema. Is this okay with you? And he said, Yes, it seems fine to me. Is that how it went down?" and Chatterjee replied, "I won't characterize it exactly that way. He asked me like what's the — what does Understand exactly capture, I want to know. I gave him the schema. And he — and I asked him, you tell me what you want to pick out of this choice" (Chatterjee Dep. at 155-56). Chatterjee also mentioned that Kemerer asked "a few questions along what this is, what that is" (id. at 157). A "couple of days later," Kemerer told Chatterjee "he was fine using [the Understand schema Chatterjee showed him]" (id. at 156). Google also asked, "[D]id you explain to him what is in the schema, or did he just look at the Python file?" and Chatterjee replied, "He took a look at it. He's done object-oriented programming in the past. So he understands the method class package relationships" (id. at 156-57).
Chatterjee's responses show that Kemerer did not perfunctorily approve the use of Understand. If Kemerer had wanted to just rubber-stamp Chatterjee's suggestion to use the default schema for Understand, he could have simply done so when Chatterjee first suggested it. Instead, Kemerer actively sought to understand the specifics of how Understand worked, asked questions of Chatterjee to that end, reviewed the default schema offered by Chatterjee, and made the ultimate decision to use Understand, apparently after some consideration. This evidence contradicts Google's claim that Kemerer exercised no supervision or input over the selection of Understand. Furthermore, there is no indication that Chatterjee at any point improperly influenced Kemerer's decision, or indeed even weighed in on it, aside from providing some answers to Kemerer's questions about Understand. Thus, there is no support for Google's assertion that "Chatterjee effectively chose" to use Understand without any supervision or input from Kemerer.
4. NUMBER OF API PACKAGES IN THE TEST SCRIPTS.
Google next contends that Kemerer's stability analysis is unreliable because there is no foundation for "the choice to use so many different [API] package names in the scripts." Google asked both Kemerer and Chatterjee in their respective depositions why the stability analysis references 248 API package names for Java, even though there are only 166 API packages in Java SE 5. Kemerer said he would have to ask his "technical team" (Kemerer Dep. at 178-79), and Chatterjee said Kemerer told him to use those packages (Chatterjee Dep. at 212). Google claims this is "circular finger-pointing" that renders the stability analysis unreliable because "the choice of package names" is unexplained.
This apparent inconsistency arises only if, as Google characterizes it, the use of 248 API package names for Java was a specific choice that someone made. The facts, however, do not support Google's characterization. When asked in deposition, "So who decided to take these particular 248 APIs?" Chatterjee replied, "It comes from the JDKs that you download from the Oracle website. And so Professor Kemerer told me to do that, and so it comes from there. So he decided" (Chatterjee Dep. at 212). Google then asked, "Who made the decision to use all 248 in this script?" and Chatterjee reiterated, "[Kemerer] made the decision. I mean, he said capture all the packages that are coming from the JDK" (ibid.). Google misleadingly abbreviates Chatterjee's answers as "Kemerer told [Chatterjee] to use those packages," but omits the rest of Chatterjee's explanation. Reading Chatterjee's answers fully and in context, it is clear that the inclusion of 248 API packages was not a specific choice made by either Chatterjee or Kemerer, but simply the result of Kemerer's earlier instruction to Chatterjee to "capture all the packages that are coming from the JDK."
Moreover, contrary to Google's implication, the stability analysis's inclusion of 248 API packages is not necessarily at odds with the fact that Java SE 5 contains only 166 API packages. As Kemerer's report explained and Oracle reiterates, the stability analysis considered API packages from all versions of the Java platform, not just from Java SE 5 (Kemerer Rpt. ¶¶ 96-97). Thus, as Oracle puts it, "the total number of packages considered would exceed the package count in any particular version of either platform." In short, Google has demonstrated neither "circular finger-pointing" nor unreliability in the methodology of Kemerer's stability analysis.
5. SUBSTANTIVE FLAWS IN KEMERER'S ANALYSIS.
Google alleges three substantial flaws in the methodology of Kemerer's analysis. For the reasons that follow, this order concludes that all three arguments go to the weight of the analysis, not to its admissibility.
A. Different Data-Gathering Techniques Used for Android and Java.
As noted above, Google takes issue with Kemerer's use of plain text and XML, rather than Java, API documentation files in his stability analysis for Android. Specifically, Google "questions . . . whether some of the differences allegedly shown by the analysis could have arisen from the different methods used to gather the underlying data." As a preliminary matter, Oracle correctly points out that all the factual elements underlying this criticism were disclosed in Kemerer's report; it is unclear why this issue was not covered in Google's expert's rebuttal to Kemerer's report, and Google waited until after the Chatterjee deposition to raise it. In any case, Google's objection goes to the weight of Kemerer's analysis, not to its admissibility. Oracle claims it makes less sense to "use an Oracle tool designed for the Java platform to collect information on Android source code" than to use "the more direct source of Android method declarations offered by Google," but this, too, is argument by counsel that goes to the weight of expert evidence, not its admissibility. Such arguments must be directed to the jury.
B. Consideration of Non-Java Code in Android.
Android contains both Java and non-Java code, and Chatterjee said in deposition that he thought the centrality analysis could have included both types (Chatterjee Dep. at 238). Kemerer, however, chose to limit the analysis to only Java code in Android (ibid.). Google challenges this decision on the basis that "taking into account the entire Android platform could end up presenting a more complete picture of what is supposedly `central' to the platform." Again, however, this methodological choice and Kemerer's reasoning for it were disclosed in Kemerer's report (Kemerer Rpt. ¶ 150); it is unclear why neither Google nor its experts raised this issue until after Chatterjee's deposition. Additionally, this is another argument that goes to the weight of the analysis, not its admissibility. Even if Google's theory about what a broader analysis of the Android platform might have shown was supported by expert evidence, that evidence would have to be presented to the jury.
C. Design of Stability Analysis.
Finally, Google criticizes Kemerer's stability analysis as "nothing more than a simple counting of changes that have not been shown to make any difference to the platform or to app developers." In other words, the analysis "was not designed to capture changes that would actually be visible to and impact developers," such as backwards compatibility. Google cites as support Chatterjee's admission in deposition that "he did not have expertise in deciding what sorts of changes would matter to app developers" (Chatterjee Dep. at 60-61). Thus, Google contends, the stability analysis is "fundamentally unsound" and should be excluded.
Google's argument, however, actually supports Oracle's position that Kemerer is the real proffered expert, not a mere mouthpiece, and Chatterjee and the Keystone team are just his research assistants. Google specifically argues, and argued in prior briefing, that Kemerer improperly relied on the research team's opinions or analysis instead of their data collection. See Dura Auto. Sys. of Ind., Inc. v. CTS Corp., 285 F.3d 609, 614 (7th Cir. 2002). But this argument is now undermined by Google's own assertion that Chatterjee's execution of Kemerer's methodology amounted to simple data crunching, not substantive analysis. Such was the proper role for Chatterjee; he did not need "expertise in deciding what sorts of changes would matter to app developers" because he was not involved in this case as an expert. Kemerer is the proffered expert who, based on the data crunching performed by Chatterjee and the Keystone team, purports to opine as to how the results show that stability matters to developers. Chatterjee's exercise of professional judgment as to the substantive analysis would be not only unnecessary, but also problematic under Dura Auto. See 285 F.3d at 613. After deposing Chatterjee, Google still has not identified any evidence that Kemerer was a mere mouthpiece for Chatterjee or any other Keystone expert. At best, Google's objection amounts to an attack on the probative value of Kemerer's stability analysis. As such, however, it would go to the weight of the analysis, not to its admissibility.
* * *
The motion to exclude Kemerer's testimony as having been spoon-fed by Chatterjee is DENIED. Google may use the points developed in the Chatterjee deposition to cross-examine Kemerer and possibly will be allowed to call Chatterjee in its rebuttal case to impeach Kemerer.
IT IS SO ORDERED.
