Open-weight licenses decoded: MIT, Apache, and the gray zones

You found an open-weight model, the download worked, and you are ready to build. Before you do, there is a question that decides whether you can actually ship: what does its license let you do? "Open" is doing a lot of work in "open weights," and it spans everything from genuinely permissive open-source terms to custom licenses with real restrictions. This guide is a plain-language map of the license families you will meet and how to read them — not a substitute for legal advice.

"Open weights" is not one thing

First, untangle the words. "Open weights" usually means the model's trained parameters are available to download and run yourself, as opposed to being locked behind an API. That is a distribution fact, not a freedom guarantee. Having the weights tells you that you can run the model on your own hardware; it does not tell you what you are allowed to do with it.

The freedom question is answered entirely by the license attached to the release. And those licenses vary enormously. Some are standard open-source licenses you already know from software. Others are custom licenses written by the model's creator, with conditions that may restrict use cases, scale, or competition. The durable move is to never assume "open weights" means "do anything" — read the specific license every time.

The permissive family: MIT and Apache

The friendliest terms come from classic permissive open-source licenses. MIT is about as simple as licenses get: do almost anything, including commercial use and modification, as long as you keep the copyright and license notice. Apache is similar in spirit — broad permission including commercial use — with some additional structure, notably explicit handling of patent rights and a requirement to note changes you make.

When a model is released under one of these, your life is simple: you can generally build commercial products, modify the model, and redistribute, provided you preserve the required notices. These are the licenses to hope for when you need maximum flexibility. The main obligation is bookkeeping — keep the notices intact — rather than restriction on what you build. If you see MIT or Apache on a model and nothing else layered on top, you are in the most permissive territory available.

The copyleft idea: share-alike conditions

A second family attaches a condition: you can use and modify the work, but derivatives must be released under the same license. This "share-alike" or copyleft approach is common in software and in some content licenses. The intent is to keep the commons open by preventing someone from taking the work, improving it privately, and closing it off.

For models, the practical question is whether the share-alike obligation reaches what you build. If a license requires that your modifications — or things derived from the model — carry the same open terms, that may be fine for an open project and a deal-breaker for a proprietary one. There is nothing wrong with copyleft; it simply imposes a direction. Know before you build whether you are willing to release your derivative work under the same terms, because retrofitting that decision later is painful.

The gray zone: custom and "responsible use" licenses

Here is where most of the confusion lives. Many prominent open-weight models ship under custom licenses written specifically for that release. These are not standard open-source licenses, and they often include conditions that standard licenses never do:

• Use-case restrictions. Some licenses prohibit specific uses — certain harmful applications, particular industries, or competing with the provider.
• Scale thresholds. Some grant broad rights up to a certain size of deployment or user base, then require a separate agreement above it.
• Acceptable-use policies. Some incorporate a separate policy by reference, so the real restrictions live in a linked document that can change.
• Branding and attribution rules. Some dictate how you must credit the model or name derivatives.

These licenses can be perfectly usable — many are generous — but "open weights under a custom license" is not the same as open source. The principle to hold: a custom license means the rules are whatever that document says, so you have to actually read it rather than pattern-match to MIT. The word "open" in marketing does not bind the license text.

"Open weights" is not always "open source"

This distinction is worth stating plainly because it trips up careful people. Open source, in the established sense, means a license that grants broad freedoms without discriminating against fields of use. A license that forbids certain industries or certain competitors, however reasonable its motives, falls outside that established definition even if the weights are freely downloadable.

So a model can be "open weights" and genuinely useful while not being "open source" in the strict sense. Neither label is a verdict on quality — the point is precision. When you evaluate a model, separate two facts: can I get the weights, and what does the license permit? They are independent, and conflating them is how teams end up surprised.

What the license does not cover

A model release is more than a license file, and the license usually speaks to your rights in the weights and code — not to everything you might worry about. Two gaps are worth naming. First, the data the model was trained on is generally not handed to you, and the license over the weights does not resolve questions about that underlying data. Second, a permissive license is a grant of rights, not a warranty of quality or safety; "you may use this freely" is not the same as "this is guaranteed to behave."

The practical consequence is that compliance with the license is necessary but not sufficient. You can be fully within your rights and still inherit risks the license never addresses — about provenance, about behavior, about fitness for your particular use. The principle to carry: read the license to learn what you are permitted to do, and treat everything else — quality, safety, suitability — as a separate evaluation you still owe. A clean license answers the legal question, not the engineering one.

Layered terms and the "rug pull" worry

One subtlety of custom licenses is that they sometimes pull in other documents — an acceptable-use policy, community guidelines, brand rules — by reference. The license you agreed to may point to a separate page, and the real constraints can live there rather than in the main text. Because those linked documents can be updated, the rules governing your use are not always frozen at the moment you downloaded the model.

This is why careful teams read not just the license but anything it references, and keep a dated copy of the full set. The durable habit is to capture the complete terms as they stood when you built, so that if a referenced policy changes later you can show what you relied on. None of this is a reason to avoid custom-licensed models — many are excellent and generously licensed — but it is a reason to treat "the license" as potentially a bundle of documents rather than a single static file.

A checklist before you build on open weights

Run every open-weight model through the same questions:

1. Name the license. Is it a standard open-source license (MIT, Apache, a copyleft license) or a custom one? This sets your expectations.
2. Confirm commercial use. Does the license clearly permit building a commercial product, or is it limited to research or non-commercial use?
3. Check for use-case limits. Are there prohibited applications or industries? Does it reference a separate acceptable-use policy you must read?
4. Look for scale thresholds. Do your rights change above a certain deployment size or user count?
5. Understand derivative obligations. Must your modifications carry the same license? Must you publish changes or preserve specific notices?
6. Mind the output terms. Does the license place any conditions on what you do with the model's outputs, not just the model itself?
7. Record it. Keep the license text and a link with your project, so the answer is documented before launch, not reconstructed after.

The takeaway

"Open weights" tells you that you can download and run a model — nothing more. The license tells you what you may actually do, and it ranges from the wide-open permissiveness of MIT and Apache, through copyleft's share-alike conditions, to custom licenses with use-case limits and scale thresholds that look open but are not open source in the established sense. Do not pattern-match on the word "open." Name the license, confirm commercial rights, check for restrictions and derivative obligations, and write it down. The download is the easy part; the license is what decides whether you can ship.

This article is general information, not legal advice. For specific situations, consult a qualified attorney.