Open Source vs. Open Weight: What Model Licenses Actually Allow

If you need a model you can put behind a paid product, fine-tune, redistribute, and eventually replace without asking a vendor, “open weight” is not enough. Start with the actual license: an Apache-2.0 release is a very different operational choice from a downloadable model governed by a custom community agreement and an acceptable-use policy.

The practical translation is simple: weights are an artifact you can download; a license is the set of permissions and obligations that determines what your team can do with that artifact. Treat the model page’s “open” badge as a discovery hint, not a procurement answer.

The useful distinction: downloadable is not permissionless

Open weights normally means the trained parameter files are available for local inference, inspection, or adaptation. That is valuable. It means you can run an inference stack on your own hardware, measure latency with your own prompts, pin a model revision, and avoid sending every request to a hosted API.

It does not automatically mean you can redistribute those weights in an appliance, train a competitor, use them for every business purpose, or publish a fine-tune under a name you choose. Nor does it mean you can reproduce the model from first principles. A checkpoint without the training code, data information, filtering process, and hyperparameters is often useful to deploy but not realistically forkable in the way a source repository is.

The Open Source Initiative’s Open Source AI Definition is a good test for that stronger claim. It requires the freedoms to use, study, modify, and share, plus the preferred form for modification: data information, complete training and run code, and parameters. Under that definition, weights alone are not an open-source AI system.

Read the license like it is part of your deployment manifest

Before a model enters a repo, run through the same questions you would for a database driver or a copyleft dependency. Put the answers next to the model version in your architecture decision record. Do this before the proof of concept grows a customer-facing endpoint.

1. What exactly may we do? Look for explicit rights to use, copy, modify, create derivatives, distribute, and offer the model through a hosted service.
2. What must travel with a redistribution? Check for a LICENSE file, NOTICE text, attribution language, model-name requirements, or a requirement that downstream users accept the same terms.
3. Do restrictions attach to our fine-tune, distilled model, synthetic-data pipeline, or only the original checkpoint? Definitions of “derivative” can be much broader than a Git diff.
4. Is there a field-of-use policy? A ban on particular applications, customers, jurisdictions, or attempts to bypass safety controls can matter more than the download button.
5. Is there a scale trigger? Check revenue, monthly-active-user, or volume thresholds, and whether affiliates count.
6. Which version did we approve? Save the model commit SHA, license text, policy URL, and date reviewed. Model cards and web-hosted policies change.

A quick shell habit helps. When you pull a model repository, inspect the legal files before wiring it into Ollama, vLLM, or a CI image:

find . -maxdepth 2 \( -iname 'license*' -o -iname 'notice*' -o -iname '*policy*' -o -iname 'readme*' \) -print

Then read the referenced URLs too. The most consequential restriction is often incorporated by reference rather than printed in the repository’s LICENSE file.

Apache-2.0 is the cleanest answer—within its scope

When model weights and the relevant code are released under Apache License 2.0, you get broad copyright permissions to reproduce, modify, distribute, sublicense, and distribute derivative works. Apache-2.0 also includes a patent grant from contributors for claims necessarily infringed by their contributions. Your redistribution obligations are real but familiar: preserve license text, retain applicable notices, mark modified files, and carry forward any NOTICE content.

That is why an Apache-2.0 model is usually the easiest option for a product team that wants to package a checkpoint into an internal platform or commercial service. Mistral, for example, lists Mistral Small 4 under Apache-2.0. But do not convert that fact into “the entire training system is open source.” An Apache license on a released artifact answers the rights question for that artifact; it does not by itself prove that training data information and full training code are available.

Apache is also not a warranty. It does not certify the provenance of training data, guarantee non-infringement beyond the license’s defined patent grant, or make a model safe for a regulated workflow. Your product still needs its own evaluation, privacy review, and controls.

Custom community licenses can be commercially usable—and still not open source

Llama 4 is a useful example because the license grants broad rights to use, reproduce, distribute, modify, and create derivatives. For many teams, that is enough to self-host or fine-tune it. But it is a custom commercial license, not an OSI-approved open-source license, and it comes with conditions your release process must absorb.

If you distribute Llama materials, a derivative, or a product or service containing them, the Llama 4 agreement requires you to provide the agreement, retain an attribution notice, and prominently display “Built with Llama.” A model created by using Llama materials or outputs to train, fine-tune, or improve another model must also begin its name with “Llama.” The agreement additionally requires a separate license request for organizations whose products or services exceeded 700 million monthly active users in the preceding calendar month on the release date.

None of that makes Llama unusable. It makes it a dependency with branding, redistribution, and downstream-model obligations. If your plan includes distillation into a small on-device model, those provisions belong in the design review, not in a legal cleanup after launch.

Policies can reach farther than the weights

Gemma demonstrates another thing engineers miss: a terms page may define “Model Derivatives” broadly enough to cover not only modifications, but models created by transferring patterns from the weights, operations, or output—including some distillation and synthetic-data approaches. Its terms also incorporate a prohibited-use policy and apply to hosted services. In other words, running the checkpoint behind your own API does not remove the contract; it can be the event that makes redistribution and policy compliance relevant.

This is where “open weight” is bad at communicating risk. It compresses local execution, source availability, commercialization rights, safety restrictions, and derivative-model rules into two friendly words. Your build system cannot enforce a marketing label. It can enforce a model allowlist tied to a specific version and approved use case.

Make the choice operational, not ideological

For a developer tool, internal coding assistant, or customer feature, choose the narrowest license risk you can live with. If you need straightforward commercial redistribution and maximum latitude for derivatives, prefer a model whose relevant artifacts are Apache-2.0 or another OSI-approved license. If a custom-license model is materially better for your workload, record every required attribution, naming rule, scale threshold, and attached policy, then make someone own them.

And be precise in your own documentation. Say “we self-host model weights released under Apache-2.0” when that is what you mean. Say “we use an open-weight model under a custom community license” when that is what you mean. That wording prevents the next engineer from assuming they can ship a fine-tune, remove an attribution line, or reuse outputs for training without checking the one file that actually decides it.