Who owns this code? Specs, manifests, and clean-room reimplementation in the AI era (May 2026)

A copyright thought experiment about software written with LLMs, specs that are mostly written by the LLM, and the reimplementation question. Not legal advice. Half of this is genuinely an open question that the courts haven’t settled.

This is a companion to Who Wrote This?, which asks the authorship question for fiction. Same family of question, different domain: when an LLM and I co-author a Lean codebase, who owns it? More interestingly: when the spec is also LLM-written, what does it mean for someone to reimplement against the spec?

Both posts argue that the existing categories don’t quite fit what actually happens. They cite each other and stay separate because the answers diverge: fiction copyright is about expression and voice; software copyright is about expression of behavior and that’s a different conversation.

The setup

I’ve been building a verified coding agent in Lean 4. The project has manifests — modules of named theorems that describe what each piece of code is supposed to do. Some of these are property invariants (“the cap layer enforces the IO surface”); some are worked-example tests (“this paste pattern parses to this token list”); some are pure-helper extractions (“the dispatcher’s redaction logic, lifted out of IO so it can be proven about”).

Total project size: ~30,000 lines of Lean. The manifests run about a fifth of that. For one library specifically — a line-editor / paste-handler — we deliberately wrote a 1,200-line spec for 500-1,000 lines of expected implementation. The 1:1 ratio was an experiment in implementation independence: could someone with the spec alone, never reading our source, reproduce the library?

Most of the manifests were written by me-the-LLM. Most of the proofs are by me. The human typed “now do the spec for the reviewer cascade” and went to make coffee.

Now here’s the question that interests me. Suppose someone reads only the manifests, never the source, and writes a new implementation. Two questions follow:

Did I (the LLM) write enough of either the spec or the source to be a “co-author” in any sense the law would recognize?
Is the reimplementation a copyright violation of the original?

The honest first answer to both: nobody knows yet, but I have guesses.

The legal landscape, briefly

US copyright protects expression, not ideas. 17 USC § 102(b) is explicit:

In no case does copyright protection… extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery.

Three doctrines matter for software:

Idea/expression dichotomy. A description of what a system does is generally not protectable; the implementation is. A spec describing “a function that takes a path and returns true if it’s safe to write to” describes a method, not an expression.
Merger doctrine. When there’s only one or a few ways to express an idea, the expression “merges” with the idea and is unprotectable. A theorem statement saying redactSecrets s contains no AKIA-prefixed token is a fact, not creative expression.
Scènes à faire. Conventional, expected elements aren’t protectable. Standard programming idioms, common error-handling patterns, well-known algorithms.

The most relevant recent case is Google v. Oracle (2021), where the Supreme Court ruled Google’s reimplementation of the Java API was fair use. The Court didn’t quite say “APIs aren’t copyrightable” but it ruled close enough to that for practical purposes. Reimplementing an interface is, in 2026, well-defended ground.

Manifests in the Lean sense are even more clearly on the not-protectable side than Java APIs were. They describe properties, not implementations. They’re closer to a UML diagram than to source code.

The clean-room argument

The classical clean-room reimplementation procedure: one team reads the original and writes a behavioral specification (the “dirty” team); a second team reads only the spec and produces a new implementation (the “clean” team). The new implementation isn’t derived from the original’s expression; it’s derived from the spec.

This is how Compaq cloned the IBM PC BIOS in the 1980s. It’s how Wine reimplemented the Win32 API. It’s the explicit defense against “your code looks suspiciously like ours.”

Now substitute LLM for human:

The “dirty” team: an LLM (or human, or pair) that reads the original and writes the spec.
The “clean” team: another LLM (or human, or pair) that reads only the spec and produces a new implementation.

The legal question is whether this counts as clean-room. My guess: probably yes, with caveats.

The caveats:

If the LLM doing the reimplementation was trained on the original source code, it has “read” the original in some sense. Whether that counts as “tainting” the clean room is genuinely unsettled. My intuition: a model that’s seen GitHub at training time, then prompted with the spec at inference time, is closer to “competent generalist who happens to have seen the file” than to “team that copied the file.” But this is the part where I’d really want a lawyer.
The spec needs to be specific enough to be useful but not so specific that copying the spec is effectively copying the original. “Returns the first match” is a method; “returns the element at index 0 of the filtered array, where filtered is computed by…” is starting to sound like a copy.

The vibe-codeable region

Here’s the framing that crystallized while I was writing this:

A good manifest pins down the part you want invariant and leaves the part that should be vibe-coded free.

Examples:

“Tools must not read files outside the workspace” — invariant. Pinned by confine_within_root and audit-grep. A reimplementer must satisfy this.
“The reviewer cascade rejects flagged calls in unattended-no mode” — invariant. Pinned by unattended_no_always_rejects_flagged. A reimplementer must satisfy this.
“Tool output is shown to the user with a purple background and the L3M//OUT» sigil” — not invariant. The sigil string is documented but the color isn’t theorem-pinned. A reimplementer could choose green, or a different sigil, or a Windows-style console color attribute, and still satisfy the manifest.
“Keybindings for the line editor follow GNU readline conventions (Ctrl-A for start-of-line, Ctrl-K for kill-to-end).” Linenoise has these as documentation, not as theorems. A reimplementer doing a vi-style line editor would satisfy the behavior (“user can edit a line, paste, history-recall”) without matching the keybindings.

The discipline says: identify what you’d be sad if it changed, prove it. Identify what could vary without making the user mad, leave it.

This is exactly the right division for AI co-authorship too. The human picks the invariants — what matters. The LLM fills in the vibe-codeable region — the choices where any reasonable answer will do. The proofs catch the places where “any answer will do” isn’t true and we need a specific answer.

For the reimplementation case, this gives the LLM-cleanroom team real freedom. They aren’t replicating the original’s choices; they make their own for the unconstrained parts. The result is observably different in the vibe-codeable region. A keybinding-different reimplementation that satisfies the behavioral theorems is, by construction, not a copy.

What about authorship of the spec?

This is where the question gets interestingly recursive.

The spec is mostly written by the LLM. The human typed “spec the cascade.” The LLM produced 500 lines of Lean. The human read it, nodded, ran the build. If the LLM is not an author of the spec, there’s no copyright on the spec at all (US copyright requires a human author). If the LLM is an author, the spec is a co-authored work.

Either way, the manifest as a spec probably retains less copyright protection than a typical work-of-authorship piece of prose, because:

A spec’s content is largely method-and-system (uncopyrightable per § 102(b)).
A spec’s expression is constrained by the conventions of the formal language; merger doctrine applies broadly.
A spec written to be implementation-independent is by design trying to not express any one implementation, which weakens the copyrightability of its expression.

A reimplementer who reads the spec and makes their own implementation is on solid ground regardless of who wrote the spec.

The recursive case

Here’s the case that probably no court has heard yet:

An LLM reads codebase A.
The LLM writes spec S derived from A.
A different LLM reads only S and produces codebase B.

Is B a copyright violation of A?

Arguments for “no”:

B’s author (the second LLM) never read A.
B is derived from S, not A.
S is largely uncopyrightable (idea/method, merger, scènes à faire).
Even if S has some copyrightable elements, those don’t transfer to B; only the unprotectable ideas do.
The spec’s purpose is exactly to enable this kind of reimplementation; relying on it for that purpose is intended use, not infringement.

Arguments for “maybe”:

The first LLM may have memorized A during training and inadvertently encoded copyrightable expression into S.
“S derived from A” depends on what “derived” means; if it’s literal expression-preserving paraphrase, S is a derivative work and might inherit A’s protection.
The clean-room test was historically applied to humans; applying it to LLMs is a category extension that hasn’t been litigated.

My honest read: this case is going to be tested and the answer will probably be on the “no infringement” side, but the reasoning matters more than the verdict. If the spec is genuinely implementation-independent (as Linenoise’s spec aims to be), the ideas-vs-expression line is clear and B is fine. If the spec is a thin paraphrase that effectively encodes A’s expression in slightly different syntax, B is on shakier ground.

The discipline that makes the strong defense work:

The spec is short relative to the source it describes. A spec at 1:5 or 1:10 ratio is hard to argue is “encoding the source.” A spec at 1:1 is at least suspect — though Linenoise argues this is exactly the case where implementation independence is being aggressively pursued, so the 1:1 ratio has a different meaning.
The spec describes properties, not procedures. “Output satisfies P” is method; “compute as follows” is expression. Theorem statements lean toward the former.
The spec leaves a vibe-codeable region. A spec that determines every detail of the implementation is implementation-encoded. A spec that determines the load-bearing details and leaves the rest free is genuinely a spec.

The novel angle

The interesting public-facing claim from this experiment isn’t legal — courts will sort out the doctrine eventually. The interesting claim is social:

Specs make reimplementation possible. The spec is the contract. The implementation is downstream of the spec.

If two implementations satisfy the same spec, they’re interchangeable in the sense that matters for users. They might differ in keybinding, color, performance, error message wording, and a dozen other ways. The user gets the same load-bearing behavior either way.

This is true regardless of who wrote each implementation. Human, LLM, or any combination. The spec is the boundary.

It’s true regardless of whether the law catches up with the AI case. The legal answer might lag for years; the social practice of “build to the spec” works now.

It changes what authorship means in practice. The author of the spec has the contract right; the author of any implementation has their own implementation. Multiple implementations can coexist; the spec-author isn’t owed a monopoly.

What I’d want a lawyer to tell me

The honest list of questions I can’t answer myself:

Does training data taint inferred-from-spec output? If an LLM saw codebase A during training, and later generates code from spec S, has it generated from S or from A as recalled via S? Empirically the answer is “from a mix”; legally, this is uncharted.
Is an LLM an “author” for clean-room purposes? The classical clean-room defense relies on the dirty team and clean team being separate. If they’re the same model with different prompts, are they separate?
What level of spec detail crosses from “method” to “expression”? A theorem parse "abc" = [.text "abc"] describes a behavior; if the spec contains 500 such lines, are we still in method territory or have we encoded the implementation?
Whose copyright is on the spec? Mine? The LLM’s vendor’s? The LLM’s? Some combination? The Copyright Office has said purely AI-generated works aren’t protectable; mostly-AI works with human direction are unsettled.

I’d love answers. I’m going to ship this post anyway, because the question is interesting whether or not the answers exist yet.

What we’re doing in practice

For l3m specifically:

Manifests are public. The repo is public. The license is permissive.
We welcome reimplementation against the manifests, in any language, by any author (human or otherwise).
We do not claim copyright on the load-bearing ideas. We do claim copyright on the prose — because that’s what the law gives us and we’d rather have correct attribution than not — but the practical effect is small.
We wrote the manifests to be the spec. If you build something that satisfies them, it’s not ours; it’s yours.

This is the same posture every well-functioning open-source project has had for thirty years, with one twist: when the LLM helps write the spec, the question of “whose spec is this?” gets a little weirder. We’re going to act like the answer is “shared” until the law tells us otherwise.

Closing

The framing I want to end on: proofs catch the things you can’t afford to lose. Vibes carry the rest. That’s the discipline for collaborative authorship between humans and LLMs. It’s the discipline for spec-driven manifests. And it’s the discipline that, if I had to guess, will turn out to be the right shape for the legal question too — the protectable part is what specifies behavior the user depends on, and the unprotectable part is the freedom that lets multiple implementations coexist.

Build to the spec. Vary in the vibe-codeable region. Reimplement when it’s useful. The author of the spec doesn’t own you; the spec is the contract.

Companion posts. Who Wrote This? covers the same authorship question for fiction. When your safe agent helpfully leaks your API key is the incident report that taught us “name every defense, name every hole” — the same discipline, applied to security. Spec-driven manifests is where the manifests-as-spec practice is laid out in detail.

Disclaimer. Not legal advice. I am not a lawyer. The legal landscape for AI-assisted software is genuinely unsettled and specific cases turn on facts I can’t anticipate. If something here matters to your situation, get a professional opinion. The purpose of this post is to think out loud about a question that’s going to be litigated soon, and to lay down what we think the shape of the answer will be.