Open Weights or Open Source? How to Audit an LLM Licence

Open Weights Is Not Open Source

If you are comparing open-source LLMs, start with the licensing question: which models can you download, run, adapt and ship under terms that fit your use case? That question, not a leaderboard position, is usually what people mean when they ask which open source LLM is best.

Here is the short answer, up front. "Open weights" and "open source" are not the same claim. A model whose parameters you can download may still carry a bespoke licence with naming duties, scale conditions, behavioural restrictions or a separate acceptable use policy. Whether any particular model qualifies as open source depends on the words in its licence file — not on the launch post, not on a leaderboard, and not on a news summary.

Downloadable, free to use and open source are three different claims. Downloadable means the weights are obtainable, possibly after accepting terms or requesting access. Free to use means you owe no fee, which says nothing about redistribution, modification or field-of-use limits. Open source is a claim about the licence granting a specific set of freedoms, judged against published criteria maintained by an outside body. Check which of the three you are actually being offered before development starts, because naming duties, output restrictions or scale conditions are expensive to discover after launch.

This article is a framework rather than a ranking. NewsForge has not, for this piece, retrieved and dated the current official licence file, model card and acceptable use policy for each prominent model family, and no verdict should be published without pointing to the clause that supports it. What follows is the audit method — the yardstick, the four layers, the licence archetypes and one workflow with one scorecard — so the answer you reach is yours, sourced and dated. It is journalism and general information, not legal advice; nothing below substitutes for review by a qualified lawyer against your specific deployment.

The Yardstick: Recognised Criteria for Calling Software and Models Open

To judge openness without simply asserting an opinion, you need a yardstick maintained by someone other than the model's publisher.

The Open Source Definition and its core freedoms

For software, the widely referenced yardstick is the Open Source Definition, maintained by the Open Source Initiative (OSI), which also operates an approval process for licences that meet it.

This article does not reproduce the definition's clause text, because quoting a controlling document from memory is how inaccurate summaries enter circulation. Open the current version on the OSI's own site, note its version and the date you read it, and treat that text as authoritative over any paraphrase, including this one.

What the definition covers, in outline, is a set of freedoms: to use, study, modify and redistribute software, including for commercial purposes. It also addresses discrimination: the definition includes a criterion directed at restrictions on fields of endeavour.

How model-specific definitions handle weights, data and code

Software definitions were not written with trained model artefacts in mind. The OSI has separately published an Open Source AI Definition addressing what an AI system must make available to be called open source — covering model parameters, code, and information about training data.

The precise obligations depend on that definition's published wording and version, and they are not interchangeable with the software criteria. In particular, whether a release must publish the training dataset itself, or information about it sufficient for a skilled person to recreate a substantially equivalent system, is exactly the distinction a paraphrase gets wrong. Read the current published version and quote from it directly if you are making a public openness claim about your own work.

Field-of-use restrictions: the standards question and the marketing question

These are two different arguments, and conflating them causes confusion in openness debates.

The standards question is not especially unsettled. The Open Source Definition contains a criterion prohibiting discrimination against fields of endeavour. A licence that forbids use in a named sector or application area sits in direct tension with that criterion. That is a conclusion drawn from the definition's own text, and you can verify it by reading the relevant criterion in the current version.

The marketing question is where the dispute actually lives. Vendors and commentators use "open" in broader senses than the OSI's — sometimes meaning downloadable, sometimes free to use, sometimes openly documented. Someone can reasonably argue that a licence with behavioural restrictions delivers most of what practitioners want, while still failing the published criteria. Both things can be true at once. What is not defensible is treating the published criterion as merely one opinion among several.

For your own audit, treat these as two separate findings: whether a field-of-use clause exists and is in tension with the non-discrimination criterion, and whether it actually affects what you intend to do.

The openness checklist used throughout this article

The four-layer checklist below is this article's analytical framework, not a standard published by anyone else:

1. Weights — obtainable? gated? under what licence?
2. Code — is inference code published? training code?
3. Data — is the training corpus released, described, or not disclosed?
4. Rights — modify, redistribute, fine-tune, commercialise, and under what conditions?

Each layer gets its own verdict. Use four labels and avoid "partial":

• Open — available under terms meeting the relevant open-source criteria; ordinary licence-compliance duties such as preserving notices may still apply.
• Available with additional conditions — available under terms that add material restrictions or bespoke duties, such as field-of-use limits, naming requirements or scale thresholds.
• Restricted — the terms forbid or gate the activity you need.
• Not disclosed — the documentation does not address the layer. This is a finding, not a gap to fill with inference.

Four Layers of Openness: Weights, Code, Data and Rights

Most models are open on some layers and closed on others. Collapsing that into a single yes/no is where readers get misled.

Layer 1: Are the weights downloadable, and under what terms?

Weight availability is the layer most people check, and the easiest to over-read. Weights hosted on a platform such as Hugging Face may still sit behind a click-through agreement, an access request, or regional conditions. When you check a repository, record three separate facts: is there a licence file, which licence is named in it, and is the download gated?

"Open weights" is a useful, accurate term for the common situation: parameters you can obtain and run, under terms that may or may not satisfy an open source definition.

Layer 2: Is inference and training code published?

Running a model needs inference code; reproducing one needs training code, data pipelines and configuration. These are different artefacts and are often released separately or not at all. An inference example or serving stub is not a training pipeline. Record them as two entries on your scorecard.

Layer 3: Is the training data disclosed, described or withheld?

Disclosure sits on a spectrum: full dataset release, a described mixture with named sources, a vague category list, or silence. If a provider does not document its corpus, the correct entry is not disclosed — not an inference from what you assume the model has read. Guessing at composition is the error this framework exists to prevent.

Layer 4: What rights do you actually receive?

This is the layer that decides whether you can ship, and the one where most unpleasant surprises are found. Work through it as a checklist, clause by clause:

• Derivative works. May you create and distribute them, and do fine-tuned models inherit the same obligations or licence?
• Naming and attribution. Some licences require notices, or specific naming for fine-tuned models. These are cheap to satisfy early and awkward to retrofit, because they touch product naming and documentation as well as code.
• Commercial use. Permitted outright, permitted conditionally, or excluded?
• Thresholds. Some licences distinguish ordinary adopters from very large deployments by user count or revenue. Find the clause and read the figure in the licence text itself; thresholds change between versions and get garbled in summary.
• Outputs. Who owns generated outputs, and may they be used to train, improve or distil another model? These are separate permissions and are often addressed in separate clauses. Distillation plans in particular live or die on the second one, so resolve it before you build a synthetic data pipeline.
• Acceptable use policy. Usually a separate, provider-hosted document with its own change mechanics. Because the provider maintains it on its own schedule, whether a later change binds an existing deployment depends on the wording of both documents — the licence's incorporation language and the policy's own terms. That is a question for counsel rather than an assumption, and one of the strongest reasons to archive dated copies of both.
• Pass-through. Do any restrictions bind only you, or must they also be imposed on your downstream users? Some texts impose explicit pass-through obligations on redistribution; others govern the licensee alone. If pass-through applies, your own customer terms may need editing, which is a product and legal task, not just an engineering one.
• Gated, regional and export conditions. These can sit outside the licence file — in platform terms, in a provider's regional policy, or in law that applies regardless of what the licence says. Record where you found each, because they are maintained by different parties and change independently.

Licence Families You Will Actually Encounter

You can classify almost any new release into one of four archetypes. What you cannot do is infer a specific obligation from the family label — the family tells you what to look for, the licence text tells you what applies. No licence family guarantees openness on every layer, and none by itself establishes anything about training-data disclosure.

Standard permissive licences such as Apache 2.0 and MIT

The Apache License 2.0 and the MIT License are OSI-approved software licences that grant broad rights to use, modify and redistribute, with attribution and notice requirements, and in Apache's case an explicit patent grant.

Operational consequence: because these are standardised texts with fixed wording, the terms you review are the same terms every other adopter reviews, and existing licence-compliance tooling recognises them by identifier. You still have to satisfy the notice and attribution obligations — real work at redistribution time, not a formality.

Bespoke community and vendor licences with added conditions

Some providers publish a custom community licence: weights are freely available, commercial use is generally allowed, and additional conditions attach — naming or attribution requirements, obligations that travel to derivative models, or thresholds above which different terms apply.

Operational consequence: each one is a separate document requiring its own review, and it cannot be assumed equivalent to any other vendor's licence — or to an earlier version of the same vendor's licence — even where the marketing language matches. If your compliance process works by licence identifier, a bespoke licence will need a manual entry.

Responsible AI licences with behavioural use restrictions

A responsible AI licence permits broad technical use while prohibiting enumerated behaviours or applications.

Operational consequence: the restrictions have to be mapped to your actual use case, and you need to establish whether they pass through to your users. Where such a licence restricts fields of endeavour, it sits in tension with the Open Source Definition's non-discrimination criterion.

Research-only, non-commercial and gated-access terms

Some weights are released for research or evaluation only, or behind approval-gated downloads.

Operational consequence: a successful prototype cannot simply be promoted to production; the licence, not the engineering, is the blocker. Establish the terms before you build the prototype.

The Audit: One Procedure, One Scorecard

This is where the work gets done — by you, on the model in front of you, from the documents that govern it. A structured first pass is quick and will identify the issues that need deeper review.

Step 1 — Retrieve the governing documents, separately, and date each one. There are usually three: the official licence file in the provider's own repository or documentation; the model card, for the data and code layers; and the acceptable use policy, which normally has its own URL and its own change mechanics. Archive a copy of each at the moment you rely on it, so you can later show what the terms said when you deployed, and record the retrieval date against each. Press coverage, benchmark write-ups and launch announcements are not evidence for any of the four layers — and neither is this article. Every later step in this procedure assumes you are reading these documents and not a summary of them.

Step 2 — Read for restrictions, not permissions. Permissions are advertised; restrictions are where the surprises live. Search the text for may not, prohibited, only, provided that, shall, must, and for any figure or threshold. Then search separately for derivative, output, train, distil, name and redistribute, and work through the Layer 4 checklist above against what you find.

Step 3 — Diff against the previous release. If you have used an earlier version of the same family, compare the two documents rather than assuming continuity. That is the reason to keep archived copies.

Step 4 — Fill the scorecard. One row per layer, each with a clause or section reference and a date.

A model with permissive weights and no data disclosure is not "open source, partially." It is open on the weights layer and not disclosed on the data layer. Saying so precisely is what makes the audit defensible when someone challenges it.

Step 5 — Apply the escalation triggers. Route to counsel if you will redistribute weights, if a threshold clause may apply, if outputs will train another model, if the licence and the acceptable use policy appear to conflict, or if you intend to describe your own product as open source. Recording an ambiguity and routing it onward is not a legal conclusion — it is the point at which a non-lawyer's audit correctly stops.

Step 6 — Set a re-check cadence. Licences and policies are revised between releases, which is why every row has a verified on column; an undated verdict tells a future reader nothing about whether it still holds. Offered as editorial recommendation rather than industry standard: re-check before every model upgrade, and on a fixed calendar interval — quarterly is a reasonable default — for anything already in production. NewsForge has not measured how often licences change across providers.

Contested Cases and the Open-Washing Argument

Some releases are genuinely arguable. Where a licence grants broad practical freedom but adds behavioural restrictions or scale conditions, two readings compete. The first is that the freedoms practitioners actually exercise — download, run, adapt, ship — are intact, so the release is open in every sense that matters operationally. The second is that a condition restricting fields of endeavour, or one that changes at scale, is precisely what the published criteria exclude, so the label is being borrowed rather than earned. Critics of the looser usage describe this as open-washing: taking the reputational benefit of open source while retaining control the label implies has been relinquished.

On the standards question the tension is resolvable by reading the Open Source Definition's non-discrimination criterion against the clause in question. That is a documentary exercise, and your audit should do it: apply the criterion to the clause, record both readings where the clause is ambiguous, and note which reading your organisation is relying on. If the answer determines whether you can call your own product open source, that is a question for counsel.

Why Openness Claims Matter Beyond Compliance

Auditability and independent security scrutiny

Downloadable weights let outside parties probe a model directly rather than through an API, which is useful for security review. The caveat is that model artefacts are not human-readable the way source code is: inspection is empirical — evaluation, red-teaming, behavioural probing — rather than a matter of reading the source. That distinction matters for anyone weighing how far automated tooling can substitute for human judgement in security work.

Reproducibility when data and code are withheld

Without training data and training code, independent researchers cannot reproduce a model. They can evaluate it. For academic work where reproducibility is part of the claim, that gap is decisive — and it is why the data and code layers, not the rights layer, bind academic readers.

Self-hosting, data residency and continuity risk

Self-hosting can keep inference inside your own boundary — but only if your infrastructure, telemetry, logging, third-party dependencies and operating practices are configured to do so. Holding the weights is not the same as being independent: a self-hosted deployment can still call out to hosted services, ship telemetry, or depend on runtimes and tooling you do not control.

Similarly, a locally held model cannot be switched off remotely the way a hosted endpoint can be deprecated, but continuity is not absolute. Access to future versions, updated weights, supporting libraries, documentation and gated downloads can all be withdrawn. The honest framing is that self-hosting converts one kind of dependency into another, usually a more manageable one.

Terms and availability can also turn on decisions taken well outside the licence file — corporate disputes, platform policy changes and regional approvals all shape which models organisations can actually deploy, as coverage of model releases and regional AI approvals illustrates.

What openness does not guarantee about safety or quality

An open licence says nothing about whether a model is accurate, safe, well-documented or supported, and a permissive licence does not resolve upstream data provenance questions. Availability is not assurance. This article makes no performance or benchmark claims; where you see them elsewhere, check who published them and note that they are a separate question from openness.

Choose By Constraint: A Decision Path for Your Use Case

Work from your binding constraint — the constraint tells you which layer decides, and the layer tells you which document to read.

• Commercial product that ships model weights. Redistribution is your constraint, so the rights layer decides. A standard permissive licence is the least complicated route because its redistribution terms are fixed and widely understood; confirm derivative-work, notice and attribution obligations before you ship. A bespoke community licence is not disqualifying, but you must read its redistribution and naming clauses in full.
• Internal tooling and self-hosted deployment. You may tolerate more licence conditions, since you are not redistributing. Still read the acceptable use policy — it typically applies to internal use too — and still check for threshold clauses, which can be triggered by internal scale.
• Academic research and reproducible publication. The data and code layers bind. Prefer releases that document the training corpus and pipeline; where they do not, state not disclosed in your paper rather than describing the corpus from inference.
• Fine-tuning and distillation plans. The rights layer binds, in two specific clauses: permission to create derivatives (and any naming or licence-inheritance duty on the result), and any restriction on using outputs to train other models. Resolve both before the pipeline is built.

Run the Check on Your Own Shortlist

Run the six-step check on each shortlisted model, fill one scorecard per model with today's date in every row, and save it into your own review template so the next audit is faster than the first. Then re-check the governing documents before upgrades or material deployment changes.