Kimi K3's weights went up on Hugging Face this week — 2.8 trillion parameters, one click, no paywall. The thread that followed said "open," and for the founder building an app on top of it, that's true enough to stop reading. For the founder building a business selling access to it, the interesting document isn't the model card. It's the license.

Short version, up front: the Kimi K3 License lets you use, modify, fine-tune, distribute, and sell what you build. It is not MIT and not Apache. It adds two conditions those licenses don't have — a $20M revenue trigger for Model-as-a-Service businesses, and a "display Kimi K3" requirement for very large products. Most teams never touch either. The ones who do are exactly the ones with the most to lose by finding out late.

The clause that actually gates you#

The trigger isn't how much you use K3. It's how you monetize it.

If you run a Model-as-a-Service — reselling inference or fine-tuning access where third parties control the inputs, parameters, or training data — the license says that once revenue across you and your affiliates crosses $20 million over any consecutive 12 months, you must sign a separate agreement with Moonshot. Not a notification. A negotiation.

That's a deliberate line. It waves through the entire long tail of builders — the SaaS product that calls K3 behind its own feature, the internal agent, the fine-tuned vertical model shipped inside a larger app. None of those are a MaaS. What it catches is the inference reseller: the "cheap K3 endpoint" startups, the routing layers that make their margin on the model itself. Give the weights to the developers, keep a hook on the people whose product is the weights.

MIT asks for a line of attribution. The Kimi K3 License asks for a phone call once your model-reselling business works. That's not a bug in the license — it's the business model of the license.

The second clause: attribution at scale#

There's a smaller one that's easy to miss. Any commercial product or service above 100 million monthly active users, or $20 million in monthly revenue, has to display "Kimi K3" prominently in its interface. This is a brand clause, not a compliance burden for normal apps — you will know long before you cross 100M MAU whether it applies. But it's worth filing, because it's the kind of term that turns into a redesign request from legal at precisely the moment you don't want one.

How it stacks up against the licenses you know#

The reason this feels unfamiliar is that the open-weight licenses founders default to don't work this way:

K3's move is to shift the gate from users to revenue. A MAU cap only catches consumer-scale platforms; a $20M revenue trigger catches a high-margin API reseller years earlier, while it's still small by user count. If you're picking an open-weight model because you intend to resell it, that difference is the whole decision.

What to actually do#

Three cases, three answers:

  1. You call the hosted API (Moonshot, Together AI, Modal). The self-host license conditions don't bind you; you're under service terms. Carry on.
  2. You self-host K3 inside your own product. You're almost certainly clear — you're not a MaaS and you're not at 100M users. Keep a dated copy of the license text with your dependency records and move on.
  3. You resell K3 access, or plan to. Read the license text on the model card now, model the $20M threshold against your revenue plan, and price the "separate agreement" as a real future line item — because it is one.

"Open" is a spectrum, and Kimi K3 sits at the permissive end of it. But permissive isn't unconditional, and the conditions here are aimed with intent. The founders who get surprised won't be the ones who couldn't read the license. They'll be the ones who assumed a free download meant a free license — and only checked when the revenue got interesting.

New this week: the full Founder's Wire for July 28 — MCP goes final, the real Kimi benchmark, and the single-node self-host math.