The legal technique known as clean room development has been around since at least the early 1980s. Phoenix Technologies used it to clone IBM’s BIOS. Compaq documented it in meticulous detail when building their XT-compatible machines. Wine has spent three decades applying it to the Windows API. The principle is always the same: you study a system’s behavior from the outside, write a specification, hand that specification to engineers who have never seen the original source, and let them implement. The result is legally distinct from the original, because it derives from a description of behavior rather than a copy of expression.
What Malus is proposing, as discussed at FOSDEM 2026, is to make that process a service. Clean Room as a Service. The idea is to take the organizational, evidentiary, and procedural overhead of running a defensible clean room and turn it into something you can subscribe to.
That sounds like a modest product announcement. It is not.
The Mechanics That Make This Hard
Clean room development works legally because copyright protects expression, not ideas or behavior. The specification that bridges the two teams captures the latter without the former. But maintaining a defensible clean room is genuinely difficult in practice, and that difficulty is mostly organizational rather than technical.
The classic two-team structure requires strict separation. Team A analyzes the original software, its APIs, its observable behavior, its file formats, its network protocols. They write a specification. Team B reads the specification and implements it. Team B members must never have seen the original source code, ideally have never worked at the company that wrote it, and must not have access to Team A’s intermediate working notes. If even one Team B engineer has read the original source, the Chinese wall collapses and the legal defense with it.
Keeping that wall intact over months or years of development requires process. You need access logs, legal attestations, personnel tracking, documentation of who reviewed what and when. If someone switches teams, their status changes. If a contractor was previously employed somewhere relevant, their involvement needs to be managed. Any court challenge will examine these records. Gaps are exploited.
This overhead has historically made clean room development expensive enough that it was reserved for high-stakes scenarios: cloning a proprietary hardware interface to break a monopoly, reimplementing a platform API to achieve compatibility, or defending against an infringement claim by demonstrating independent creation. Wine, which implements the Windows API across tens of thousands of functions, has sustained this process for decades partly because it is a large volunteer project with a long institutional memory and explicit legal guidance.
For a smaller team trying to build a compatible reimplementation of some proprietary software, the overhead is often prohibitive. You need legal counsel, you need process tooling, and you need someone whose job it is to maintain the wall.
What a Service Changes
If Malus provides the infrastructure, the tracking, the attestation, and the legal process as managed services, the barrier drops substantially. A team that wants to build a clean room reimplementation of some proprietary service no longer needs to design its own separation protocols from scratch. It can outsource the evidentiary and organizational machinery to a provider whose entire business model is making that machinery reliable and court-defensible.
This is the same pattern that changed other previously expert-only domains. Certificate authorities made TLS accessible. Stripe made payment processing accessible. If clean room compliance becomes a subscription service with a clear audit trail and legal guarantees, the number of teams willing and able to undertake reimplementations goes up significantly.
The FOSDEM 2026 talk connected to Malus carries a title in the neighborhood of “Let’s end open source,” which is deliberately provocative framing for what is actually a sharper argument: that copyleft licensing, particularly the Affero GPL, may not survive the widespread availability of managed clean room services.
The Copyleft Angle
Copyleft depends on a specific legal mechanism. If you distribute a modified version of GPL-licensed software, you must distribute the source under the same license. The AGPL extends this to network use: if you run modified AGPL software as a service, you must still share the source. This was designed to close the “SaaS loophole” that let companies like Amazon take GPL code, modify it, and run it as a cloud service without contributing back.
Clean room reimplementation bypasses this entirely, because a clean room reimplement is not a derivative work of the original. It is a new work that happens to be compatible. Wine is not a derived work of Windows. It implements the Windows API specification from behavioral observation. Microsoft cannot use GPL-style licensing on Windows to stop Wine, because Wine does not contain Windows code.
The same logic applies to any software, including AGPL software. If you observe the behavior of an AGPL-licensed service, write a complete specification of that behavior, and implement from the specification, you have produced something that competes with the original without triggering any copyleft obligation. You can license your reimplementation however you choose.
This has always been true in theory. The Oracle v. Google litigation, which concluded with the Supreme Court ruling in Google’s favor on fair use grounds in 2021, touched adjacent territory: whether APIs can be copyrighted and whether reimplementing them constitutes infringement. The ruling was narrow and the fair use analysis was fact-specific, but the broader principle, that functional specifications describing behavior rather than expression occupy different legal territory than the original code, was not seriously challenged.
What has kept this from being a widespread problem for copyleft projects is the cost and complexity of the clean room process. Lower that cost, and you change the economics.
Historical Precedents Worth Examining
The IBM BIOS clone era is instructive. In 1981, IBM shipped the PC with a proprietary BIOS. Phoenix Technologies, Award Software, and AMI all developed compatible BIOS implementations using clean room methods. By 1984, the PC-compatible clone market existed, IBM’s hardware monopoly was broken, and the entire personal computing industry was reshaped. IBM’s decision to use off-the-shelf components and an open architecture backfired specifically because clean room development made the BIOS clonable.
IBM responded not by suing Phoenix out of existence but by developing the Micro Channel Architecture for PS/2 machines, a proprietary bus that was harder to clone, and by making the BIOS itself less central through EISA and later standards. The technical response to clean room reimplementation was to move to protocols and formats that were harder to specify and reimplement, not obfuscation exactly, but complexity and moving targets.
You can expect similar responses if managed clean room services lower the barrier to reimplementation significantly. Projects relying on AGPL for protection may invest more heavily in network effects, data moats, and integrations that are hard to replicate from behavioral observation alone, rather than relying on licensing to maintain competitive position.
What This Means in Practice
For systems programming and infrastructure software, the most immediate implication is that the copyleft protection layer that some projects use as a business model becomes thinner. Databases, messaging systems, observability platforms: several of these switched from permissive to AGPL or Server Side Public License specifically to prevent cloud providers from running the software as a service without contributing. A managed clean room service does not automatically make those reimplementations easy, because the implementation work is still substantial, but it removes one organizational barrier.
For smaller open source projects, the change is probably minimal. No one is going to pay for clean room reimplementation of a niche tool with a few thousand users. The economics only work when the target software has significant commercial value.
For the broader open source ecosystem, the more interesting question is whether this accelerates a shift in how projects think about sustainability. If licensing-based protection becomes harder to rely on, the conversation moves further toward community, documentation, integrations, and trust as the actual moat. Some projects are already there; SQLite’s approach, which involves explicit public domain dedication and a focus on reliability as the competitive advantage, is immune to this kind of pressure entirely.
Malus is a product announcement and a legal service. It is also a test of whether a specific theory of open source protection holds under different market conditions. The clean room technique is not new. Making it accessible and auditable as a subscription might be.
The FOSDEM framing is provocative, but the underlying observation is precise: copyleft licenses protect against derivative works, and a sufficiently disciplined reimplementation is not a derivative work. The question is whether the friction of doing that properly has been the main thing keeping it rare.