Source Code Protective Orders, from the perspective of a source-code examiner

Attorneys working in software-related litigation (such as patent, copyright, and trade secret cases) often agree to protective order (PO) restrictions on source code access, without thinking through the implications for how the source code will be examined by experts and consultants. Certain common PO restrictions may dramatically increase source-code examination time and expense, or in some instances even possibly affect its thoroughness. (For background on computer software source code, see article here.)

As a simple example, consider a software copyright case, in which source code from the defendant and plaintiff must be compared against each other to look for literal as well as substantial similarity. It has actually happened that the two sides will blithely agree to a PO in which each side's source code must be kept on a separate standalone computer; the two source-code computers will likely be at law offices in two separate cities, and the PO will permit no copying between the two computers. Comparing the two bodies of source code under these circumstances is, needless to say, challenging. That the PO was agreed to in the first place indicates that the PO was viewed as an abstraction, without thinking through how it would impact a crucial part of the case's fact finding.

The producing party's law firm, which is hosting its client's source code for inspection by the other side, may well understand the PO's impact on the source-code exam, and may be insisting on certain PO restrictions as much for the adverse effect on source-code exam time/expense, as to actually protect the trade-secret or confidential nature of the source code itself. Restrictive POs may be insisted upon as a perceived tit-for-tat response to other side’s “fishing expeditions” or discovery abuse, especially by so-called “trolls” for whom mutuality of discovery burdens doesn’t hold.

This article urges attorneys, especially those receiving source code productions, to think through how a PO will impact the source-code exam, and if possible to get your expert or non-testifying consultant involved in reviewing a proposed PO, rather than presenting the expert with a fait accompli (which one wag has defined as "French for 'the train has left the station' ").

While the author happens to also be a lawyer, he is mainly a source-code examiner, and this article is based on about 20 years experience in source-code examinations for patent, copyright, and trade-secret litigation. The following material is excerpted from a forthcoming book on source code and software patent litigation, particularly the chapters on POs (detailed outline here) and on the source-code exam "environment" (i.e., where the source code is kept, and how it can be examined; outline here). The source-code exam environment is heavily affected by the PO, and the main point of this article is to discuss this impact. The material here is applicable to patent, copyright and trade-secret cases.

Some typical PO restrictions on source-code access are listed below; this list includes both reasonable and unreasonable restrictions:

• “Attorneys eyes only” (AEO), including outside experts: no access to source code by opposing party itself, especially its in-house engineers; and no sharing even of quotations from source code (thus, a party's own expert reports and claim charts, when based on the other side's source code, may need to be redacted, or not shared at all with the party itself).
• Patent prosecution bar: no source-code access for attorneys helping the other side acquire patents (in what areas?; including reexam?; see Unwired Planet v. Apple; Geotag).
• Source-code provider receives CVs of other side's proposed source-code examiners, and may object if examiner could pose a competitive risk (see Symantec v. Acronis); may examiner also be "tainted" by access to other source code in previous cases?; note the ability to probe the background of non-testifying consulting experts.
• Source code only accessible on "standalone" protected computer, without internet connection; while this is intended to prevent opposing experts and consultants from leaking a company's "crown jewels" to the internet, is there a good reason to believe that a properly-crafted non-disclosure agreement (NDA) wouldn't almost always have the same effect?
• Protected source-code computer only accessible M-F 9-6 at producing law firm site or escrow facility.
• “No analysis of source code” outside the restricted source-code room: no printing for later analysis; all analysis, i.e. careful reading of the code, must be done in situ; does this include the testifying expert reading source-code print-outs generated by non-testifying consultants?
• No ability to copy anything (not just source code) to or from the protected source-code computer: no accessible USB ports, CD drives, etc.
• Thus. no ability for examiner to copy software-examination tools to source-code computer; tools must be agreed upon beforehand, and attorneys unfortunately often agree to the set of tools, without consulting experts as to the tools best suited for the particular job.
• Further, no ability for examiner to copy notes, examiner's own script output, etc. from source-code computer; see below on hand-written notetaking.
• “No copying of source code” interpreted to mean no direct quotations from source code in expert reports, claim charts, etc.; one work-around is to cite proper nouns (function names, variable names, etc.) from source code, without transcribing lines of code, or any portions of lines that contain “logic” (basically, anything with an equal sign).
• Any document which does quote from, or perhaps even refer to, source code will thereby come under the same PO restrictions as the source code itself.
• Source-code computer only has standard operating-system-provided tools (e.g., findstr, grep, VB, awk), or those explicitly agreed to in the PO (e.g., SciTools Understand, PowerGrep, Apple XCode, Microsoft Visual Studio, dtSearch, WinMerge, Sigasi (for VHDL or Verilog code), Cygwin (Linux-like environment for Windows), text editors for printing, such as Notepad++, TextWrangler or EditPadPro, etc.; for a PO naming such tools, see here); some parties decide (though not addressed in the PO) to turn off command-line access, which seriously impacts source-code examination by more skilled examiners.
• Examiner may not bring laptop, mobile devices, etc. into source-code room; usually internet searches must be done in separate "break-out" room (which is typically provided).
• No laptop in the same room as source code means: only hand-written notes allowed; in some cases, producing party may have an opportunity to inspect or copy examiner’s hand-written notes. See EPL Holdings v. Apple on note-taking.
• Limitations on quantity of source code files, pages, and/or lines which may be printed; the PO may also restrict print-outs to source-code files themselves, not allowing the (often important) printing of directory listings, script output, etc. (see e.g. Apple v. Samsung, 2013 WL 1563253, preventing Apple from taking printouts of output from the "diff" program: "... if the diff reports are Apple experts’ notes, those notes necessarily include source code, and removal of notes with source code references is prohibited under the Protective Order").
• Printouts are generally reviewed by the producing party, before production to the requesting party; this in some ways is the very purpose of a source-code exam (see outline for forthcoming source code book on examination purposes); the producing party may thus glean early inferences into the other side's case, and this in turn yields a perverse incentive to delay printing source-code files until the last-possible minute.
• Proctor often may sit in room with examiner, or just outside door of source-code room; may the proctor actively monitor the source-code computer screen, keystrokes, file accesses, searches?
• Sometimes lengthy sign-in/sign-out required even for brief coffee or 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.
• Continuing impact of PO, past the life of the case, including not only continued protection for source code and for litigation-created materials based on that source code, but also possible attempted restrictions on future work by experts and consultants who have been exposed to the source code (e.g. BIAX v. Brother Int'l. on party's "arrogant" attempt to restrict opposing expert from similar work for four years, based on exposure to source code; such a restriction would seriously limit the "pool" of experts needed by the patent litigation system).

In other words: no laptop in room, hand-written notes only, no direct quotations from source, no internet connection, no cutting and pasting “veryLongFunctionNamesLikeThis” into Google; instead, write them down on paper, walk down the hall, type them in; limited printing; all analysis must be done in situ.

While some of these restrictions are likely reasonable under some circumstances, as a whole it is reminiscent of the Thatcher Library vault room scene in Citizen Kane.

Typical source-code PO restrictions are also discussed in a law review article by Lydia Pallas Loren & Andy Johnson-Laird, “Computer Software-Related Litigation: Discovery and the Overly-Protective Order,” 6 Fed. Courts L.R. (2012); the article covers e.g. security for printed source code in transit; proscribed items in source-code room; requirement that examiner only take handwritten notes; restriction on “studying” source code outside source-code room; proctors; etc.

Overly restrictive source-code POs often reflect a confusion (or deliberate mystification) of source code, as though "The Source Code" were, in and of itself, a trade secret (TS) and/or confidential business information (CBI), merely by virtue of being source code. However, much of the information in source code (though certainly not all) is often already public (mostly clearly in the case of "open source"), or readily ascertainable e.g. by reverse engineering a product on the market (apart from license restrictions on reverse engineering, which may not apply in litigation; see author's article on reverse engineering to investigate software patent infringement).

A blanket PO is typically placed over the entire body of produced source code, even when that produced source largely contains open source (albeit perhaps with significant vendor modifications), and even if the owner has not indicated the presence of any specific trade secrets or sensitive materials (e.g. code relating to passwords, security, or encryption) contained within the source code. The most confidential portion of the source code is often "comments" by the programmers, which are generally removed before distribution of software to consumers, and hence not susceptible to reverse engineering; but ironically, such comments are unlikely to hold up to a trade-secret analysis of whether the owner derives economic benefit from others not knowing them.

Under the Federal Rules of Civil Procedure (FRCP) 26(c)(1), a party seeking a PO has the burden of demonstrating "good cause" 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).

The need to specifically show "good cause" appears to be ignored once source code is involved, either because source code itself, as a whole, is assumed to be a trade secret (even though no one would ever regard the near-parallel category of “company internal email” as inherently TS), or because it is (with some good reasons) seen as too time-consuming or expensive to figure out beforehand where the trade secrets are within the code as a whole.

Depressingly but not surprisingly, companies often have little idea what their valuable trade secrets actually are, until the issue comes up when employees walk out the door to start their own company ("you don't know what you got until it's gone"), and so many litigants would be unprepared, if pressed, to show particularized good cause (i.e., something more specific than "our source code is our crown jewels") as typically required in PO case law.

Because of the special blanket protective status seemingly given to source code as a general category, and because the issue comes up again and again in modern civil litigation, there are model POs covering source code. See e.g. N.D. Ca. (section 9 on source code); E.D. Tex. (paragraph 10 on source code); D. Del. (“Default Standard for Access to Source Code”); ITC (“Source Code Provision to be inserted in Model Commission APO”). Some of these model POs enshrine unnecessarily restrictive source-code examination practices.

Source-code POs are becoming more restrictive. Some underlying reasons are legitimate; at least as many appear to be illegitimate. First, some legitimate reasons for PO restrictions on source code (apart from those restrictions which could be put in place through a standard non-disclosure agreement [NDA]):

• Keeping the other side's engineers and patent prosecutors from seeing your source code; see AEO and patent prosecution bar above.
• Desire to maintain TS status (especially vis-a-vis one's own employees) of source code, by noisily exercising "reasonable security precautions" (RSP) in litigation with outsiders.
• Likely genuine TS or CBI status of some portions of source code, coupled with perceived difficulty of demarcating these portions beforehand (though shouldn't the source-code owner know some specifics about its "crown jewels"?).
• Perhaps a belief that the source code as a whole, even if known to be comprised largely of publicly-known information such as open source, constitutes a TS compilation (a secret aggregation of otherwise public information; see recent case); while reasonable sounding, the author has never heard this put forward as an explanation for why a compilation of largely open source requires a highly restrictive PO, as opposed to a standard NDA.

Some less legitimate reasons for restrictive POs:

• Desire to create artificial “crown jewels” aura around source code (which may later backfire in damages calculations, e.g. when source-code owner requests restrictive PO on the basis of valuable "crown jewels" or “secret sauce” nature of what it may later (re: damages) characterize as its old, stale, no-longer-used code accused of infringement; or backfire when the party turns out to have lost some of the source code; because the wheels of justice grind slowly, litigation in this area will often be about partially-missing older code, which however the owner will have held up as the crown jewels).
• 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).
• Producing party’s law firm enforces bizarre restrictions to keep client happy: "we're really sticking it to them" (and law firm then sometimes relaxes restrictions when client is not present).
• Producing party wishes access to source-code examiner’s work product.
• Desire to make the other side's discovery less thorough; a testifying expert may be hesitant to complain of how a PO-restricted source code exam affected their work, or that of their assistants or consulting non-testifying experts. You can just hear the deposition question/answer: "Your source code access was greatly restricted, Dr. Expert, so your report is based on only a partial or limited view of the code, unlike the conclusions of my expert, who had full access to our own source code?" "But wait, you're the one who put those very restrictions in place, despite knowing that over half the source code was open source!" "Be that as it may, nonetheless your view was restricted and my expert's view was not?" (There may be perfectly good answers, such as "Actually, no, because like I said much of the code was open source, and I examined that, and also your product was shipping with debugging symbols enabled, so the product itself is practically an open book, even without the source code. We needed your produced source code largely to confirm what we already knew from the product itself, and so your restrictions made that confirmation more expensive and time-consuming, but didn't undermine the basis for my conclusions.")

Those negotiating source-code protective orders should not be overly impressed by utterance of the seemingly magical incantation "source code." It is far better to think of source code as akin to a company's confidential internal emails, i.e., as just another type of document (albeit one which definitely has a more direct role in producing the company's products; see author's article contrasting source code to other forms of electronic discovery).

Attorneys negotiating source-code protective orders should try to have their technical expert or consultant assess the impact a proposed or model PO will have on the source code exam, and on the ways in which the needs of a given case may depart from the assumptions of a model PO. Attorneys should push back against certain restrictions, such as forbidding a laptop in the same room as the source code; such a ban results in a requirement that all notes be handwritten. Also try to scale back discovery requests (see forthcoming article on source code discovery and abuse), so that the other side is less tempted to retaliate with, or has less excuse for, overly restrictive source-code protective orders.

For more information, see http://www.SoftwareLitigationConsulting.com.