Source code ch.11: Protective orders

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 11: Source code protective orders (POs)

11.0 Introduction

  • Attorneys should understand what they are agreeing to in PO negotiations over source code: how will PO impact the source-code examination, and the ability of experts and source-code examiners to do their job without undue cost or time?
  • POs in this area often reflect confusion over (or deliberate mystification of) source code
  • Blanket, over-designation of source code as a whole as a confidential trade secret (TS) and/or confidential business information (CBI), while under-appreciating the specific TSes which really do reside in some source code
  • See article, Source code protective orders (POs), from the source-code examiner’s perspective

11.1 Source code production is more restrictive than most non-source production

  • 11.1.1 Introduction to POs: PO often to restrict discoverability, and to limit further dissemination beyond the current litigation; here focus is on form/manner/place/time conditions under which the source-code exam will occur; see chapter 15 on the source-code exam environment
  • 11.1.1b FRCP 26(c), especially FRCP 26(c)(1)(G): “requiring that a trade secret or other confidential research, development, or commercial information not be revealed or be revealed only in a specified way”; and (B) “specifying terms, including time and place or the allocation of expenses, for the disclosure or discovery”
  • 11.1.1c Party seeking a PO has the burden of demonstrating “good cause” (FRCP 26(c)(1)) by showing a particularized need for the protection sought; good cause is shown when “when it is specifically established that disclosure will cause a clearly defined and serious injury. Broad allegations of harm, unsubstantiated by specific examples … will not suffice” (Glenmede Trust v. Thompson; see also tobacco litigation Cipollone v. Liggett; prozac litigation In re Eli Lilly)
  • 11.1.1d The need to  specifically establish harm often seems to be ignored once source code is involved, even though source code as a general category does not establish trade-secret or confidential nature, any  more than would the general category of “company internal email”
  • 11.1.2 Source code POs becoming more restrictive; see Lydia Pallas Loren & Andy Johnson-Laird, “Computer Software-Related Litigation: Discovery and the Overly-Protective Order,” 6 Fed. Courts L.R. (2012); article covers e.g. security for printed source code in transit; proscribed items in room containing standalone source-code computer; requirement that examiner only take handwritten notes; restriction on “studying” source code outside source-code room; proctors; etc.
  • 11.1.3 Source code examination is “review”: not quite production, not quite inspection: see chapter 13, and FRCP 34(a)(2)
  • 11.1.3b Source-code discovery ought to be less expensive than non-source (e.g. email) discovery, since there is little reason to review source code for e.g. attorney/client privilege;  up-front review for specific trade secrets (as opposed to blanket designation of source code in its entirety as “crown jewels”) almost never done
  • 11.1.3c Blanket designation vs. e.g. specific review and redaction; efficiency when large quantity of material, but may merely defer issues of confidentiality (see e.g. criticism of blanket POs in John Does v. Yogi, DDC 1986)
  • 11.1.3d Blanket designation of all source code as highly confidential, even when easily shown that large portion of source code is open source, and even when this is knowable from publicly-accessible info (e.g. software vendor’s use of GPL; reverse engineering product to show use of open-source code)
  • 11.1.4 Location: usually producing party’s law firm, or escrow facility; less often at development or on hosted secure web site
  • 11.1.5 Time/manner: usually only M-F 9-5, on computer disconnected from internet, in room in which laptop/mobile devices prohibited (see list of typical restrictions below at 11.6); also continued impact of PO after case
  • 11.1.6 Requesting party attorneys frequently agree to PO restrictions without fully understanding the impact on the source-code exam, or the potential impact on expert’s ability to follow a reasonable examination methodology
  • 11.1.7 Possible use of restrictive POs as a perceived tit-for-tat response to other side’s “fishing expeditions” or discovery abuse, especially by non-practicing entities (“trolls” for whom otherwise-typical mutuality of discovery/PO doesn’t work)

11.2 “Blanket” or “umbrella” protective order for entirety of source code

  • 11.2.0 Typically, claims of privilege or special sensitivity must be on document-by-document basis (see e.g. tobacco litigation)
  • 11.2.1 But here, typically heightened protection for all source code, without specific demarcation of trade secret (TS) portions
  • 11.2.1b Is “the source code” (likely comprising thousands of separate files) viewed as a single highly-confidential document?
  • 11.2.1c Because of its seeming inscrutability to attorneys, source code is often assumed to be TS, using a vague border around a wide area, rather than a high, truly closely-guarded, wall around a narrower area
  • 11.2.2 Is source code, as such, truly sufficiently distinct from other documents in discovery (such as a company’s internal emails, Word docs, or PowerPoints), to merit heightened protection?; see chapter 1, on the extent to which source code is & is not a special or sui generis, type of document
  • 11.2.2b Is source code as a whole a trade secret, by virtue of reasonable security precautions (RSP) around the source code as a whole?; low fence around large area; vs. high fences around smaller carefully-demarcated areas
  • 11.2.2c Is  entire set of  source-code files, as a whole, a TS, merely by virtue of assumed presence within it of some individual files containing trade secrets (coupled perhaps with attorney assumed incapability of quickly determining which  those individual files are)?
  • 11.2.2d Should burden be on producing software company to already know beforehand which particular source-code files contain trade secrets, and otherwise assume that lack of such particularized knowledge indicates lack of TS status?
  • 11.2.3 Source code POs & availability of open source closely matching protected source code; do vendor modifications, to particular parts of particular open-source files, render the vendor’s copy of open source, in its entirety, a TS?; see e.g. Bedrock v. Google
  • 11.2.3.1 Potential TS status of compilation even if all or most constituent parts are non-TS
  • 11.2.3.2 Vendor’s modifications, additions to, and deletions from, open source
  • 11.2.4 Clear trade-secret status of some source code (e.g. code re: passwords, security, encryption; code which runs behind firewall)
  • 11.2.5 Difficulties of demarcating TS beforehand; easier to use blanket/umbrella, have requesting party extract/select few items it wants from large repository; then review few selected items before printing/production
  • 11.2.6 Comments in source code are especially likely to be TS, and most source files will contain at least one comment, so this argues for either producing source code with comments redacted (yuch) under normal NDA, or if want comments (as all litigants will) then must agree to highly-restrictive PO?; but comments are also least likely to constitute “crown jewels,” or to have (per TS definition) economic value from not being generally known in the industry
  • 11.2.7 Source-code review procedure similar to “quick peek”: make all available for inspection, requesting party’s consultant/expert/examiner selects, selected files then reviewed and produced

11.3 Legitimate reasons for special PO treatment of source code

  • 11.3.1 “Attorneys eyes only” (AEO): no access by opposing party itself, especially its in-house engineers
  • 11.3.2 Patent prosecution bar
  • 11.3.3 Susceptibility of source code to redistribution?
  • 11.3.4 Desire to maintain trade-secret status (especially vis-a-vis employees) via “reasonable security precautions” (vis-a-vis handling by outsiders in litigation)
  • 11.3.5 Genuine trade-secret status of some source code (see 11.2.4 above), with difficulty of demarcating beforehand (especially re: comments; see 11.2.6 above)
  • 11.3.6 PO is seen in part as admission ticket to source-code discovery (sliding scale: more PO, more source code); a reason for narrowly-tailed source-code discovery requests?
  • 11.3.7 When push-back by requesting party is not worthwhile, vs. when attorney should “go to bat” for source-code expert/examiner
  • 11.3.8 Up-front demarcation of specific protectable source-code files seen as overly costly/burdensome, compared with requesting party’s tightly-restricted review of source code as a whole, followed by selection of files of interest

11.4 Illegitimate reasons for special PO treatment of source code

  • 11.4.1 Desire to create artificial “crown jewels” aura around source code (which may later backfire in damages calculations, e.g. when party asserted valuable “secret sauce” nature of old, stale, no-longer-used code accused of infringement)
  • 11.4.2 Desire to make source-code examination inconvenient, expensive, and time-consuming, for opposing party (especially if that party is seen as otherwise immune to normal discovery mutuality, as discussed e.g. by Bone, Economics of Civil Procedure)
  • 11.4.3 Genuine but mistaken belief in magical quality of source code, and in insufficiency of normal NDA
  • 11.4.4 Requesting party attorney’s failure to appreciate impact of PO restrictions upon source-code exam
  • 11.4.5 Courts will generally accept PO-created inconvenience to requesting party, so long as the party is “not prejudiced” [case]
  • 11.4.6 PO/spoliation contradiction: party first asserts special need to protect code, especially older code, which it then cannot find; see chapter 10 on spoliation, “missing” code; because the wheels of justice grind slowly, litigation in this area will often be about older code; see tobacco litigation: speculative allegations of injury from disclosure of years-old information not sufficient to warrant PO
  • 11.4.7 Producing party’s law firm enforces bizarre restrictions to keep client happy (and sometimes relaxes restrictions when client is not present)
  • 11.4.8 Producing party wishes access to examiner’s work product

11.5 Local Model POs for source code

11.6 Typical PO restrictions on source code access, and implications for source-code examination of such restrictions

  • Source code only accessible on standalone protected computer, without internet connection
  • Protected source-code computer only accessible M-F 9-6 at producing law firm site or escrow facility
  • No ability to copy to/from protected source-code computer: no accessible USB ports, CD drives, etc.
  • No ability for examiner to copy examination tools to source-code computer
  • No ability for examiner to copy notes, script output, etc. from source-code computer
  • “No copying of source code” interpreted to mean no direct quotations from source code in expert reports (see chapter 27), infringement contentions, etc. [work-around is to cite proper nouns (function names, variable names, etc.) from source code, without “logic” (anything with an equal sign)]
  • Any document which does quote from source code will thereby come under the PO [may be subject to motion to seal, etc.]
  • “No analysis of source code” outside the restricted source-code room (no printing for later analysis)
  • Source-code computer only has standard operating-system-provided tools (e.g., findstr, grep), or those explicitly agreed to in PO (e.g., SciTools Understand, Microsoft Visual Studio, dtSearch, WinMerge, etc.)
  • Source code is possibly maintained in proprietary or non-standard version-control system
  • Examiner may not bring laptop, mobile devices, etc. into source-code room; usually internet searches must be done in separate room
  • Only hand-written notes allowed; producing party may have opportunity to inspect or copy examiner’s hand-written notes
  • Limitations on quantity of source code (number of files and/or lines) which may be printed
  • Printouts are generally reviewed by producing party, before production to the requesting party
  • Proctor may sit in room with examiner, or just outside door of source-code room
  • Sometimes lengthy sign-in/sign-out required even for brief toilet breaks: is this because of a genuine (if false) mystique around the source-code’s value, or is it deliberately intended to break examiner concentration?
  • Because there is no internet connection, examiner is prevented from running comparisons of produced source code with e.g. public open source
  • May producing party actively monitor the source-code computer screen, keystrokes, file accesses, searches?
  • Again: no laptop, no internet connection, no Google in the room, though it should be just down the hall; no cutting and pasting “veryLongFunctionNamesLikeThisOrLonger” into Google; instead, write them down on paper, walk down the hall, type them in

11.7 Further discussion of PO source-code restrictions

  • 11.7.1 PO restrictions may prevent expert/examiner from using standard non-litigation methodology (Daubert criteria)?; e.g., amazingly in some software copyright cases, the two parties’ respective source-code trees are located on different computers, inhibiting the normal manner of performing a source-vs.-source comparison
  • 11.7.2 PO restrictions may provide producing party with opportunity to monitor requesting party work product, e.g. when reviewing requested printouts; this may encourage delay in printing until the last possible moment
  • 11.7.3 PO restrictions as way to raise litigation costs, and thereby discourage “frivolous” litigation: PO restrictions as a disguised heightened case prerequisite (similar to pleading requirements; see chapter 6)?
  • 11.7.4 For attorney who reads some PO restrictions listed at 11.6 above as bizarre (no source code analysis outside protected source-code room?!): this may be what you just agreed to in your most recent case
  • 11.7.5 For source-code expert/examiner: knowing the PO restrictions is crucial, before you begin the source-code exam (see chapter 15)
  • 11.7.6 Continuing impact of PO, even after conclusion of case
  • 11.7.7 Estimates of additional expense/time caused by typical source-code PO
  • 11.7.8 Perverse incentives for over-requesting and over-printing created by typical source-code PO (see chapter 24)
  • 11.7.9 Contradiction of  “crown jewels” stance towards source code, with later damages stance of “oh, that old thing, even if it did infringe, we don’t use it, it’s not important, we get no revenue from it”

Source code protective order (PO) cases

  • Bergstrom v. Glacier Bay (only allow TIFF screen shot of source code, with later OCR of TIFF?), N.D. Ill. 2010
  • Dynetix v. Synopsys (need 24/7 access to source code?; NO, expert inconvenience ok; version control), ND Ca. 2012
  • Kelora Sys. v. Target (ability to compile, laptop in room?), ND Ca. 2011
  • BIAX v. Brother Int’l (expert not work in field for 4 years?; NO), D. Col. 2011
  • BIAX v. Nvidia (source code accessible only during normal business hours)
  • Function Media v. Google (heightened protection; clear the courtroom?)
  • Ameranth v. Pizza Hut (no patent-prosecutor access to source code?), S.D. Ca. 2013
  • HTI IP v. Webtech (log all access to source code), S.D. Ca. 2010
  • Mediostream v. Microsoft (tools needed to examine source code)
  • Apple v. Samsung (examiner notes, “diff” output)
  • GE v. Sonosite (P source code only available at P’s office for D review), W.D. Wisc. 2008
  • eBay v. Kelora (cost of isolating & presenting eBay source code on secured & locked down computer in anticipation of inspection; so PO restrictions costly for producing party as well), N.D. Ca. 2013
  • MVS v. Bingo Bean (requestor agrees to harsh sanctions if violation; Chinese Wall at firm), C.D. Ca. 2011
  • Dynamic Microprocessor v. EKD (no demarcation: “the source code constitutes a trade secret”), E.D.N.Y. 1996
  • EPL Holdings v. Apple (printing limits; note-taking), N.D. Ca. 2013
  • Unwired Planet v. Apple (printing limits; quoting source code in reports, filings), D. Nev. 2013

 

Print Friendly, PDF & Email