'Open Weights' Is Not 'Open Source.' Founders Betting Their Stack on the Difference Will Get Burned.

Let me be clear about where I stand before I say anything else. I build on open models. I want them to win. The strongest argument for open AI is that it lets people like us build companies without asking a lab for permission. This piece is not against open models. It is against the sloppy vocabulary that is about to cost some founders their stack.

Here is the problem. 'Open source' has become a marketing word that covers everything from MIT-licensed weights you can do anything with, to click-through community licenses with revenue gates and kill switches buried in the terms. Jensen's letter says 'open weights.' Moonshot says 'open frontier intelligence.' The press flattens all of it to 'open source.' Founders inherit the confusion, pick a model because a headline called it open, and bet their infrastructure on a license they never read.

Freedom Is Binary

The Open Source Initiative has spent decades defending a specific standard, and it exists precisely because vendors keep trying to sell conditional access as freedom. Nick Vidal of the OSI put it plainly: 'Freedom, by its very nature, is binary. You either have it, or you don't.' A license that is free until you hit a user cap is not free. A license the vendor can amend after you ship is not a license, it is a leash. The OSI's open-source AI definition goes further than most people realize. It requires access to training code and data documentation, not just a weights file on Hugging Face.

By that strict standard, very few models qualify. Pythia from EleutherAI does, Apache 2.0 with full training data and code. OLMo from AI2 does, Apache 2.0 with the complete training pipeline published. Google's T5 does, Apache 2.0 with the methodology documented. Then there is a second tier that fails the full OSI definition but carries genuinely permissive weights: DeepSeek under MIT, Qwen under Apache 2.0, Mistral Large 3 under Apache 2.0, and releases like Kimi K3 and GLM where you need to check each release's license individually because terms shift between versions.

And then there is everything else that gets called open but is not. Llama 4 ships under a Community License: free only if you stay below 700 million monthly active users, subject to an Acceptable Use Policy that Meta can change unilaterally, with naming constraints, IP claims that extend to model outputs, and newer versions that exclude EU persons entirely. Gemma 3 comes with Google retaining remote restriction rights. Older Mixtral releases had revenue thresholds. Phi-2 shipped under a restricted license. None of these are open source. They are freeware with conditions.

How You Actually Get Burned

These are not hypothetical distinctions. Here is how they hit a real company.

The user-cap trap. You build on a community-licensed model as a small startup, well under the threshold. Two years later you get acquired by, or sign a deep partnership with, a company above the MAU line. Your license evaporates mid-deal. The acquirer's lawyers find it in diligence, and now your core inference stack is a negotiation item, priced against you.

The AUP trap. The licensor updates its acceptable use policy and your use case becomes noncompliant overnight. You did nothing. The terms moved under you. This is a closed-API deprecation wearing an open costume, and you have exactly as much recourse as you would have had with a proprietary vendor, which is none.

The EU trap. Llama's newer licenses exclude EU persons outright, and the Llama license is likely not eligible for the EU AI Act's open-source exemption. That means two models both described as 'open' in the same news cycle can put you in completely different regulatory positions. If you serve European users or plan to, the word 'open' in a press release tells you nothing about your compliance posture.

The remote-restriction trap. Gemma-style retained rights mean the vendor can reach into your stack after the fact and restrict use of a model you already deployed. Read that again. A model sitting on your own hardware, in your own datacenter, and the vendor holds a contractual right to turn it off for you.

Read the License, Not the Blog Post

The fix is boring and it works. Before you make any model load-bearing, read the actual license, not the announcement. Check for user or revenue caps, field-of-use bans, rights the licensor keeps to change the acceptable use policy, IP claims over outputs, redistribution rights, EU eligibility, and whether the license is OSI-approved. MIT and Apache 2.0 are. Community licenses are not, no matter what the launch tweet says. For anything critical to your business, prefer MIT or Apache 2.0 weights. Treat community-licensed models the way you would treat a heavily discounted closed model: useful, sometimes the right call, but with strings you should price in from day one.

The stakes on this are rising, not falling. License terms now interact with regulation, since the EU AI Act carves out exemptions for genuinely open-source models and not for conditional ones. They interact with M&A, since acquirers re-run license checks and a shaky model license becomes a valuation haircut. They interact with geopolitics, since model bans and export fights are now live policy questions. 'It was on Hugging Face' is not a legal strategy, and no acquirer, regulator, or court will treat it as one.

Precision Is the Pro-Open Position

None of this is a reason to avoid open models. It is a reason to be precise, and precision is what the open ecosystem deserves from the people who benefit from it. The MIT and Apache 2.0 world is the real thing: irrevocable freedom you can build a company on, weights nobody can claw back, terms that survive an acquisition, an audit, and a change of heart in a vendor's legal department. The community-license world is vendor freeware with conditions, and calling it open source insults the projects that actually earned the term.

Both are useful. Only one is yours. Know which one you are holding.