Article

Open Source Does Not Mean Open Door

A plain English guide for lawyers on what open source really is, why it is already everywhere, why an open model can be safer than a closed one, and the better questions to ask any vendor.

In November 2025 the High Court handed down its judgment in Getty Images v Stability AI [2025] EWHC 2863 (Ch), the first major English ruling on generative AI. The copyright analysis got the headlines. But one phrase travelled much further than the legal detail: "open source AI model". Stable Diffusion, the model at the centre of the case, was described throughout as open source, available for anyone to download, and that description appeared in every summary and news story that followed.

Since then we have noticed something in conversations with law firms and other professional services businesses. The phrase has stuck, and it has stuck with the wrong meaning. To many people outside software, open source sounds like a warning. Open sounds like exposed. If the model is open, surely our data is open too?

That instinct is understandable, and it is wrong. It is also starting to shape real procurement decisions, so it is worth taking apart properly.

What open source actually means

All software starts life as source code: the human readable instructions that programmers write. Open source simply means that this code is published under a licence which allows anyone to read it, run it, change it and share it. That is the whole definition.

Notice what the definition covers: the code. Notice what it does not cover: your data. Open source describes how software is made and distributed. It says nothing about where your documents go when you use it. Running open source software on your own systems no more publishes your files than citing a public statute publishes your client file.

Lawyers should find the underlying idea familiar, because the law itself works this way. Legislation and judgments are published precisely so that anyone can read them, test them, argue about them and build on them. Centuries of open scrutiny is what makes precedent trustworthy. Nobody suggests that publishing case law makes legal advice insecure. Open source applies the same logic to software: trust built through visibility rather than secrecy.

It is also worth saying that open source is not the absence of rules. It is a body of licences. Some are permissive, some carry strict conditions, and those conditions are enforceable. Open source is not anarchy. It is contract.

You are already running on it

Open source is not a niche choice made by enthusiasts. It is the substrate of modern computing. Black Duck's 2025 Open Source Security and Risk Analysis, an annual audit of real commercial software, found open source components in 97% of the codebases it examined. On average, around 70% of the code in a commercial application is open source in origin, and a typical application contains over 900 open source components.

You touch it constantly. Android is built on the open source Linux kernel. Chrome and Microsoft Edge are built on the open source Chromium engine. The encryption behind the padlock in your browser, the one protecting your online banking, is open source. Most of the servers running the internet run Linux. The cloud platforms your firm relies on, and the practice management systems sitting on top of them, are assembled largely from open components. Microsoft, Google and Amazon are among the biggest contributors to open source in the world, because their own products depend on it.

If open source were inherently unsafe, online banking would not exist. Neither would most of the internet.

Where the fear comes from

The confusion usually comes from collapsing three different ideas into one.

The first is the idea that visible code means visible data. It does not. Publishing the recipe does not put your dinner in the street. What matters for your data is where the software runs and who operates it, and that question applies equally to open and closed software.

The second is the idea that if anyone can modify the code, someone can tamper with your copy. They cannot. Anyone can modify their own copy. Changes to the official version of a serious open source project go through review by named maintainers, in public, with a permanent record of who changed what and why. Compare that with a closed product, where changes happen behind a wall and you learn about them, if at all, from release notes.

The third is the idea that open means amateur or unsupported. In reality, much of the world's most important open source is written and maintained by paid engineers at large companies, and commercial support for open source is a mature industry in its own right.

Then there is the judgment itself. When the court and the coverage described Stable Diffusion as open source, they were describing how the model was distributed: its weights had been made available for anyone to download. It was not a finding about safety. In fact, the court's central copyright finding points the other way. Assisted by expert evidence, the court held that the model's weights never stored copies of the images used in training, which is why the model could not be an "infringing copy". That finding is under appeal, but the irony stands. The case that put "open source AI" into everyone's vocabulary examined an openly distributed model in forensic detail and found it did not contain the data people assume such models must be carrying around.

What "open" means for an AI model

An AI model is not a normal program. The valuable part is the weights: billions of numbers produced during training which together encode what the model has learned. When people say a model is open, they almost always mean the weights are published and anyone can download and run them.

Strictly speaking, that is "open weights" rather than open source. The Open Source Initiative, the body that stewards the definition of open source, published a definition for AI in late 2024, and it demands more: the code, the weights and meaningful detail about the training data. Very few well known models meet that bar. Meta's Llama models, for example, ship with commercial restrictions that a true open source licence would not permit. So when a vendor says "open source model", the right response is one lawyers already know well: read the licence.

For the safety question, though, the practical point survives the terminology. A model whose weights you can download is a model you can run entirely on infrastructure you control: your own servers, or your own private cloud environment. Your prompts, your documents and the model's outputs never leave that environment. There is no third party processing your client data, no vendor retention policy to diligence, no chain of sub-processors to trace. Confidentiality is protected by architecture, not only by contract. This is exactly why banks, governments and defence organisations often prefer self-hosted open models for their most sensitive work. That is roughly the opposite of the "open means leaky" assumption.

One honest caveat. Running your own model means you own the operational security, and done badly, self-hosting is worse than a well run vendor. The point is not that open models are magically safe. The point is that openness gives you options and control that closed systems structurally cannot.

The closed source question

Now turn the question around. With closed, proprietary software, what do you actually know?

You know what the vendor tells you. You know what the contract says. And you probably know the vendor holds certificates: SOC 2, ISO 27001 and so on. Those certificates matter, but be precise about what they are. They attest that an organisation has defined processes and controls, assessed within a scope the organisation itself chose, often at a point in time, by an auditor the organisation pays. They are not a line-by-line review of the product's code, and they are not a warranty that the software is free of flaws. Lawyers, of all people, understand the difference between a representation about process and a guarantee about outcome. A certificate is much closer to the former, yet in procurement it is routinely treated as the latter.

Meanwhile, the code itself is invisible. You cannot inspect it. Independent researchers cannot inspect it. When something goes wrong inside it, you find out when the vendor chooses to tell you, or when the breach notification arrives.

This is not a theoretical concern. SolarWinds was closed, certified, enterprise software. Attackers compromised its build process and shipped a poisoned update to roughly 18,000 customers, none of whom had any way to look inside it. MOVEit was a closed file transfer product trusted by thousands of organisations, including law firms, until a single flaw in it was exploited at scale in 2023. Closed did not mean safe. It meant nobody outside the vendor could check.

Open source has its own failures, and it would be dishonest to pretend otherwise. The Log4Shell vulnerability sat in a widely used open library for years before it was found in 2021, and audits consistently show that most commercial codebases contain outdated open components that nobody has patched. But notice how these stories end. Log4Shell was analysed, fixed and independently verifiable in public within days. In 2024, an attempted backdoor in the open source xz library was caught by a single engineer who noticed something slightly off, went and looked at the code, and raised the alarm before the compromised version reached mainstream systems. Openness did not prevent the attack. Openness is what caught it.

Neither model is automatically safe. The real difference is simple. Open source gives you, and the whole world, the ability to verify. Closed source gives you a promise.

Better questions than "is it open source?"

Whether a tool is open or closed tells you very little on its own. These questions tell you far more. Where does our data go, and on whose infrastructure does it sit? Who can access it? Can we, or anyone independent, inspect what the software actually does, or are we relying entirely on the vendor's representations? Who maintains it, and how quickly are flaws fixed? And what, precisely, does that certificate cover?

Ask those questions of every tool you buy, open or closed, and the answers will do more for your risk register than any label ever will.

Open source is not a risk category. It is a transparency model, and it is one the legal profession should recognise instantly, because it is how the law itself earns trust: publish, expose to scrutiny, improve in the open. Treat "open" as an invitation to inspect, not a warning sign. The things genuinely worth worrying about, where your data flows, who controls the infrastructure, and what you can verify, apply to every piece of software you use. The label just tells you whether you are allowed to look.


Talk to a conductor

Got a build that’s quietly stalling?

We do a free 30-minute review. No pitch deck. We’ll tell you whether it’s a fit or whether you’re better off with someone else.

Book a call →

Khiliad Team