# Open model licensing: what can you do commercially?

[Skip to content](#lm-inhoud)Network/[NL](/en/licenties-van-open-modellen-wat-mag-je-commercieel-doen)EN[Hubhub.llmnet.nlCompare models on task, language, cost and licence.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organisation, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Flicenties-van-open-modellen-wat-mag-je-commercieel-doen&text=Open%20model%20licensing%3A%20what%20can%20you%20do%20commercially%3F)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Flicenties-van-open-modellen-wat-mag-je-commercieel-doen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Flicenties-van-open-modellen-wat-mag-je-commercieel-doen&title=Open%20model%20licensing%3A%20what%20can%20you%20do%20commercially%3F)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Flicenties-van-open-modellen-wat-mag-je-commercieel-doen&text=Open%20model%20licensing%3A%20what%20can%20you%20do%20commercially%3F)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Flicenties-van-open-modellen-wat-mag-je-commercieel-doen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Flicenties-van-open-modellen-wat-mag-je-commercieel-doen&title=Open%20model%20licensing%3A%20what%20can%20you%20do%20commercially%3F)[](#)

 
# Open model licenses: what are you allowed to do commercially?

 By Ivo Donker — compiled with AI support (Claude & Gemini)

 The term "open source" is widely used across the AI landscape for language models and multimodal networks whose weights are publicly downloadable. Yet this label rarely carries the traditional legal weight. Whereas classic open-source software falls under strict definitions from the Open Source Initiative (OSI), modern AI model providers frequently employ custom user agreements, behavioral clauses, and distribution restrictions. Anyone integrating a model into a commercial SaaS product, internal workflow automation, or a customer-facing chatbot must know precisely which rights and obligations apply.

 A mistaken assumption about model rights can lead to mandatory recertification, unexpected licensing fees upon scaling, or even a ban on using derivative datasets. In addition, maintenance and lifecycle management play a decisive role; anyone looking to understand how model updates and deprecations are handled contractually can consult the guidelines on [model versioning and planning a model migration](https://hub.llmnet.nl/en/modelversies-en-deprecatie) . In this article, we cover the various license types, their commercial restrictions, and the technical implications for production environments.

 
## The distinction between open source and open weights

 In traditional software development, an open-source license (such as MIT, BSD, or GPL) grants complete access to human-readable source code. Anyone may inspect, modify, compile, and commercially exploit the source code without functional limitations on the field of use. With large language models (LLMs), things are fundamentally different. A neural network consists of billions of numerical parameters (weights), training scripts, data transformation pipelines, and tokenizer configurations.

 When an organization only publishes the model weights without releasing the training data, data loading scripts, and exact filtering methods, it is referred to as open weights rather than strict open source. The license terms attached to these weights dictate what a user is permitted to do. Many providers deliberately opt for hybrid licensing models that charge no royalties, but impose restrictions regarding monthly active users, training competing models, or specific industries.

 For a detailed legal analysis of commercial rights, refer to the in-depth article on [commercial usage rights and obligations for open models](https://hub.llmnet.nl/en/commerciele-gebruiksrechten-open-modellen). It is crucial to determine in advance whether a model file falls under a standardized software license or a model-specific license agreement.

 
## Permissive software licenses: Apache 2.0 and MIT

 True permissive licenses provide the most straightforward foundation for commercial software development. Models released under Apache 2.0 (such as various releases from Mistral AI, Qwen, and early Falcon models) or MIT grant developers maximum operational freedom.

 Under these terms, an organization is permitted to:

 
 
- Run the model internally on its own servers or in a virtual cloud environment;
 
- Integrate the model into a paid commercial application or SaaS service;
 
- Modify the weights via full fine-tuning, LoRA, or quantization and distribute the result internally or externally;
 
- Offer inference via a public or private API to paying end users;
 
- Use the generated data for internal evaluation and training other models, provided this is not restricted by separate platform terms.
 

 The primary obligation under Apache 2.0 and MIT is attribution. Anyone redistributing the original model or a derivative version (for example, by bundling weights in downloadable software) must retain the original license text, copyright notices, and any NOTICE files. If the model is merely called server-side via an API without distributing the weights themselves to the client, the redistribution requirements do not apply to the end user of the interface.

 
## Community Licenses with Thresholds: The Llama Model

 Since Meta's introduction of Llama, a new licensing model has gained popularity: the Community License Agreement. These terms are designed to enable free innovation for developers and SMEs, while requiring dominant tech companies to obtain a separate commercial license.

 The core of these licenses contains two crucial restrictions that a company must examine closely:

 
 
- The MAU threshold (Monthly Active Users): If a product or service has more than 700 million monthly active users on the model's release date, or reaches this number during the period of use, the model may not be used without explicit written permission from the licensor. For the vast majority of businesses, this number poses no barrier, but for telecom providers, large marketplaces, and social platforms, it warrants immediate legal consultation.
 
- Trademark and name attribution: Derivative models are often required to include the original brand name in their naming (for example, "Built with Llama" or "Fine-tuned Llama").
 

 In addition, such agreements require strict acceptance of the associated Acceptable Use Policy (AUP), which contractually prohibits content generation for certain regulated or harmful purposes.

 
## The Prohibition on Synthetic Distillation and Model Improvement

 One of the most overlooked pitfalls in modern model licensing is the restriction on model distillation. Both commercial API providers and certain open-weight licenses prohibit users from using the output of model A to train, fine-tune, or evaluate model B when model B is a competitor.

 Llama licenses contain a specific nuance: generated data from Llama may be used to train derivative versions of Llama to train and improve, but not to optimize a fundamentally different foundation model (such as a proprietary neural network or a competing model from another party). With closed-source providers (such as OpenAI, Anthropic, and Google), using API outputs for model training is contractually typically entirely prohibited for competing services.

 Those bundling or comparing model outputs across multiple backends can consult the architecture in the [guide to LLM aggregators](https://api.llmnet.nl/en/aggregator-uitleg) to monitor data flows and license boundaries. After all, inadvertently writing API responses to a training dataset for internal LoRA adapters can lead to a breach of the license agreement.

 
## Responsible AI Licenses: OpenRAIL and Behavioral Restrictions

 Organizations such as BigScience (BLOOM) and Stability AI introduced the OpenRAIL (Responsible AI License) framework. OpenRAIL licenses combine the open availability of model weights with legally binding use restrictions.

 Unlike pure open-source licenses—which, under OSI philosophy, must not contain restrictions on fields of endeavor ("no discrimination against fields of endeavor")—OpenRAIL explicitly prohibits deployment for specific purposes. Typical exclusions include:

 
 
- Fully automated decision-making in legal, medical, or financial allocation processes without human intervention;
 
- Social credit systems and biometric surveillance in public spaces;
 
- Generating medical diagnostic advice without qualified supervision;
 
- Military applications and weapons development;
 
- Large-scale disinformation campaigns or automated spam.
 

 Furthermore, OpenRAIL includes a downstream obligation: anyone fine-tuning or redistributing an OpenRAIL model is required to impose the same use restrictions on their own end users. This means SaaS providers must pass these restrictions down into their terms of service and end-user license agreements.

 
## Multimodal Models and Domain-Specific Restrictions

 Alongside text models, specialized models for vision, speech, and audio are increasingly deployed locally. These modalities introduce distinct intellectual property and privacy considerations that directly impact applicability.

 For audio and speech applications, voice cloning and training data carry additional legal caveats; see the overview on [AI for music and audio models](https://hub.llmnet.nl/en/audio-en-muziek-modellen) for specific modality requirements. While speech-to-text models like Whisper fall under the highly permissive MIT license, models for singing and music generation often carry non-commercial clauses (such as CC-BY-NC) due to copyright claims on the underlying training material.

 
 Caution with Creative Commons (CC-BY-NC): Models tagged as "Non-Commercial" may not be used in any way for direct or indirect revenue generation. This excludes not only selling API access, but also internal business use to support paid staff.
 

 
## Data Processing, Privacy, and the GDPR with Local Models

 A common argument for running open-weight models on proprietary infrastructure is data sovereignty. Because prompts and documents do not leave the local IT environment, certain risks regarding data transfers to third countries (such as the US) are eliminated.

 However, this does not exempt an organization from compliance obligations. When a model processes personal data within an enterprise application, the guide on [AI models, privacy, and GDPR compliance](https://hub.llmnet.nl/en/ai-modellen-en-privacy-avg-compliance) to legally secure the role of processor and data processing agreements. A local open-weight model must also be assessed for data minimization, retention periods, and the risk of reproducing personal data memorized in the network during pre-training.

 
## Comparative Overview of Common Model Licenses

 To quickly understand what is and isn't permitted, the table below outlines the key characteristics of the most commonly used license types for open models.

 
 
 
 
 License Type | 
 Commercial Use Allowed? | 
 Distillation Allowed? | 
 User Cap (MAU) | 
 Attribution Requirement | 
 Typical Models | 
 

 
 
 
 Apache 2.0 | 
 Yes, unrestricted | 
 Yes (subject to terms) | 
 None | 
 Yes (NOTICE/License text) | 
 Mistral 7B (v0.1), Qwen 2.5 (parts), Falcon | 
 

 
 MIT | 
 Yes, unrestricted | 
 Yes | 
 None | 
 Yes (Copyright notice) | 
 Whisper, BERT, various Hugging Face tools | 
 

 
 Llama Community | 
 Yes (subject to conditions) | 
 Only for Llama derivatives | 
 700 million MAU limit | 
 Yes ("Built with Llama") | 
 Llama 3, Llama 3.1, Llama 3.3 | 
 

 
 Gemma Terms of Use | 
 Yes (subject to conditions) | 
 Restricted per Google AUP | 
 No explicit figure | 
 Yes | 
 Gemma 2, CodeGemma, RecurrentGemma | 
 

 
 OpenRAIL-M / RAIL | 
 Yes (with use restrictions) | 
 Depending on the variant | 
 None | 
 Yes + downstream clauses | 
 BLOOM, Stable Diffusion (earlier versions) | 
 

 
 CC-BY-NC 4.0 | 
 No (strictly non-commercial) | 
 No for commercial purposes | 
 N.v.t. | 
 Yes | 
 Research models, various audio/video networks | 
 

 
 
 

 
## Validating model cards and license texts for production

 In practice, a model's license can change between different releases from the same developer. For instance, a base model (base weights) may be released under Apache 2.0, while the instruction-tuned model (Instruct/Chat) falls under a more restrictive agreement due to synthetic data used during the post-training process.

 For a methodical approach to checking documentation, the guide on [reading model cards and model licenses for production](https://hub.llmnet.nl/en/modelkaarten-en-licenties-lezen) provides practical guidance. Always check the LICENSE or LICENSE.txt file in the root of the model repository on Hugging Face or GitHub, and do not rely solely on the metadata tags in the web interface.

 
## Step-by-step plan for legally compliant model selection

 To avoid surprises during rollout, development teams can use a structured validation process:

 
 
- Verify the specific checkpoint license: Check which terms apply to each individual model file (base vs. instruct vs. quantized GGUF/EXL2). Community-uploaded quantizations always retain the license of the original base model.
 
- Assess the use case against the Acceptable Use Policy: Verify whether the intended functionality (e.g., financial document analysis or automated communication) does not conflict with specific sector restrictions in RAIL or Community licenses.
 
- Map the data flows: If model outputs are stored for continuous quality improvement or the training of smaller sub-models, determine whether the licensor permits distillation.
 
- Implement required attribution: Ensure documentation, help sections, or API notices include the required source attributions in accordance with Apache, MIT, or Llama guidelines.
 
- Record the decision in an internal registry: Document the license type, date of download, and permitted use cases in a software bill of materials (SBOM).
 

 By routinely including these verification steps in the development pipeline, deploying open models remains legally robust, scalable, and future-proof.
