An open AI download needs a release packet before it becomes a product

DeepSeek, Qwen, Mistral and Gemma show why rights, training transparency and tested behaviour belong in separate parts of a release record.

A team can download a model in the morning and discover in the afternoon that it cannot distribute the package it planned to build. The difficulty is often hidden in an innocent phrase: open AI. That phrase can describe accessible weights, permissively licensed software, a research release or a system whose training process can actually be studied. Those are different starting points for a product.

The useful question is concrete: what exactly will this team use, modify, host or hand to someone else? A release packet answers that question for a named artifact. It connects rights, provenance and operational evidence without pretending that a download badge settles all three.

Start with the meaning of open

The [Open Source Initiative's definition, version 1.0](https://opensource.org/ai/open-source-ai-definition), links freedoms to use, study, modify and share with access to the preferred form for modification. Its machine-learning requirements include data information, code and parameters. This is a definition of openness, not an independent quality certificate for every model carrying an open label.

Keep the description proportionate to the evidence. If weights and inference instructions are available, say that. If the full training recipe or sufficient data information is missing, record the gap rather than silently treating it as present. A permissive weight license and an incomplete scientific reproduction package can coexist.

The repository name is only the beginning

The [DeepSeek-R1 repository's licensing section](https://github.com/deepseek-ai/DeepSeek-R1) says its code and weights use MIT, while separately identifying Qwen and Llama ancestors for its distilled checkpoints and their original licenses. That lineage is important: a family label does not remove the need to inspect the exact derivative and its upstream terms.

For a release packet, record the checkpoint identifier, revision, weight-file hashes, tokenizer and configuration alongside the relevant license files. If a distributor converted or quantized the weights, retain that distributor's identity and conversion description as well. A filename chosen by a mirror is not evidence that its contents match the upstream release.

Compare artifacts without generalising about companies

The official cards for [Qwen3-8B](https://huggingface.co/Qwen/Qwen3-8B) and [Mistral Small 3.1 24B Instruct 2503](https://huggingface.co/mistralai/Mistral-Small-3.1-24B-Instruct-2503) identify Apache 2.0. These are versioned examples, not a claim that every Qwen or Mistral product has identical terms, or that either is the newest release on 15 October 2026.

Google's [Gemma terms](https://ai.google.dev/gemma/terms), whose page reports an update on 1 April 2026, include distribution conditions and use restrictions. A team should preserve the terms applicable to its actual Gemma artifact and proposed use. Calling all these releases simply unrestricted would conceal a material difference.

A fictional publisher finds the missing handoff

Imagine a small publishing cooperative in Nairobi preparing an offline cataloguing assistant for partner libraries. This is an illustrative workflow, not a reported deployment. Its prototype reads invented book descriptions and proposes subject tags. The partners want a package they can install without creating an account with the cooperative.

That distribution requirement changes the review. The cooperative must describe what travels in the package: model files, tokenizer, runtime, application, example records and documentation. Each may have different provenance. The application license cannot by itself grant permission to redistribute all the other components.

The developer and librarian make a release inventory before choosing a candidate. They do not begin by collecting every model on a popularity list. One owner is assigned to each unresolved item, with the proposed distribution paused while the question remains unanswered.

Separate four kinds of evidence

Their first page records rights: the named files, applicable terms, notices and planned distribution. The second records provenance: where the files came from and how they changed. The third records technical reproduction: the runtime and configuration that produced the demonstration. The fourth records acceptance: which library tasks were actually tested.

This separation prevents a familiar slide in reasoning. A model can be legally obtainable yet fail the cataloguing task. It can perform well in a demonstration while its redistributed package lacks a notice. Neither a successful answer nor a license file is a substitute for the other kind of evidence.

Give modifications a history

Suppose the cooperative adds a small adapter, changes the prompt template and converts the result into another format. Its inventory should describe those as separate changes. The retained original remains available for comparison. A new package should not quietly reuse the old package's acceptance statement after its behaviour changes.

Write the modification record so a replacement maintainer can understand it. Include the purpose, input artifact, transformation tool version, output identity and a link to the relevant evaluation. Avoid claiming that a conversion reproduced the developer's research results unless that comparison was actually performed.

A model card is evidence to examine

The [Hugging Face model-card documentation](https://huggingface.co/docs/hub/en/model-cards) describes cards as Markdown and metadata accompanying a model, including intended uses, limitations, training and evaluation information. A card is therefore a useful starting document, but its assertions still need to be read with their authorship and scope visible.

For the fictional library package, the cooperative writes its own short system card. It explains that the assistant suggests tags from supplied text, that a librarian approves them, and that unsupported topics return for review. It describes the languages tested rather than announcing worldwide competence from the location of the model developer.

Distribution includes the person receiving the update

The partner library needs an identifiable version, readable notices, installation instructions and an ordinary way to remove the package. It also needs to know whether a later update changes rights, required hardware or output behaviour. A vague promise that everything will remain compatible cannot replace a tested upgrade path.

For an offline partner, a useful test is practical: can another authorised maintainer reconstruct the package from the retained inventory and understand which documents apply? If the answer depends on a disappearing chat message or a developer's personal cache, the handoff is incomplete even if the prototype still opens.

Leave unknowns visible

Training-data information can be incomplete, upstream terms can be ambiguous and a mirror can lack a verifiable history. Record the specific uncertainty and its consequence for the proposed use. Do not turn an unavailable document into an accusation, and do not invent a reassuring answer simply to finish a checklist.

The cooperative can still learn from a restricted research exercise while declining to distribute that artifact. It can also choose a different candidate with a clearer package. Those decisions should be documented as project choices, not as universal rankings of a developer or country.

What the release packet earns

The result is a claim another person can inspect: this exact package was reviewed for this use, with these retained obligations and these remaining gaps. That is more useful than a broad open-source badge attached to an unidentified file. It also makes a future model replacement easier to discuss without rewriting the project's history.

This is educational reporting, not legal advice or an endorsement of a model or license. Source terms were checked on 15 October 2026; organisations should obtain an appropriate review of their own intended use. No model was downloaded, evaluated or distributed for this article.

Evidence diagram and readable guide


Original explanatory diagram: four evidence lanes meet at a proposed-use review.

[Open the complete evidence diagram](/assets/open-source-workflow-release-rights-20261015.svg)

Read the diagram

**Review a model release**

Four evidence lanes meet at a proposed-use review. No arrow certifies legal compliance or model quality.

- **Exact artifact.** Identify the checkpoint, revision, tokenizer and files.

- **Rights and notices.** Retain applicable terms and notices for the intended use.

- **Derivation history.** Record upstream artifacts and each transformation.

- **Reproduction record.** Describe the actual tested runtime and configuration.

- **Task evidence.** Record the narrow task, reviewers and failures.

- **Review proposed distribution.** Review the evidence together; unresolved rights do not become permission.

Dashed outlines group parallel inputs. Arrows carry information for review, not a measured effect.