Source code ch.25: Authentication, admissibility, weight

Source Code & Software Patents: A Guide to Software & Internet Patent Litigation for Attorneys & Experts
by Andrew Schulman (
Detailed outline for forthcoming book

Chapter 25: Authentication, admissibility, and “weight” of source code

25.1 Authentication of source code

  • Often auto-authentication, from party’s production in response to discovery request for source code to a given product/version
  • Authentication of source code produced in discovery is often straightforward, except for date/timestamps (see 25.2 below)
  • Authentication of source code produced in response to sufficiently-specific interrogatory under FRCP 33(d) (produced source code is “tied” or “linked” to the request)
  • Rare problems of incorrect (“unauthentic”?) source code located in source-code production
  • Authentication of source code not produced in discovery (e.g. open source, used for comparison with vendor’s modified version as produced)
  • Authentication of expert/examiner’s test files on protected source-code computer; these can be made the subject of deposition question or request for admission
  • Authentication of output from expert/consultant’s reverse engineering, pre-filing investigation
  • Authentication of web site screenshots
  • Stipulations to authenticity under FRE 901
  • “Is the source code a fair representation of what it purports to represent?”: i.e., is this the correct source code for the product/service at issue?

25.2 Authentication of source-code date/timestamps

  • Source code dates are especially significant to prior art, on-sale bar, public-use bar
  • A single source-code file will likely have several different dates (date within file itself; within version-control system; within OS file system; date reflected in related non-source files; etc.)
  • Cases in which files were backdated (see also chapter 10 on spoliation)
  • Ease of modifying file dates, or selecting wrong one; but no mere speculation on file dates as basis for exclusion or as basis for satellite “discovery on discovery”
  • Authentication of dated files from “Wayback Machine” (Internet Archive)

25.3 Admissibility and “weight” of source code

  • Occasional attempts to have source-code comments or dates excluded as “hearsay”
  • Business records exception (source code should present fewer problems than e.g. emails)
  • “Machine hearsay doctrine” and software-generated (vs. merely software-stored) evidence [application to wizard-generated code?]
  • Cases on admissibility of files from Wayback Machine (Internet Archive)
  • “Corroboration”? [mostly re: priority, swearing behind, pre-AIA]
  • Expert’s reasonable reliance on inadmissible evidence, upon which expert would rely in non-litigation context (especially re: open source,, Google Cache, etc.); see chapter 8 on experts
  • But no use of expert as “conduit” for inadmissible (or “backdoor” to late) evidence
  • Disputes about admissibility usually end up as a matter of arguing “weight” to the fact finder (e.g., how reliable are these file dates?; how much care went into writing these source-code comments?; can you really count on the name of this file or function, in contrast to what an expert says the file or function really does?)
  • Admissibility rules often provide a useful way to structure presentation of evidence, to emphasize its reliability and “weight”

25.4 Intersection of admissibility with discovery

  • Holding back source code as “not relevant” or “not admissible”: the standard is discovery “calculated to lead to” relevant/admissible evidence
  • Source code likely contains names of software developers, references to internal documents (specs, requirements, etc.)
  • Source code relevance unlikely to be speculative in software patent case; contrast speculative value of source code in e.g. DUI Breathalyzer cases (!)
  • Source code in “discovery about discovery”: source code for producing party’s internal records-keeping systems, to determine cost/burden/availability of other evidence; court will often decline satellite discovery; but spoliation, file backdating, etc. can lead to inspection of producing party’s records-keeping systems

Source-code cases re: authentication & admissibility

  • Netscape v. Valueclick (source code date as hearsay?)
  • Kenexa Brassring v. Taleo (ease of modifying file timestamp)
  • Comp. Assoc. v. Simple (no mere speculation re: ability to modify source code; FRE 901(b)(9) re: timestamp)
  • Cordance v. Amazon (source code author’s testimony: issue of weight, not admissibility)
  • Motorola Mobility v. Apple (parties stipulate to authenticity under FRE 901)
  • In re Epstein (source-code dating, corroboration, in patent prosecution case)
  • Netscape v. Valueclick (hearsay, corroboration, date; business record?)
  • ACTONet v. Allou (contract case; HTML code admissible evidence similar to photograph, because produces visible website appearance?)
  • Globespanvirata v. TI (need to link source-code files with specific products, when expert based opinion on source code from opponent’s workstation?)


Print Friendly, PDF & Email