Open weights vs closed APIs

"Open" is a spectrum, not a switch. What makes the local-AI scene possible is not philosophy — it is that permissively licensed weights exist, so engines, quantizers, and UIs have something to target. Know the tiers before you build anything on top of a model.

The spectrum

Families drift across tiers over time — a permissive release one version, a capped one the next — so check per model, not per brand. The tier names here describe the license, not the quality: capped Llama and Gemma releases routinely out-rank permissive ones on benchmarks.

Weights are not data are not code

• Open weights: you get the parameters and the tokenizer. You can run, quantize, fine-tune, and redistribute them (within the license).
• Open source, strictly speaking: weights + training data + training code. Rare — OLMo is the flagship effort; nearly everything else is open-weight only.
• The practical difference: open-weight models cannot be reproduced or fully audited; you trust the publisher's description. For running models locally, the weights are all you need.
• Training data and code, when published, live in separate repos (datasets, GitHub). Weights alone never tell you how the model was made.
• For trust, permissive ≠ audited: an Apache license says nothing about data provenance either. It says what you may do, not what was done.

Why the local scene runs on the permissive tiers

Every tool in this guide — llama.cpp and its GGUF quants, desktop UIs, OpenAI-compatible local servers — grew around downloadable weights, taking off with the first genuinely usable open 7B generation in 2023. Capped licenses still permit local use, which is why Llama-family models saturate the ecosystem despite not being open source in the strict sense. Permissive families get the deepest tooling simply because nobody has to read the terms first.

Gotchas to check before commercial use

• User caps: the Llama community license flips to a separate commercial agreement above 700M monthly active users. Irrelevant below that, but know it exists.
• Acceptable-use policies: Llama and Gemma ship usage policies that bind licensees — restricted use categories apply even below the caps.
• Naming and branding: notices like "Built with Llama" and Gemma attribution requirements are license obligations, not suggestions.
• Regional and entity terms: some licenses exclude specific jurisdictions or sanctioned entities; ordinary export controls stack on top.
• Quantized mirrors inherit the base license: a community GGUF of a Gemma model carries Gemma terms. Read the base model's license, not just the repo you downloaded from.

Check a license in 30 seconds

1. Open the model repo's LICENSE file — not the README summary, the actual license text.
2. If the repo is a quant/variant, click through to the base model it was quantized from and read that license instead.
3. Search the text for: "monthly active users", "revenue", "acceptable use", "attribution", "jurisdiction".
4. Decide only after step 3 — most caps never matter for small products, but you should know they are there.

Anatomy of a Hugging Face repo name

Qwen/Qwen2.5-14B-Instruct
 │      │         │   └─ stage/variant: instruct, chat, base, coder, vl, ...
 │      │         └─ size: parameter count
 │      └─ family + version
 └─ organization

community/Qwen2.5-14B-Instruct-GGUF
 └─ quantizer's repo: same weights, repackaged format

filename: qwen2.5-14b-instruct-q4_k_m.gguf
           family      size  stage  quant tag

Reading order: organization / family-version-size-stage. Original repos hold safetensors; community quantizers publish GGUF and other variants — the weights are the publisher's, and the license travels with them (model formats).

Judging repos in the wild:

• First-party orgs publish the originals; a handful of well-known community quantizers republish GGUF/AWQ variants of everything; unknown mirrors add no value and occasional surprises.
• Download counts and last-updated dates are decent health proxies — a stale quant of a two-generations-old model is usually a dead end.
• When two repos claim the same model, take the one linked from the base model's page.

Practical stance

• Hobby and local use: nearly any open-weight license is fine — you are running the model, not redistributing it.
• Shipping a product: Apache/MIT families save lawyer time; capped licenses are usually fine below the caps, but read the use policy once.
• Closed APIs: best raw frontier quality, zero local control, per-token pricing. A common hybrid: local models for volume, privacy, and latency; the API for the hard 5%.
• Redistributing weights is different from running them: shipping a GGUF inside your product is distribution — check terms first.
• Some licenses attach conditions to model outputs or fine-tuned derivatives; none (as of this writing) claim your prompts, but read before selling generated content at scale.

Local weights vs API, side by side

When local wins: privacy requirements, offline use, huge token volume, latency-sensitive UX, reproducibility (pin the exact weights). When the API wins: the hardest 5% of tasks, zero setup, elastic scale. Most serious setups end up hybrid.

How to choose concretely: choosing. What each family brings: model families.

Related: model families · choosing · model formats · engines