Guides · Open-Source AI

Open-Weight vs Open-Source AI Licenses: What Enterprises Can Actually Use

By Loïc Jané·Updated August 18, 2026·10 min read

At a Glance: "Open" means different things in AI, and the difference matters commercially. Strict open source (OSI-approved, like Apache 2.0 or MIT) and open weight (source-available, like Meta's Llama Community License or — for most enterprise uses — the Kimi K3 License) both let a business self-host and use a model commercially in nearly every practical scenario. For internal company deployment, the licence is rarely the blocker; the real task is reading the exact terms, checking for scale-based conditions, and archiving everything so your DPO can stand behind it. This guide decodes the licenses you will actually meet and how to review one in minutes.

Open Weight vs Open Source: The Distinction That Matters

The AI industry borrowed the word "open" from software but did not import the definition.

Strict open source means the OSI definition: the license is approved, everyone gets the same rights, derivatives and redistribute under the same terms. In practice for models, that usually means Apache 2.0 or MIT — permissive licenses that allow commercial use, modification and distribution with few conditions. Models published this way (several from Mistral, Alibaba's Qwen family in part, many small and mid-size models) are the closest AI has to familiar open-source software.

Open weight (or source-available) means something narrower: the trained weights are public and you may use them, but under a purpose-written license that may add conditions — attribution at scale, a model-as-a-service clause, or restricted fields of use. Meta's Llama Community License and Moonshot's Kimi K3 License live here. These are often called "open weight" rather than "open source" precisely because they do not meet the OSI definition. A fresh, well-known example in August 2026: Alibaba's Qwen3.8-Max (a 2.4-trillion-parameter model with 95 billion active) ships under a dedicated Qwen3.8-Max License — open weight, but a source-available licence, not OSI open source.

The practical point for a business: both buckets are deployable commercially, and both let you self-host. The difference shows up in the fine print and the scale thresholds, not in whether you can get started.

The Licenses You Will Actually Meet

License	Filed as	Commercial self-hosting	Watch out for
Apache 2.0	OSI open source	Yes, freely	Attribution in substantial derivations; patent grant
MIT	OSI open source	Yes, freely	Attribution in copies/substantial portions; no warranty
Llama Community License	Open weight / source-available	Yes	Scale thresholds for MAU before it becomes conditional; no model-as-a-service without agreement above limits
Kimi K3 License	Open weight (MIT-based)	Yes; internal use explicitly exempt from conditions	Attribution above 100M MAU / $20M revenue; separate agreement for large-scale model-as-a-service

This is a map, not legal advice — always read the actual text and, for anything you will build on, have counsel confirm it. But notice the pattern: the permissive OSI licenses are essentially frictionless, and the open-weight licenses are permissive too at any realistic enterprise scale. The hard cases are niche (reselling the model itself at huge scale), not the everyday self-hosted deployment.

Why Licenses Matter More As Models Keep Shipping

We are a year or two into a flood of open-weight releases, and the compliance risk is not the flagship frontier model — teams read the card for those. The risk is the assistant that a developer installed from a leaderboard, whose license nobody read. Shadow deployments are where licensing problems actually live in companies.

Three habits close that gap:

License review is part of the intake. Every model that touches company data gets its license read, archived, and its obligations recorded — the same discipline as dependency scannuses in software engineering.
Field-of-use clauses get read literally. A rare model restricts certain industries or purposes; the small print decides whether it is usable for your case.
Distribution is treated separately from internal use. Serving the model to your own teams is one thing; exposing it as a service to customers is another, and that is where most conditions trigger.

What "Internal Use" Actually Means In Practice

For the overwhelming majority of Fleece deployments — a model self-hosted behind a gateway, used by your own teams with RAG on your documents — internal use is the operative scenario, and across these licenses it is the lightest one:

Apache 2.0 and MIT: no meaningful conditions beyond attribution; internal self-hosting is entirely ordinary.
Kimi K3 License: internal company use is explicitly out of scope of the scale-based conditions — it behaves like MIT for your own teams.
Llama Community License: internal use is permitted and standard; conditions scale with your user base if you gate the model behind a product.

The moment it changes is if you offer the model as a service to third parties — that is where model-as-a-service clauses and revenue thresholds come into play, and where counsel is worth the call. If you are integrating a model into software you sell to clients, the terms apply to your product, and that is a different (still usually workable) conversation.

How to Review a Model License in Minutes

Read the actual text. Open the license file — it is linked from the Hugging Face model card or the publisher's repository. Headlines and blog posts paraphrase and get it wrong.
Answer three questions: (1) Commercial use allowed? (2) Self-hosting and modification allowed? (3) Any conditions — attribution, scale thresholds, fields of use, model-as-a-service? If all three are clean, you are deployable.
Check your scenario against the conditions. "Allowed" is not the same as "unconditional". Confirm whether your usage plan (internal, client product, hosted service) triggers any clause.
Archive everything. Save the license text, the pinned weight version and its checksum. This is what lets your DPO answer "what model, under what terms?" in an audit.

Common Pitfalls

Trusting the label, not the license. "Open" and "free" are marketing until you read terms. Read the file.
Ignoring the difference between internal use and distribution. Serving to your own teams and shipping it in a client product are governed differently.
Skipping the archive. A permissive license still needs pinned versions, checksums and an archived text file to stand up in an audit.
Assuming model-as-a-service clauses never matter. They rarely matter for self-hosting — and they matter absolutely if you resell model access at scale. Know which side of the line you are on.

Frequently Asked Questions

What is the difference between open-weight and open source AI?

Open source (as in Apache 2.0 or MIT) means an OSI-approved license granting the same rights to everyone, including redistribution under the same terms. Open weight (or source-available) means the trained weights are public under a purpose-written license that may add conditions — like Meta's Llama Community License or Moonshot's Kimi K3 License. Both allow commercial use and self-hosting in nearly every practical enterprise scenario; the difference shows up in scale-based conditions and attribution, not in whether you can get started.

Can my company use an open-weight model commercially?

In nearly all practical cases, yes. Apache 2.0 and MIT models are freely usable commercially. Permissive open-weight licenses like the Kimi K3 License also permit commercial use, with obligations that only trigger at extreme scale (attribution above 100 million monthly users or 20 million dollars of monthly revenue) — and internal company use is explicitly exempt. The Llama Community License allows commercial use within defined scale thresholds. Read the exact license for your chosen model, but the default answer for a self-hosted internal deployment is 'yes'.

Does the licence let us self-host and fine-tune?

For Apache 2.0, MIT, and the permissive open-weight licenses (Kimi K3, Llama), self-hosting and fine-tuning are permitted. That is precisely what makes open-weight models deployable on your own infrastructure. The light conditions that exist target attribution and extreme-scale redistribution, not internal use and adaptation — which is why self-hosted deployments are rarely the hard licensing case.

Is it a problem if an open-weight model comes from a Chinese publisher?

Not because it is open weight. Self-hosted, the weights run entirely on infrastructure you control and the publisher never sees your prompts, so the sovereignty point inverts. The diligence that remains is license review, output quality on your tasks, and your own governance — the same for any model regardless of origin. The licensing question is about the terms, not the flag.

Do I need a lawyer to deploy an open model in my company?

For a purely internal self-hosted deployment under Apache/MIT or a permissive open-weight license, usually not — read the license and archive it. Involve counsel when a model is embedded in software you sell to clients, or when you plan to serve it to third parties as a service, because that is where distribution and model-as-a-service clauses become relevant. We review this with the client's DPO in every deployment.

Which open models are truly open source (Apache 2.0 or MIT)?

Apache 2.0 and MIT models include several from Mistral and parts of Alibaba's Qwen family, plus many smaller models trained and released under permissive licenses. Many frontier or recent open-weight releases use source-available licenses instead. The license is always stated on the model card — check the exact file rather than relying on category labels, since 'open' alone does not tell you which regime you are in.