If AI can rewrite anything: What’s left of copyright and copyleft?

Every software license you have ever used - from a proprietary EULA to the GNU GPL - rests on a single assumption: that code is copyrightable, and that copying its expression is something different from reimplementing its ideas. For half a century, that premise and distinction held. It gave us the IBM PC clone market and most notably the entire GNU Project.

Paradoxically, copyright also became the foundation of Free and Open Source Software (FOSS). Authors use their copyright to grant permissions rather than restrict them. Instead of keeping exclusive control, they choose to give users the freedom to use, study, improve, and share their work through licenses like the GNU GPL.

Then AI coding agents, trained on the entirety of FOSS projects, became capable to reimplement almost anything based on a mere description of what it does.

This post looks at how we got here, from the birth of software copyright to the clean room approach that made it legal to build API-compatible clones. Then it approaches the key question: if an AI can rewrite any computer program to circumvent copyright, what is left of intellectual property in software, and what does that mean for FOSS?

TL;DR

The rise of competing AI-driven reimplementations threatens FOSS and proprietary software equally by bypassing traditional protections like copyright, which only cover source code. Related artifacts - like specifications, test suites, APIs, or documentation - are critical enablers for automated cloning but lack robust legal safeguards. While IP protections could theoretically shield these materials, they risk undermining FOSS’s core principles of openness and collaboration. Without proactive measures, AI could leave FOSS vulnerable to wholesale appropriation while eroding the commercial software industry as a whole.

Software as Intellectual Property

Software has not always been treated as intellectual property. In the early days of computing, during the 1950s and 1960s, programs were largely shared freely among academics and users of the same hardware. Software was considered a byproduct of the machine, bundled together and not seen as a distinct, protectable work.

This started to change when, in 1969, a United States antitrust case against IBM pressured the company to unbundle its software from hardware, effectively giving birth to the commercial software industry.

In 1974, the US Congress established the Commission on New Technological Uses of Copyrighted Works (CONTU) to determine whether and how copyright law should apply to computer programs. CONTU’s final report in 1978 recommended that software be explicitly protected under copyright, which led to the Computer Software Copyright Act of 1980, amending the US Copyright Act of 1976 to clearly include computer programs.

A landmark case followed in 1983 when Apple v. Franklin established that not only source code (the human-readable form) but also object code (the compiled binary that the machine executes) qualifies as a copyrightable literary work. The classification as “literary work” may seem odd for something a computer runs, but it means that software is legally treated like a book or an article - the author’s creative expression is protected, regardless of the medium.

Internationally, these principles were harmonized through WIPO’s Copyright Treaty (WCT) in 1996 and, at the European level, through Directive 91/250/EEC on the legal protection of computer programs, later refined as Directive 2009/24/EC. Today, it is universally accepted that software is protected as a literary work under copyright law.

Ideas versus Expression

Copyright law, however, draws a critical line: it protects the expression of an idea, not the idea itself. This principle, known as the idea-expression dichotomy, is fundamental to all of copyright law but has particular significance for software.

An algorithm, a mathematical formula, or a functional concept cannot be owned by anyone. Only the specific way in which such an idea is implemented in code, the particular arrangement of statements, the structure and flow, the chosen names and architecture, is subject to protection. To put it simply: the recipe is free, but the specific wording of the cookbook is not.

This distinction was the crux of the epic Oracle v. Google case, which wound through US courts for over a decade before the Supreme Court ruled in 2021 that Google’s use of Java API declarations, essentially the names and signatures of programming interfaces, not their implementation, constituted fair use. The boundary between what is a protectable expression and what is an unprotectable functional interface remains blurry. But the underlying principle stands: you can reimplement someone else’s functionality, as long as you write your own code to do it.

This is not merely a theoretical legal construct. It is the very foundation that enabled the personal computer revolution and, by extension, the modern software industry as we know it.

The Clean Room Approach

In 1981, Compaq Computer Corporation faced an enormous challenge: it wanted to build a personal computer fully compatible with the IBM PC, but IBM’s Basic Input/Output System (BIOS) was copyrighted. Simply copying the BIOS code would have been straightforward infringement. Instead, Compaq pioneered what is now known as the Clean Room approach to reverse engineering.

The method works by strictly separating the process into two independent teams. The first team, sometimes called the “dirty” team, studies the original software in detail. They examine its behavior, document every function, interface, input, output, and edge case. Crucially, they produce only a functional specification: a description of what the software does, without any reference to how the original code achieves it. No source code is ever included. The second team, the “clean” team, then receives only that specification. They have never seen the original code and implement the required functionality entirely from scratch.

The result is a new, independently authored work that achieves the same functionality. Because the clean team never had access to the original expression, their code is their own creative work. The idea-expression dichotomy is preserved: the idea is reimplemented, but the expression is original.

Compaq’s approach proved legally sound. Phoenix Technologies followed the same approach shortly after for their own IBM-compatible BIOS. Together, these clean room implementations gave birth to the entire IBM PC clone market - a market that would eventually become the dominant computing platform worldwide.

The legal validity of clean room reverse engineering was further cemented through court decisions. In Sega v. Accolade (1992), the Ninth Circuit held that reverse engineering a program to understand its unprotected functional elements constitutes fair use. In Sony v. Connectix (2000), the same court upheld the legality of reverse engineering Sony’s PlayStation BIOS to create an emulator.

In sum, a clear and reliable legal framework was established: if you want to create a compatible or competing implementation, you can do so legally - provided you never directly access or copy the original source code. The clean room approach became standard practice. Projects like Wine (reimplementing the Windows API), ReactOS (a Windows-compatible operating system), and various FOSS reimplementations of proprietary protocols all rely on this principle.

Perhaps the most consequential application of clean room thinking, however, came from the Free Software movement itself. When Richard Stallman launched the GNU project in 1984, the explicit goal was to create a complete, Unix-compatible operating system composed entirely of Free Software. Every core utility - the shell, the compiler, the assembler, the text editor, the core libraries - had to be reimplemented from scratch without ever looking at AT&T’s proprietary Unix source code.

The GNU Coding Standards made this obligation unambiguous: “Don’t in any circumstances refer to Unix source code for or during your work on GNU! (Or to any other proprietary programs.)” Contributors who had a vague recollection of Unix internals were instructed to deliberately organize their reimplementation along different lines - optimizing for speed instead of memory, using dynamic allocation instead of static tables, eliminating temporary files, or adding extensibility through embedded programming languages - so that the resulting code would be structurally dissimilar to the original.

The GNU project worked exclusively from publicly available specifications like the POSIX standard (which defines how Unix-like systems should behave), manual pages, and documented behavior. In essence, a massive, decades-long clean room effort carried out by a global community of volunteers - and it produced tools that in many cases surpassed their Unix counterparts in reliability and capability.

A Well-Defined World

For decades, the software industry operated within this well-defined legal framework. Copyright protects code as a literary work. Ideas and functionality are free to be reimplemented. The clean room approach provides a legally sound method to create compatible software without infringement. FOSS licenses build upon copyright to grant specific freedoms. And the boundaries, whilst occasionally litigated, were reasonably clear.

Then came AI-powered programming assistants, trained on millions of repositories of source code. And the question of what constitutes original expression, independent creation, and clean room separation suddenly became a lot less straightforward.

AI as the New Clean Room?

What was once a months-long effort by two carefully separated teams of engineers can now be accomplished by a single person with a prompt and a bunch of AI coding agents. Recent examples illustrate both the impressive capabilities and the deeply unsettling implications for the established legal framework.

In February 2026, Anthropic researcher Nicholas Carlini published a blog post describing how he set 16 instances of the AI model Claude loose on a shared codebase, tasking them with building a C compiler from scratch. A compiler translates human-readable source code into machine instructions - it is one of the most fundamental and complex pieces of software in existence. Over two weeks and nearly 2,000 sessions costing about $20,000 in API fees, the AI agents produced a 100,000-line Rust-based compiler capable of building a bootable Linux 6.9 kernel. It achieved a 99 percent pass rate on the GCC torture test suite and could compile major FOSS projects including PostgreSQL, SQLite, Redis, FFmpeg, and QEMU.

The result was claimed a “clean-room implementation” because the agents had no Internet access during development. But the underlying model was trained on enormous quantities of publicly available source code, almost certainly including GCC, Clang, and numerous smaller C compilers. In a traditional clean room, the implementing team has never seen the original code. Here, the model has, in a very real sense, read all of it.

This could point to a fundamental flaw of the clean room concept when applied via AI. The traditional approach works because there is a hard wall between two separate teams: one reads the original, the other writes the new code, and the two never met. With a large language model, that wall does not exist. The model is both teams simultaneously. It absorbed the original code during training and produces new code during inference. The very separation that gave the clean room its legal validity has collapsed into a single entity. The one exception may be proprietary software whose source was never public and therefore, in principle, never available as training data. Even that assumption is only as reliable as the confidentiality behind it, as more than one inadvertent code leak has shown.

Around the same time, in March 2026, the Python character encoding library chardet became the epicenter of a heated debate. Character encoding detection is a relatively small but widely used building block - chardet is downloaded millions of times per month. Its maintainer Dan Blanchard released version 7.0 as what he described as a complete rewrite using Claude, relicensing the project from LGPL to MIT. In practical terms, this meant moving from a copyleft license (which requires that modified versions remain FOSS) to a permissive license (which allows the code to be used in proprietary products without sharing changes back). Mark Pilgrim, the library’s original author, returned to dispute the relicensing, arguing that the maintainer had ample exposure to the originally licensed code and that “adding a fancy code generator into the mix does not somehow grant additional rights.”

Richard Fontana, an IP lawyer at Red Hat, raised fundamental questions about whether AI-generated code can be copyrighted at all - and if not, whether applying any license to it, including MIT, is even meaningful. If the code was essentially written by Claude, under whose copyright is it being licensed? The general legal consensus leans toward generative AI output not being copyrightable without sufficient human creative involvement, which makes the entire relicensing premise fragile.

Taking the AI-fueled reimplementation concept to its logical, and provocative, ultimate conclusion, the service Malus launched in early 2026 as a self-described “Clean Room as a Service”. As reported by 404 Media, Malus is a piece of satire that appears to also be functional: an allegedly real service provider that uses an LLM to produce functional clones of existing FOSS, effectively stripping off any license obligations. Point it at a copyleft-licensed project, and out comes a reimplementation that claims to be free of the original license’s conditions. The premise is deliberately uncomfortable: if an AI can reimplement any software from a functional specification and the resulting code is considered an independent creation, then copyright (incl. copyleft) can be circumvented at the push of a button.

AI coding agents are producing substantial, functional software, from libraries to compilers to entire applications, at a pace and scale that was unthinkable just a year ago. But each case surfaces the same unresolved questions. Is the output truly an independent creation, or a lossy reproduction of its training data? Can a model that has ingested millions of lines of copyrighted code ever produce a genuine clean room implementation? And if the resulting code cannot be copyrighted by the person who prompted it, what does that mean for the licensing mechanisms like copyleft, or proprietary licensing, that fundamentally depend on copyright to function?

It is also worth pausing to consider who benefits from all of this. The companies building these AI coding agents have trained their models extensively on FOSS code - code that was shared freely by a global community of volunteers and contributors. Those same companies now offer tools that can, in effect, strip away the very licenses that made the training data available in the first place. The community provides the raw material, the companies extract the value, and the resulting output may no longer carry any of the obligations that the original authors intended. It is a peculiar kind of circular economy - one in which the circle only benefits those who close it.

Protecting Software in the Age of AI

If we accept, even tentatively, that AI coding agents will soon be capable of reimplementing virtually any piece of software based on a functional specification alone, regardless of whether the original is FOSS or proprietary, then the question shifts. It is no longer about whether a particular reimplementation infringes copyright. It is about whether copyright, as the primary mechanism for protecting software, remains sufficient at all.

For FOSS, its underlying principles and collaborative nature are at stake. Within the commercial software industry, the entire business model of selling usage licenses of proprietary software could be eliminated.

If the expression of code can be regenerated at will, and only the original expression and not the underlying idea is protected, then what exactly is left to protect?

And the problem cuts both ways. If AI-generated code is not copyrightable, as current legal consensus suggests, then it cannot be placed under any license. Not a proprietary one, not a permissive one, and not a copyleft one either. Copyright is the legal foundation that makes all software licensing possible, including every FOSS license ever written. Without copyright, there is no license. Without a license, there are no obligations - but also no guaranteed freedoms such as those FOSS provides.

Excursus: Software and Patents

Unlike copyright, which protects the specific expression of an idea, a patent protects the idea itself - the invention, the method, the technical solution. In theory, a software patent could prevent anyone, human or AI, from reimplementing the same functionality, regardless of how different the resulting code looks. This would close the very gap that the clean room approach exploits.

In practice, however, the picture is far more complicated and varies significantly across jurisdictions.

In the United States, software patents have been available since the 1990s and were granted liberally for years. This changed somewhat with the Supreme Court’s decision in Alice Corp. v. CLS Bank (2014), which held that abstract ideas implemented on a generic computer are not patentable. The ruling narrowed the scope but did not eliminate software patents. Software that demonstrates a concrete “technical improvement” can still be patented. As a result, the US landscape remains large but contentious, with ongoing debates about overly broad claims, entities that acquire patents solely to extract licensing fees (so-called patent trolls), and the chilling effect on innovation.

In Europe, the situation is deliberately more restrictive. Article 52(2)(c) of the European Patent Convention (EPC) explicitly excludes “programs for computers” from patentability - as such. A proposed Directive on the Patentability of Computer-Implemented Inventions was famously rejected by the European Parliament in 2005 after intense lobbying from the FOSS community, among others. This rejection remains one of the most significant legislative victories for FOSS in Europe.

Even where software patents are available, they come with significant limitations. They are expensive to obtain and maintain, typically limited in time, difficult to enforce across borders, and require public disclosure of the invention - which, paradoxically, could itself feed into the training data of future AI models. For individual developers and small FOSS projects, the patent system is largely inaccessible. And for the broader FOSS ecosystem, software patents have historically been perceived as a threat, not a protection, precisely because they restrict the very freedoms that are core to the definition of FOSS.

So patents, too, fall short as an answer. They are inaccessible to most FOSS projects, actively distrusted by the community, and, outside narrow technical inventions, often unavailable at all.

Beyond Source Code

Which brings us back to the original question: how else might we be able to protect original computer programs against undesired AI-based reimplementations?

A computer program is not just its code, though the source code and the developers who write it have been the most precious asset so far. But around every non-trivial piece of software exists a framework of accompanying works that are essential to its creation, its validation, and its use. And these are often what makes reimplementation possible in the first place:

• Specifications and standards. The Anthropic C compiler was feasible precisely because the C language specification is decades old, publicly available, and well-defined. Without a formal specification of what the software is supposed to do, a precise description of its expected behavior, no clean room implementation, whether human or AI-driven, can even begin. Specifications range from public standards (like ISO norms) to proprietary interface definitions and API documentation. They describe the what, which is exactly the part that copyright does not protect.
• Test suites and test data. Carlini himself acknowledged that the task verifier is critical: “it’s important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem.” The C compiler’s development was guided by the GCC torture test suite - a comprehensive set of test programs developed over decades by the FOSS compiler community and released under the GPL. Without those tests, the AI agents would have had no way to check whether their compiler actually works correctly. Test suites are, in many ways, the specification made executable. They define correct behavior through concrete examples, covering edge cases that no written specification could exhaustively enumerate.
• Documentation and manuals. User-facing manuals, API documentation, architecture overviews, and tutorials describe the intended behavior and design rationale of software. They are frequently available publicly and almost certainly part of a product delivery. Whilst documentation describes how software works from the user’s perspective, it often reveals enough about internal structure and behavior to guide a reimplementation.
• Software Development Kits (SDKs). An SDK is a package of tools, libraries, code examples, and documentation that helps developers build software that works with a particular platform. SDKs provide the implementation framework that guides interested developers in creating platform-compatible applications. At the same time and with its level of detail, it might also enable reimplementations of the underlying platform itself.
• User interfaces (UIs). The look and feel of an application - its layout, icons, screen flows, and interaction patterns - is often what users actually recognize and value, and it is trivial for an AI to reproduce from screenshots or a running instance.

Each of these artifacts is a copyrightable work in its own right. Test code is source code. Documentation is a literary work. Specifications, depending on their form, scope, and originality, may qualify as well. UIs could be made subject to design patent (in the US) and registered design (in the EU) protection.

And yet, their role in enabling AI-based reimplementation is largely overlooked.

Protecting The Underlying Artifacts, Not Just the Code

If protecting source code alone is no longer sufficient to prevent wholesale reimplementation by AI, could protecting the surrounding artifacts - the specifications, test suites, documentation, SDKs, and user interfaces - provide a more effective barrier?

An AI coding agent cannot reimplement software it cannot understand or validate. If the defining artifacts are not freely available, or are licensed under terms that explicitly prohibit use for AI training/guidance or more specific automated reimplementation, the clean room approach collapses. Without tests, the AI produces code that may compile but has no way to prove it actually works correctly. Without specifications, it cannot understand what to build. Without documentation, it lacks the behavioral context to handle edge cases. Without a proper UI, its user experience will be very limited. The source code becomes just one piece in a much larger puzzle - and perhaps not even the most important one anymore.

For FOSS projects, any restriction creates a painful tension. The entire philosophy of FOSS is built on transparency and the freedom to study, modify, and redistribute. Limiting access to specifications, test suites, or documentation runs counter to these principles. It would fragment the ecosystem, create barriers to legitimate contributions, and undermine the collaborative model that has made FOSS so successful.

Yet leaving all of these artifacts freely available, including for consumption by AI models, effectively provides a complete blueprint for automated reimplementation, potentially stripping away the very license conditions that the project’s authors chose to apply.

There are no easy answers. Discussions have also started at Creative Commons. The Authors Guild has some recommendations on how literary work can be better controlled by dedicated terms for AI training and re-use. The Software Freedom Conservancy has more specific recommendations on “Using LLM-backed Generative AI Systems for FOSS Contributions”.

Ultimately, the focus on legal mechanisms alone might be too narrow. FOSS has never been just about code and licenses. It is, at its core, a social construct. Behind every successful project stands a community: maintainers who understand the architecture, contributors who know the history of design decisions, an issue tracker full of context, a governance structure built on trust. An AI can clone the code. It can even ingest the tests and the documentation. But it cannot clone the power of community. It cannot replicate the years of institutional knowledge, the relationships between maintainers and contributors, the reputation that makes users trust one implementation over another. Perhaps the most durable protection that FOSS has was never the license at all - but the people and their collaborative and supportive will behind it.

But it could be the end of the commercial software industry as we know it.

In the past, copyright enforcement always won. This time, the AI industry may have the stronger - more expensive - arguments.

Notes

Inspired by “Let’s end open source together with this one simple trick” by Dylan Ayrey & Mike Nolan and “GNU and the AI reimplementations” by antirez.

Research and copy-editing assisted by Mistral and Anthropic.

This blog post does not constitute any legal advice.