Open Source vs. Open Weight: Why the Difference Matters

Open weight means you can obtain a model’s learned parameters and usually run or fine-tune them yourself; open source means you have the practical freedoms and ingredients needed to study, modify, and share the system. The distinction matters because downloadable weights solve an immediate deployment problem, while open source determines how independently you can debug, reproduce, extend, and redistribute what you build.

Weights are useful, but they aren’t the whole model story

Think of an LLM as more than one giant file. The weights are the billions of learned numerical values produced by training. They are the part you load into vLLM, llama.cpp, Transformers, Ollama, or your serving stack to turn tokens into predictions. When a lab releases weights, you can often run inference on hardware you control, choose your quantization, keep prompts inside your network, and fine-tune adapters for a domain-specific task.

That is a big deal. For an engineering team, open weights can mean lower vendor lock-in, a private coding assistant, predictable per-token economics, or the ability to deploy in an environment where calling a third-party API is unacceptable. None of those benefits require knowing exactly how the original model was trained.

But if the output is strange, a benchmark claim looks suspicious, or you need to create a materially different base model, weights alone do not tell you the full story. You may not have the data recipe, filtering pipeline, tokenizer details, training code, hyperparameters, intermediate checkpoints, evaluation setup, or rights to redistribute derivatives. In other words: you can operate the artifact without being able to fully inspect or recreate the factory that made it.

“Open source” is a claim about freedoms, not just file access

In conventional software, source code is the preferred form for making changes. If a project gives you an executable but not the source, calling it open source would be misleading even if the executable were free to download. AI complicates that analogy because the behavior of a trained model comes from code, data, and parameters together.

The Open Source Initiative’s Open Source AI Definition frames the standard around four freedoms: use, study, modify, and share. For a machine-learning system, it says the preferred form for modification includes parameters, complete training and runtime code, and sufficiently detailed information about the training data for a skilled person to build a substantially equivalent system. Importantly, that does not necessarily mean every byte of training data can be republished; some data may be unavailable or legally restricted. It does mean the provenance, selection, processing, and replacement path cannot be a black box.

That is a stricter bar than most engineers mean when they casually say “open-source model.” It is also a useful bar. It asks whether another capable team can understand what produced the system and make meaningful changes without begging one vendor for hidden context.

What open weights let you do right now

Open weights are still valuable, and you should not treat the phrase as an insult. They provide concrete operational capabilities that closed API-only models do not.

• Run inference on your own laptop, workstation, cluster, or private cloud.
• Control deployment details such as batching, context limits, quantization, caching, routing, and observability.
• Fine-tune the released base model, often with LoRA or other parameter-efficient methods.
• Evaluate it against your own codebase, tickets, documents, and failure cases rather than trusting a public leaderboard.
• Avoid dependence on one hosted inference provider for availability, data handling, and pricing.

For many products, that is enough. If your goal is to run a capable internal assistant, an open-weight model under terms compatible with your intended use may be the best practical choice. You do not need to retrain a frontier model from scratch in order to get real autonomy at inference time.

Where open weight can stop short

The gap appears when you need deeper control. Suppose a model consistently produces poor results in a language, domain, or safety-sensitive workflow. With weights only, you can prompt it, retrieve better context, fine-tune it, or train a successor using its outputs. But you may not be able to audit the original data mix, repeat its pretraining run, identify whether a preprocessing decision caused the issue, or redistribute your result under terms your company expects.

Licensing is the other half of the problem. A model can be downloadable and modifiable while still imposing conditions that are unlike a standard permissive software license. Terms may apply to commercial use, redistribution, hosted services, acceptable uses, attribution, or downstream derivatives. For example, Google’s Gemma terms govern use, reproduction, modification, distribution, and hosted deployment under a separate agreement. That does not make Gemma unusable; it means “the weights are available” is not a shortcut for “the license is Apache-2.0-like.”

Treat model selection as a bill-of-materials review

Before putting a model behind a production endpoint, inspect it the way you would inspect a dependency with native code, a copyleft license, and a complicated supply chain. The useful question is not “Is this open?” It is: “Which layers are open, under what terms, and do those layers give us the control this project needs?”

1. Read the actual model license and any linked acceptable-use or distribution policy. Check hosted-service and derivative-model clauses, not just commercial-use language.
2. Confirm what is released: weights, architecture, tokenizer, inference code, training code, evaluation code, data documentation, and training checkpoints.
3. Separate your near-term need from your long-term need. Local inference may require only weights; independent reproduction or research-grade auditing requires much more.
4. Record the exact model revision, quantization, source, conversion tool, and serving configuration. Reproducibility inside your company starts with your own deployment notes.
5. Use precise language in architecture documents: say “open-weight model under X terms” unless you have verified that the full system meets an open-source standard.

This vocabulary is not pedantry. It keeps a procurement conversation from silently becoming a legal assumption, and it keeps an engineering experiment from being mistaken for a reproducible research foundation. Call a model open weight when weights are what you have. Call it open source when the system actually gives you the freedom—and the materials—to understand and change it.