Pages

Monday, July 6, 2015

Entangled Trade Secrets and Presumptive Misappropriation

Posted by
Michael Risch

Over at Prawfsblawg, Orly Lobel discusses the case of former Goldman Sachs programmer Sergey Aleynikov,who has had an up and down (more like down and up) experience dealing with criminal trade secret prosecutions. I think the case is worthy of discussion for a variety of reasons, but I will focus on how different viewpoints will color the facts of this case. Prof. Lobel describes this as a story of "secrecy hysteria," while I view this as a run of the mill "don't copy the source code" case.

I'll discuss my point of view briefly below, but I will admit my priors: I spent my career advising companies and employees in trade secrecy: how to protect them, how to exit without getting sued, and how to win lawsuits as plaintiffs and defendants. I probably represented plaintiffs and defendants with the same frequency, and -- of course -- my client was always right.

More facts after the jump. I should make clear that I've got no position on the criminal prosecutions; my views here are more about trade secrecy than whether the criminal laws should be used to protect them (or should have applied to this particular case). Prof. Lobel and I may well agree on the latter point.
Here are the basic facts of this case, as told in the Prawfs post:

Sergey Aleynikov was a star programmer at Goldman Sachs. A month after
leaving Goldman Sachs to work for a new company, Teza Technologies, he
was arrested by the FBI, and later prosecuted and convicted under the
Economic Espionage Act for stealing proprietary technology. Goldman had
accused Aleynikov of stealing computer code and sending himself 32
megabytes of source code.... Aleynikov was sentenced to eight years in federal
prison. Alyenikov worked as a programmer for Goldman’s high frequency
trading platform where he, like other programmers, used open source
software on a daily basis. Unlike the frequently practiced requirement
of putting open source code back to the common pool after use and
modification, Goldman had a one-way attitude about open-source. When
Goldman programmers took open source, it became Goldman’s proprietary
information. Goldman would not return the adjusted code to public
domain, likely in violation of the open-source licensing agreements.
. . .
When Alyenikov quit his position at Goldman he agreed to remain in his
position for six more weeks to help train others at Goldman and teach
them what he knew. During that time, he mailed himself source code he
had been working on that contained large amounts of the open-source code
he had been using for two years intertwined with code he developed at
Goldman. His claim at trial was that he sent this code to himself
because he hoped to later disentangle the two and have the open source
available if he needed a reminder of what he had used.

This is an interesting story. I'll start by saying that there's nothing wrong with using open source code for a new employer. Unless it were super complicated and difficult, I don't think it would be wrongful for Aleynikov to have gone to his new employer, redownloaded the same open source, and started over. But the open source discussion is a red herring. Open source does not mean that all modifications become freely usable. Open source does not require someone to release their internally software just because someone wants them to. Companies may hire people to develop changes and keep those changes secret under an NDA. Thus, only released products must be shared.

So, if you take the open source red herring out of the picture, what you are left with is a run of the mill source code misappropriation. I'm not saying that he should have been convicted or even prosecuted. I'm also not saying that he has no defense on the merits; once you parse the open source out of what he took, perhaps there was little left from Goldman Sachs.

But is the overarching point so hard to see here from the prosecution side? When you leave a company, don't copy its source code and take it with you. It's as simple as that. The machinations, explanations, hemming and hawing you have to do to justify it will at best get you little. Yes, sometimes it will be overzealous prosecution, but this type of thing is so hard to detect that overzealousness is the only way to deter it.

Surely, if you copy source code wholesale there will sometimes be innocent explanations. But it is also true that most of the time there are not. Remember that two juries convicted Aleynikov; they did not believe his
story. Only helpful judges thinking that particular criminal statutes
might not apply saved him. A jury of his peers believed he
misappropriated trade secrets.*

This does not bother me normatively. The company paid the programmer to write the source code (even additions to open source). Thus, I see no problem with a default rule that errs by saying the company presumptively owns its source code as against employees who would copy it wholesale. I might even go further. Prof. Lobel quotes an expert who described this source code as sort of a "memory notebook":

In Serge’s case, think of being at a company for three years and you
carry a spiral notebook and write everything down. Everything about your
meetings, your ideas, products, sales, client meetings—it’s all written
down in that notebook. You leave for your new job and take the notebook
with you (as most people do).

The expert goes on to say that the notebook isn't really relevant to the new work, it's just for remembering what was done. I have two responses. My first is of the skeptic: Really? Then why do you need it? What good is it if it's of no relevance? Why would you ever need to look at it again? I don't doubt that engineers feel this way about their notebooks, but I think it's a rationalization: either you need the notebook because you need it, or you are a pack rat. But arguing that you need it but don't need it is circular.

The second response is more legal: Much to the chagrin of employees everywhere (and to Prof. Lobel, I suspect), that notebook -- certainly the ideas within it -- belong to the employer in almost every case. Everything the expert describes is information that is likely assigned to the employer in an agreement, or otherwise proprietary to the employer. Even if the material is not trade secret, as between the company and the employee, who should own a list of otherwise secret sales figures? I don't say that just to be pro-plaintiff; I represented plenty of employees who wanted to keep this information. But, if it truly lacks relevance, the new employer shouldn't want those ideas anyway, because it only opens up a lawsuit. I've represented plenty of defendants that wished their employees had left more behind. Even in the Aleynikov case, the new employer disavowed any need for the information.

That's all I have to say on this topic. Perhaps Prof. Lobel and I are focused on different things. For her, the criminal prosecution (especially with poor legal footing) is hysteria. For me, when you copy all of someones source code, the best you will ever do is an acquittal/no liability verdict after a long, expensive, and ugly battle, and --whatever merits there are to other human capital spillover-- I think that's OK.

*Even in what little I know about this case, I find it hard to believe him as well. This one line rings hollow for me: "His claim at trial was that he sent this code to himself because he hoped to later disentangle the two and have the open source available if he needed a reminder of what he had used."

Maybe I am naive and he used some version of open source that I don't know about, but most projects I'm aware of have repositories with version control. There was no need to "disentangle" anything. Perhaps there's a lot more to the context than this point, but my BS meter says "no way" on this one. Furthermore, to the extent that so much was used that it's impossible to put together again without looking at the original source code, then that's the type of proprietary interest that Goldman paid for by employing him and others over a course of years; it's hard to call it "experience" that the employee owns if he must use the source code to recreate it.