What “Open” Means

Lesson 1 of 3 in Open vs Closed Weights.

“Open model” is a marketing phrase. Underneath it sit at least four separate claims, and a release can make any subset of them: the weights are downloadable; the training code and recipe are published; the training data is disclosed; and the license lets you do what you intend to do. Most releases marketed as open are precisely one of these: Open weights releases. You get the tensors. The data, the recipe, and — as the next lesson shows — sometimes a surprising amount of your freedom stay with the developer.

The vocabulary matters because each claim fails differently. A model can be open-weights and still legally encumbered. It can be permissively licensed and still be a black box you cannot retrain, because the data and recipe are private. Genuinely fully open releases — where a Model card documents the whole recipe — exist but are the exception: Hugging Face’s SmolLM3-3B card, for instance, describes itself as a “Fully open model: open weights + full training details including public data mixture and training configs”. That sentence is rare enough to be a selling point.

At the other end sit the Closed weights API families — GPT, Claude, Gemini — where the weights never leave the provider and you rent inference under proprietary API terms. Between the poles is where most of the landscape lives, and where the map-reading skill pays: given any Model release, you should be able to say which of the four claims it makes, from its card, before you commit anything to it.

Now the mechanical question: what does having the weights actually let you do? Four things, each of which this site teaches elsewhere:

• Self-host. Run inference on hardware you control — your VPC, your datacenter, a laptop. Nothing about your prompts or outputs transits the developer. (What running your own serving stack really costs is the managed-vs-self-hosted module’s subject.)
• Inspect. Load the tensors, read the architecture, probe activations. Interpretability work, security review, and honest debugging all start from access the API families simply do not offer.
• Adapt. Fine-tune the model on your data — fully, or cheaply with LoRA adapters — and distill it into something smaller.
• Compress and carry. Quantize the weights to fit smaller hardware, down to Edge deployment on devices, and pin the exact version in your artifact store forever. Nobody can retire a file you hold.

Just as important is what the weights do not grant. Not rights — those come from the license, which is a separate document making separate demands. Not the data or the recipe — you can run the model but usually cannot reproduce or fully audit it. And not support: no SLA, no deprecation notices, no one on call but you.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.