Why Commercial Companies Open Source: The Motives Behind "Free Weights" and the Fine Print in Licenses
We · October 2026
This is the first article in the "Open Source & Commercial Use" series. The series answers two questions: why commercial companies open source, and how the clauses in their licenses are designed. Two other articles in the series are already live: 《Open Source Software Licenses Explained》 covers the rules of software licenses themselves; 《audio.cpp Model Licenses and Commercial Use》 goes through each model on our platform and whether it can be used commercially; 《Where Model Files Actually Come From》 covers what to check before you download—this article covers why the license is written that way. We don't review, rank, link out, or give legal advice. All clause descriptions in this article follow each repository's LICENSE file as of October 2026.
1. Start with the counterintuitive question
How much does it cost to train a frontier model? Public reports commonly put the figure in the hundreds of millions of dollars. Running inference costs money; API pricing pages spell it out clearly. Then the same company puts the trained weights on a download site, price tag at zero.
The only coherent explanation is this: the free part isn't charity—it's business. The weight is just a file that can be copied. What's actually being sold lives elsewhere: compute, subscriptions, enterprise contracts, standards influence. When we catalog the license information for apps and models on our platform, we keep running into the same pattern. Almost every "free" release has a clear commercial logic behind it. And almost every one of those logics has a corresponding clause buried in the LICENSE file.
Let's pin down two terms first. The rest of the article depends on them:
- "Open source" is marketing language. It shows up in launch events, blog headlines, and download-site tags. It just means "you can download it and look at the code."
- The license is the actual commercial contract. It spells out whether you can use it commercially, whether you can offer it as a service, whether you have to attribute, and under what conditions the grant can be revoked.
- The Open Source Initiative (OSI) has a strict definition of "open source license." The community licenses, research licenses, and BSL-style clauses used by major model providers do not qualify. So we call them "open weights" below. This isn't pedantry. If you read these clauses with "open source" intuitions, you will almost certainly misjudge them.
Once those two terms are separated, only two questions remain: what is the company after, and what is buried in the clauses.
2. Five motives: a single company usually holds several at once
2.1 Ecosystem lock-in: grab the developer's default starting point
Meta's Llama family and Google's Gemma family are the textbook examples here. Both have complete closed-source commercial product lines behind them. Releasing the weights doesn't earn money from the model itself—it locks in the company's format and toolchain as the developer's default starting point.
Once the fine-tuning community, the quantization community, and the inference-engine ecosystem are all built around one model family, migration costs finish the job for them.
Llama has offered free weights to researchers since the second generation and moved to large-scale commercial availability after March 2024. The Gemma family has long been distributed alongside Google's cloud services. One observable pattern: in local AI communities in China and around the world, quantized and fine-tuned versions built on the Llama and Qwen families have consistently dominated by volume. The ecosystem battle is largely decided the day the weights go free.
2.2 Revenue funnel: use the free version as an acquisition channel
In this model, the boundary between free and paid is drawn with surgical precision—and the boundary itself is written into the license.
- Alibaba Cloud's Qwen family: the online API and Bailian platform charge, while multiple weight versions are open for download download. Their custom Qwen License allows free commercial use but sets a threshold of 100 million monthly active users; beyond that, you must negotiate a separate commercial license.
- Stability AI: the community license states that companies with annual revenue under $1 million can use it commercially for free; above that, you must purchase an enterprise license and register. That revenue line isn't a restriction—it is the pricing.
- Mistral: the 7B small model (April 2024) is fully open under Apache 2.0; the flagship version once used the Mistral Research License to restrict commercial use. Small models bring people in; large models collect the money.
The common thread in all these clauses is a single sentence: the smaller you are, the freer you are; the bigger you are, the more you pay. This is commercially coherent: small users aren't worth charging; large users have to pay.
2.3 Defensive weapon: use the license to compress competitors' margins
DeepSeek's V3 and R1 weights are released under MIT. No MAU threshold, no geographic restriction, no naming requirement—the most permissive tier available. This choice has a clear commercial meaning beyond the technical: when your training efficiency is an order of magnitude better, giving the weights away for free compresses the margins of every closed-source provider charging per token. The academic version of the R1 paper landed on the cover of Nature in September 2025. The MIT license turned that method into public infrastructure for the whole industry at the same time.
OpenAI's release of the gpt-oss family in August 2025 under Apache 2.0 is the other side of the same coin. The more charitable reading isn't that OpenAI chose to open up—it's that the squeeze from the open-weights camp made "not offering downloadable weights" start to get expensive. One more thing worth noting: the very term "open source" at the time sparked a definitional debate. That恰好 confirms this article's core point: the word the publisher uses and the actual constraint in the clause are two different things.
2.4 Compliance and narrative control: write the rules into your own license
The Gemma license ships with a Prohibited Use list that explicitly rules out weapons, biochemical applications, and other abuse directions. These clauses serve two purposes. Externally, they're a compliance posture and a boundary of liability. Internally, they remove one approval hurdle when the model enters regulated industries.
One layer deeper: whoever writes the license gets to define "what counts as compliant." When a company turns "Built with Llama" into a contractual obligation and writes MAU thresholds into the clause, it is effectively writing its commercial interests into the industry's default compliance language.
2.5 Community as outsourced R&D: save on conversion and adaptation costs
Once weights are released, the community spontaneously produces GGUF conversions, quantized versions, inference adaptations, and cross-platform packaging. If the company did all that itself before release, it would be a significant engineering expense. The community does it for free—and does it more thoroughly, because they face all sorts of non-standard hardware.
One comparison is instructive. Terraform is also open-source code, but its commercial value sits in managed services and enterprise contracts; the community never solved "can I run this on my machine" for it. Model weights are different: whether they're usable at all depends heavily on the adaptation ecosystem. So for model companies, community adaptation isn't a byproduct—it's a necessary operating condition.
This is also why almost every company releasing open weights takes a permissive or even encouraging stance toward community quantization versions. Strict license wording doesn't mean排斥 the ecosystem.
3. Nine clause designs: every one of them is public
This section is the core of the article. Not a single clause is hidden; they're all in the LICENSE file. The reason we call them "designs" is simply that most people never open that file. Let's be clear up front: this section isn't accusing anyone of deception—it's teaching how to read. The grading rubric is already printed on the answer sheet.
1. Scale thresholds. The Llama family has had a 700-million-MAU clause since the second generation, retained through 3.1, 3.3, and Llama 4. Qwen's custom license sets a 100-million-MAU threshold. The meaning is straightforward: companies reaching this scale must have a channel to negotiate a commercial license with the original provider.
2. Revenue caps + registration requirements. The typical combination in community licenses like Stability AI's is: below a certain annual revenue, commercial use is free; above it, you must buy an enterprise version—and you must register on the website for it to take effect. The second half is the most commonly missed: if you haven't registered, the grant itself may not be valid.
3. Ban on using outputs to train competitors. Both Llama 2 and Llama 3 licenses prohibit using model outputs to train other models. This restriction was relaxed starting with Llama 3.1, but a new obligation was introduced in exchange: derivative models must prominently attribute Llama. One restriction traded for one obligation—this is the most common exchange structure in license negotiations.
4. Forced brand bundling. Llama 4 (effective April 5, 2025) requires that redistribution or derivative products display "Built with Llama." Derivative models trained on its outputs must have names starting with "Llama." The Qwen License has a symmetric "Built with Qwen" attribution clause.
5. Geographic restrictions. The Llama 4 community license attaches restrictions for EU companies on the distribution of multimodal models. The same document grants different rights in different jurisdictions.
6. Revocability. This is the one we most want ordinary users to remember. Rights granted under Apache 2.0 and MIT are irrevocable: once granted, the original author cannot take them back. Custom community licenses from various providers generally reserve the right to terminate; Llama 4 explicitly states that Meta can terminate the grant. The conclusion is: the more permissive the license, the more freedom it gives you; the more custom the license, the more revocation rights the publisher keeps. This isn't a coincidence—it's by design.
7. Code and weights licensed separately. In the same repository, the code is Apache 2.0 and the weights are under a different set of terms—this is the norm in AI projects. Three real examples:
- Black Forest Labs' FLUX: in the same batch of repositories, the schnell weights are Apache 2.0, the dev weights are under a non-commercial research license.
- OpenAI's Whisper, CLIP, and tiktoken are permissively open source; the GPT family services are closed source.
- Aggregation repositories whose README says Apache 2.0 while individual packaged weights are actually CC BY-NC—this isn't rare. OmniVoice, for example: the code is Apache, but the weights are restricted by the license on the training data; 《audio.cpp Model Licenses and Commercial Use》 flags this separately.
One more thing: GitHub's automatic license detection can be wrong. The audio.cpp LICENSE file contains the full standard Apache-2.0 text, but the repository tag shows NOASSERTION. So always read the file, not the tag.
Code and weights are two layers; weights you modify yourself form a third. Whether quantized, LoRA-adapted, or fine-tuned outputs remain governed by the original license is covered in depth in 《After Quantization, LoRA, and Fine-Tuning, Is the Model Still Governed by the Original License?》—we don't expand on it here.
8. Relicensing is the norm, not the exception. This one is most easily misled by historical information like "it used to be Apache." The same product line changing licenses across different years has happened many times in the AI and infrastructure industries:
| Project | License change | Date |
|---|---|---|
| Qwen family | Research license → Apache 2.0 → custom Qwen License for some versions | 2023-08 → 2024 → 2025 |
| Qwen-Image | Previous generation Apache 2.0 → version 2.1 switched to research license (SaaS and weight redistribution require commercial license) | 2026-09 |
| Terraform | MPL 2.0 → BSL 1.1 (promises automatic reversion to MPL 2.0 after four years) | 2023-08 |
| MongoDB | SSPL introduced | 2018 |
| Elasticsearch | Apache 2.0 → SSPL + Elastic License v2 dual license; AGPLv3 added in 2024-08 to make it triple-licensed | 2021-01 → 2024-08 |
| CockroachDB | Apache 2.0 → BSL | 2019-10 |
| Redis | BSD → RSALv2 / SSPLv1 dual license | 2024-03 |
| Mistral | 7B Apache 2.0 → flagship on research license → early 2025 multiple model weights announced switch back to Apache 2.0 | 2024 → 2025 |
The Terraform case is the most complete. Within a month of the relicensing, competitor companies launched the OpenTF Manifesto; OpenTofu then entered the Linux Foundation as an independent fork. At the same time, BSL itself states that each version automatically converts to MPL 2.0 after four years. Restrictions have an expiration date—this is a completely different strategy from "permanently closed source."
One pattern in this table is worth noting even more: almost every relicensing spawns a fork. Elasticsearch's relicensing produced OpenSearch; Redis's produced Valkey; Terraform's produced OpenTofu—all three now under the Linux Foundation. Qwen-Image's September 2026 relicensing sparked a public debate in the technical community about "where the open source promise went." The debate itself is worth a look: relicensing is usually legally fine, but it costs community trust.
Our only practical recommendation here is: go by the LICENSE of the version you actually use. Historical information, previous generations' statements, other people's summaries—none of that counts. Relicensing has a complete storyline: why it clusters, whether it has retroactive effect on older versions, what the forks take with them. 《Why Open Source Projects Switch Licenses Mid-Stream》 in this series covers that story in depth—we don't expand on it here.
9. "Open weights" does not equal "open source." The OSI's list of recognized open source licenses does not include community licenses, research licenses, or BSL. Precision in wording isn't pedantry. If you make decisions treating these as "open source," you will underestimate the clauses. If you make decisions treating them as "open weights plus a commercial contract," you'll actually read that contract.
4. A spectrum table: from permissive to restrictive
The table below is ordered from permissive to restrictive, not ranked, and not a recommendation. Each cell represents a difference in clause type; verify against the original text for specific projects.
| License | Camp | Free commercial use? | Can offer as a service? | Main threshold | Revocation risk |
|---|---|---|---|---|---|
| MIT | Permissive open source | ✅ | ✅ | Retain copyright notice | None (grant is irrevocable) |
| Apache 2.0 | Permissive open source | ✅ | ✅ | Retain notice + NOTICE + mark modifications | None |
| CC BY-4.0 | Attribution | ✅ | ✅ | Must attribute | None |
| Custom provider license (Qwen License, etc.) | Open weights, not OSI open source | ⚠️ Below scale, yes | ⚠️ Depends on clause | MAU threshold + forced attribution + specified jurisdiction | Yes |
| Community license (Llama / Stability style) | Open weights, not OSI open source | ⚠️ Registration required, has cap | ⚠️ Depends on clause | MAU or revenue cap + ban on training competitors + brand clauses, some with geographic restrictions | Yes |
| Research / non-commercial license (incl. FLUX dev style) | Non-commercial | ❌ | ❌ | Use restricted, no commercial negotiation space | Yes |
| CC BY-NC family | Non-commercial | ❌ | ❌ | Non-commercial + attribution, common for models with restricted training data | Yes |
The most effective way to read this table is to look at the last two columns. The further down you go, the more specific the conditions you must meet, and the more rights the publisher reserves. The top three permissive tiers compress obligations down to a single thing: "retain the notice." The lower tiers simultaneously set scale lines, use restrictions, attribution obligations, and revocation rights.
How exactly are these obligations triggered? Distribution, dynamic linking, network service, NOTICE retention—《Open Source Software Licenses Explained》 on this site goes through the boundaries of GPL, AGPL, LGPL, and MPL clause by clause. That article covers software licenses; this one covers model weights. Only after you take the intersection of both layers do you get your actual freedom.
5. By your role, check three things each
| Who you are | First three things to check | Further reading on this site |
|---|---|---|
| Just playing locally, learning and researching | ① Is use restricted to non-commercial? ② Does it require registration to take effect? ③ Do quantized versions inherit the original license? | 《Where Model Files Actually Come From》, and for campus use, 《Do Schools and Research Groups Need to Care About Licenses When Using Open Source Models and Software》 |
| Content creator (taking paid commissions) | ① Does the weight license allow commercial use? ② Are there extra clauses on ownership of generated content? ③ Voice and likeness authorization | 《What Speech AI Is Doing》 |
| Developer integrating models into products | ① Main license camp | ② Strictest clause in the dependency tree |
| Team offering services externally | ① Any MAU / revenue cap? ② Is the service itself restricted? ③ Can the grant be terminated? | 《audio.cpp Model Licenses and Commercial Use》 |
One specific reminder: quantization, format conversion, and LoRA fine-tuning all produce derivative works; the original model's license continues to apply. This is already stated in 《audio.cpp Model Licenses and Commercial Use》, but community quantization download pages usually don't repeat it. So when we catalog models on our platform, we make "can it be used commercially" a separate field rather than leaving users to infer it themselves.
To understand how many hands a model passes through from training to landing on your disk, see 《Where Model Files Actually Come From》. To understand how these models are organized into usable agents, 《The AI Agent Landscape》 covers a different layer.
6. Our take
First, the motives aren't secrets, and neither are the clauses. All nine designs above come from public documents. Where a company draws the scale line, whether it grants revocation rights, whether it requires attribution—these reflect its understanding of the business. Reading these tells you more about what it's doing than reading its launch deck.
Second, the more permissive the license, the closer it is to industry public infrastructure. DeepSeek on MIT, gpt-oss and FLUX schnell on Apache 2.0—what really changes the industry isn't the model capability, it's letting everyone stand on it without bearing authorization risk. Conversely, the more specific the license, the more it looks like a fence custom-built for a particular business model. The fence itself isn't malicious, but you need to know whether you're inside it or outside it.
Third, ordinary users need to read licenses too, because the cost asymmetry is brutal. Reading a LICENSE takes a few minutes. Misjudging a commercial authorization once can cost you a product takedown or a lawyer's letter. There is no substitute for this.
The five motives in this article share one assumption: the publisher has something to sell. Schools, labs, and individual developers don't fit that assumption. Their free really isn't business—the motives and clauses are a different half of the story. 《Why People Who Aren't in Business Also Open Source: License Choices by Universities, Labs, and Individual Developers》 in this series covers that half.
If we had to give this series a direction, we'd say: "Open source" answers "can you get it"; the license answers "what can you do once you have it." On the local AI chain, users are already used to caring about VRAM, quantization, and speed. The next field that deserves equal attention is that sub-200-character LICENSE file. Once those judgments have been made and made correctly, the license information should be built directly into the download and and installation flow—not left in documentation for someone to look up later. We believe this is what local deployment tools should look like when they reach the last mile.
Disclaimer: This article is our summary of public information and does not constitute legal advice. Community-sourced information in the text is labeled as such; query time is October 2026. For any decision involving real commercial interests, consult professional legal counsel and always go by the project's current LICENSE file.