Open Weights, Open Source and Model Licensing

The word "open" covers very different things in AI. One model comes with weights, training code and the full training data under a permissive license; another offers downloadable weights under a custom license that restricts certain uses, sets user-count thresholds, or dictates how derivatives must be named. If you build a product on a model, fine-tune one for a client, or release your own, the license is as much a design constraint as context length or memory footprint. This lesson gives you the vocabulary, the main license families, a method for reading terms, and the supply-chain hygiene needed to load third-party weights safely. It is an engineer's orientation, not legal advice: licenses change between model versions, and for any commercial decision you should read the current text and consult a lawyer.

Intuition: a recipe, a cake, and the ingredients list

Think of a trained model as a cake. Open weights means you are given the cake: you can eat it, slice it, add frosting (fine-tune it), and sometimes sell slices, under whatever conditions the baker attached. Open source in the traditional software sense means you also get the recipe and the freedom to bake, modify and share it for any purpose. Open data means you get the ingredients list and, ideally, the ingredients themselves. Most "open" models today are cakes with conditions. A handful come with the recipe and the ingredients.

Three layers of openness

The OSI Open Source AI Definition

The Open Source Initiative (OSI), steward of the Open Source Definition for software, published version 1.0 of the Open Source AI Definition in October 2024. It carries over the four freedoms of free software to AI systems: to use the system for any purpose without asking permission, to study how it works, to modify it, and to share it with or without modifications. To make those freedoms practical it requires access to the "preferred form for making modifications", which it spells out as three components:

• Data information: sufficiently detailed information about the training data (sources, selection, processing, labelling) that a skilled person could build a substantially equivalent system. It does not strictly require publishing every training document, a compromise that drew criticism from those who argue open source AI must include the data.
• Code: the complete source used to train and run the system, including data processing and filtering, under OSI-approved licenses.
• Parameters: the weights and configuration, under OSI-approved terms.

The practical consequence: licenses that restrict who may use a model or for what purpose (user thresholds, field-of-use bans) are not open source under this definition, even if the weights are free to download. OSI has said this explicitly about Meta's Llama licenses. "Open weights" is the accurate term for most downloadable models.

The main license families

Permissive: Apache-2.0 and MIT

• MIT is a few short paragraphs: do almost anything, including commercial use, modification and sublicensing, provided you keep the copyright and license notice. No warranty.
• Apache-2.0 is similar in spirit but longer and more explicit. You must include the license, keep copyright and attribution notices, carry forward any NOTICE file, and state significant changes you made. Importantly, it includes an express patent license from contributors, with a termination clause if you sue a contributor over patents in the work. Many companies prefer Apache-2.0 for that patent clarity.

Many open-weights models from Mistral, Qwen, Microsoft's Phi line, DeepSeek (R1 was released under MIT) and others have used Apache-2.0 or MIT. These permit commercial use, fine-tuning, distillation and redistribution with attribution, which makes them the easiest to build on. Note that a permissive license on the weights does not by itself settle questions about the training data.

Custom community licenses: the Llama example

Meta's Llama models ship under model-specific community license agreements plus an Acceptable Use Policy (AUP). The Llama 3.x-era licenses grant a broad, royalty-free license to use, reproduce, modify and distribute the model and derivatives, with conditions that include:

• A scale threshold: if your products or services had more than 700 million monthly active users on the model version's release date, you must request a separate license from Meta.
• Attribution: redistributions must include a copy of the license, and products or services using the model must prominently display "Built with Llama".
• Naming: if you use the model or its outputs to create, train, fine-tune or otherwise improve an AI model that you distribute, its name must begin with "Llama". (Llama 3.1, for example, permits using outputs to improve other models on these terms, whereas the original Llama 3 license did not allow it for non-Llama models.)
• Acceptable use: the AUP, incorporated by reference, forbids categories of use such as illegal activity, certain weapons and critical-infrastructure applications, and deceptive impersonation.
• Version-specific terms: versions have differed on points such as the outputs clause above and on certain regional or multimodal restrictions. Always read the license for the exact version you use.

For most companies these terms permit commercial use, but they are not open source, they impose obligations that flow through to your users and derivatives, and Meta can update the AUP.

Gemma Terms of Use

Google's Gemma models up to Gemma 3 were released under the custom Gemma Terms of Use with a Prohibited Use Policy; Gemma 4 (2026) switched to Apache-2.0, so as of November 2026 the license depends on which generation you use. Under the Gemma Terms of Use, commercial use, modification and redistribution are permitted, but the use restrictions must be passed on: if you distribute Gemma or a derivative (including a fine-tune or, under the terms' definitions, a model trained on its outputs for certain purposes), you must include the use restrictions in your agreement with recipients and provide them with a copy of the terms. Google states it claims no rights over outputs you generate, and it reserves the right to restrict usage that it believes violates the terms. Gemma's move from custom terms to Apache-2.0 is a concrete example of why you must check the terms attached to each specific release: vendors change license strategy between generations.

OpenRAIL: responsible AI licenses

RAIL (Responsible AI Licenses) and its OpenRAIL variants pair a permissive, royalty-free grant with use-based restrictions listed in an attachment, for example prohibitions on using the model to harm minors, generate or spread verifiably false information intended to harm others, or provide medical advice and interpret medical results. The key mechanism is that the restrictions must be carried forward into the license of any derivative or redistribution. The BigScience BLOOM model used a RAIL license, and Stable Diffusion's early releases used CreativeML OpenRAIL-M (the "M" denotes that the licensed artifact is the model). A redistributor may use different terms for a derivative but must keep the use-based restrictions. Like the Llama and Gemma terms, these are not open source under OSI's definition because they restrict fields of use.

Non-commercial and research-only licenses

Some models are released under research-only or non-commercial terms (including Creative Commons NC licenses applied to weights). These are fine for experiments and academic work but rule out production use. Read carefully: "non-commercial" often includes internal business use.

What you can and can't do commercially: a working checklist

When evaluating a model for a product, answer these questions from the license text itself:

1. Commercial use: allowed at all? Any revenue or user thresholds?
2. Field-of-use restrictions: an AUP or attachment of prohibited uses? Does your use case touch any category (medical, legal, biometric, surveillance, critical infrastructure)?
3. Redistribution: may you ship the weights (for example on-device)? What must accompany them (license copy, notices, use restrictions)?
4. Derivatives: are fine-tunes, merges, quantisations and distilled models "derivatives"? What naming, attribution or license-inheritance rules apply?
5. Outputs: any restrictions on using generated outputs, especially to train other models?
6. Attribution and branding: required notices or "Built with" displays?
7. Termination and changes: can the licensor update policies by reference? What triggers termination?
8. Patents and indemnity: is there a patent grant? Any indemnity (rare for open weights; sometimes offered by commercial hosting providers)?
9. Data and third-party rights: what does the model card say about training data, and does any of it raise copyright or privacy questions for your use?

Worked example: choosing a base model for a client project

A startup asks you to fine-tune a 7 to 9B model for an on-device customer-support assistant. It will be embedded in their mobile app (about 2 million users), they want to sell the fine-tuned model to other businesses, and some of their clients are healthcare providers.

1. Shortlist three candidate families of similar quality from current benchmarks and the site's AI Index: one Apache-2.0 model, one under a Llama-style community license, one under terms like the Gemma Terms of Use.
2. Scale threshold: 2 million users is far below 700 million, so the Llama-style threshold is not an issue.
3. Redistribution and derivatives: selling the fine-tune means distributing a derivative. The Apache-2.0 model needs the license, notices and a statement of changes. The Llama-style model needs the license copy, "Built with Llama" display, and a model name beginning with "Llama". The model under Gemma-style terms requires passing the use restrictions to every customer contractually.
4. Use restrictions: healthcare clients may touch medical-advice categories in AUPs or prohibited-use policies. Check exact wording; a support bot for appointment scheduling is very different from symptom triage.
5. Decision: if quality is comparable, the Apache-2.0 model minimises ongoing obligations and branding constraints. If a restricted-license model is clearly better, it can still be viable, but budget for compliance (notices, naming, contract terms) and legal review.
6. Record the model name, exact version and revision hash, license text and date reviewed in the project's documentation.

Model cards

A model card (Mitchell et al., 2019) is structured documentation shipped with a model: intended uses and out-of-scope uses, training data summary, evaluation results across relevant groups and conditions, limitations and biases, environmental cost, and license. On the Hugging Face Hub the card is the repository's README.md with a YAML metadata header that records the license, base model, datasets and tags. Read cards critically: they are self-reported, and a missing data section is itself informative. When you publish a model, write a card that a downstream engineer could use to decide whether your model fits their task.

Provenance and supply-chain safety

Downloading weights is downloading code-adjacent artefacts from the internet. Treat it like adding a dependency.

Serialisation formats: pickle versus safetensors

PyTorch's traditional checkpoint format uses Python's pickle, and unpickling can execute arbitrary code. A malicious .bin or .pt file can run commands on your machine the moment you load it. safetensors, developed by Hugging Face, stores only tensors and a JSON header, so loading cannot execute code; it also supports fast, memory-mapped, lazy loading. GGUF, used by llama.cpp-family runtimes, is likewise a data-only format.

from safetensors.torch import load_file, save_file
import torch

weights = {"linear.weight": torch.randn(4, 4), "linear.bias": torch.zeros(4)}
save_file(weights, "model.safetensors")
loaded = load_file("model.safetensors")       # no code execution possible
print({k: tuple(v.shape) for k, v in loaded.items()})

# If you must read a legacy pickle checkpoint, restrict it to tensors:
# state = torch.load("legacy.pt", weights_only=True)

Since PyTorch 2.6, weights_only=True is the default for torch.load, which refuses to unpickle arbitrary objects; pass it explicitly anyway so the intent is clear and older versions behave safely.

Remote code

Some Hugging Face models need custom architecture code and require trust_remote_code=True. That flag downloads and runs Python from the repository. Only enable it for publishers you trust, read the code, and pin a specific commit with the revision= argument so the code cannot change under you.

Verifying publishers and integrity

• Use official organisations on model hubs and check for verified-organisation badges; typo-squatted names ("meta-llama" versus look-alikes) exist.
• Pin revisions: reference a commit hash, not just main, in production configs.
• Check hashes of downloaded files against published checksums, and mirror approved models into an internal registry.
• Scan repositories with available malware and pickle scanners; prefer safetensors or GGUF releases.
• Be wary of re-uploads, merges and quantisations by unknown accounts: the license still applies, the weights may have been tampered with (for example backdoored with trigger phrases), and the declared base model may be wrong.
• Track an AI bill of materials: model, version, hash, license, data provenance, and fine-tuning datasets, the same way you track software dependencies.

Choosing a license for your own model

When you release weights you have trained or fine-tuned:

1. Check what you inherit. A fine-tune of a Llama-licensed model must follow the Llama license; a derivative of an OpenRAIL model must carry its use restrictions; Apache-2.0 bases leave you free to choose, subject to notices.
2. Check your data. Training data licenses (for example non-commercial datasets) and model-output terms may constrain how you can license the result.
3. Decide your goal. Maximum adoption and simplicity favours Apache-2.0 (patent grant) or MIT. Wanting to bind downstream uses favours a RAIL-style license, at the cost of not being open source and of extra friction for adopters. Wanting to share for research only favours a non-commercial license.
4. Publish a complete model card with license, intended use, data summary, evaluations and limitations, and release in safetensors.
5. Consider the full open-source standard: releasing code and data information under OSI-compatible terms makes your model genuinely reproducible and widely trusted.

Common pitfalls

• Assuming "open" means "open source". Read the license; most popular open-weights models carry use restrictions.
• Reading the license of the wrong version. Terms change between generations and sometimes between sizes in the same family.
• Forgetting that derivatives inherit obligations, including quantised and merged models you redistribute.
• Loading pickle checkpoints from unknown sources, or enabling trust_remote_code without pinning and reading the code.
• Ignoring output and distillation clauses when generating training data.
• Not recording versions and hashes, which makes later audits and incident response impossible.

In practice

Mature teams maintain an approved-models list reviewed by legal and security, with each entry recording license, version hash, permitted uses and required notices. Engineers pull models only from an internal mirror, in safetensors or GGUF, with revisions pinned. Before any customer-facing release, they confirm attribution and naming obligations, propagate required use restrictions into customer terms, and ship a model card. Licensing landscapes shift quickly, so re-check terms at each model upgrade. Nothing here is legal advice; for commercial decisions, read the current license text and consult a qualified lawyer.