Preserving the Crown Jewels: Practical Strategies for Protecting Source Code in Patent Litigation Discovery

In today's Internet age, the most valuable asset belonging to many of the world's most successful organizations is “source code” ' the programming underlying all software operating systems, databases, and applications. As a result, keeping source code from leaking to the public is of paramount concern, especially in light of the fact that source code published over the Internet can proliferate at an exponential pace with little more than a series of mouse clicks. If confidential code is released into the public domain, even inadvertently, it risks losing any trade secret protection it once enjoyed. See, e.g., Linkco, Inc. v. Fujitsu Ltd., 230 F. Supp. 2d 492, 498-99 (S.D.N.Y. 2002). In short, once the “genie” is out of the bottle, it cannot be put back in.

To preserve the secrecy of their source code, many companies impose strict security policies on their own employees. As an example, code may be restricted to a small number of secure facilities, computers, and company employees who have a specific need for access. Even employees that do gain access may be prevented from viewing or downloading a full copy of the source code, but may be restricted instead only to necessary portions of the code. Furthermore, password protection, copy protection, and source control software are ubiquitous ' making unauthorized access difficult while keeping close track of who last “checked in” and “checked out” source code from a secure server.

In litigation, especially patent litigation, these same software companies often face discovery requests from opponents demanding the production of the entirety of the source code for a given product or products ' typically as the code is contained in easily searched, and thus easily copied, electronic formats. In practice, most of these discovery requests result in the production of all of the requested source code to an opponent's attorneys and expert consultants. Considering that opponents in litigation are often hostile competitors in the marketplace, such production is tantamount to a leap of faith in which the producing party gambles heavily on the receiving party's compliance with any obligations it may have to preserve the confidentiality of the source code and to use it only for the purposes of the litigation.

This risky surrender of source code need not be accepted as a necessary evil of modern patent litigation. Instead, when faced with a discovery demand for its source code, a party should first consider alternative approaches that can minimize the risk of exposure. The first such approach is perhaps the most obvious: Resist. In patent litigation, courts can, and occasionally do, issue protective orders or quash subpoenas pursuant to Federal Rule of Civil Procedure 26 (the rule governing discovery in Federal Court) to preclude the production of source code entirely. These motions are also costly (requiring at least one or more briefs and often an oral hearing), and difficult to win. The standard a requesting party must meet to justify its demand for source code is a low one. If it can show that the source code is “reasonably calculated to lead to the discovery of admissible evidence” under the facts of the case, a requesting party is likely to secure production. See Fed. R. Civ. P. 26(b)(1). On the other hand, if one can prove that the burdens and risks associated with producing source code outweigh its materiality to the case, a complete bar on production can be achieved. See Fed. R. Civ. P. 26(c)(1).

If a court in a particular case is likely to resist barring the production of the source code as a whole, litigants can appeal to the considerable discretion given to the court by the Federal Rules to shape the scope and methodology of production. See Fed. R. Civ. P. 26(c)(2)-(3) (permitting courts to restrict discovery so that it “may be had only on specified terms and conditions, including a designation of the time or place,” and “only by a method of discovery other than that selected by the party seeking discovery”). Under these rules, a producing party has great flexibility to request and often to obtain from courts creative forms of relief that limit the risks to its source code.

One relatively moderate approach is to limit production only to an exemplar version of the requested source code as opposed to every version or revision that may have been requested. From a review of this exemplar source code, the requesting party can identify the portions that are relevant to its case, and production of the other versions and revisions of the source code for the remaining accused products can be limited only to those key portions. This approach is often an effective way to give both parties what they really want, or at least what they really need. The receiving party gets unfettered access to a complete version of the source code, but a controlled and limited scope of exposure is maintained for the responding party. In many instances, however, this approach will be inadequate – there are still risks that even the single produced version of the source code may get leaked. If a software program is well known, of great interest to the public, or of great value and sensitivity, this risk may be intolerable.

A second approach is to insist that source code be produced only on paper. For obvious reasons, it is far less likely that the entirety of the source code for a given program will be leaked to the public when it is stored only on reams of paper as opposed to on a single CD-ROM or on a computer with Internet access. This approach thus greatly reduces the risk that the entirety of the source code will find its way onto the Internet or be leaked to the public on easily replicated electronic media. (The code would have to be scanned or retyped onto a computer before the risk of a leaked electronic version could even arise.) This approach, however, is frequently impracticable. The source code for even medium-sized software programs may exceed millions of lines, and thus tens or hundreds of thousands of pages. The costs related to organizing, copying, collating, labeling and producing this volume of printed source code (each page of which must be kept in sequence to maintain the integrity of the program) can exceed hundreds of thousands of dollars. Moreover, in most instances requesting parties will insist upon an electronic copy of the code so that key word searches can be used on a computer to identify quickly the pertinent portions of the larger program. Courts are likely to sympathize with the need for such electronic searching and thus to compel the production of electronic versions of the code, especially in the typical case where electronic versions are already kept by the responding party in the normal course of business.

If electronic versions must be made available to the requesting party, often the best approach is for the producing party to permit an inspection of the code at its own facilities or those of its attorneys, and to resist handing a copy of the code over to its opponent. In general, permitting an inspection instead of physically producing documents satisfies a producing party's discovery obligations. See Fed. R. Civ. P. 34. Inspection of source code, instead of physical production, has also been accepted by a number of courts as an appropriate balance between the interests of requesting and producing parties. See, e.g., GM Network Ltd. v. E-Gold Ltd., No. 01 Civ. 962, 2002 WL 1013320 (S.D.N.Y. May 17, 2002) (approving inspection of defendant's source code at its attorney's office while being supervised by a paralegal in the inspection room); Beam Syst., Inc. v. Checkpoint Systs., Inc., No. CV 95-4068 RMT, 1997 WL 423113 (C.D. Cal. July 16, 1997) (restricting plaintiff to “inspection of defendants' software subject to strictly regulated procedures”). As these cases acknowledge, inspection in lieu of physical production greatly reduces the risk of exposure of source code. With an inspection, the producing party can maintain much stricter control on the handling of its code, the locations in which it is made accessible, and the people who gain access to it. This allows a producing party to maintain many of the same security procedures it may impose on its own employees and thus gives far greater assurance that code will not be made accessible to those who would publish it, whether intentionally or inadvertently.

In addition to the inspection, the producing party may be required to permit the requesting party to make and take away copies of the key code portions that are relevant to the disputed issues in the case. See, e.g., GM Network, 2002 WL 1013320 at *3. The combination of an inspection and a partial physical production of limited portions of source code in this way will often strike a reasonable balance between the producing party's need to protect its code and the receiving party's attorneys' and experts' desire to have code available at their own offices for ongoing and private analysis.

The facts of a given case ' including the public's interest in, and the sensitivity of, the relevant software program, cost, and the predilections of the judge likely to hear a discovery dispute ' will dictate the best approach for responding to a discovery demand for source code. In many instances, a hybrid of the approaches discussed above will be the best bet. For example, an on-site inspection can be bundled with the provision of only an exemplar version of the source code. After a first inspection of that exemplar version, further inspections can be restricted only to the relevant portions of the code as opposed to its entirety. Similarly, the production of any “key” code portions identified at an inspection may be restricted to paper copies as opposed to electronic ones. In all cases, any one of the approaches discussed above, alone or in combination, can go a long way toward preserving the secrecy of source code in discovery.

In today's Internet age, the most valuable asset belonging to many of the world's most successful organizations is “source code” ' the programming underlying all software operating systems, databases, and applications. As a result, keeping source code from leaking to the public is of paramount concern, especially in light of the fact that source code published over the Internet can proliferate at an exponential pace with little more than a series of mouse clicks. If confidential code is released into the public domain, even inadvertently, it risks losing any trade secret protection it once enjoyed. See, e.g., Linkco, Inc. v. Fujitsu Ltd. , 230 F. Supp. 2d 492, 498-99 (S.D.N.Y. 2002). In short, once the “genie” is out of the bottle, it cannot be put back in.

To preserve the secrecy of their source code, many companies impose strict security policies on their own employees. As an example, code may be restricted to a small number of secure facilities, computers, and company employees who have a specific need for access. Even employees that do gain access may be prevented from viewing or downloading a full copy of the source code, but may be restricted instead only to necessary portions of the code. Furthermore, password protection, copy protection, and source control software are ubiquitous ' making unauthorized access difficult while keeping close track of who last “checked in” and “checked out” source code from a secure server.

In litigation, especially patent litigation, these same software companies often face discovery requests from opponents demanding the production of the entirety of the source code for a given product or products ' typically as the code is contained in easily searched, and thus easily copied, electronic formats. In practice, most of these discovery requests result in the production of all of the requested source code to an opponent's attorneys and expert consultants. Considering that opponents in litigation are often hostile competitors in the marketplace, such production is tantamount to a leap of faith in which the producing party gambles heavily on the receiving party's compliance with any obligations it may have to preserve the confidentiality of the source code and to use it only for the purposes of the litigation.

This risky surrender of source code need not be accepted as a necessary evil of modern patent litigation. Instead, when faced with a discovery demand for its source code, a party should first consider alternative approaches that can minimize the risk of exposure. The first such approach is perhaps the most obvious: Resist. In patent litigation, courts can, and occasionally do, issue protective orders or quash subpoenas pursuant to Federal Rule of Civil Procedure 26 (the rule governing discovery in Federal Court) to preclude the production of source code entirely. These motions are also costly (requiring at least one or more briefs and often an oral hearing), and difficult to win. The standard a requesting party must meet to justify its demand for source code is a low one. If it can show that the source code is “reasonably calculated to lead to the discovery of admissible evidence” under the facts of the case, a requesting party is likely to secure production. See Fed. R. Civ. P. 26(b)(1). On the other hand, if one can prove that the burdens and risks associated with producing source code outweigh its materiality to the case, a complete bar on production can be achieved. See Fed. R. Civ. P. 26(c)(1).

If a court in a particular case is likely to resist barring the production of the source code as a whole, litigants can appeal to the considerable discretion given to the court by the Federal Rules to shape the scope and methodology of production. See Fed. R. Civ. P. 26(c)(2)-(3) (permitting courts to restrict discovery so that it “may be had only on specified terms and conditions, including a designation of the time or place,” and “only by a method of discovery other than that selected by the party seeking discovery”). Under these rules, a producing party has great flexibility to request and often to obtain from courts creative forms of relief that limit the risks to its source code.

One relatively moderate approach is to limit production only to an exemplar version of the requested source code as opposed to every version or revision that may have been requested. From a review of this exemplar source code, the requesting party can identify the portions that are relevant to its case, and production of the other versions and revisions of the source code for the remaining accused products can be limited only to those key portions. This approach is often an effective way to give both parties what they really want, or at least what they really need. The receiving party gets unfettered access to a complete version of the source code, but a controlled and limited scope of exposure is maintained for the responding party. In many instances, however, this approach will be inadequate – there are still risks that even the single produced version of the source code may get leaked. If a software program is well known, of great interest to the public, or of great value and sensitivity, this risk may be intolerable.

A second approach is to insist that source code be produced only on paper. For obvious reasons, it is far less likely that the entirety of the source code for a given program will be leaked to the public when it is stored only on reams of paper as opposed to on a single CD-ROM or on a computer with Internet access. This approach thus greatly reduces the risk that the entirety of the source code will find its way onto the Internet or be leaked to the public on easily replicated electronic media. (The code would have to be scanned or retyped onto a computer before the risk of a leaked electronic version could even arise.) This approach, however, is frequently impracticable. The source code for even medium-sized software programs may exceed millions of lines, and thus tens or hundreds of thousands of pages. The costs related to organizing, copying, collating, labeling and producing this volume of printed source code (each page of which must be kept in sequence to maintain the integrity of the program) can exceed hundreds of thousands of dollars. Moreover, in most instances requesting parties will insist upon an electronic copy of the code so that key word searches can be used on a computer to identify quickly the pertinent portions of the larger program. Courts are likely to sympathize with the need for such electronic searching and thus to compel the production of electronic versions of the code, especially in the typical case where electronic versions are already kept by the responding party in the normal course of business.

If electronic versions must be made available to the requesting party, often the best approach is for the producing party to permit an inspection of the code at its own facilities or those of its attorneys, and to resist handing a copy of the code over to its opponent. In general, permitting an inspection instead of physically producing documents satisfies a producing party's discovery obligations. See Fed. R. Civ. P. 34. Inspection of source code, instead of physical production, has also been accepted by a number of courts as an appropriate balance between the interests of requesting and producing parties. See, e.g., GM Network Ltd. v. E-Gold Ltd., No. 01 Civ. 962, 2002 WL 1013320 (S.D.N.Y. May 17, 2002) (approving inspection of defendant's source code at its attorney's office while being supervised by a paralegal in the inspection room); Beam Syst., Inc. v. Checkpoint Systs., Inc., No. CV 95-4068 RMT, 1997 WL 423113 (C.D. Cal. July 16, 1997) (restricting plaintiff to “inspection of defendants' software subject to strictly regulated procedures”). As these cases acknowledge, inspection in lieu of physical production greatly reduces the risk of exposure of source code. With an inspection, the producing party can maintain much stricter control on the handling of its code, the locations in which it is made accessible, and the people who gain access to it. This allows a producing party to maintain many of the same security procedures it may impose on its own employees and thus gives far greater assurance that code will not be made accessible to those who would publish it, whether intentionally or inadvertently.

In addition to the inspection, the producing party may be required to permit the requesting party to make and take away copies of the key code portions that are relevant to the disputed issues in the case. See, e.g., GM Network, 2002 WL 1013320 at *3. The combination of an inspection and a partial physical production of limited portions of source code in this way will often strike a reasonable balance between the producing party's need to protect its code and the receiving party's attorneys' and experts' desire to have code available at their own offices for ongoing and private analysis.

The facts of a given case ' including the public's interest in, and the sensitivity of, the relevant software program, cost, and the predilections of the judge likely to hear a discovery dispute ' will dictate the best approach for responding to a discovery demand for source code. In many instances, a hybrid of the approaches discussed above will be the best bet. For example, an on-site inspection can be bundled with the provision of only an exemplar version of the source code. After a first inspection of that exemplar version, further inspections can be restricted only to the relevant portions of the code as opposed to its entirety. Similarly, the production of any “key” code portions identified at an inspection may be restricted to paper copies as opposed to electronic ones. In all cases, any one of the approaches discussed above, alone or in combination, can go a long way toward preserving the secrecy of source code in discovery.