“Think different”
— Apple 1997 ad campaign for the Mac
The story seems to unfold the same way every time, whether the actor is a high-level departing employee or a customer or business partner. When sharing confidential information in a long-term relationship results in the release of a similar product by the recipient, the reaction is a claim of theft, laced with accusations of treachery and betrayal. And the response is equally strong: “no, I did this on my own”; in legal terms, “I engaged in ‘independent development.’”
Strictly speaking, this means that the development of the new product was accomplished “independently” of the information shared in the confidential relationship. As a practical matter, this can be difficult to prove. Once you have been exposed to the secret process or design, or other related information, how do you demonstrate that your work was entirely your own?
This is a particular conundrum for companies that are looking to expand their business through acquisitions, or who respond to inquiries from an innovator interested in some sort of relationship to co-develop a new technology. A recent article in the Wall Street Journal reported on cases where Apple met with startups to look at technology related to the iPhone or Apple Watch, and the legal battles resulting from Apple’s decision to pursue those projects on its own.
One way that a large organization can try to protect itself from these claims is to insert a “residuals clause” into the agreement with the smaller company. Alongside the usual promises of confidentiality and limited use of shared information it inserts a significant exception for information “retained in the unaided” (i.e., human) memory of the individuals who were exposed to it. If that strikes you as a significant carve-out, you’re right. In effect, by entering into an agreement with a residuals clause, you’re granting a license to the other side to use whatever they remember from the transaction.
As a result, the residuals clause is frequently refused, and the process goes forward with a more or less standard NDA in which each side agrees to maintain information in confidence and to use it only to assess the proposed deal. The receiving company may reduce its risk to some extent by declaring in the agreement that it is engaged in its own related research. But even with that sort of disclaimer, there will be exposure to information that makes it a challenge later to demonstrate truly independent development.
An exposure like this doesn’t only happen in the case of potential acquisitions or licenses. Confidential information can be shared in connection with purchase of a commercial product, in which the terms of sale include protection for the seller’s designs. The same might apply to enterprise software, in which the customer is not given access to underlying code, but is exposed to information about how the tool works, usually accompanied by a promise not to reverse engineer it. And of course sensitive information sometimes arrives in the head of an engineer hired from a competitor.
However it occurs, the “information infection” operates more or less automatically to constrain the recipient’s freedom in some way. That constraint can be measured by the risk that there will be some sort of claim, and by the robustness of the evidence that the recipient did not in fact use the information it received in confidence.
The key word here is “use.” To assert a claim of trade secret misappropriation, you don’t have to show copying. The law imposes liability if the later development was influenced, or just accelerated in some way, by access to confidential information. This includes using knowledge of the blind alleys already explored by the originator who invested in research to determine what doesn’t work, or what works less well. These so-called “negative secrets” can be very valuable as a “head start” toward success. Recall that Thomas Edison, in relating his effort to invent a long-lasting filament for the light bulb, said “I haven’t failed; I’ve found 10,000 ways that won’t work.”
In a dispute over breach of confidentiality, the plaintiff always has the “burden of proof,” in the sense that it has to convince the judge or jury that its secrets were misappropriated. But as a practical matter, if the defendant had trusted access and later sold a similar product, all eyes will be on the defendant, who better have a good story to tell.
That story, as we noted at the beginning, is one of “independent development.” But how does the accused convince a (potentially skeptical) audience that there was no breach of trust, that the development was “clean?”
Here, the gold standard is the “clean room” form of reverse engineering, in which you start with publicly available information about a product, or a set of basic specifications for a desired product, and you hand that over to an outside team of developers who have never been exposed to the secret information. Of course, you have to be certain that all the participants are clean, and that the information you give them to start with was not derived from the trade secret. But if you can pull that off, then you should win.
The problem is that a true “clean room” is often impractical for a number of reasons. There may not be enough time, or enough budget. The people with the right skills and experience may not be available when needed. Or the extent of exposure may have been so limited that the risk is viewed as acceptable.
Indeed, assessing the risk is key to most attempts at independent development. The company that is exposed to sensitive data has to recognize that the issue is not clean-cut, but depends on thoughtful risk management, beginning at the point when the relationship is established and the information received. Anticipating the practical burden of proving independent development, the recipient will focus on ways to preserve its options in the event of a claim.
This effort begins with the originating transaction. If the company is entering into a confidential relationship, the contract should be drafted in a way that makes it clear to the other side that if things don’t work out the recipient will be forging ahead on its own. Provisions for specific marking of all confidential information (and prompt written confirmation of verbal disclosures) will help reduce the risk of misunderstanding about what the protected information consists of.
For recruiting exposure, the hiring company should make clear its policy on respecting others’ IP, and should consider establishing protocols to guide the behavior of new recruits and their new colleagues. In exceptional cases, the company may want to provide access to independent counsel to provide the individual with specific, confidential guidance.
All this front-loaded action may not help much without follow-up to ensure that exposure is carefully managed and that good records are kept of how the company has complied with its obligations.
This brings us back to the question of how to structure a development path when there has been some exposure to someone else’s trade secrets. The answer begins with recognizing that it doesn’t necessarily require a hermetically sealed “clean room.” It is possible to create your own product or service “independently” using one or more of the people who had access to sensitive data. For obvious reasons you should limit their participation to what is necessary under the circumstances. But the law only punishes a misuse that is “substantial,” and depending on the context, you may be able to convince a court that any influence from exposure to confidential information was negligible.
The key to success lies in understanding the risk of future litigation and preserving the evidence of your work. This becomes critical as context for a judge or jury to see that your development effort was robust and honest, and that you didn’t cut corners by avoiding the research or experimentation that was already done by others. To show that what you did was “independent” of what you learned from someone else, you should frame your plans accordingly. Begin by thinking different.