Open-model licenses in plain language

Open weights and open source are not the same thing

When people call a model open, they usually mean open weights. Weights are a large file of numbers produced by training. Once you have that file, you can run the model on your own server, get answers from it and wire it into your business processes without calling anyone else's cloud.

Open source in the traditional sense means considerably more: the training code is published, the composition of the training data is described, and anyone can reproduce the result from scratch. For the vast majority of well-known models that is not the case. What gets published is the finished weights file and a technical model card, while the kitchen stays behind closed doors.

The practical takeaway is simple. Do not carry habits from ordinary open-source software over to models automatically. Before deployment, look at what was actually released and on what terms.

• The model weights, meaning the file you download and run.
• The serving code and helper tools, which may carry their own separate license.
• The training data, rarely published and usually under different terms.
• The model card or report describing limitations and known weak spots.

Apache 2.0 and MIT: the calmest options

These are two classic permissive licenses inherited from the software world. Broadly speaking, both allow commercial use, modification and distribution of modified versions, and neither requires you to open your own source code. For a business this is the most predictable arrangement you will encounter.

The main obligation is similar in spirit for both: preserve the attribution and the license text wherever you distribute derived material. If you simply run the model inside your own company and never hand the files to anyone, the obligations are noticeably lighter, but keeping the original license files next to the model is still a good habit.

The difference usually mentioned first is the patent clause. Apache 2.0 explicitly addresses the grant of patent rights related to the material, and it also terminates those rights if the recipient starts patent litigation against the authors. MIT contains no such construction and is shorter and simpler. Lawyers often treat Apache 2.0 as the better protected option precisely because of that clause.

Neither license offers any warranty of quality, and both disclaim the authors' liability for consequences of use. That is not a formality, and we return to it below.

The Llama community license: commercial, but with strings

The Llama family ships not under a classic permissive license but under its own terms-of-use document. Commercial use is allowed, and for the overwhelming majority of companies it works without friction, yet the set of obligations is noticeably wider than under Apache 2.0.

The point discussed most often is the user threshold. The terms are written so that very large services, whose product audience at the time the model was released exceeds the threshold stated in the document, must request separate permission from the rights holder. Small and mid-sized businesses never come close to that line, but if you are planning a mass consumer product, read the clause carefully.

The second obligation concerns naming. If you distribute a derived model or a product built on it, you are asked to state the origin, include the family name in your model's name and keep a visible notice that the product is built on this model. That is not a prohibition but a packaging duty, and it is easy to forget.

The third is the acceptable use policy, a separate document listing prohibited scenarios: harm to people, circumventing the law, deception and similar categories. One more clause people miss: model outputs may not be used to train unrelated models except where the terms explicitly allow it.

Terms of use instead of a license: the Gemma pattern

Some models ship not under a license in the familiar sense but under a document called something like terms of use. The difference is more than wording. Such a document is usually structured as an agreement between you and the rights holder, and it tends to include clauses that classic licenses simply do not have.

The typical package looks like this: commercial use is allowed, fine-tuning and distributing derived versions are allowed, but you must pass the same restrictions on to anyone you hand the model to, comply with the prohibited-use policy, and accept that the rights holder reserves the right to demand that use of a specific version stops if it breaks the rules.

For a business the important part is that this is a living document. It can be updated for the next model release, and the terms for the new version may differ from the ones attached to the file you downloaded a year ago. So the version matters, and the download date matters twice as much.

There is an upside too. Such terms are usually drafted by a large company's legal team for a broad range of scenarios, and they read more clearly than people expect. The problem is not their strictness but the fact that almost nobody reads them to the end.

Non-commercial and research-only licenses

This is the category where a mistake costs the most. Licenses such as CC BY-NC, or labels like research-only, non-commercial and for research purposes only, mean the model was released for research, learning and personal experiments, not for making money.

What counts as commercial use is described broadly in such licenses. It covers not only selling access to the model but also using it inside a company for commercial benefit: handling customer requests, generating commercial copy, helping employees do paid work. Wordings and interpretations differ, which is exactly why a lawyer's reading matters here.

An important nuance: a non-commercial model does not become commercially usable after fine-tuning. The derived model inherits the restrictions. Nor does the restriction disappear because you charge for a subscription rather than for the model's answers, with the model being only one feature among many.

The practical rule is simple. If the product touches money in any way, non-commercial models belong in prototypes and hypothesis testing, while production runs a model with suitable terms. That is often a second model, and the migration is worth planning from the start.

AGPL and why businesses are wary of it

AGPL is a copyleft license. Its idea is that freedom should travel onward: if you take AGPL material, modify it and let people use the result, you must release the source of your version on the same terms.

The key difference from the older GPL is the network clause. Under classic GPL the obligation to publish source arose when you distributed the program. AGPL closes that gap: if users interact with your system over a network, through a website or a service interface, that counts as distribution and the obligation applies anyway.

For a company that has built a proprietary product around a model, this sounds like a demand to hand over its own work. In reality everything depends on what exactly falls under the license and where the boundary of a derived work runs, and that is precisely the question you should not answer without a lawyer.

In the model world AGPL appears less often on the weights themselves than on the surrounding tooling: serving stacks, libraries, interfaces. The whole set needs checking, not just the model file.

Regional carve-outs: where a model may not be used

A notable feature of recent years: some models ship with geographic restrictions. You will find wordings under which the license is not granted to users and companies located in certain regions, most often the European Union, the United Kingdom, Switzerland or South Korea. The reason is usually regulatory rather than technical.

What matters is not only where your company is registered but also where your product's users are and where your servers physically sit. A company in the UAE with customers in Europe and a server in Germany already spans three jurisdictions in one project.

Another restriction arrives from a different direction: export rules and sanctions regimes of the model's country of origin. They are not written into the license text, though they are usually referenced, and they apply regardless of what the parties want.

The planning takeaway is that geography belongs in the technical brief, not in the final checklist. If you operate in both Russia and the UAE, the list of usable models has to be checked separately for each environment.

The license on the weights and the rights to the training data

A common confusion. Permission to use the weights says nothing about the terms on which the texts, images and recordings used for training were collected. These are two separate layers with different questions attached.

The rights holder allows you to run the model but gives no guarantee that the training set contained no third-party protected material. Case law around this question is still forming in different countries, there is no single answer, and as of today the careful position is to treat the question as open.

The practical consequences show up wherever the model generates something that becomes your asset: website copy, advertising images, code inside your product. It is worth agreeing internally, in advance, what you publish under your own name and what review those materials go through.

If you fine-tune the model yourself, a third layer appears: the rights to your own data. That is covered in the guide on fine-tuning.

What a business should check before deployment

A practical sequence that takes little time and removes most of the unpleasant discoveries later.

1. Check the specific version, not the family. Terms can differ between releases in the same line, and a previous check does not carry over to a new model automatically.
2. Keep a copy of the license text and the model card as of the download date, together with the exact version name. The document on the vendor's site can change; your copy is the record of what you agreed to.
3. Check the licenses of the whole stack: weights, serving software, libraries, interface and any extra models such as translation or speech recognition.
4. Write your scenario down in one paragraph and show it to a lawyer along with the saved documents. The question is not whether Llama is allowed, but whether this specific use, in this specific way, for these specific users, is allowed for you.
5. Keep a simple register: which model, which version, which license, where it runs, who owns it. Update the entry whenever the model changes.

This list does not replace legal advice. It makes that advice fast and inexpensive, because the lawyer receives specifics instead of a request to research the field.

A license does not answer for what the model generates

The point people miss most often. A license answers whether you have the right to run the model. It does not answer who is responsible when the model quotes a wrong price, invents a fact, gives an incorrect medical or legal suggestion, or produces offensive text.

Almost every model license disclaims warranties and limits the author's liability. By default, therefore, the consequences land on whoever put the model in front of the customer, which is you.

From that follows a set of measures that belong to system design rather than law: separate general answers from facts the model pulls out of your own knowledge base, show the source, never let the model quote prices and deadlines on its own, put a human in the loop for sensitive scenarios, and keep a log of answers.

The higher the cost of an error in your field, the earlier a review procedure appears in the project. That is not bureaucracy; it is the only way to answer calmly what happens when the model gets something wrong.

What this looks like in practice on your own server

When a model is deployed inside a company, the licensing side usually turns into a few concrete artifacts. There is a list of what is installed, with versions and links to the saved documents. There is a description of where data lives and what exactly reaches the model. There is a decision about geography: which data center hosts the server and what follows from that.

Technical decisions then follow from the licensing ones. A non-commercial model moves to the test bench, while production gets a model with suitable terms. A tool under a copyleft license is either replaced or deployed in a way that keeps the derived-work question from arising at all.

Upgrades are handled explicitly. A new model version means a fresh terms check, not just a file swap. In practice that takes half an hour and happens once, before the upgrade, rather than after the product is already running on new weights.