Open Weights vs Open Source AI: What the Difference Actually Is

The definitions, precisely

Open weights means a model's trained parameters are published for download, under a license permitting at least some use, inspection, and fine-tuning. Open source AI, as formalized in the OSI Open Source AI Definition, requires substantially more: the freedoms to use, study, modify, and share the system, backed by the complete code used for training and inference, the model parameters, and sufficiently detailed information about training data to allow a skilled person to build a substantially equivalent system. The difference is the pipeline. Open weights gives you the output of a training process; open source AI gives you the process itself, or enough of it to recreate and genuinely modify the system rather than only adapt its endpoint. By this standard, most celebrated open releases, including many models labeled open source in their marketing, are open weights: the parameters are public, but training code is partial or absent and data information falls short of reproducibility. The label matters because the two categories support very different claims about transparency, auditability, and control, which the rest of this page separates.

What open weights actually give you, and it is a lot

Open weights should not be dismissed as openness theater, because the practical freedoms are substantial. You can run the model on your own hardware, which is the foundation of sovereign AI: no API dependency, no usage surveillance, no deprecation risk. You can inspect activations and attention patterns, probe for biases and backdoors behaviorally, and quantize or distill for deployment, including running 7B-class models on consumer GPUs. You can fine-tune: LoRA and MoE adapter approaches adapt a frozen base cheaply, which is how most real-world specialization happens. And you can verify artifact identity: a downloadable file has a hash, so anyone can confirm they are running exactly the published model, a property hosted APIs cannot offer even in principle, since the provider can change the model behind the endpoint silently. What open weights do not give you: knowledge of what the model was trained on, the ability to retrain it differently from scratch, or grounds to audit training-data provenance and consent. Those live on the other side of the line.

What the gap withholds: data, code, and reproducibility

The distance between open weights and open source AI is concentrated in two artifacts. Training data information is the larger one: without knowing what a model was trained on, you cannot audit for contamination of evaluation benchmarks, assess copyright and consent posture, explain systematic biases at their source, or reason about memorized sensitive data. The OSI definition requires sufficiently detailed data information rather than the raw datasets themselves, a pragmatic compromise that acknowledges legal constraints while still demanding meaningful disclosure; many releases provide nothing beyond a vague description like publicly available data. Training code is the second: the full pipeline including preprocessing, filtering, and hyperparameters, without which even a well-resourced lab cannot reproduce or fundamentally modify the model, only fine-tune its surface, a distinction that matters for decentralised training efforts trying to build on prior work. The consequence is a transparency asymmetry: open-weights models can be audited behaviorally (what does it do?) but not causally (why does it do it, and what shaped it?). Honest labeling, weights-available versus open source AI, is the minimum the ecosystem owes users.

Verification: the dimension both definitions underweight

There is a third dimension the open weights versus open source debate mostly skips: whatever is published, how do you know the artifact you downloaded is the artifact that was released, and that the claims attached to it are true? Licenses govern rights, not authenticity. The verification stack starts with digests and grows from there, as detailed in the model integrity guide: checksums prove file identity, signatures prove publisher, and attestation proves that specific parties vouched for specific claims at a specific time. QBC's release illustrates the strong end of this stack applied to an open-weights model. Its served model, the frozen Qwen2.5-7B base (itself an Apache-licensed open-weights release) plus a 10-expert Sephirot MoE adapter, is published on HuggingFace, and its manifest root was attested by validator quorum on-chain at block 1,097,990, with a model registry binding served inference to that exact artifact via per-block commitments. Training progress on the adapter is itself quorum-measured. Openness plus attestation answers a question neither license category addresses: is the model you are using the model they say it is?

Practical guidance: reading a model release critically

When a release crosses your desk, five checks locate it honestly on the spectrum. One: are the raw weights downloadable, and under what license, specifically what restrictions apply to commercial use and derivatives? Two: is training code published, all of it, including the data pipeline, or only inference code, which is the common sleight of hand? Three: what data information is disclosed, and would it satisfy the OSI standard of enabling a substantially equivalent rebuild? Four: are evaluation claims reproducible, with pinned harnesses and disclosed prompts, or just headline numbers? Five: is artifact identity verifiable, digests at minimum, signatures or on-chain attestation better? Applied to QBC's own release, honestly: weights open, adapter training measured and attested on-chain with specific claims (GSM8K up about 10 points, MMLU flat), artifact identity attested by quorum; the frozen base model inherits Qwen's open-weights status, not full open source AI, and QBC does not claim otherwise. That kind of precise labeling is what the open training movement and community frontier-model efforts need to normalize: openness as a checklist, not a vibe.

Attested provenance in practice: a worked release

What openness plus attestation looks like operationally is easiest to see in a concrete release trail. When QBC unified its served model, moving phi measurement, training, and serving onto one in-process artifact, the release was documented in the v7.1 unification post: which components changed, what the resulting manifest contains, and where its root landed on-chain. Capability claims shipped separately, in the real benchmarks post, with named suites and honest nulls: GSM8K up about 10 points, MMLU flat, no aggregate marketing number. Training provenance for the adapter is continuous rather than episodic, because every accepted epoch passed quorum-measured held-out evaluation before finalization, giving the release a public improvement series rather than a single launch claim. The pattern generalizes into a release discipline any lab could adopt for open-weights models: publish the artifact, publish the digests, attest the manifest somewhere external, and attach falsifiable numbers, which is the release-side half of verifiable AI. Provenance of model outputs downstream, the other half of the story, connects to content provenance standards. None of this requires full open source AI status; it requires treating a release as evidence.

Running open weights well: the efficiency question

The freedoms open weights grant are only real if you can afford to exercise them, which makes inference efficiency part of the openness story. A 7B-class model in full precision wants more memory than most contributors have, so the practical stack leans on quantization of weights and, increasingly, of the attention cache: KV cache quantization attacks the memory term that grows with context length, which is usually what actually evicts consumer hardware from the game. QBC's serving stack demonstrates the payoff: its TurboQuant work, described in the efficient inference post, reached a 3.8x reduction in KV cache memory with cosine similarity 0.998 against the unquantized baseline, keeping the attested 7B model servable on modest hardware while every inference still emits its Proof-of-Thought commitment. Efficiency also compounds the sovereignty argument: the cheaper it is to run your own copy, the less gravitational pull hosted APIs exert, and the more people can independently reproduce published metrics rather than trusting them. When you evaluate an open-weights release, check what the community can actually run it on; a model only inspectable inside a data center is open in license but closed in practice.