Open Weights, Open Source, and Open Models Are Not the Same Thing
A practical checklist for understanding what an AI release actually includes, what its licence permits, and whether its results can be reproduced.
An AI model can be free to download without being open source. It can publish code without publishing the trained parameters. It can publish weights while restricting commercial use, certain users, or particular applications.
Those releases may still be useful. The problem begins when “open,” “open weights,” and “open source” are treated as interchangeable labels.
The reliable way to evaluate a release is to ignore the headline and inventory the artifacts, permissions, and missing pieces.
What model weights are
Training adjusts a large collection of numerical parameters. The resulting parameters are commonly called weights. Combined with the model architecture and inference software, they transform an input into an output.
When a developer publishes weights, other people may be able to run the model on their own hardware, inspect some of its behaviour, quantize it, or fine-tune it. This can improve privacy, reduce dependence on a hosted API, and make experiments easier to repeat. Hugging Face’s retrospective on open language-model releases also describes weights as the learned parameters used for inference and as a starting point for adaptation.
But weights alone do not reveal the full process that produced them. They may omit the training data, filtering rules, training code, hyperparameters, evaluation setup, intermediate checkpoints, and post-training recipe.
That is why “open weights” is a useful description. It states what is available without making a broader promise.
What open source means
Open source is not simply a synonym for “publicly accessible” or “available at no cost.” It concerns freedoms to use, study, modify, and share a work under defined terms.
For AI, deciding what constitutes the preferred form for modification is more complicated than it is for a conventional software package. An AI system may depend on code, parameters, data, documentation, and a costly training process.
The Open Source AI Definition 1.0 from the Open Source Initiative applies the freedoms to use, study, modify, and share to AI systems and their components. It says that the preferred form for modification must include detailed training-data information, the relevant training and inference code, and model parameters under suitable terms.
The definition is one formal standard, not a magic resolution to every legal and technical dispute. The OSI also maintains an FAQ explaining the definition’s scope. Together, these materials are much more precise than accepting a marketing label.
“Open model” may describe a spectrum
People often use “open model” informally for releases that expose more than a closed API but less than a fully reproducible training system.
A release might include:
- downloadable final weights;
- architecture and inference code;
- tokenizer files and configuration;
- fine-tuning code;
- an evaluation report;
- a high-level data description;
- some or all training data;
- a complete training recipe;
- intermediate checkpoints and optimizer state.
Each additional artifact can improve inspectability or reproducibility, but availability is separate from permission. A public file can still carry terms that restrict how it may be used or redistributed.
Instead of placing every release into a vague open/closed binary, state exactly which artifacts and freedoms are present.
Read the licence, not the repository badge
A public repository does not automatically grant permission to use its contents. The model card, code, weights, tokenizer, and dataset may also use different licences.
Check at least these questions:
- Is commercial use permitted?
- Is modification or fine-tuning permitted?
- Can the original and modified weights be redistributed?
- Are there field-of-use, user-count, revenue, or geographic restrictions?
- Must derivative releases use the same terms?
- Are attribution or notice files required?
- Are data, code, and weights covered by separate terms?
- Are trademarks or acceptable-use rules separate from copyright permissions?
Restrictions may be motivated by safety or commercial strategy, but a licence with use restrictions does not provide the same freedoms as an unrestricted open-source licence. Describe it accurately rather than arguing that every publicly downloadable model must fit one category.
Hugging Face’s discussion of OpenRAIL licences illustrates the tension: AI-specific licences can promote access and redistribution while adding responsible-use restrictions. Those goals may be valuable, but the resulting terms should not be silently equated with conventional open-source software terms.
This article is a technical checklist, not legal advice. Organizations making consequential licensing decisions should review the actual terms with qualified counsel.
Openness and reproducibility are different
A release can grant broad legal permission while remaining difficult to reproduce. Conversely, a detailed research paper can describe training precisely while withholding artifacts or limiting their use.
To assess reproducibility, look for:
- data provenance and a usable description of selection and filtering;
- preprocessing and deduplication procedures;
- model architecture and tokenizer versions;
- training code, dependencies, arguments, and random seeds;
- compute and numerical-precision details;
- checkpoint-selection criteria;
- post-training, preference, and safety-tuning methods;
- evaluation prompts, datasets, scoring code, and raw outputs;
- known limitations and failed experiments.
Exact retraining may be economically unrealistic for a large model. A release can still make its claims more auditable by publishing enough evidence for smaller replications, behavioural evaluation, and careful comparison.
Downloadable does not mean safe
Openness can support independent scrutiny, local control, and faster correction. It does not guarantee that a model is accurate, secure, unbiased, or appropriate for a task.
Before deployment, verify file integrity and provenance. Prefer formats and loading methods that do not execute arbitrary code. Review custom inference code, dependencies, model configuration, and remote-code settings. Evaluate the model on your own tasks and threat model.
Also examine the supply chain around the release. A legitimate model name can be copied by an unrelated account. Model files, adapters, container images, and example applications may come from different publishers.
A compact disclosure format
Anyone publishing or describing a model can reduce confusion with a small table:
| Item | Available? | Terms or location |
|---|---|---|
| Final weights | Yes/No | Licence and checksum |
| Architecture and inference code | Yes/No | Repository and code licence |
| Training and post-training code | Yes/No | Repository and version |
| Training-data information | Full/Partial/No | Dataset card or provenance report |
| Evaluation materials | Full/Partial/No | Prompts, code, and raw outputs |
| Redistribution | Yes/No/Conditional | Relevant clause |
| Commercial use | Yes/No/Conditional | Relevant clause |
| Modification and fine-tuning | Yes/No/Conditional | Relevant clause |
This is more informative than a green “open” badge. It lets researchers, companies, and users decide whether the release meets their actual needs.
The practical rule
Use the narrowest accurate label.
If only the parameters are available, say “open weights” and name the licence. If the code is public but the weights are not, say so. If a release claims open-source status, identify the definition and show where the required artifacts and permissions can be found.
Openness is valuable precisely because it supports real freedom and scrutiny. Clear descriptions protect that value better than stretching one word across fundamentally different releases.