When the Binary Can’t Keep a Secret, the Contract and the Server Have To
Part 2 of 2: Licenses, trade secrets, patents and architecture after AI decompilation
The short answer
In Part 1, we described how AI agents have turned decompilation, the reconstruction of readable source code from a compiled program, from a rare specialty into an engineering project within reach of many developers, and why copyright law never protected as much of a program as many owners assumed. Copyright protects code, not function, and the federal courts, including the Eleventh Circuit, have long treated reverse engineering for legitimate purposes as fair use.
If copyright is the first lock, four others remain. A license agreement can forbid reverse engineering even where copyright would permit it. Trade secret law protects what is genuinely secret, but it has always allowed reverse engineering, and AI raises the question of whether code shipped to customers can still be a secret at all. Patents protect inventions regardless of how anyone wrote the code. And the most reliable protection of all is architectural: code that never leaves the company's servers cannot be decompiled by a customer.
Each of those protections has limits, and each looks different after October 2026. This post walks through them and closes with practical steps for software owners and for businesses considering these tools.
Lock two: the license agreement
A contract can take away what copyright allows. In Bowers v. Baystate Technologies, Inc., 320 F.3d 1317 (Fed. Cir. 2003), the software license at issue prohibited reverse engineering. The defendant argued that a state-law contract claim could not forbid conduct that federal copyright law permits as fair use. The Federal Circuit, applying First Circuit law, disagreed, holding that the contract claim was not preempted by the Copyright Act because mutual assent and consideration made it different in kind from a copyright claim. The court affirmed a breach of contract judgment. One judge dissented on that point, warning that enforcing such terms in standard form licenses would let software sellers eliminate fair use by contract. The Supreme Court declined review.
Most commercial software licenses contain a clause prohibiting the user from reverse engineering, decompiling or disassembling the product, or attempting to derive its source code. Under Bowers, a licensee who points an AI agent at that product may face a straightforward breach of contract claim, whether or not the same conduct would be fair use under Sega and Connectix.
The limits of the contract. A contract binds only the people who agreed to it. A license protects the owner against its own customers and anyone else who accepted the terms. It does nothing against a person who never did. The clause must also be enforceable in the first place: a license buried behind a link that no one had to accept is weaker than one the user affirmatively clicked to accept, and courts outside the Federal Circuit have not uniformly followed Bowers. Many licenses also carve out whatever the law requires them to allow, such as the narrow interoperability exception in the Digital Millennium Copyright Act, 17 U.S.C. § 1201(f), or the decompilation rights that EU law makes non-waivable. And contract damages are measured by the owner's actual loss, not by copyright's statutory damages.
The AI vendor's terms are a second contract. The person running the decompilation has usually agreed to a second set of terms: those of the AI provider. Some AI services restrict use of their models to build competing products or to violate third-party rights. Breaching those terms is an issue between the user and the AI company, not a defense for anyone, but it adds a layer of exposure that many users have not considered.
Telling the AI to do it is still doing it. An instruction to an AI agent does not move responsibility for the act to the agent. If a licensee is contractually forbidden to decompile a product, directing a model to decompile it is the licensee's breach. The provider's disclaimers protect the provider, not the user.
Licenses are catching up. Some newer license agreements prohibit, in terms, the use of artificial intelligence or automated analysis tools to derive source code or proprietary information. Whether courts will enforce that language more readily than the traditional clause is untested. It at least removes any argument that the parties did not contemplate the conduct.
Lock three: trade secret law
Reverse engineering has always been fair game. The federal Defend Trade Secrets Act defines "improper means" to include theft, bribery, misrepresentation, breach of a duty to maintain secrecy and espionage, and states expressly that it "does not include reverse engineering, independent derivation, or any other lawful means of acquisition," 18 U.S.C. § 1839(6)(B). Florida's Uniform Trade Secrets Act, chapter 688, Florida Statutes, defines improper means the same way but does not mention reverse engineering. The uniform act on which Florida's statute is based treats reverse engineering of a product acquired by fair and honest means as a proper means of discovering a secret, and Florida's statute separately protects information only if it is "not being readily ascertainable by proper means," § 688.002(4).
The practical consequence has always been that trade secret law offers little protection for anything a competitor can learn by buying the product and taking it apart. What AI changes is how much of a software product falls into that category.
The secret may stop being a secret. A trade secret must derive its value from not being generally known or readily ascertainable by proper means. If a capable developer with AI tools can reconstruct an algorithm from a shipped binary in days, a court could find that the algorithm was readily ascertainable, and therefore was never protectable as a trade secret against anyone, including a former employee who walks out with the source code. That is a quiet but significant risk. Owners who have relied on trade secret law to protect code they distribute to customers should expect defendants to make this argument.
Scale may matter: the Eleventh Circuit's bot case. There is a counterargument, and Florida's federal appeals court supplied it. In Compulife Software, Inc. v. Newman, 959 F.3d 1288 (11th Cir. 2020), a life insurance quoting company offered quotes through a database that anyone could query, one quote at a time, on the internet. A competitor used a bot to request and save more than 43 million quotes, covering every combination of inputs for two zip codes. After a bench trial, the magistrate judge found no misappropriation, reasoning that the individual quotes were public. The Eleventh Circuit vacated the judgment and remanded. It reasoned that manually accessing quotes is unlikely ever to be improper, but "using a bot to collect an otherwise infeasible amount of data may well be," and that taking enough of the quotes "must amount to misappropriation of the underlying secret at some point." The court analogized to E.I. duPont deNemours & Co. v. Christopher, 431 F.2d 1012 (5th Cir. 1970), in which photographers flew over a chemical company's methanol plant and photographed it: the plant was exposed to view from above, but the method of obtaining the secret was still improper.
No court has applied Compulife to AI-assisted decompilation, and there are real differences. Compulife's competitor was harvesting a database through the owner's website. A person who buys software and decompiles it is examining a product they lawfully own, which is exactly what the reverse engineering exception protects. Still, Compulife shows that the Eleventh Circuit is willing to look at the method and volume of an extraction, not just at whether each piece was technically accessible. For conduct that looks less like taking apart a purchased product, such as systematically querying a hosted service or an AI model to reconstruct how it works, the argument for improper means is considerably stronger.
Contracts as a bridge. Some commentators argue that breaching a license prohibition on reverse engineering turns otherwise proper reverse engineering into improper means, because "improper means" includes breach of a duty to maintain secrecy. That theory has support, but it is not settled: whether a standard form license creates the kind of confidentiality duty the statute contemplates depends on its terms and on the court. It is a reason to draft the clause with care, not a guaranteed second claim.
The lesson from the customer file. The strongest trade secret cases have always involved information that never left the owner's control: the customer file on the company's server, the formula in the lab, the pricing model on the internal drive. Those secrets are lost through people, not products, and AI decompilation does not change that. What it changes is the status of secrets that are shipped to customers inside a product. Those were always vulnerable in principle. Now they are vulnerable in practice.
Lock four: patents
Raymond's thread identifies patents as one of two remaining protections, and on the law he is right. A patent protects an invention, not a particular piece of code. A competitor that independently writes new code practicing a patented method infringes, no matter how clean its clean room was, and independent creation is no defense.
The limits are practical. Patents are expensive, public and finite. Many software innovations cannot be patented at all after Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), which narrowed patent eligibility for abstract ideas implemented on a computer. And, as Raymond notes, enforcing patents against vast numbers of end users is unrealistic. Patents are most useful against commercial competitors who ship a product, which is where most of the money is in any event.
Lock five: architecture
The one protection everyone agrees on is the oldest. Code that runs on the vendor's server and is accessed over a network is never in the customer's hands, so there is nothing to decompile. Raymond calls software as a service the one remaining way to maintain secrecy.
It is not a universal answer. Customers resist subscriptions and cloud dependence, and some products cannot depend on a network connection at all: medical devices, machine tools, vehicles, industrial controls and anything that has to work during an outage. Firmware has to live on the device. Technical measures still have value: code signing and secure boot can prevent modified software from running on a device even if the original has been read, and obfuscation and anti-tamper tools raise the cost of analysis, although AI lowers it. And hosted services carry their own risk: an AI agent can probe a service's behavior systematically, which is the scenario in which the Compulife reasoning applies most naturally.
The practical answer for many companies will be a hybrid. Keep the valuable logic, the proprietary models, the pricing engines, the data and anything that would hurt to lose on the server. Ship only what must run locally, and assume a competitor will read it.
What about the AI companies?
Some commentators have suggested that AI providers could face large liability for tools foreseeably used to destroy the value of proprietary software. Current doctrine does not readily support that theory. Under Sony Corp. of America v. Universal City Studios, Inc., 464 U.S. 417 (1984), distributing a product capable of substantial non-infringing uses does not by itself make the distributor liable for infringement by users, and AI coding tools have overwhelmingly lawful uses. MGM Studios Inc. v. Grokster, Ltd., 545 U.S. 913 (2005), imposes liability on a party that distributes a tool with the object of promoting infringement, shown by clear expression or other affirmative steps. A provider that marketed its model as a tool for cracking competitors' software could face a different analysis. A general-purpose model used by a customer for decompilation, in our view, is unlikely to create provider liability under existing law. That could change if courts or Congress decide otherwise, but it is not the law today.
Practical steps for software owners
Inventory what you ship. Identify every piece of valuable logic that leaves your control in a binary, an app, a browser bundle or a firmware image. Assume a motivated competitor can read it.
Move the crown jewels to the server. Where the product allows it, keep proprietary algorithms, models, rules and data in services you host. Treat what runs on the customer's device as public.
Revisit the license. Make sure customers affirmatively accept your terms. Prohibit reverse engineering, decompilation and the use of AI or automated tools to derive source code or proprietary information, subject to whatever the law requires you to allow. Add confidentiality obligations that a court can recognize as a duty to maintain secrecy.
Do not rely on trade secret law for shipped code. Document reasonable secrecy measures for what stays in-house. For what ships, rely on contracts, patents and architecture.
Consider patents for the genuinely inventive. Where a technique is novel and eligible, a patent may be the only right that survives an independent reimplementation.
Audit your own code before someone else does. Raymond predicts that "dirty laundry" will come out once anyone can read anyone's binary. That includes undisclosed open source components whose licenses require disclosure or attribution, third-party code used without a license, and code brought in by former employees of competitors. It is better to find those problems yourself.
Watch for clones and preserve evidence. If a competitor's product appears to reproduce yours, preserve your versions, documentation and release history. Copying of expression, trade dress, trademarks and license breaches remain actionable even when function is fair game.
Practical steps for businesses considering these tools
Check what you agreed to. If you licensed the target software, read the license before you analyze it. A clause prohibiting reverse engineering may be enforceable even when copyright law would allow the work.
Do not circumvent technical protections. Breaking encryption or anti-tamper measures raises separate liability under the Digital Millennium Copyright Act, and the interoperability exception is narrow.
Build a real clean room and document it. Separate the analysis of the original from the writing of new code, including separate AI sessions and separate people where possible. Never give the writing process the decompiled code. Keep the specification, the prompts and the logs. Run similarity analysis on the result.
Mind the look, the name and the market. Do not copy icons, interface designs, product names or branding. Trade dress and trademark claims do not depend on how the code was written.
Check your AI provider's terms. Confirm that the intended use is permitted.
Plan for Europe separately. Decompilation rights under the EU Software Directive are narrower than U.S. fair use.
Get advice before you release. Studying a program and publishing a reconstruction of it are very different acts. Most litigation risk sits at the moment of commercial distribution.
What remains undecided
No court has decided whether an AI-mediated clean room is clean enough to prove independent creation, whether training data exposure defeats a claim of isolation, whether large-scale AI decompilation can be improper means under trade secret law, or whether license terms aimed specifically at AI tools will be enforced more readily than older clauses. Many of the most dramatic claims circulating this month, including reports of complete decompilations of major games, have not been independently verified. The tools are improving quickly, and so are the arguments on both sides.
What is not undecided is the direction. For forty years, the difficulty of reading compiled code did much of the work that software owners attributed to the law. That difficulty is going away. The legal protections that remain, the license, the trade secret, the patent and the server, were always the ones that mattered. Owners who strengthen them now will be in a much better position than those who wait for the first clone to appear.
Sources
Bowers v. Baystate Technologies, Inc., 320 F.3d 1317 (Fed. Cir. 2003).
Compulife Software, Inc. v. Newman, 959 F.3d 1288 (11th Cir. 2020); E.I. duPont deNemours & Co. v. Christopher, 431 F.2d 1012 (5th Cir. 1970).
Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014); Sony Corp. of America v. Universal City Studios, Inc., 464 U.S. 417 (1984); MGM Studios Inc. v. Grokster, Ltd., 545 U.S. 913 (2005).
18 U.S.C. § 1839(6); 17 U.S.C. § 1201(f); sections 688.001 to 688.009, Florida Statutes.
Eric S. Raymond (@esrtweet), thread on the end of software secrecy, X (Oct. 5, 2026); Malte Kirchner, "Open-Source Guru Raymond: AI Ends Closed-Source Software," heise online (Oct. 8, 2026).
Andres Guadamuz, "Recreating Adobe: AI and the limits of software copyright," TechnoLlama (Oct. 9, 2026).
Disclaimer
This post discusses publicly reported legal developments for general informational purposes. It is not legal advice, it does not create an attorney client relationship, and it does not reflect the firm's position in any pending matter. Outcomes depend on the specific facts and the governing law of the relevant jurisdiction.