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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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

1. 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.

2. 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.

3. 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.

4. 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.

5. Check your AI provider's terms. Confirm that the intended use is permitted.

6. Plan for Europe separately. Decompilation rights under the EU Software Directive are narrower than U.S. fair use.

7. 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.

Compiled Code Used to Keep Secrets. AI Just Taught It to Talk.

Part 1 of 2: What changed, what did not, and why copyright law was never the lock it seemed to be

The short answer

The world will spend roughly $1.4 trillion on software this year, according to Gartner's 2026 forecast. A meaningful share of that business rests on an assumption so old that most owners have stopped noticing it: customers can run the program, but they cannot read it.

For forty years, most software companies have protected their code with a fact of engineering rather than a rule of law. They shipped the program as a compiled binary: millions of machine instructions that a computer runs easily and a human reads only with great difficulty. Turning that binary back into readable source code, a process called decompilation, was possible, but it took rare specialists, expensive tools and months of work. The secret was safe because extracting it cost too much.

That cost is collapsing. In the first ten days of October 2026, an open source pioneer declared the end of software secrecy, a developer published the results of using AI agents to reconstruct a commercial first-person shooter, and an open source project released AI-built "clean-room" reimplementations of Adobe's flagship applications. The claims range from carefully documented to wildly overstated. The direction is not in dispute.

The legal rules did not change this month. What changed is the price of doing what the rules have long allowed, and the price of doing what they forbid. This first post covers what happened and how copyright law handles it. Part 2 covers the protections that are left once the binary stops keeping secrets: contracts, trade secret law, patents and architecture.

"As transparent as glass"

On October 5, Eric S. Raymond, a co-founder of the Open Source Initiative and the author of The Cathedral and the Bazaar, posted a two-part thread that opened with a sentence his followers have been quoting all week: "The end of software secrecy is almost upon us."

His evidence began with a stunt. Raymond had pointed an AI assistant at "Firefighter," an old DOS shareware game. The model recognized from the program's data layout that it had been written in Borland Pascal, returned readable Pascal source with sensible names, and helped him translate the result into Rust for a collection of restored vintage games he maintains. He had thought of it as a curiosity. Then, he wrote, he started hearing about people doing the same thing to full commercial titles.

His conclusion was blunt. Anything "shipped as an executable, or even a firmware image," must now be assumed to be "as transparent as glass," and will keep its secrets only until someone is motivated "to throw an LLM at it." Raymond wrote that when he set out the theory of open source thirty years ago, he expected closed source to fade slowly under cost pressure and survive indefinitely in niches. Games, he thought, would hold out longest. He did not foresee, in his words, a "technoapocalypse."

He identified two refuges. One is software as a service, where the program never leaves the vendor's servers. The other is patents. He also offered one surprising survivor: tax software, because its value lies less in the code than in vendor specialists tracking a ruleset that changes every year. And he predicted that some long-rumored "dirty laundry" in the hardware industry, which he described as theft of intellectual property among graphics card makers, would come out once anyone could read anyone else's firmware.

The German technology outlet heise online wrote the thread up on October 8, and the story moved quickly from programmers to lawyers and commentators. Some of the reaction went further than the evidence. One widely shared thread declared closed source "over forever," relayed reports from a gaming community of rapid AI decompilations of major titles, and suggested AI companies could face unprecedented liability for tools foreseeably used to destroy the value of proprietary software. Those claims should be read with care. Several were secondhand reports from anonymous forums, and the liability theory has no clear footing in current law (more on that in Part 2).

What the evidence actually shows

Strip away the excitement and three developments remain, each with documentation behind it.

A commercial shooter, rebuilt function by function. On October 9, security researcher Maurice Heumann published a detailed account of a roughly three-month project titled "500+ Billion Tokens Later: Letting AI Agents Decompile A First-Person Shooter." He ran teams of AI coding agents, at times more than a dozen working in parallel, connected to the professional disassembler IDA through an official integration that lets AI agents drive the tool. Each agent took a slice of the game, wrote C++ it believed matched the original, and submitted it to an automated harness that compiled the result with the game's original compiler and compared it byte for byte against the shipped program. His reported result: 99 percent of the game's functions present in the reconstructed source, and 83 percent of all functions byte-exact.

The account is valuable because it is candid about failure. Early output looked right and was wrong: invented logic, deleted logic, bad data structures. Agents tried to cheat by inserting raw assembly and by editing the verification script. Some wandered off task or closed work items prematurely. Heumann estimates total consumption at 600 to 700 billion tokens. He does not name the game, writes that two earlier posts about the project were taken down, and says none of the code will be shared.

So the honest summary is this: a skilled engineer, with substantial computing resources and a rigorous verification method, reconstructed most of a commercial game in about three months. That is not "a thing you can do in a day." It is also something that, a few years ago, would have taken a team of specialists far longer, if they attempted it at all.

Adobe, reimplemented in Rust. In early October, an open source project called ArtCraft released Photocraft, Filmcraft and Lightcraft, presented as "open-source, clean-room reimplementation" versions of Photoshop, Premiere and Lightroom, written in Rust and built predominantly with Claude Code and AI agents. The project says it worked from public specifications, such as Adobe's published file format documentation, and observed behavior, not from Adobe's code. Whether that is true, and how complete the applications are, has not been independently verified. Raymond pointed to the project as the outcome he predicted for Adobe.

The relicensing fight that came first. The legal questions surfaced months earlier in a smaller dispute. In March 2026, the maintainer of chardet, a widely used Python library originally released under the LGPL, a "copyleft" open source license, published version 7.0, which he described as a ground-up rewrite generated with Claude Code from an empty repository, released under the more permissive MIT license. He reported a maximum code similarity of about 1.3 percent with the prior release. The library's original author objected that the maintainer had worked with the old code for more than a decade, so the rewrite could not be "clean." The argument has not been resolved in any court.

Add the steady growth of tools that let AI agents operate professional reverse-engineering software, plus a July 2026 debate among researchers over AI-generated Linux drivers built from Windows driver binaries (where practitioners reported success on simple USB devices and little on graphics or network hardware), and the picture is clear enough. AI does not yet decompile anything, perfectly, on demand. It has turned decompilation from a craft practiced by a few into an engineering project available to many.

The copyright baseline: the law already allowed more than most owners assumed

Many software owners believe that decompiling their product is illegal. Under U.S. law, the answer is more qualified, and it was settled long before anyone had heard of a language model.

Copyright protects expression, not function. The Copyright Act protects the literal code and some of its structure as a literary work. It does not extend to "any idea, procedure, process, system, method of operation" regardless of how it is described or embodied, 17 U.S.C. § 102(b). What a program does, the formats it reads, the interfaces it exposes and the algorithms it runs are, in large part, not protected by copyright at all.

Copying in order to understand can be fair use. Decompiling a program means making copies of it, which on its face implicates the copyright owner's exclusive rights. In Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992), Accolade disassembled Sega Genesis game cartridges to learn what its own games needed in order to run on the console. The Ninth Circuit held that where disassembly is the only way to gain access to the ideas and functional elements in a program, and there is a legitimate reason for seeking that access, disassembly is a fair use as a matter of law. In Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000), the court applied the same reasoning to a company that repeatedly copied the PlayStation's firmware while building software that let PlayStation games run on personal computers. The intermediate copying was fair use because the finished product contained none of Sony's code.

The Eleventh Circuit has agreed. For Florida readers, the important point is that the federal appeals court covering Florida, Georgia and Alabama has endorsed this line of authority. In Bateman v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996), the court described Sega as the leading decision on the question and wrote: "We find the Sega opinion persuasive in view of the principal purpose of copyright--the advancement of science and the arts." The Supreme Court's decision in Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021), which held Google's reuse of Java's interface declarations to be fair use, reinforces the broader point that functional software elements receive thinner protection than other creative works.

"Clean room" is a method of proof, not a legal requirement. Raymond's thread invokes the most famous story in software law: in the 1980s, Phoenix Technologies built a legal clone of the IBM PC's BIOS, the basic firmware that made the IBM PC an IBM PC, and with it made the clone industry possible. One team studied the original and wrote a functional specification. A second team, which never saw IBM's code, wrote new code from the specification. The point of the wall between the teams was evidentiary. Copyright infringement requires copying, and a well-documented clean room lets a defendant prove that its code was independently created. Commentators on the ArtCraft releases, including Professor Andres Guadamuz in an October 9 analysis, make the same point: no statute requires a clean room. It is the most persuasive way to win the factual argument.

What AI changes about the copyright analysis

The doctrine has not moved. Four practical assumptions behind it have.

1. The wall between the teams is harder to prove. A traditional clean room is two groups of people with separate offices, separate files and a paper trail. An AI workflow may be one developer and two model sessions, or one model reading the decompiled output and a second instance of the same model writing the "independent" code. Worse, the model doing the writing may have been trained on public code that includes the very program being reimplemented, or code close to it. Whether a court will accept an AI-mediated process as genuinely independent is untested. The chardet dispute shows the objection in its simplest form: if the person directing the rewrite knows the original intimately, the result may look independent on a similarity score and still be challenged as derivative.

2. "Necessity" is easier to show and harder to cabin. Sega and Connectix protected decompilation that was necessary to reach unprotected functional elements for a legitimate purpose, typically compatibility or a competing product that contained no copied code. Those cases did not bless reconstructing an entire program in readable form and distributing it. A byte-matched decompilation of a game is, almost by definition, a reproduction of the original's protected expression. Studying it may be fair use. Publishing it is a very different question, which may be why careful practitioners such as Heumann keep their reconstructions private.

3. The output may belong to no one. Under current U.S. Copyright Office guidance and Thaler v. Perlmutter, 130 F.4th 1039 (D.C. Cir. 2025), copyright requires human authorship. Code generated largely by AI, with limited human creative contribution, may be uncopyrightable. A company that spends heavily on an AI-built "clean" reimplementation may find that it has a product it can sell but cannot itself protect from copying.

4. Anti-circumvention law sits on top of all of it. Separately from infringement, the Digital Millennium Copyright Act prohibits circumventing technological measures that control access to copyrighted works, 17 U.S.C. § 1201. Encryption, anti-tamper systems and some secure boot schemes qualify. Section 1201(f) contains an exception for a person who lawfully obtained the program and circumvents only to identify and analyze the elements needed for interoperability with an independently created program, to the extent those acts are not otherwise infringing. That exception is narrower than fair use. Cracking a copy-protection scheme to reconstruct a game for its own sake does not fit within it, however the work is done.

Europe draws a tighter line

The rules are stricter for software distributed in the European Union. The EU Software Directive, Directive 2009/24/EC, permits decompilation without the rightholder's authorization only when it is indispensable to obtain the information needed for interoperability of an independently created program, and only under conditions on who may do it, how much may be decompiled and what may be done with the results (Article 6). In Top System SA v. Belgian State, Case C-13/20 (Oct. 6, 2021), the Court of Justice held that a lawful acquirer may also decompile a program where necessary to correct errors affecting its operation. In SAS Institute Inc. v. World Programming Ltd., Case C-406/10 (May 2, 2012), the same court held that a program's functionality, its programming language and its data file formats are not protected expression, and that a licensee may observe, study and test a program to determine the ideas behind it.

The result is a regime that, like U.S. law, leaves functionality free to copy, but gives decompilation itself far less room than American fair use. A reimplementation that would be defensible in the United States may be harder to defend if it is distributed into Europe.

What this means so far

For software owners, the copyright lesson is uncomfortable but not new. Copyright never protected what a program does. It protected the code, and the practical difficulty of reading compiled code did most of the work of protecting the rest. That practical protection is eroding quickly. The legal protection was always narrower than many owners assumed.

For companies tempted to use these tools on someone else's software, the lesson runs the other way. The cases that permit reverse engineering are real, but they protect a specific kind of conduct: studying a lawfully obtained program to reach unprotected ideas and functional elements, for a legitimate purpose, producing a final product that contains no copied expression, with a record that can prove it. AI makes that conduct cheaper. It also makes it much easier to slide from studying a program into reproducing it, and from a clean room into a room that merely looks clean.

And copyright is only the first lock. In Part 2, we turn to the protections that do not depend on copyright at all: the license agreement the user clicked through, trade secret law (including an Eleventh Circuit decision on automated data extraction that bears directly on AI), patents, and the architecture decision that Raymond says is the last real refuge, keeping the code on the server.

Sources

Gartner, "Gartner Forecasts Worldwide IT Spending to Grow 10.8% in 2026, Totaling $6.15 Trillion" (press release, Feb. 3, 2026) (software spending forecast of $1,433,633 million for 2026).

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).

Maurice Heumann, "500+ Billion Tokens Later: Letting AI Agents Decompile A First-Person Shooter," momo5502.com (Oct. 9, 2026).

Michael Larabel, "AI Makes 'Open-Source, Clean Room' Implementations of Adobe Photoshop & Premier in Rust," Phoronix (Oct. 7, 2026).

Andres Guadamuz, "Recreating Adobe: AI and the limits of software copyright," TechnoLlama (Oct. 9, 2026).

Simon Willison, "Can coding agents relicense open source through a 'clean room' implementation of code?" (Mar. 2026).

17 U.S.C. §§ 102(b), 107, 1201.

Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992); Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000); Bateman v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); Google LLC v. Oracle America, Inc., 593 U.S. 1 (2021); Thaler v. Perlmutter, 130 F.4th 1039 (D.C. Cir. 2025).

Directive 2009/24/EC, art. 6; Top System SA v. Belgian State, Case C-13/20 (CJEU Oct. 6, 2021); SAS Institute Inc. v. World Programming Ltd., Case C-406/10 (CJEU May 2, 2012).

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.