Defend Trade Secrets Act codifies “open season” on app reverse engineering

Code obfuscation and the doctrine of “contributory negligence”

On May 11, 2016, President Obama signed the Defend Trade Secrets Act of 2016.

Enjoying unprecedented bipartisan support (Senate 87-0 and the House 410-2), this bill expands trade secret protection across the US and substantially increases penalties for criminal misconduct – and what could go wrong with that?

After all, according to the Commission on the Theft of American Intellectual Property, the theft of trade secrets costs the economy more than $300 billion a year. …and, thanks in large part to technology, trade secrets have never been easier move, to copy, and to steal. In fact, in their 5 year strategic plan, the FBI labeled trade secrets as "one of the country's most vulnerable economic assets” precisely because they are so transportable.

…and nothing in today’s world is more mobile than application software

If you were to assume that this bill has been custom-tailored to protect the trade secrets embedded in application software - you would be in good company

In her most recent blog post praising the Defend Trade Secrets Act, Michelle K. Lee, Under Secretary of Commerce for Intellectual Property and the current USPTO Director writes, "No matter the industry, whether telecommunications or biotechnology, traditional or advanced manufacturing or software, trade secrets are an essential driver of innovation and need to be afforded proper protections.” … “Trade secret owners now also have the same access to federal courts long enjoyed by the holders of other types of IP.”

...but do we really? Do software developers really now "enjoy the same access to federal courts?" Sort of – maybe – OK – maybe not.

I’ll be writing a lot about this topic in the coming weeks and months, but, for now, let’s just drop to the bottom line. Without special care, Application owners have been stripped of every protection granted under the Defend Trade Secrets Act (DTSA).

Let me explain. The DTSA applies exclusively to VALUABLE information that is both SECRET and has been STOLEN (the legal term is “acquired through Improper Means”).

Developer ALERT: The DTSA 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.”

Is this an oversight? Did the legal staff of the Senate Judiciary Committee (who authored this bill) accidentally use this overloaded development term?

The answer is an unequivocal no – the exclusion of reverse engineered software is intentional and by design.

I recently found myself in a briefing on Capitol Hill with senior legal counsel inside the Senate Judiciary Committee (the agenda was encryption that day – not trade secrets) – but I asked this question directly – “Did the committee intentionally include language that would exempt any intellectual property that could be accessed via reverse engineering of applications?” He did not hesitate – in fact, to be honest, he was emphatic. “Yes” he said, “if I can see your IP with a reverse engineering tool – it’s mine.”

OUCH – is this the end of days? Is every algorithm and process embedded in your software officially free for the taking?

Thankfully – no – it’s not nearly that dire.

First – whether or not your IP is covered under this law – obfuscating .NET, Android, Java, or iOS apps make reverse engineering much harder. Code obfuscation will prevent – or at least reduce the number of times that your IP is lifted through reverse engineering.

The real question is whether application obfuscation can be used to extend the protections of the DTSA to include application software in a court of law.

“Reasonable Efforts” and “The Doctrine of Contributory Negligence”

How do you ensure employees don’t publicize your textual and image-based trade secrets (and exempt these from protection as well)?

You make sure employees know that they are secret through clear markings, communication, and education – and you secure relevant documents with physical and electronic locks. These are called “affirmative steps” that demonstrate concrete efforts to preserve confidentiality.

Failure to take these kinds of reasonable efforts lead to The Doctrine of Contributory Negligence.

This “doctrine” captures conduct that falls below the standard to which one should conform for one’s own protection. When you fall below this standard, courts will often treat your information as public – and, to the extent you rise above that standard – courts are typically more willing to accept both the secret nature and the value of the IP in question.

Unfortunately, applications are not documents - and so standard “electronic and physical locks” do not apply.

However, code obfuscation does apply here. Obfuscation is a well-understood, widely practiced, and recognized practice to prevent reverse engineering. Code obfuscation does not guarantee absolute secrecy – but it is unquestionably recognized as a “reasonable step” to preserve secrecy – it’s a lock on a front door that sends an unmistakable message to anyone who approaches – if I’m obfuscated – keep out.

Will development organizations who fail to include basic code obfuscation fall prey to the ominous sounding “Doctrine of Contributory Negligence?”

Can application obfuscation send a clear enough message to the courts to bring back trade secret theft protection under the newly minted Defend Trade Secrets Act?

These and other pressing Intellectual Property questions will be answered in upcoming episodes of “As the IP World Turns” (or, more realistically, my next blog post)

In the meantime, don’t forget to take reasonable precautions to protect any potential software trade secrets from reverse engineering.