What's the difference between open source and open weights?

Open weights means: the trained model parameters are freely downloadable and usable – the model runs on your own hardware. True open source would additionally include the training data, training code and recipe, so the model would be reproducible. Almost all “open” AI models are only the former: usable, but not reproducible. For practical purposes, that's often enough – for terminological honesty, it isn't.

Am I allowed to use open models commercially?

Usually yes, but never without checking: licences range from genuine freedom (Apache 2.0, MIT) through community licences with conditions to clauses that exclude certain user sizes or use cases. Before production deployment, the specific model licence belongs on the table – “open” in the name is not a legal opinion.

What's the difference between a quantised model and the original?

Quantisation shrinks a model after the fact by reducing the precision of its numerical values – the model then needs significantly less memory and runs on weaker hardware, but loses some quality in the process. For many everyday tasks, the difference is barely noticeable; for demanding reasoning or edge cases, it can become noticeable. Anyone deploying heavily quantised models should check that on their own test cases rather than relying on vendor claims alone.

Can I fine-tune an open model on my own data?

For most open models, yes – that's one of their biggest practical advantages over closed models. It's important to check the licence beforehand for whether fine-tuned derivatives are subject to the same conditions as the original model – some community licences regulate this explicitly. Technically, fine-tuning needs a curated data set and some test runs, but by now it's well accessible with standard tools.

How do I tell whether an open model is trustworthy?

By three signals: a well-maintained model card with details on training data, known weaknesses and recommended usage limits; an active community or lab that's visibly still publishing updates; and reproducibility of the advertised performance figures in independent tests, not just the vendor's own benchmarks. If all three are missing, extra caution is warranted before production deployment.

Technology · Models & tools

Open-Weight Models: What “Open” Really Means in AI

Open-weight vs. open source in AI: the three levels of openness, a licence comparison, the most common mistakes, and a checklist before deployment.

By Boaz Lichtenstein

Article image: Open-Weight Models: What “Open” Really Means in AI

Hardly any term in the AI world gets stretched more than “open source” – and hardly any gets used more loosely. When a lab releases its model as “open”, it almost always means the weights: the billions of trained parameters you can download and run yourself. That’s valuable – but it’s something different from open source in the classic sense. Knowing the differences leads to better decisions.

Key takeaways

“Open” in AI models almost always just means open weights – usable, but not reproducible, because the training data and recipe are missing.
Openness is a spectrum of three levels: open weights, an open recipe, and, cutting across both, the specific licence.
Licences range from genuine freedom (Apache/MIT) to conditions that exclude certain user sizes or purposes.
Open models deliver data sovereignty, cost control under sustained load, and independence from price rises – with a shrinking, but real, quality gap to the top.
Before production use, the licence, model card and data provenance all belong on the table – “open” in the name is not a legal opinion.

The three levels of openness

Level 1 – open weights: The model is usable, runnable locally, fine-tunable. What’s missing: the training data and recipe. You can run the model, but not reproduce or fully audit it – the norm for almost all prominent “open” models. Level 2 – open recipe: Training code and data documentation on top of that; rare, mostly from research and non-profit projects. Level 3 – the licence question, cutting across both: Even open weights come with very different rights attached – from genuine freedom (Apache/MIT) to community licences with usage conditions. So “open” doesn’t describe a category, but a spectrum – and it’s worth knowing where a model sits on it before you build on it.

Why does level 2 stay so rare? Disclosing training data in full breadth means, for most labs, exposing their own competitive advantages and potential legal risks (for instance around copyrighted training material) – economically unattractive as long as level 1 delivers the same practical benefit without taking on those risks. For users, that means: anyone who needs real traceability – for a research paper, say, or a regulatorily sensitive application – has to specifically search out the few models with an open recipe, rather than relying on the label “open” alone.

Comparison: popular open licence types at a glance

Not every “open” licence permits the same thing – this rough breakdown shows what to look for at first glance in a licence.

Licence type	Commercial use	Typical conditions	Character
Permissive (Apache 2.0, MIT)	Unrestricted	Almost none, usually just attribution	Genuine freedom
Community licence with a user cap	Allowed up to a user/revenue threshold	Large companies need a separate licence	Common among big labs
Research licence	Usually non-commercial only	Commercial use excluded or separately licensable	Academic in character
Restricted-use licence	Certain use cases excluded	Prohibition clauses for specific industries or purposes	Rare, but does occur

Important: licence terms change between model versions – a model permissively licensed in version 1 can appear under a more restrictive community licence in version 2. Before every production deployment, the licence should therefore be checked again, not just once at the first download.

An example: the same task, two licences

Two fictional but typical cases show why the licence question belongs before the technical decision, not after.

Case A – small team: A five-person startup wants to deploy an open model for internal document search. The model is under a community licence with a user cap far above the company’s own size – in this case, the licence is, in effect, as free as a permissive one. Case B – growing company: Same starting point, but the team grows past the threshold defined in the licence, say through a merger or strong growth. From that moment on, the user cap kicks in, and a separate, usually paid licence becomes necessary – a circumstance that’s easily overlooked at the original model setup, because it wasn’t relevant yet at the start.

The lesson from both cases: a licence check isn’t a one-off tick at project start, but a condition that can change with company size. Anyone growing should periodically revisit the licence questions of the models they use – not only once a provider points it out.

Why open models are a gift nonetheless

For practical purposes, what matters is what open weights make possible – and that’s a lot: data sovereignty (running in-house, no prompts sent to third parties – the argument from our article on local AI vs. cloud), cost control under sustained load, adaptability through fine-tuning for your own tasks, independence from price rises and model discontinuations. On top of that, the ecosystem effect: open models have a worldwide tinkerer and research scene delivering quantisations, tools and specialised variants that no single provider would ever build. The quality gap to the best proprietary models still exists – but it’s shrinking in waves, and for many standard tasks it’s long since become irrelevant.

The most common mistakes with open models

Confusing “open” with “unrestricted use”: The name suggests more freedom than the specific licence actually grants. Fix: actually read the licence text, not just the “open” label.

Ignoring the model card: Known weaknesses, training data provenance and recommended usage limits get skipped over. Fix: go through the model card before deployment like a data sheet.

Assuming a quantised version is equal in quality: A heavily shrunk variant gets treated like the original model without checking. Fix: check quality against your own test cases, not marketing claims.

No update strategy: Nobody is responsible when a vulnerability in the model becomes known. Fix: clarify responsibility and update cadence before going into production.

Licence checked only once: When a model updates, the new licence doesn’t get re-checked. Fix: anchor a licence check as a fixed step at every version change.

Checklist before deploying an open model

Identify the licence type and match it against the intended use.
Check the model card for known weaknesses and training data provenance.
Check quality against your own test cases, not benchmark numbers alone.
Determine the quantisation level for the target hardware.
Clarify the update cycle and responsibility within the team.
Match privacy and security requirements against self-hosting.

The decision logic

Three questions sort out the deployment: is the task standardisable enough for an open model (classification, extraction, summarisation: usually yes; open-ended research and top-tier reasoning: probably not)? Are data or cost the driving argument for self-hosting? And does the licence permit the specific case? Anyone who can answer “yes” twice and “checked” once often does better with open weights – and, with the router pattern (simple stays local, complex goes to the cloud), keeps the best of both worlds.

From experience: the most pragmatic way in is rarely the search for the “best” open model overall, but the search for the best model for one specific task, tested on three to five real examples. Benchmark leaderboards are a good first filter, but rarely measure exactly what matters for your own use case – a model that performs middlingly on general tests can still be the better choice for a narrowly defined task like invoice classification, if it performs cleanly enough there and the licence suits the company.

The bottom line

“Open” is a promise with small print when it comes to AI models – valuable, but not unconditional. Anyone who knows the three levels of openness, checks the licence before every deployment, and works through the checklist once, uses exactly the freedom that open models actually offer: data sovereignty, cost control, independence – without being caught off guard by the confusion around “open source” once it’s about law or liability.