Open Source AI for the Enterprise: State of Play, Licensing, and Total Cost

The open-weight question has flipped. Capability is no longer the reason to say no: the best open-weight model scores 60 on the Artificial Analysis Intelligence Index against 63 for the top proprietary entry^[1]. The real decisions now live in two less glamorous places — the license file that ships next to the weights, and the total cost of actually operating them. This guide covers both, plus a framework for deciding which workloads belong on open weights at all.

1. "Open weight" is a spectrum, not a category

The central tension in 2026 is not open versus closed. It is that "open" itself has fractured into tiers, and the tier is decided per checkpoint, not per vendor. Mistral publishes its 675B-parameter Mistral Large 3 under Apache 2.0^[4] and its 128B Mistral Medium 3.5 under a "Modified MIT License" with a revenue-based carve-out^[5]. Alibaba's Qwen team ships Qwen3.8-27B under Apache 2.0^[6] while its 2.4T-parameter flagship carries a custom "Qwen3.8-Max License"^[7]. "The vendor is open" is therefore not a due-diligence conclusion. The checkpoint's license is.

Read the table as three tiers. Tier 1 is genuinely permissive open source — MIT and Apache 2.0 — where your obligations end at attribution. Tier 2 is the community license, pioneered by Meta: free for almost everyone, but with use-based strings (user thresholds, naming, an acceptable use policy). Tier 3 is the revenue-threshold license now favored by Moonshot AI, Qwen's flagship tier, and Mistral's mid tier: permissive until your company or your model-as-a-service business crosses a stated revenue line, at which point you owe the vendor a negotiation. The pattern worth noticing: several vendors put strings on the flagship and Apache on the mid-size — the strings sit exactly where the commercial value concentrates.

2. The landscape in August 2026

The frontier of open weights is now dominated by very large, very sparse mixture-of-experts models from Chinese labs. Kimi K3 pairs 2.8T total parameters with only 104B activated per token — 16 experts selected from 896 — plus native image input and a 1,048,576-token context window^[14]. DeepSeek-V4-Pro activates 49B of 1.6T parameters and also reaches a 1M-token context, under plain MIT^[2]. Mistral Large 3 is the strongest Apache 2.0 entry from a European lab: 675B total, 41B active, multimodal, 256k context, and deployable in FP8 on a single 8× B200 or H200 node^[4]. That sparsity is the economic story: what you pay to serve a MoE model tracks activated parameters and memory footprint, not the headline trillions.

For most enterprises the more consequential shelf is the mid-size one, because that is what you can actually afford to serve. Qwen3.8-27B is a dense vision-language model under Apache 2.0 with a 262,144-token native context, scoring 52 on the same index — one point behind a 1.6T-parameter frontier system^[6][17]. OpenAI's gpt-oss-120b runs 117B total parameters with 5.1B active and fits on a single 80GB GPU (H100 or MI300X)^[9]. Mistral's Magistral Small, a 24B reasoning model, "can be deployed locally, fitting within a single RTX 4090 or a 32GB RAM MacBook once quantized" per its own card^[18]. Serious capability now fits on hardware a platform team can reason about.

Meta's position illustrates the churn rate. Llama 4 Scout and Maverick, released April 5, 2025 with a then-remarkable 10M-token context on Scout^[10][12], remain Meta's newest flagships sixteen months later — and no Llama 4 variant appears in the top five of the open-weights index above^[17]. An open-weight leader can become mid-pack inside eighteen months without shipping anything wrong.

3. Licensing: what counsel actually needs to read

Open weight is not the same thing as open source, and the difference is not academic — it is written in the license file that sits next to the weights on Hugging Face. Your legal review should target four things in that file: scale thresholds and how they are measured, attribution and naming duties, acceptable-use restrictions, and termination triggers.

Tier 1: genuinely permissive

MIT and Apache 2.0 checkpoints are the only ones where "open source" applies without an asterisk. DeepSeek is the most explicit vendor here: the DeepSeek-R1 card states the series "support commercial use, allow for any modifications and derivative works, including, but not limited to, distillation for training other LLMs"^[8] — the only major license family that names distillation as a granted right, which matters if your strategy includes training small task models from a large teacher. Apache 2.0 (Mistral Large 3, gpt-oss-120b, Qwen3.8-27B) adds an express patent grant on top^[4][9][6].

Tier 2: community licenses

The Llama 4 Community License Agreement is free for the vast majority of enterprises, but it is a contract with Meta, not an open-source license. If your products exceeded 700 million monthly active users on the release date, "you must request a license from Meta, which Meta may grant to you in its sole discretion"^[11]. Distributed derivatives must "include 'Llama' at the beginning of any such AI model name"^[11], products must display "Built with Llama," use is bound to Meta's acceptable use policy, and the license terminates if you initiate litigation against Meta over the model or its outputs^[12]. None of those clauses will bite a typical internal deployment — but each is a diligence item if the model ships inside a product.

Tier 3: revenue-threshold licenses

The newer pattern converts the community license's user threshold into a revenue gate. The Kimi K3 License requires a model-as-a-service business whose aggregate revenue "exceeds 20 million US dollars... in total over any consecutive 12 months" to "enter into a separate agreement with Moonshot AI before using the Software or its derivative works for any commercial purpose," and requires "Kimi K3" to be "prominently displayed" on products above 100 million monthly active users or US$20 million in monthly revenue^[15]. The Qwen3.8-Max License uses the same shape at a US$50 million trailing-12-month threshold for model-as-a-service and AI-work-assistant businesses, with a display duty at the same 100M-MAU/US$20M-monthly line^[13]. Mistral Medium 3.5's "Modified MIT" gates on whether your company's "global consolidated monthly revenue... exceeds $20 million... for the preceding month"^[16] — note that this one measures your whole company, not your AI business line, which puts essentially every large enterprise on the paid side of the line for that particular checkpoint.

4. The adoption decision: four real drivers

Strip away the ideology and open weights earn their place in an enterprise stack through four concrete drivers. If none of them is strong for a given workload, the API vendor is almost always the better answer; if two or more are strong and you have a platform engineering team, open weights deserve a pilot.

The offsetting cost is operational burden, and it is chronically underestimated: serving infrastructure, capacity planning, security patching of the inference stack, evaluation, and the upgrade treadmill described above. A useful middle path exists — every major cloud now hosts open-weight models as managed endpoints — which captures residency and vendor-diversification benefits while outsourcing the serving problem. Treat "open weights" and "self-hosted" as separate decisions; conflating them is the most common error in these business cases.

5. Honest TCO: the GPU math nobody escapes

The license fee on an open model is zero, and that number is irrelevant. Self-hosting TCO is compute, people, and the treadmill. Start with compute, using published cloud rates as the floor — on-premises hardware changes the financing shape, not the order of magnitude.

Run the arithmetic before the architecture. One 8× H100 node at $41.528/hr^[3] is roughly $364,000 per year at 24/7 utilization — before storage, networking, a second node for availability, or a single engineer's salary. That figure only beats API pricing if the node is actually busy: at 30% utilization your effective cost per token more than triples, while an API bills you nothing for the quiet hours. This is why bursty or unpredictable workloads almost never justify self-hosting, and steady pipeline workloads sometimes do.

Model size sets the memory bill, and vendors now publish exactly what you need. Mistral's card states that running the 24B Mistral Small 3.2 "on GPU requires ~55 GB of GPU RAM in bf16 or fp16"^[19] — so even a "small" model at full precision wants most of an 80GB accelerator, and quantization is what brings it down to workstation scale, as with Magistral Small on a single RTX 4090^[18]. gpt-oss-120b was designed to the boundary: 5.1B active parameters, one 80GB H100^[9]. At the frontier, Mistral Large 3 in FP8 needs a full 8× H200 or B200 node^[4], and the trillion-parameter MoE flagships sit beyond a single node entirely. The serving-layer engineering that determines whether you hit acceptable throughput on this hardware — batching, KV-cache management, quantization strategy — is its own discipline; see /guides/llm-inference-at-scale for that half of the problem.

6. Honest objections: you probably don't need to self-host

The strongest case against the project most teams are tempted to run: most enterprises overestimate their need to self-host. Data control, the headline justification, is usually satisfiable several rungs below racked GPUs — dedicated cloud tenancy, in-region managed endpoints for the very open-weight models discussed here, and contractual data-handling terms cover the large majority of residency requirements without your team owning an inference stack. If the requirement is "our data stays in our tenant in our region," a managed open-weight endpoint meets it. Only "no third party may ever operate the serving infrastructure" actually forces self-hosting, and few regulatory regimes say that.

Capability cuts the same way. The three-point frontier gap is measured at maximum reasoning effort on the strongest open model^[1] — and that strongest open model is a 2.8T-parameter system^[14] that virtually no enterprise will serve in-house, under a Tier 3 license. What you can realistically self-host is the mid-size shelf, which is excellent but not frontier; for the hardest reasoning workloads the proprietary API remains the pragmatic default (see /guides/reasoning-models-enterprise-guide). Meanwhile the scarce resource in most AI programs is not GPU access but evaluation and platform engineering talent — and every engineer assigned to keeping vLLM clusters healthy is an engineer not building the retrieval, evals, and integrations that actually differentiate your deployment. Add the upgrade treadmill and the burden compounds annually.

Where the objection fails — and self-hosting genuinely wins — is a short list: air-gapped or classified environments; sovereignty mandates that name infrastructure operation, not just data location; sustained high-volume pipelines where a well-utilized node beats negotiated API rates; and distillation or deep-customization programs that require the weights themselves. If your workload is on that list, the economics and the licenses above are your map. If it is not, run open weights through a managed endpoint or do not run them at all.

7. The read

Treat open weights as a portfolio position, not a conversion. The defensible 2026 stance for a large enterprise: proprietary APIs for frontier reasoning and low-volume, high-variance work; one or two mid-size open-weight families (Apache 2.0 or MIT tier first) for high-volume, residency-bound, or customization-heavy workloads, served managed unless a hard requirement forces self-hosting; a standing eval harness that re-baselines quarterly; and a license register that records tier, thresholds, and duties for every checkpoint in production. That posture captures the leverage and the economics of open weights while spending your scarcest resource — platform engineering attention — only where it changes an outcome.