An open-weight model can be free to download and still carry conditions that matter in a product. The license decides whether you may use the weights commercially, modify them, redistribute them, or build a service around them. The label on a model card is only the start of that review.
This guide explains how to read those terms before a prototype becomes a deployment. It is a practical screening method, not legal advice.
Start with the exact release, not the model family
License review begins with the files you plan to use. Record the model name, version, publisher, download location, and license file that accompanied that release. Do the same for a fine-tune or quantized copy obtained from another repository.
A family name does not prove that every release uses the same license. Mistral’s licensing help page, updated August 12, 2026, says most of its open-source models use Apache 2.0, while certain models use a modified MIT license with an extra condition for companies above a stated revenue threshold. Mistral directs readers to the individual model cards for the applicable terms.
That is why a spreadsheet entry such as “Mistral: commercial use allowed” is too broad. The row should name the release and link the license that applies to it. The same caution applies to mirrors. A third party can package the weights in a different file format, but that packaging does not erase the publisher’s terms.
Our open model directory records licenses release by release. The earlier explainer on open-weight and open-source AI covers the larger distinction between downloadable weights and an open system.
A permissive license still has conditions
Apache License 2.0 is a useful baseline because its permissions and obligations are published in one standard text. The Apache Software Foundation’s license grants rights to reproduce, modify, sublicense, and distribute the covered work, subject to its conditions.
If you distribute the work or a derivative, Section 4 requires a copy of the license. Modified files need prominent notices that they changed. Relevant copyright, patent, trademark, and attribution notices must be retained. If the original distribution includes a NOTICE file, its applicable notices must travel with the derivative in one of the allowed forms.
Apache 2.0 also includes a patent license from contributors, with a termination clause tied to certain patent litigation. It does not grant general permission to use the licensor’s trademarks. The work comes without warranties, and the user remains responsible for deciding whether it fits the intended use.
In practice, “Apache 2.0” does not mean “nothing to do.” It usually means the compliance work is predictable: keep the license, preserve applicable notices, mark modifications, and separate license rights from branding claims. Check which artifacts the publisher actually placed under Apache 2.0. The model code, weights, tokenizer, example application, and documentation may not all share one license.
A custom community license needs its own checklist
Do not treat a custom model license as a renamed permissive software license. Read the grant of rights, the redistribution section, incorporated policies, commercial thresholds, naming rules, and termination language.
The Llama 4 Community License Agreement, effective April 5, 2025, illustrates the difference. It grants limited rights to use, reproduce, distribute, modify, and create derivatives of the Llama Materials. It also sets specific redistribution duties. A distributor must provide the agreement and prominently display “Built with Llama” in a related interface or publication. Copies must retain the stated attribution in a Notice file.
The agreement incorporates Meta’s Acceptable Use Policy. It also says that a licensee whose products or services exceeded 700 million monthly active users in the preceding calendar month on the release date must request a separate license and is not authorized under the community agreement unless Meta grants one.
Those details affect different teams. Product needs to know about interface attribution. Engineering needs to know which files and derivatives are covered. Legal or procurement needs the commercial threshold and incorporated policy. Release engineering needs the required agreement and Notice file in the shipped package.
Do not copy this example into a blanket “Llama terms” rule. Store it against Llama 4 and the April 5, 2025 agreement. A different Llama release can have a different agreement or effective date.
Commercial use is more than charging money
When a license says commercial use is allowed, ask what activity you will perform. Running a model internally, exposing it through a hosted service, shipping the weights with software, distributing a modified model, and using outputs to improve another model are separate acts.
A free download may be acceptable for internal inference but impose extra duties when the weights leave your organization. A custom license can also attach conditions to a hosted product even when customers never receive the files. Revenue, monthly active users, production use, or the identity of the licensee can trigger terms that a personal experiment never reaches.
Write the intended use in plain language before reviewing the license. For example: “We will fine-tune this release, host it in our cloud account, expose responses through our paid support product, and will not distribute the weights.” That sentence gives reviewers something concrete to compare with the grant and restrictions.
If the intended use changes, repeat the review. Approval for an internal evaluation is not evidence that redistribution or a customer-facing service is permitted.
Open source asks a broader question than access
The Open Source AI Definition 1.0 from the Open Source Initiative says an open-source AI system must grant freedoms to use, study, modify, and share the system for any purpose. It also describes the preferred form for making modifications as including detailed data information, the complete code used to train and run the system, and the parameters, all under appropriate terms.
That standard helps explain why public weights and commercial permission do not settle the “open source” question. A release can be useful, self-hostable, and available under a permissive license while still lacking the code or training-data information needed to reproduce substantial parts of the system.
For procurement, keep two columns: license permission and system openness. The first asks what your organization may do with the exact artifacts. The second asks what is available to study and modify the system. Combining them into one “open” field hides material differences.
Build a release record before deployment
Keep one review record per release. It should include:
- the canonical repository and the exact commit, tag, or revision downloaded;
- hashes for the weight and tokenizer files you store;
- every applicable license, Notice file, use policy, and model card;
- the planned activities: internal use, fine-tuning, hosting, distribution, or derivative publication;
- commercial thresholds and whether the organization is below them;
- required attribution, naming, license-copy, and modification notices;
- any prohibited uses or incorporated acceptable-use policy;
- who reviewed the record and the date of that review.
Save copies of the terms reviewed rather than relying only on a mutable web page. A current repository headline can change without altering what accompanied an older download. The saved record should make it possible to reproduce the decision later.
Then turn obligations into release checks. A requirement to ship a license belongs in packaging. A display requirement belongs in the product checklist. A restriction on redistribution belongs in artifact-access controls. The license review is useful only when its conditions reach the people building and releasing the product.
Sources and document stamp
Checked October 13, 2026 against the Open Source AI Definition 1.0, Apache License 2.0, Mistral’s open-model licensing guidance, and the Llama 4 Community License Agreement.
