In May, the Defend Trade Secrets Act (DTSA) was signed into U.S. law. At the signing ceremony, President Obama remarked: “Unfortunately, all too often, some of our competitors, instead of competing with us fairly, are trying to steal these trade secrets from American companies. And that means a loss of American jobs, a loss of American markets, a loss of American leadership.”
Not to be outdone, eight days later, the Council of the European Union adopted its own directive on trade secret protection that, while not identical to the DTSA, agrees on most every material point. Taken together, these two pieces of legislation established a legal trade secret protection framework spanning two continents.
These bills expand trade secret protection and substantially increase penalties for criminal misconduct, and what could go wrong with that?
(Related: Different paths to IoT connectivity)
After all, according to the Commission on the Theft of American Intellectual Property, the theft of trade secrets costs the economy more than US$300 billion a year. Thanks in large part to technology, trade secrets have never been easier move, copy, and steal. Unfortunately, there is nothing else more mobile in today’s world than application software.
So all appears good for the software developer, right? Appearances are in fact deceiving here for us as well, because the way the new law is written, applications have been stripped of every protection granted under the DTSA. In fact, it explicitly excludes reverse-engineering as an improper means. The DTSA states that Improper Means does not include “reverse-engineering, independent derivation, or any other lawful means of acquisition.” Even worse for protecting your IP, the exclusion of reverse-engineered software is intentional.
High value and high stakes for high tech
First, a little background before we get to suggestions about the steps developers must now take under the new law. Trade secrets are a separate class of IP distinct (but not mutually exclusive) from copyrights and patents, and they are playing an increasingly important complimentary role in protecting application development investments.
| Trade Secret | Copyright | Patent | |
| Distinguishing traits and characteristics | Information that is secret, has commercial value and that value is derived from its secret status.
Further, the trade secret owner must take reasonable measures to preserve its secret status. |
An original, creative expression of an idea through any medium. | Functional expression of a new and useful idea, e.g. a process, machine, or improvement thereof |
| Examples | Algorithms, processes, or data held in documents, code, or files. | Source code, written words, musical recordings, video content. | Any product that incorporates the patented invention or process. |
| Approval process | None | None | Lengthy, expensive, and unpredictable |
Comparison of Intellectual Property categories.
Trade secret strategies for application owners
Trade secret protection fills important IP protection gaps for application owners when:
Embedded functionality, while offering competitive advantage, is not patentable, and/or
The algorithms and workflows (not the source code itself) deliver the competitive advantage, thus voiding most copyright protection that only extends to the media—not the ideas embedded therein.
Another role for Trade Secret protection is as an interim strategy for patentable applications during the uneasy (and indeterminate) time period before a patent is awarded.
Security’s other role: The prosecution of successful attackers
Application security controls typically cluster around two dimensions of application protection: thwarting (or materially impeding) determined/skilled attackers, and deterring opportunistic or casual attackers. Yet, there is a third dimension of application protection that is rarely prioritized and often ignored: enabling the prosecution and punishment of successful attackers. Developers prefer to leave the legal stuff to the lawyers.
The DTSA and its European counterpart directly challenge this worldview by explicitly protecting development practices in the law itself—specifically, declaring reverse engineering as a lawful practice.
Reverse-engineering: A legal and protected activity
Trade Secret theft is defined as acquiring a trade secret through “improper means.” Improper Means are defined in two ways: actions that are improper, and those that are protected. The DTSA defines it as:
“(a) Theft, bribery, misrepresentation, breach or inducement of a breach of a duty to maintain secrecy, or espionage through electronic or other means; and
(b) Does not include reverse-engineering, independent derivation, or any other lawful means of acquisition.”
According to Daniel J. McMullen, adjunct professor at Case Western Reserve University School of Law and a Partner at Calfee, Halter & Griswold, where he chairs their Intellectual Property Practice: “By statutorily excluding reverse-engineering from the definition of misappropriation, the DTSA creates a clear legal delineation that invites would-be trade secret thieves to look for and characterize their actions as forms of reverse-engineering.”
In non-legal parlance the DTSA has essentially declared open season on reverse-engineering your code. Is every algorithm and process embedded in your software officially free for the taking? Thankfully, no, it’s not that dire.
Reasonable measures
How do you ensure employees don’t share textual and image-based trade secrets (and exempt these from protection under trade secret laws as well)? You take “affirmative steps” that demonstrate concrete efforts to preserve confidentiality that include clear markings and communication – and you secure relevant documents with physical and electronic locks.
It is important to keep in mind that the objective of these controls is not to guarantee secrecy. The objective is to demonstrate an unambiguous commitment to “reasonable” secrecy that cannot be missed by either individuals or the courts.
There is no reason to believe that software-based trade secrets should be treated any differently; affirmative actions to demonstrate reasonable measures to secure software-based trade secrets need to cover the same contractual, electronic and physical dimensions.
Contracts and confidentiality agreements should prohibit reverse-engineering. Executables, like their electronic document counterparts, should be secured against reverse-engineering, unauthorized tampering, and monitoring (using both physical and electronic locks). And source-code repositories should restrict source-code access.
Protecting trade secrets and the ALM and DevOps status quo
In April 2016, respondents from more than 150 development organizations evaluated their company’s risk-management practices. An unprecedented 100% of respondents from organizations with 1,000+ employees reported that IT and development’s inability to connect their activities to their company’s risk-management priorities weakened their ability to manage that risk. Development and IT cannot afford to leave legal stuff to the lawyers anymore.
The journey to an effective IP protection strategy begins with a balanced assessment of how copyright, patent and trade secret protections apply to your organization’s works (and that must include the code you develop and the applications you distribute) internally, across your supply chain, and beyond to external markets and users.
In order to minimize the cost and complexity of managing IP risk, look for opportunities to apply controls that can play multiple roles: thwarting and impeding the determined, deterring the opportunistic, and (last but no longer least) prosecuting the successful.
Finally, wherever possible, coordinate and document your policies; consistency of a practice is as important as how effective it is when applied.
Whether or not the details of this round of trade secret legislation are immediately relevant to your development roadmap, the trend is clear: Development organizations can no longer afford to ignore the increasingly explicit connections between development practices and the law.
