Open-Weight Model Licences Compared: What You Can Ship

"Open weights" is a description of availability, not of permission. Two models can both be downloadable and impose completely different obligations on what you do next, and the difference only surfaces when it is expensive.

The field in 2026 splits cleanly enough to be worth memorising, because the split does not track capability at all. Some of the strongest models carry the most conditions.

The MIT tier

GLM-5.2 and both DeepSeek V4 variants — Pro and Flash — ship under the MIT licence. MIT is about as permissive as software licensing gets: use it, modify it, redistribute it, sell it, embed it in a closed product, with essentially no obligation beyond keeping the copyright notice.

There is no revenue threshold to monitor, no restriction on offering the model as a service, no field-of-use limitation and no clause that changes as your business grows. Whatever you can do with the model today, you can do at a hundred times the scale.

The practical consequence is the absence of a whole category of work. There is no legal review to schedule before a launch, no compliance trigger to instrument, and no term that becomes a problem the quarter you succeed. For a startup that expects its usage to change shape, that predictability is worth real money.

Moonshot's terms are different

Kimi K3 and Kimi K2.6 are not MIT. Moonshot uses its own licence, and for K3 that licence is custom and includes a revenue threshold that applies specifically to offering the model as a service.

The structure is common in this space and the logic is straightforward: below the threshold you are broadly free, and above it there are obligations. It is aimed at large commercial redistributors rather than at engineering teams using the model internally.

Where this matters is where your product's value proposition is serving the model to customers. If you are building a coding assistant, an API resale business, or anything where the customer is paying for model access, the threshold is a term you need to read properly, and probably to have someone with a legal background read too. If you are running the model to help your own engineers ship your own product, it rarely bites. The Moonshot family explained covers the rest of the family's properties.

Qwen and the tier problem

Qwen ships permissive terms on most tiers, which is comfortable for commercial work. The qualifier matters more than it looks.

Licences in large model families vary by tier and by generation. The 27B you evaluated and the larger sibling you deploy may not carry identical terms, and a preview tier may carry terms that change at general availability. Assuming the family rather than checking the model card is where teams get caught.

The habit worth forming is to record the exact model identifier, version and licence at the moment you make a deployment decision. When someone asks eighteen months later what you are allowed to do, you want an answer from a record rather than a reconstruction. The Qwen family explained covers the tiers themselves.

Open weights is not open source

An MIT-licensed set of weights is not an open-source model in the sense the term originally meant. You get the numbers. You do not get the training data, the data-selection pipeline, the training code, or enough information to reproduce the model.

That matters for two practical reasons beyond the philosophical one. You cannot audit what the model was trained on, which is a real gap if you have obligations about provenance or contamination. And you cannot rebuild it — if you need a variant, you are fine-tuning what exists rather than training what you want.

None of that makes open weights less valuable, but it does mean the guarantee is narrower than the phrase suggests. The distinction in full covers where it bites.

What the licence actually buys you

Most teams that care about licensing never self-host. The value is optionality rather than deployment.

A permissive licence on open weights means that if your provider raises prices, changes terms, degrades quality, deprecates the model or disappears, you have somewhere to go. That is genuine insurance and it is the main reason to prefer an MIT model over a closed one at similar capability, even when you have no intention of running it yourself.

Be honest about what exercising that option costs, though. DeepSeek V4 Pro holds 1.6T parameters in memory and Kimi K3's weights are roughly 1.6TB. Migrating to self-hosted is a project measured in weeks and a bill measured in cluster time. The insurance is real; the excess is high. Open-weight against closed models weighs that trade.

A working checklist

Before committing to a model, answer five questions. Which exact model and version, since licences differ by tier. Does the licence restrict offering the model as a service, since that is where the conditions cluster. Is there a revenue or usage threshold, and do you have a way to notice when you approach it.

Then: does anything restrict your field of use or your jurisdiction. And can the terms change for a version you have already deployed, or does your copy stay under the terms it shipped with.

The decision rule is short. Building a product that resells model access — start from the MIT tier and treat everything else as a legal question. Using a model internally — capability and price should dominate, and almost any licence will be fine. Either way, record the answer at decision time. The open-weight field compared covers capability alongside these terms.