Source code ch.24: Extracting, notetaking, and printing

Source Code & Software Patents: A Guide to Software & Internet Patent Litigation for Attorneys & Experts
by Andrew Schulman (http://www.SoftwareLitigationConsulting.com)
Detailed outline for forthcoming book

Chapter 24: Extracting relevant source code: note taking & printing

24.1 Note-taking restrictions under source-code protective order (PO)

  • No “copying” may be interpreted to severely restrict note taking: no lines of code
  • E.g., ND Cal model PO covers information copied, extracted, excerpts, summaries, compilations; this may be applied to examiner’s notes as well as to print-outs
  • “Tainting” when PO covers anything which extracted/copied/summarized from protected source code
  • Potential discoverability of expert’s source-code notes: FRCP 2010 amendments protect drafts of report but not other expert-generated materials, e.g. source-code inspection notes, which must be produced since own notes have been “considered” (one reason to use non-testifying examiner); see ABA, Litigators on Experts at 157; but likely mutual stipulations between parties
  • Sometimes producing party copies and reviews examiner’s notes, but this is becoming rare: purpose to ensure PO compliance, or for other side to monitor work product?
  • All this in context of source-code “aura” (e.g., the heavily-protected code might be only slight modification to open source, though producing party’s attorney or examination proctor unlikely to know this or to appreciate significance)
  • PO restrictions on “copying” source code also affect the expert report (see chapter 27)

24.2 Mechanics of note-taking during source-code examination

  • Often must hand-write, because PO prohibits bringing laptop or mobile device into room (see chapters 11 and 15)
  • Why “less is more” when it comes to note-taking
  • Remember that rough notes can be easily misinterpreted
  • Expert/examiner will have to rely on notes when source code is no longer accessible
  • Using pre-printed forms for note-taking
  • Preparing pre-printed form from patent claims (see chapters 7 and 26 on claim charts; forthcoming book on claim charts); abbreviations or numbers for elements/steps for easy cross-reference; especially important for the seemingly less-important (and more easily-overlooked) claim limitations
  • Preparing pre-printed forms from product reverse engineering (see chapter 6)
  • Preparing checklists (e.g. of source-code filenames, function names, and logging statements) from product reverse engineering
  • How to take notes without “copying” code logic (e.g. arrows to show caller/callee; only writing down file/function names, nothing with an equals sign, etc.)
  • Logging time (see “diligence” in chapter 14)
  • Expert/examiner will want to be able to say what actually DID in this case (what code actually examined), NOT what usually do, so keeping logs important even though some attorney fears of note-taking
  • Avoid premature lock-in to particular interpretation; multiple interpretations may be consistent with client’s case; avoid unnecessary commitment to what would otherwise (apart from writing down) be a “NOP”
  • Avoiding words are also legal terms of art (e.g. “obvious”)
  • Avoiding “patent profanity” (characterizing the invention, e.g. “key”, “important”, “crucial”) [on patent profanity, see Root, Rules of Patent Drafting]

24.3 Source-code printing restrictions under PO

  • Printing quantity limits under protective order
  • Producing party may challenge quantity printed (see e.g. ND Cal model PO)
  • Negotiating changes to printing limits, after source-code exam has begun and previously agreed-to limits appear unreasonable/infeasible
  • Necessary printing quantity often underestimated at start of case (P thinks its case is simple; D’s job is to complicate D’s case, leading to more source code to be printed)
  • Failure to consult experts/examiners before PO negotiations (see chapter 8), or to consider past experience (“in the previous case like this we worked on, the experts ended up printing out 3,000 pages”) [basically, failure to consider implications of the PO, when negotiating it]
  • “Why are you printing so much?”: elements/steps scattered across many files; need to print lower-level code to confirm what relevant code does; need to print higher-level code to show how relevant code is used within product as a whole; see chapter 23 on source-code quantity
  • Producing party resisting printing is often the same party whose points made in litigation can only be addressed with a wider range of source code files, i.e. with more printing
  • Printing examiner’s own output on source-code machine (e.g., ND Cal model PO covers “compilations,” which arguably includes examiner’s “own” output from scripts, command lines, directory listings, etc.)
  • Typical PO restriction can produce perverse incentives for over-printing: need to print everything one could possibly later need for reports or claims tables, because will not have source-code access when do need (11th hour preparation of expert report, claims tables; see chapters 7 and 26, claim charts book)
  • No printing for later analysis: most POs require that source-code analysis be done on the spot (see chapters 11 and 15 on impact of PO on source-code exam methodology)

24.4 Mechanics of source-code printing

  • Result of the source-code exam is to select relevant files from large source production; have printed and Bates stamped
  • Four possibilities: (1) source-code computer will have attached printer will pre-printed Bates-stamped paper; (2) attached printer with plain paper, which producing party will later Bates stamp; (3) examiner provides producing party with list of source-code files to be printed; (4) examiner “prints” source code to PDF, and producing party prints PDF files
  • Problems with pre-printed Bates stamped paper (tight controls over quantity)
  • If list of files to be printed, how to designate files within version-control system; need to give instructions on how to print (wrapping long lines; line numbers; landscape; header with full path; etc.)
  • Printing of output from examiner’s scripts, command lines, directory listings, “diff” files, etc.
  • Mechanics of printing from tools, e.g. Understand, TextWrangler, EditPadPro: wrapping for long lines; line numbers; landscape mode; printing entire path/filename without clipping long paths; printing date of file, not date of printing; etc.
  • Understand is generally less suitable for printing source code for litigation, because of e.g. truncation of long pathnames
  • Printing diagrams e.g. from Understand
  • Printing diagrams, screen shots, etc. which are part of the source-code tree
  • Create spreadsheet of printed files, including Bates numbers, once known

24.5 What to print

  • Often, every relevant version of “key” dozen files in case, even if only minor variations, unless can anticipate no dispute over smaller, more informative “diff” output generated by source-code examiner
  • Printing excerpts from files, vs. entire file; excerpts are often more convenient for both sides, and help maintain quantity limits, but easier to overlook printing something necessary; return trip to print can be costly, time-consuming, or even impossible (see chapter 14 on logistical difficulties of return trips to source code, under typical PO)
  • PO perverse incentive to print more than one would think is necessary, especially code corresponding to seemingly “trivial” or standard claim limitations
  • Printing not only directly relevant code, but the code that calls it, and the code it calls (see chapter 19 on tracing up/down from directly-relevant layer of code)
  • Printing files from source-code production, even when they appear to match standard or open-source files which are readily available outside the PO restrictions [explain why: vendor modifications, difficulty of comparing source-code production with open source; authentication]
  • Printing examiner’s own output, e.g. “dir” listings with filedates; findstr or grep output; “diff” or other file-comparison output
  • Full pathname/filename
  • Date of file (NOT date printed)
  • Line numbers

24.6 Post-discovery handling of print-outs and notes

  • Generally, examiner will not take print-outs with them; first vetted by producing party, then sent to requesting party’s law firm
  • Restrictions on number of copies made of print-outs, even between multiple offices of same law firm
  • Lock-boxes
  • Use of source-code print-outs at depositions: see chapter 28
  • Return or destruction of print-outs at conclusion of case [vs. use in subsequent cases?]
  • Return or destruction of examiner’s notes & work product based on source code, at conclusion of case

24.7 Additional source-code printing issues

  • BOX: Is producing party “monitoring” the requesting party’s “work product”?
  • Importance of print-outs in context of protective order [requesting party will later depend on notes and print-outs, because PO, together with time/expense, will restrict return visits to source code; need to “get it right the first need” as expressed in print-outs; benefits to requesting party of extracts vs. entire file, since print-outs will have to be “eyeballed,” in contrast to normal source-code practice of reading electronic version; creating brief abstracts from print-outs]

Source-code cases re: note-taking, printing

  • EPL Holdings v. Apple (whose burden to justify number of pages printed?)
  • Unwired Planet v. Apple (whose burden to demonstrate reasonableness/unreasonableness of source-code portions printed?; source code not printed for review/analysis outside source-code room)
  • Apple v. Samsung (note-taking; examiner’s diff output leave room? no)

 

Print Friendly, PDF & Email