What Is an AI “Clean Room as a Service” — and Is It Legal?

# What Is an AI “Clean Room as a Service” — and Is It Legal?

An AI “Clean Room as a Service,” as pitched by Malus, is a proposed service that uses AI to recreate open‑source dependencies from scratch—based on public documentation and interfaces—so a company can ship a “replacement” under corporate-friendly licensing instead of complying with the original project’s attribution or copyleft terms. Is it legal? That’s highly uncertain: the pitch hinges on the idea that a functionally equivalent reimplementation is “legally distinct,” but whether such output avoids becoming a copyright-infringing derivative work is unresolved, jurisdiction-dependent, and risky—especially if the goal is explicitly to dodge open-source obligations.

What Malus Means by “Clean Room as a Service”

“Clean room” is a loaded phrase in software. Traditionally, it refers to independent reimplementation: one team documents what a program does, and another team—kept separate from the original source—writes new code that matches the behavior. Malus borrows this framing and adds AI as the engine.

On its site, “MALUS — Clean Room as a Service” presents itself as a commercial offering that provides “liberation from open source license obligations,” including explicit callouts to Apache-2.0, MIT, and AGPL-3.0 as “problem” licenses. The message is blunt: companies can keep shipping proprietary software without attribution or copyleft obligations—“No attribution. No copyleft. No problems.”

The tone, however, is conspicuously provocative and contains artifacts that observers have taken as satirical or at least not fully production-real: counters on the site read “0 Projects Processed / 0 Active Clients / $0 Attribution Given,” and badges lean into the bit (“Robot-Reconstructed · Zero Attribution”). That ambiguity—startup landing page or commentary performance—matters, because it affects how literally to take the claims. But the underlying idea is real enough to surface hard questions about AI, code generation, and open-source compliance.

How the Technical Pitch Works (in Plain Terms)

Malus’s core claim is that its proprietary AI “robots” can independently recreate any open source project from scratch, producing “legally distinct code.”

The process is presented roughly like this:

• A customer supplies dependency information—illustrated with JSON-like examples that show popular packages swapped for prefixed alternatives (e.g., react → m-react, lodash → m-lodash, express → m-express).
• The system then uses documentation, API specifications, types, and public interfaces to synthesize a replacement implementation.
• The company emphasizes separation from the original codebase with a key promise: the AI has “never seen the original source code.”
• The output is delivered under a “corporate-friendly” license—implying permissive or proprietary terms (the site includes stylized labels like “MC-0 Pass ✓” and references such as “MalusCorp-0” in the surrounding framing).

Conceptually, it’s a form of automated reimplementation: rebuild the dependency so you can stop distributing (or depending on) the original project—and therefore stop following its license terms.

Whether that works depends on what you mean by “works.” From a purely engineering perspective, building a “drop-in” compatible library may be feasible in many cases. From a legal perspective, functional equivalence is not the same thing as legal safety.

Why This Attracts Attention—and Skepticism

The appeal is easy to understand. Malus markets directly to a long-standing corporate anxiety: “license contamination” and compliance overhead. If you could swap out an AGPL-3.0 dependency (which Malus cites explicitly) for a “clean” replacement, you could avoid complex debates about what copyleft obligations attach and when. Likewise, even permissive licenses like MIT and Apache-2.0 come with obligations (notably attribution and notices) that some organizations find operationally annoying.

But the skepticism is just as straightforward:

• Legal uncertainty: Even if the code is newly generated, it may still be considered infringing if it reproduces protected expression—especially if the result is extremely close in structure, sequence, and organization.
• AI-specific doubt: “Never saw the original source” is a big claim, and it’s hard to audit in practice without strong provenance and process controls.
• Credibility questions: The site’s own “0 projects processed” posture and the deliberately provocative language have led to commentary describing it as satire or at least a provocation rather than a battle-tested legal product. Simon Willison, for example, flagged the project in that context (see his post in the sources below).

The net effect: Malus has ignited attention precisely because it compresses a complicated debate into a single tempting promise—then dares everyone to argue with it.

The Core Legal Risks and Uncertainties

Malus’s marketing implicitly relies on a narrow idea: that if you don’t copy source code, you’re safe. The problem is that copyright disputes in software don’t always turn solely on literal copy/paste.

Key uncertainties raised by the material and commentary include:

• Derivative work questions are unresolved. Whether a functionally equivalent reimplementation is a derivative work depends on jurisdiction and on what a court considers protected expression versus unprotected ideas, interfaces, and functionality.
• Licenses govern copyrighted code, not pure “function.” Open-source licenses apply to distributing copyrighted material. But a “clean-room” reimplementation that mirrors more than functionality—e.g., replicating expressive choices—can still raise infringement risk even if it’s not a line-for-line copy.
• AI complicates provenance. Courts and policymakers are still grappling with how to evaluate AI-generated outputs, including concerns about memorization and whether a “clean-room” claim meaningfully prevents copying when a model could have been influenced elsewhere.
• “Legal shields” aren’t magic. The research brief notes that indemnities and offshore structures are not foolproof: even if a vendor promises protection, litigation risk, reputational harm, and scrutiny can still land on customers.

The most important practical takeaway is intent: using AI reimplementation specifically to evade license obligations doesn’t make the risk go away—it can make the scrutiny sharper.

Why It Matters Now

This is timely because Malus’s March 2026 pitch—and the rapid wave of reactions calling it provocative or satirical—puts a spotlight on a broader reality: companies are adopting AI tools for code generation faster than legal clarity is arriving.

Even if Malus itself never processes a single real client, the idea it dramatizes is already present in boardrooms and engineering teams: “Can we use AI to get the benefits of open source without the obligations?”

At the same time, the legal regime is in flux. The research brief emphasizes that courts and lawmakers are actively grappling with how AI-generated code relates to copyright and derivative works. That gap between technical capability (generate code quickly) and legal certainty (what obligations attach) is exactly where risky policy decisions get made.

For a broader view on how agents and developer tooling are evolving right now, see Today’s TechScan: Agents Speak UI, Thread‑safe Networking, and a few surprises.

Practical Steps Developers and Legal Teams Should Take

If someone proposes “recreated dependencies” as an escape hatch, treat it as high-risk until proven otherwise.

Concrete steps suggested by the risks highlighted in the brief:

• Don’t treat “AI clean room” as a compliance shortcut. Assume the legal question is unsettled and could turn on facts you can’t confidently verify (training, memorization, similarity, process).
• Keep doing the unglamorous work: dependency tracking, SBOMs, license scanning, and legal review—especially for strong copyleft licenses like AGPL and GPL variants (AGPL is explicitly part of Malus’s pitch).
• If you explore reimplementation, document rigorously. “Clean-room” claims live or die on process evidence: what inputs were used (docs, APIs), what was excluded (original source), and how provenance was logged.
• Plan for reputational impact. Even if a strategy is arguable legally, being perceived as evading open-source obligations can damage developer trust and customer confidence.
• Read vendor promises skeptically. Warranties and indemnities can help, but the brief cautions they aren’t a complete shield.

What to Watch

• Early litigation or guidance that clarifies when independently generated, functionally equivalent implementations are treated as derivative works.
• Jurisdictional moves (US/EU/UK) on AI, copyright, and generated code—especially rules that change how “clean-room” claims are evaluated.
• Evidence about memorization and provenance that could undermine “never saw the original source” narratives.
• Industry and ecosystem responses: open-source foundations, package registries, and community norms that could label, restrict, or reject “reconstructed” packages.
• Whether Malus evolves from provocation to production—and how customers and counsel react if it does.

---

Sources: https://malus.sh/ ; https://letsdatascience.com/news/malus-provides-clean-room-recreated-open-source-code-6edac75b ; https://conzit.com/post/maluscorps-clean-room-a-controversial-software-liberation-service ; https://sesamedisk.com/malus-clean-room-open-source-licensing/ ; https://simonwillison.net/2026/Mar/12/malus/ ; https://abit.ee/en/artificial-intelligence/ai-open-source-gpl-licence-derivative-work-copyright-generative-ai-code-open-source-law-en