Open weights vs open source: the difference that matters

The distinction between open weights and open source determines whether you can fine-tune, redistribute, or legally embed a model in a commercial product. Most “open” models today release weights under restrictive licenses that look open but aren’t. Understanding the difference saves you from compliance surprises and architectural dead ends.

What the terms actually mean

Open weights means the model parameters — the tensors — are downloadable. You can run inference, fine-tune, and often quantize. But the training code, dataset, data preprocessing pipeline, and evaluation harness remain proprietary. The license typically restricts commercial use, derivative works, or deployment above a certain scale.

Open source means the entire artifact chain is available under an OSI-approved license: training code, data curation scripts, the dataset itself (or a reproducible recipe to reconstruct it), tokenizer, evaluation benchmarks, and weights. You can inspect, modify, redistribute, and embed without asking permission.

Llama 3.1 is open weights. Its community license forbids use by entities with >700M monthly active users and requires you to pass the license downstream. DeepSeek-V3 is open weights under MIT — permissive for weights, but the training pipeline is closed. OLMo 2 and BLOOM are open source: code, data, and weights under Apache-2.0 or RAIL.

# You can do this with any open-weights model
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")

# But you CAN'T do this with Llama — no training code released
# from llama.training import train  # doesn't exist

Licensing: the dimension that bites you

The Llama community license is the most common trap. It looks permissive until you hit the acceptable use policy: no military, no surveillance, no “harmful” content generation — terms vague enough that legal will flag them. DeepSeek-V3’s MIT license on weights is cleaner, but without training code you can’t prove the weights weren’t distilled from a proprietary model, which matters for IP indemnification.

Fine-tuning and adaptation rights

Open weights lets you fine-tune. Open source lets you reproduce the fine-tuning recipe exactly.

With Llama 3.1, you can LoRA-tune on your data. You cannot reproduce the base model from scratch. You don’t know the learning rate schedule, the data mix proportions, the annealing strategy, or whether synthetic data was used. If your fine-tune diverges, you debug in the dark.

With OLMo 2, the training config is a YAML file in the repo. The data mix is documented with exact token counts per source. You can ablate the pretraining recipe, then apply the same ablations to your fine-tune.

# OLMo 2 training config excerpt — reproducible
model:
  d_model: 4096
  n_layers: 32
  n_heads: 32
data:
  sources:
    - name: dolma-v1_7
      weight: 0.67
      tokens: 2.1T
    - name: starcoder
      weight: 0.15
      tokens: 480B
    - name: peS2o
      weight: 0.18
      tokens: 560B
optimizer:
  name: adamw
  lr: 3e-4
  weight_decay: 0.1
  warmup_steps: 2000

This reproducibility matters when you need to certify model behavior for regulated environments. “We fine-tuned Llama” is a black box. “We reproduced OLMo’s pretraining on our corpus with these three config changes” is an audit trail.

Deployment and operational constraints

Open weights models often ship with usage caps baked into the license, not the API. Llama 3.1’s 700M MAU threshold sounds high until you consider that a successful B2C feature can hit it. DeepSeek-V3 has no such cap on weights, but the model card warns against “high-risk” use without definition.

Open source models impose no deployment constraints beyond the license terms. Apache-2.0 and MIT let you run anywhere: on-prem, edge, air-gapped, multi-cloud, embedded in a device you ship to customers. No phone-home, no telemetry, no provider can revoke access.

# Deploying an open-source model to an air-gapped cluster
# No license server, no token, no external dependency
docker run --rm -v /models:/models \
  ghcr.io/huggingface/text-generation-inference:latest \
  --model-id /models/olmo-2-7b \
  --port 8080

Contrast with a managed endpoint where the provider can deprecate the model, change pricing, or enforce rate limits you can’t control. n4n.ai forwards provider cache-control hints and honors client routing directives, but the underlying model availability still depends on the provider’s decisions — something you avoid entirely when you own the weights and the license.

Ecosystem and tooling maturity

Open weights wins on ecosystem today. Llama has the deepest tooling: vLLM, TensorRT-LLM, llama.cpp, MLX, ExLlamaV2, Ollama, LM Studio. Quantization recipes are battle-tested. LoRA adapters are shared on Hugging Face by the thousands. If you hit a performance wall, someone has already solved it.

Open source models lag. OLMo 2 and BLOOM work in vLLM and llama.cpp, but you’ll find fewer pre-quantized GGUFs, fewer community LoRAs, less benchmark data on niche hardware. You do more engineering legwork.

The gap narrows fast. The Allen Institute releases OLMo checkpoints at multiple training stages specifically for research ablation. The community builds tooling around what’s available. But if you need to ship tomorrow, open weights has the shorter path to production.

Data transparency and compliance

This is where open source pays off for regulated industries.

With open weights, you have no visibility into the training corpus. Llama 3.1’s data card describes “publicly available sources” and “data filtered for quality.” You cannot verify whether copyrighted code, PII, or licensed creative works are in the weights. You cannot generate a data sheet for compliance review.

With open source, the dataset is part of the release. OLMo 2’s Dolma dataset has a datasheet documenting source domains, filtering criteria, deduplication strategy, and known limitations. You can audit for GDPR, CCPA, or sector-specific rules. You can filter the dataset yourself before retraining.

{
  "dataset": "dolma-v1_7",
  "source": "commoncrawl",
  "filters": [
    "language_id:en",
    "quality_classifier>0.5",
    "pii_detection:remove",
    "copyright_detection:flag"
  ],
  "deduplication": "minhash_lsh_threshold_0.7",
  "token_count": 2100000000000
}

If your legal team asks “prove this model wasn’t trained on our competitor’s codebase,” open source gives you an answer. Open weights gives you a shrug.

Cost structure: not what you think

Open weights is not “free.” You pay for:

• GPU hours for fine-tuning (same as open source)
• Inference infrastructure (same)
• Legal review of custom licenses (unique to open weights)
• Compliance risk from unknown training data (unique to open weights)
• Vendor lock-in if you build on a managed endpoint serving that model

Open source adds:

• Potential pretraining compute if you need to reproduce from scratch (rare)
• Engineering time for less mature tooling

The license review cost is real. A typical enterprise legal review of Llama’s community license takes 2-4 weeks and $15-40k in counsel time. Apache-2.0 takes hours. Multiply across model evaluations and the difference compounds.

Comparison table

Which to choose

Choose open weights when:

• Prototyping speed matters more than long-term IP clarity. You need a strong model today, you’ll swap it later, and you’re not shipping the model as part of a product.
• You’re building internal tooling. No redistribution, no external users, legal risk is contained.
• You depend on ecosystem tooling. You need vLLM optimization, specific quantization formats, or community LoRAs that only exist for Llama/Qwen/DeepSeek.
• The license fits your scale. Your MAU stays under thresholds, your use case doesn’t trigger acceptable-use restrictions.

Choose open source when:

• You’re embedding the model in a shipped product. Device firmware, mobile app, on-prem appliance — anywhere you can’t control the deployment environment.
• Regulated industry. Healthcare, finance, defense, government — anywhere you need a data sheet, provenance chain, or IP indemnification.
• You need to reproduce or ablate training. Research, safety work, or custom pretraining where you must control the data mix.
• Legal review budget is tight. Standard licenses are pre-approved; custom licenses aren’t.
• Long-term independence matters. No provider can revoke access, change terms, or deprecate the model.

The pragmatic middle path:

Start with open weights for velocity. Validate the use case. If it ships, budget the engineering time to migrate to an open-source equivalent or train your own on an open recipe. The migration cost is real but bounded — same architecture, same tokenizer family, same inference stack. What changes is the legal envelope and the audit trail.

# Migration pattern: same interface, different checkpoint
# Open weights
model_id = "meta-llama/Llama-3.1-8B-Instruct"

# Open source equivalent (when available)
# model_id = "allenai/OLMo-2-7B-Instruct"

# Your inference code doesn't change
from transformers import pipeline
pipe = pipeline("text-generation", model=model_id, device_map="auto")

The industry is converging. DeepSeek-V3’s MIT license on weights is a step toward open source. Meta releases more training details with each Llama generation. Allen Institute releases OLMo checkpoints at every training stage. The boundary will blur. But today, the license you sign determines the product you can ship. Read it before you fine-tune.