On "open source" in Munir: a precision matter.

Some readers of Munir v SSHD [2026] UKUT 81 have moved from "public AI services destroy privilege" to "open-source AI destroys privilege" in one step. This is a category error, driven by an ambiguity in the phrase "open source". The judgment is about where data goes, not what licence the code carries. The architectural answer is open code, self-hosted inference, no public egress.

Last week, on Will Chen's LinkedIn post about Mike, a thoughtful commenter — Jeff Dutton — flagged a worry that I think is going to surface again and again as the legal-tech press digests Munir. The worry is roughly this:

If Munir says public AI destroys privilege, and Mike (or Donna, or any other open-source legal AI) is "open source", then doesn't Munir capture the open-source category too? Aren't we back to the same problem?

It's the right instinct — Munir is unusually consequential and worth reading carefully — but the worry rests on a slip of language. The phrase "open source" denotes at least two distinct things in popular discourse, and the case is about one of them, not the other.

What Munir actually held

The Upper Tribunal ruled, at [37]–[41], that uploading client material to a public AI service amounts to placing that information on the internet in the public domain, and thus to a breach of client confidentiality and a waiver of legal privilege. The supervising solicitor was referred to the SRA. The firm was referred to the ICO. Privilege was treated as gone — not suspended, not contingent, not curable by undertaking — but gone, in respect of the material that had been uploaded.

The Tribunal also did something quieter but architecturally important. At [38], it expressly distinguished between two categories of AI tooling:

The structural point is about where the data goes, not about who wrote the code or under what licence. Munir's ratio is a data-flow proposition, not a licence-of-source proposition. The Tribunal's lazy phrase "closed-source" in the second clause has caused some of the confusion, because it sounds like a statement about source code. It isn't.

The slip in "open source"

In popular discourse, "open source" can mean any of the following — and they are not the same thing:

• Open data — the model was trained on, or has access to, publicly available data. This is the sense in which a "public AI service" is sometimes loosely called "open" — its inputs are public, its outputs are produced from public material, and (importantly) the data you put into it is not protected.
• Open code — the source code of the AI tool is published under a permissive or copyleft licence. Anyone can read it, modify it, run it. This is the standard meaning in software engineering.
• Open service — the running endpoint is publicly reachable. Anyone with an API key can hit it; the operator retains rights to inspect, store, or train on submitted content.

Munir is about category 3 — the service. The solicitor in Munir was using a consumer-facing public AI assistant. The data left the firm. The data went to a third party with rights (express or implicit) to retain and inspect.

Mike, Donna, and any other AGPL-3.0 legal-AI project sit in category 2. The code is open. Where the running inference happens is a separate question. If the firm clones the repository, runs the model on its own GPUs, and never lets data egress to a third-party API, no part of Munir's ratio is engaged. The data has not been disclosed to the public domain. Privilege is preserved, because nothing left the firm.

The architectural answer to Munir, in plain English, is: open code, self-hosted inference, no public egress. Each clause does work the others cannot do.

Why open code matters here

A reader might ask: if Munir is about the running service, why open the code at all? The closed-source answer (Harvey, Legora) is also compatible with the architectural pattern Munir describes — those vendors run inside firms' tenant infrastructure, on closed-source codebases, and Munir's ratio is satisfied.

Three reasons open code matters in this moment:

1. Verifiability of the audit chain. When the engine that signs and chains decisions is open, the regulator does not have to trust the firm or the vendor — the regulator can run the verifier independently. Closed-source verifiers are an "extraordinary claims" problem.
2. No vendor lock-in for the firm. A firm running a closed-source legal-AI stack today is making a 5-year decision under conditions of unusual regulatory uncertainty. Open code preserves the firm's optionality if the regulator's view of the technology shifts.
3. Architectural dialogue with the bar. The next case after Munir will probably ask the bar to specify what an acceptable closed-source AI tool looks like in detail. That conversation is going to need open-protocol references for terms of art (audit chain, tamper-evidence, replay) that bar bodies do not yet have shared definitions for. Open protocols — like our happi.md v1.1 — let the dialogue happen at the right level of specificity.

What this means for the legal-tech press

When Munir gets summarised for general legal audiences, expect to see headlines that conflate "public AI" and "open-source AI". The conflation is understandable — both phrases are casual, both invoke a sense of "something that's not under the firm's control". The conflation is also wrong, and it matters, because the architectural answer to Munir is precisely a kind of AI tooling that is open in code and closed in service. Misreading Munir as a blanket prohibition on open-source legal AI would push firms toward exactly the closed-source vendor lock-in pattern that is the worst long-term position to be in under EU AI Act compliance scrutiny from August.

The line we'd offer the press, to be cited or quoted as helpful:

Munir is about where client data goes, not what licence the AI code carries. The architectural answer is open code, self-hosted inference, no public egress. DONNA is built for that answer.

Adjacent layers — what others are building

The architectural answer to Munir is not just DONNA. It is the converging shape of how the legal-tech category is responding. Worth naming a few of the projects building toward the same answer at adjacent layers, because no one product is the whole story:

• Document drafting — Mike (Will Chen, AGPL-3.0). The draft / summarise / redline layer, open-source. Pairs naturally with self-hosted inference (Joseph Breda's PR #20) for firms that need Munir-compliant document generation inside their perimeter.
• Document search + retrieval — CloseVector (Dean Hoffman). On-premises AI document search with cryptographic verification of every retrieval. Patent pending; proprietary. The architectural pattern is the same audit-chain primitive applied at the search layer: "Every search produces results and a defensible record of methodology." CloseVector validates the broader thesis — that audit chains for AI use in regulated practice are now table stakes, not future-state.
• Knowledge research — Omnilex (Ismael Seck & Marco Henri). Zurich-built legal-research engine focused on DACH legal systems. Raised USD 4.5M in November 2025.
• Open audit-chain protocol — happi.md v1.1. The protocol DONNA implements; the protocol any audit-chain implementation can read.

These projects do different things. They share an architectural insight: audit chain at every layer where an AI made a decision the firm has to defend. CloseVector audits retrieval; DONNA audits delegation. Different surfaces, same answer to the same regulator.

We say so explicitly because the post-Munir story is going to be told as "DONNA versus X" in some places, and that framing misses what is actually happening. The shape of the category is settling, in real time, around the audit-chain primitive. The firms that adopt it now are getting a 2026 architecture for a 2026 regulatory environment. The firms that wait are positioning themselves for the next Munir, with the same architecture, two years late.

What DONNA does about it

DONNA's voice surface, MCP server, skill files, HAL provider abstraction, and AGORA pattern all ship under AGPL-3.0. The cryptographic engine that signs and chains every delegated decision — the IDR (Intent Decision Record) primitive — is the substrate of our NEXUS tier. The protocol is open at happi.md v1.1; the engine that implements it is licensed.

In Munir's vocabulary: open code, self-hosted, no public egress. In our vocabulary: Donna probat — Donna proves it. The verb is the brand. The structural property is the substance.