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.