- Under the OSI definition an open AI system grants four freedoms: to use, study, modify and share.
- The condition is access to information on training data, code and parameters, not weights alone.
- Before using one in a product read the licence: limits on uses and company size can matter.
In conversations about AI the word “open” means three different things: a model available through a free API, a model whose weights can be downloaded, and a model that meets a rigorous open source definition. Mixing them leads to mistakes in both directions: you reject something you could safely use, or you deploy something with restrictions you did not notice. This text sorts out the concepts so that in the open models hub you read descriptions with the right filter.
The OSI definition in brief
The Open Source Initiative published the Open Source AI Definition. It says an open AI system is one made available under terms that grant four freedoms: to use it for any purpose without asking permission, to study how it works and inspect its components, to modify it for any purpose, including to change its output, and to share it onward with or without modifications. A precondition for exercising these freedoms is access to the preferred form for making modifications.
For machine-learning systems the definition lists three elements that must make up that form. The first is data information: a sufficiently detailed description of the training data so that a skilled person can build a substantially equivalent system, including the provenance of the data, its scope and how it was obtained and filtered. The second is code: the complete code used to train and run the system, including data processing, training, evaluation and architecture. The third is parameters, that is weights and other settings. The definition speaks of open source models and open source weights and adds that these too must include the data information and the code used to derive those parameters.
| API access | Open weights | Open source AI (OSI) | |
|---|---|---|---|
| Weights can be downloaded | No | Yes | Yes |
| Description of training data | Usually general | Depends on the release | Required, detailed |
| Training code | No | Depends on the release | Required |
| Freedom to modify | Limited to settings | Depends on the licence | Full |
| Run it yourself | No | Yes | Yes |
In practice many popular releases are “open weights” under licences with restrictions. That is not a flaw in itself: you can run such a model locally and adapt it to a task. You just need to know what it is, and not promise a customer something the licence does not allow.
What to check in the licence before deployment
Before using a model in a product, read its licence in full, not just the label. Pay attention to five things. Is commercial use allowed? Are there limits on uses, for example a ban on certain industries or purposes? Does a threshold of company size, number of users or revenue change the terms? Must you label the use of the model or keep its name in the product? Do derivative models that you fine-tune inherit the same terms? Write the answers into a short note in the repository, because a year from now the team must know on what terms the product runs.
- 01Model cardRead the description, uses and limitations.
- 02LicenceCheck the scope of commercial use.
- 03DataWhat is known about the training data?
- 04FormatPrefer safetensors, avoid unknown pickle files.
- 05TestRun it on your own set of cases.
- 06NoteRecord the conclusion and the date checked.
When an open model makes sense
You usually choose an open model for four reasons. The first is control over data: a model run on your side does not send texts to an external service, which is sometimes a requirement when working with sensitive documents. The second is cost at large scale, where fixed hardware can come out cheaper than paying for every token. The third is the possibility of adapting the model to a narrow task. The fourth is independence from price changes and version retirements at a provider. On the other hand you take over maintenance, updates and security, and on some hard tasks the strongest closed models may still do better, which is worth checking on your own examples. Instead of ideology, simply choose the tool for the task and test it on your own cases.
The model card and file safety
The basic source of information about a model on Hugging Face is the model card, a README.md file with metadata. The documentation says it should describe the model, its intended uses and limitations, including biases, the training parameters, the datasets used and the evaluation results. The metadata let you filter models and display the licence. A missing card, or a card without a licence, is a warning sign.
The second topic is the file format. Pickle is the default format of PyTorch weights, and the Hugging Face documentation warns that loading such a file can execute arbitrary code. It advises trusting reliable authors and organizations and mentions the safetensors format as another approach to storing weights. A practical rule: download models from known publishers, prefer safetensors and do not run files from unknown sources on a machine holding production keys. I will write more about downloading in Hugging Face for beginners, and about running on your own hardware in the Local AI hub.
Last checked: 20 October 2026. Definitions and licences change; always check the current licence text of the particular model.