What does "open" mean in an AI model?

 On open weights, open source and licences, why the large providers choose what they choose, and which choice we make.

Last reviewed: 4 September 2026

"Open source" once meant something unambiguous: you could inspect, use, modify and distribute the source code.

In the AI market the term is used more loosely, and that difference has consequences for what you may and can do with a model.

Three kinds of model

• Closed. The model exists only on the provider's servers. You send a query, the answer comes back, and what happens in between is beyond your observation. You cannot download it, inspect it or run it yourself. The flagship models of OpenAI, Anthropic and Google work this way.
• 
  
• Open weights. The numbers the model learned during training, which together determine how it answers. You can download them and run the model on your own equipment, without a connection to the provider. What does not come with them is the training data and the full training process. You can therefore use and adapt the model, but not reconstruct it or examine what it was built on. Llama, Mistral, DeepSeek, Qwen, Gemma, the GPT-OSS models and the Phi series fall into this category.
• 
  
• Open source in the strict sense. In October 2024 the Open Source Initiative published a definition for AI which, alongside the weights, also requires information on the training data, the architecture and the training code. Few models meet that standard. OLMo from the Allen Institute is one of the few that does.
• 
  
• On that definition, the large majority of what is presented as open source in the market is not open source but open weights. The Open Source Initiative has been critical of that use of the term for some time.

The licence is a second, separate question

Open weights say nothing about what you may do with them. That is set out in the licence, and there the models differ considerably.

• Permissive. Apache 2.0 and MIT permit use, modification, redistribution and commercial deployment, without a revenue threshold and without a separate agreement. Requiring attribution is permitted; restricting use is not. The core models of Mistral, DeepSeek and part of the Qwen series sit here.
• 
  
• The provider's own licence. These publish the weights but impose conditions. Meta's Llama licence has a user ceiling: above a certain number of monthly users the free permission lapses and a separate agreement is required. Google's Gemma terms permit commercial use subject to conditions and have not been approved by the Open Source Initiative. The larger Qwen variants sit under a proprietary licence rather than Apache 2.0.
• 
  
• Non-commercial. Some models sit under a licence that excludes commercial use without a separate agreement. Even within a single provider this differs from model to model.
• 
  
• Two models both called "open" can therefore be entirely different in legal terms. Read the model card before you put something into production, not afterwards.

What the Regulation regards as open

The EU AI Act applies its own standard, stricter than common usage. For the exemption for general-purpose models, three conditions apply together: a licence permitting access, use, modification and distribution; publicly available parameters, including the weights, the architecture information and the usage information; and no monetisation.

The Commission's guidelines are strict on the first point: all four rights must remain intact. A licence that restricts use does not meet the test. Above a compute threshold of 10²⁵ floating-point operations, a model is presumed to present a systemic risk, and the exemption then lapses for the provider.

! Note ! that exemption applies to the provider of the model, not to you as the party deploying it. As soon as you use a model for a specific application, you are the deployer of an AI system, and its risk category follows from that application. Deploying an open model to filter CVs produces a high-risk system, exactly as with a closed model.

Why the providers choose what they choose

Both strategies are rational. It is useful to set them side by side without judgement.

1. The reasoning behind closed.
2. The model is the product. As long as it is reachable only through your own servers, you sell access per use and retain the margin. You also retain control: you can enforce terms of use, cut off misuse and withdraw a model. That last point is also used by providers as a safety argument: published weights cannot be recalled and can be adjusted by third parties in a direction the original provider does not want. And training is expensive; a party investing hundreds of millions does not give the result away.
3. 
   
4. The reasoning behind open weights.
5.  Publishing your weights buys distribution. Developers build on them, the provider becomes the standard in its ecosystem, and revenue shifts to what sits around it: hosted inference, support, enterprise platforms. It is moreover an attack on the margin of the closed competitor: putting a free alternative of reasonable quality into the market pushes down the price of paid access. For smaller and European providers there is a positioning argument as well: a party that cannot win on raw model size can win on deployability under its own management.
6. 
   
7. Both camps are moving.
8. Several providers that keep their flagship closed also publish smaller models with open weights.

Advantages and disadvantages, by side

What closed models do better.

They are generally stronger on general and creative tasks, because the largest models are not published. You do not have to manage infrastructure. You scale immediately through an API. There is support, and there is one party to address when something goes wrong.

What closed models cannot do.

Your data has to go to the provider, because otherwise the model cannot see it. You cannot demonstrate what happens between query and answer. You cannot adapt the model thoroughly. Your costs follow usage and the pricing set by a single party. And the provider can phase out a model at a moment you do not choose..

What open-weight models make possible.

Running on your own equipment, in an environment you isolate yourself. An auditor can inspect the weights, the tuning logs and the data flows. You can adapt the model to your own data. Your costs are the costs of your equipment and therefore predictable. And you are not dependent on the life cycle of a single supplier: the model you download today keeps running.

What open-weight models cost.

They perform less well on general tasks than the largest closed models. You have to set up and manage infrastructure yourself. There is no supplier liable for the operation of your setup. And you cannot flex elastically as a large cloud provider can: your capacity is what you have in place.

Where Thor sits

Thor 1.0 builds on Mistral Small 3, an open-weight model under Apache 2.0.

That choice is not a preference but a requirement. Thor has to run on isolated equipment in a Belgian data centre, without internet access, connected to the client's ERP environment. That presupposes that the model can physically sit there. With a closed model that is impossible by definition, whatever the contract says. The permissive licence is the second requirement: without commercial use and the right to adapt, the arrangement equally falls away.

We therefore also carry the disadvantages set out in part 5. The model will perform less well on general and creative tasks than the largest closed models. The setup is heavier than a cloud service. At low volumes the fixed costs of an environment of your own do not outweigh the benefits. And because we run on leased equipment, we cannot add capacity without limit.

For an organisation wanting to deploy AI on data that may not leave its jurisdiction, that trade-off is worth making. For an organisation without that constraint, a cloud service is probably the better choice. That is not modesty but a delineation of where we are useful.

What to check before you choose

1. Is the model closed, open weights, or open source in the strict sense?
2. Under precisely which licence does it sit, and is that a standard licence or the provider's own?
3. Does that licence permit commercial use, without a ceiling or exception that applies to you?
4. May you adapt it and distribute the result?
5. Do territorial or sectoral restrictions apply?
6. For which application are you deploying it, and in which risk category does that application fall?

The first five determine what you may do with the model. The sixth determines which obligations rest on you, and that is independent of how open the model is.