Outdated Protective Orders are Impeding Software Code Analysis in Copyright and Trade Secret Cases

As an expert witness on intellectual property litigations, I have noticed over the past few years parties with poor arguments in software copyright and software trade secret cases, both plaintiffs and defendants, have been taking advantage of technologically outdated protective orders to gain an unfair advantage.

The Problem

The U.S. District Court for the Northern District of California, where probably the majority of software IP cases take place, has a Model Protective Order for Litigation Involving Patents, Highly Sensitive Confidential Information and/or Trade Secrets that has become a de facto standard for software IP cases around the country. It is antiquated and needs to be updated. In particular, it specifies restrictions on an exam computer on which software is to be examined. The particular problem paragraph is 9(c):

“Any source code produced in discovery shall be made available for inspection, in a format allowing it to be reasonably reviewed and searched, during normal business hours or at other mutually agreeable times, at an office of the Producing Party’s counsel or another mutually agreed upon location. The source code shall be made available for inspection on a secured computer in a secured room without Internet access or network access to other computers, and the Receiving Party shall not copy, remove, or otherwise transfer any portion of the source code onto any recordable media or recordable device. The Producing Party may visually monitor the activities of the Receiving Party’s representatives during any source code review, but only to ensure that there is no unauthorized recording, copying, or transmission of the source code.” (emphasis added).

In my expert witness work, I use tools to compare software code to identify indicators of copying. Such tools are necessary to give an objective analysis based on quantitative measures rather than the subjective opinions of dueling experts. One of these tools uses a Google API to scour the Internet looking for code that came from an open source or other third party or is just some term commonly used by programmers. In other words, this Internet search is necessary to avoid false accusations of copying. Unfortunately, some parties to software IP cases have found a convenient way to push back on the use of these kinds of tools by arguing that it would violate the protective order’s prohibition about network connection. Parties to a litigation that have a weak case have discovered in recent years that getting this kind of tool eliminated from the evaluation process allows them to find the most persuasive expert witness whose opinion can be influenced by various factors other than solid facts.

A Misunderstood Standard

I’ll address that situation momentarily, but I came across an even stranger argument recently, by a lawyer who wanted to hire my consulting firm but was concerned that sending her client’s code over the Internet could damage their trade secrets by making the code “publicly available.” What?

First, trade secrets do not have to be 100% inaccessible. That would not be possible under any practical circumstances. Most states have adopted the Universal Trade Secret Act, and the trade secret laws of those states that have not adopted it have only minor differences with it. The UTSA states that a trade secret is “the subject of efforts that are reasonable under the circumstances to maintain its secrecy.” (emphasis added). The national Defends Trade Secret Act has very similar language. It states that something can only be a trade secret if “the owner thereof has taken reasonable measures to keep such information secret.” (emphasis added)

One particularly useful tool divides the software code into basic code elements (identifiers, statements, comments, strings, and instructions) and then stores any elements that match between two code bases into a database of matching elements. The tool then sends out all the matching elements through a secure, encrypted API to Google in alphabetical order to determine whether any of the code can be found online. If someone were fortunate enough to know the exact time that someone was running this tool and the exact IP address of that computer, and were able, on the fly, to crack the private key encryption that the NSA claims it cannot crack without a large server farm and a lot of time, they would obtain a bunch of code fragments completely out of order. There is hardly a better definition of a reasonable effort to maintain secrecy.

Let us assume arguendo that an Internet-connected computer that sends code over an encrypted connection to a location on the Internet destroys a trade secret. Google has an API data retention policy and a restrictive privacy policy that do not give third-party accessibility to the search terms. Assume further that some remote server in the cloud stored the code indefinitely. Assume that instead of reordered fragments of code, the entire code in the correct order was shipped to this remote server. Assume that every working day for a period of months or years, full copies of code were sent back and forth to these servers. If an Internet-connected code comparison tool destroys trade secrets or somehow allows access to the code by malicious actors, then there is no such thing as a software trade secret because nearly every company on earth that develops software keeps their code in an online repository like GitHub, owned by Microsoft, and by this understanding gives up all its trade secrets in this manner.

In another matter, my client’s lawyers were unable to convince a judge to allow the use of a particular tool because the opposing party’s lawyers argued that the tool had the ability to access the Internet. That’s interesting because those same lawyers had argued for an exam computer that was not connected to the Internet, so did they think that the tool could access the Internet magically? Of course not. In fact, they gave a long list of allowable tools, all of which have the ability to access the Internet. Only one requested tool was excluded—the code comparison tool. Why? Because that was the one tool that might destroy their case.

The Consequences

What is happening is that the standard protective order that requires no network connection is hindering the ability to do a reliable analysis and comparison of software code. The concern is based on false premises. The standard protective order needs to be modified. Every person on the planet is connected to the Internet by their phones, their TVs, their personal computers, and almost every electronic device they own. Every business person is connected in even more ways because they are also connected via their business computers, business phones, even their office thermostats. Every programmer is even more connected and ships their source code to unknown locations in the cloud on a daily basis. The real way to reasonably protect the code is to install malware detection, antivirus software, and firewalls on the computers and to keep them up to date. Any full restriction from Internet access is simply a way to encourage false outcomes in litigation.

Someone will argue that with an Internet connection, the expert could purposely and maliciously transfer code to some remote location and, perhaps sell it to a competitor. Sure. And a real expert working with a non-Internet connected computer could do the same. After all, we’re experts. We know how to hack into systems. It is as much a risk, or actually less of a risk, than your employees stealing code because 1) you have many more employees, 2) they have many more opportunities to steal code, and 3) expert witnesses are vetted by both parties and typically under observation while working on the exam computer. If not, they should be. I personally have been observed by a lawyer from the opposing party and sometimes videoed while working on an exam computer. Some companies offer specially configured computers where the camera is turned on the entire time of the exam, in order to observe me. Just as there are severe consequences for a programmer who steals code, there are severe consequences, including jail time, for an expert who steals code.

Unfortunately, most judges don’t understand this issue. In the interest of avoiding the appearance of impropriety, they insist that exam computers be fully disconnected, and in doing so, they are making software IP litigation more arbitrary and likely unfair.

As an engineer, not a lawyer, I don’t know the process for fixing this problem. Who can help me change the thinking on outdated protective orders so that software IP cases using modern tools for examining, analyzing, and comparing code are once again quantitative and objective?