Commercial use of open models: usage rights and obligations
When organizations decide to deploy artificial intelligence within their internal operations or in commercial products, the choice increasingly falls on openly accessible models. The idea that a model can be downloaded freely from a platform and run locally quickly creates the impression that no legal or operational restrictions attach to its use. In practice, however, the term 'open' in the world of artificial intelligence covers a considerably broader and more complex spectrum than it does in traditional open-source software.
Downloading a language model's weights gives an organization the technical ability to run the model, but that is separate from legal permission to deploy that model for every conceivable purpose. The conditions under which these artifacts are made available vary widely per creator and per release. It is therefore essential to have a clear picture of the legal layering of AI models, the different types of usage restriction found in the market, and the obligations resting on organizations once they start applying this technology commercially. Anyone looking for suitable models within a catalogue such as the overviews of open modelsis well advised to understand in advance which legal complications distribution files can carry.
Why 'open' in AI does not mean the same as in software
In traditional software development, the concept of 'open source' is tightly defined. Source code released under a recognized license grants the user four fundamental freedoms: the right to run the software for any purpose, to study and modify how it works, to share copies and to distribute modified versions. With artificial intelligence, and large language models in particular, the situation is different. An AI model does not consist of classic source code written line by line by a human, but of a collection of billions of numerical values (weights and parameters) resulting from an intensive training process.
When a developer or organization publishes model weights, people in practice often speak of 'open weights'. This only means that the binary files with which the model reasons or generates text are freely accessible. The conditions under which you may use, store, modify or commercially exploit these weights are determined by the accompanying agreement or license text. Many creators add specific clauses restricting use to particular application areas or particular organization sizes. A model can therefore be technically open and freely downloadable yet strictly delimited for commercial purposes in legal terms.
Running a model also requires more than the weights alone. It requires supporting software such as tokenizers, inference pipelines and specific software architectures. The fact that the inference engine's code falls under a free license does not automatically mean the same freedoms apply to the weights loaded into the graphics card's memory. Separating technical availability from legal rights is the first crucial step in a careful assessment of AI applications.
The four legal layers of an AI system
To determine what is and is not permitted commercially, an organization should view an AI system not as a single product but as a stack of four separate layers. Each layer can fall under its own regime of conditions and intellectual property rights. It is very common for these four layers rarely to fall under exactly the same conditions, which makes a separate check per layer necessary.
| Layer of the AI system | Typical content | Point of attention in licensing |
|---|---|---|
| 1. Model weights | Billions of parameters in binary files | Usage restrictions, thresholds for revenue or users |
| 2. Supporting code | Tokenizers, inference scripts, training pipelines | Often traditional software licenses (such as Apache 2.0 or MIT) |
| 3. Training data | Text corpora, datasets, annotated sources | Third-party copyright, provenance, database rights |
| 4. Model output | Generated texts, code, results | Restrictions on training competing models |
The first layer consists of the model weights themselves. These are the computational results of the training process. The conditions on this layer determine who may load the weights, on which hardware that may happen, and whether commercial services may be built around the model.
The second layer concerns the software around the model. Think of the inference engine's source code, the scripts for pre-processing data and the integration code with databases. This code is regularly published under permissive software licenses. So the code with which you call the model may be entirely free while the weights loaded by that code carry restrictive conditions.
The third layer is the training data with which the model was built. In practice this is the most complex layer, because rights to the raw data rarely rest entirely with the model's creator. A model creator can release the weights under generous conditions, but if the model was trained on copyrighted material without a license, a real provenance risk remains for the eventual user.
The fourth layer concerns the output the model generates for the end user. Some conditions set rules on what may be done with this output. For a deeper analysis of the legal aspects around generated content, consult the overview of intellectual property and copyright in AI. To dissect the full documentation around a specific model properly, it is also advisable to follow the guidelines for reading model cards and licenses.
Types of conditions in practice
In the current landscape of openly accessible AI models, usage rights fall into four main categories. Each category has specific consequences for a project's commercial viability.
1. Genuinely free conditions
Under this type of condition the user receives virtually unlimited freedom. You may use the weights for commercial applications, modify the model, integrate it into your own products and offer the service to third parties without financial compensation or usage restrictions in return. The only obligation is usually retaining the original copyright notice and a disclaimer of liability.
2. Conditions with a usage restriction (acceptable use policies)
Many popular open models fall under conditions permitting commercial use provided the model is not deployed for specific applications. Typical exclusions concern medical advice without human intervention, generating disinformation, automated adjudication, law enforcement, or assessing individuals' creditworthiness. As soon as your application falls within one of these selected domains, permission to use the model lapses.
3. Conditions with a threshold
Some developers apply conditions permitting commercial use free of charge up to a certain limit. This limit is often expressed as a maximum number of monthly active users of the product the model is built into, or a maximum annual revenue for the organization deploying the model. As soon as your organization or product exceeds this threshold, the agreement obliges you to contact the creator to conclude a separate commercial license agreement.
4. Research and non-commercial use only
A considerable share of available models is released with an explicit prohibition on commercial exploitation. These models are intended solely for academic research, educational purposes or personal experimentation. Deploying such a model in an internal business pipeline supporting commercial revenue is a direct breach of the conditions.
Note: A model containing restrictions on purpose of use or company size does not, by official standards, meet the definition of 'open source'. Applying usage restrictions excludes the principle of equal access without discrimination against fields of endeavor. More background on this legal and categorical discussion can be found in the article on the licensing debate around open models.
Attribution, derivative models and training competitors
Besides the question of whether a model may be used commercially, conditions often set concrete requirements for how the model is deployed and developed further. These obligations are regularly overlooked in practice, which can cause complications during an audit or acquisition.
A common requirement is the obligation of attribution and passing on conditions. If you integrate an open model into a software product you deliver to customers, you are often obliged to state in the documentation or user interface which base model the service is built on. Many conditions also require that if you redistribute the model, you pass the original license text and usage restrictions on to your customers. You cannot, therefore, grant your customers more rights than you received from the original creator yourself.
What happens with derivative models?
In practice, open models are rarely used in exactly their original form. Organizations often carry out fine-tuning, train additional adapters (such as LoRAs) or apply quantization to make the model run faster. It is a misconception that training your own layer on an existing model legally 'erases' the underlying model.
The general rule is that derivative works remain bound to the conditions of the original base model. If the base model has usage restrictions or applies a threshold, those restrictions apply in full to the model you fine-tuned and to the separate adapter files. You cannot circumvent a base model's restrictive license by adding a small amount of your own data to it.
The prohibition on training competing models
One specific clause included in many modern model conditions concerns using the output to train other AI models. Large model creators want to prevent a competitor or commercial customer from using their model as a cheap 'teacher' to train a smaller model of their own through data synthesis (distillation).
If a license explicitly forbids using generations to train, improve or validate competing models, this has direct consequences for your data architecture. In that case you may not store the answers the model generates in a database in order to use them as a training dataset for an internal, smaller model. This prohibition often applies regardless of whether the eventual application is internal or external.
Record-keeping, intermediaries and provenance risk
Deploying open models responsibly within an organization requires a sound administrative and technical approach. Merely downloading a file is not enough to secure compliance over the long term.
What should you record internally?
Model conditions are not static. Providers sometimes adjust their conditions with new release versions. To demonstrate during an inspection that your organization acts lawfully, a fixed dossier has to be maintained for every model used. This dossier should contain at minimum the following elements:
- The exact variant and version number of the model (including the specific commit hash of the repository).
- The exact date and time at which the model files were downloaded.
- A local copy of the license text and conditions as they applied at the moment of downloading.
- Documentation of the intended application, demonstrating that the use does not fall under the excluded domains.
The role of intermediaries and managed hosting
Many organizations choose not to run an open model on their own GPU hardware but to obtain it through an intermediary such as a cloud provider or a specialized hosting platform. It is a common fallacy that the intermediary thereby takes over the legal risk and the conditions.
A hosting provider offers only the infrastructural facility for running the model. As a user of the API you remain in most cases directly bound by the underlying model's usage rights. When concluding agreements with intermediaries you have to establish clearly who guarantees the license conditions, whether indemnification against infringement applies and how data processing is arranged. For contractual agreements around service provision and guarantees, see also the overview of AI contracts and SLAs.
Provenance as the underlying risk
The most fundamental risk with open models concerns the provenance of the training data. A model creator can make the weights available under an extremely generous and permissive license, but that gives no guarantee whatsoever about the legal status of the material the model was trained on.
If a model was trained on copyrighted books, articles or code repositories without permission having been granted, a rights holder can argue that the end product or its operation infringes intellectual property. A friendly license from a model creator gives you as end user no indemnity against claims from third parties whose data was used without a license. For organizations with a strict risk profile, establishing data provenance is therefore a decisive part of vendor assessment.
A practical order for suitability analysis
To keep a development team from investing weeks in testing a model that later runs into legal objections, it is advisable to apply a fixed order of analysis. Technical suitability should only be tested as the last step.
- Step 1: check usage restrictions. Check whether the intended application (financial advice, personnel selection or customer service, for instance) falls under one of the explicitly forbidden categories in the model's conditions.
- Step 2: check organizational conditions. Establish whether your organization falls under a threshold for revenue or user numbers, and whether the required attribution can be fitted into the product interface.
- Step 3: evaluate financial and cost structure. If the model requires license fees on exceeding thresholds, or if self-hosting brings high infrastructure costs, this has to be weighed. See the analysis of the total cost of ownership of open versus closed models for a realistic picture of the cost equation.
- Step 4: technical evaluation and benchmarking. Only once it is established that the model may and can be deployed legally and operationally does evaluation of accuracy, speed and technical suitability for the task begin.
By applying this systematic approach, organizations avoid becoming dependent on models that produce unexpected legal and financial obstacles when revenue scales or audits arrive.
