Open Weight Is Not Open Source: What Businesses Should Know

Start with the release, not the label

For a business choosing an AI model, ask three separate questions: what can you download, what does its license allow, and what happens to customer data when you use it?

These questions do not have the same answer. For example, DeepSeek-R1's model card provides weight downloads, describes API access and identifies the license. API access and downloadable weights can coexist; they are not opposite categories.

What makes an AI model open source

The Open Source Initiative's Open Source AI Definition 1.0 requires freedoms to use, study, modify and share a system, including use for any purpose without asking permission. Its preferred form for modifying a machine-learning system includes three elements:

• Data information: enough information about the training data for a skilled person to build a substantially equivalent system. This includes provenance, selection and processing details, plus listings of publicly available data and data obtainable from third parties. The information must be under OSI-approved terms.
• Code: the complete source code used to train and run the system, including data processing and filtering, under OSI-approved licenses.
• Parameters: weights and other model configuration settings, under OSI-approved terms.

The definition calls for detailed information about even unshareable data; it does not require every raw training item to be redistributed. A third-party text rendering of the OSI page provides the full requirements if the original page is unavailable.

Weights are not hyperparameters. Google's Machine Learning Crash Course distinguishes model parameters, such as weights learned during training, from hyperparameters that control training. Learning rate controls the size of parameter updates; batch size controls how many examples are processed before an update.

Availability and licensing need separate checks

Two useful examples of publishers releasing more than final weights are:

• Pythia: EleutherAI's repository states that the models, data and code used in its paper were publicly released for research into interpretability and learning dynamics. Separately, the Pythia-70M model card identifies that model's license as Apache 2.0. That model-license statement does not establish a blanket Apache 2.0 license for its training dataset, The Pile. Review dataset permissions separately.
• OLMo: AI2's release page links model weights, code and reports, describes released training-data mixtures and lists evaluation tools. Treat these as artifacts to inspect, not a substitute for checking the terms of the particular release you intend to use.

These are examples of release transparency, not a legal certification of every artifact or a recommendation to deploy a research model unchanged.

Read two concrete licenses closely

Here, open weight means trained weights are made available to download. It is not a promise that the release meets all of OSI's requirements. Compare the artifacts and permissions in these two releases:

DeepSeek-R1: check the distilled model's base too

DeepSeek-R1's model card identifies its code repository and model weights as MIT-licensed and permits commercial use, modifications and distillation. The card describes training methods but does not link a pretraining dataset. A permissive weight license alone therefore does not establish a complete training release.

The card also identifies different bases for its distilled models: Qwen 2.5, Llama 3.1 and Llama 3.3. It points to their original licenses. Record both the distilled release and its base when reviewing permissions; do not assume every model with “R1” in its name has identical obligations.

Llama 3.1: requesting permission is not receiving it

The Llama 3.1 Community License covers trained weights under Meta's custom terms. Its additional commercial term applies if, on the Llama 3.1 release date, products or services made available by or for the licensee or its affiliates had more than 700 million monthly active users in the preceding calendar month.

A qualifying licensee must request a license from Meta. Meta may grant it at its sole discretion, and the licensee cannot exercise the agreement's rights unless or until Meta expressly grants them. Submitting a request is not enough. Section 1(b)(ii) also states that Section 2 does not apply to recipients who receive the materials from a licensee as part of an integrated end-user product.

Other obligations remain relevant even below that threshold. The same agreement includes attribution, redistribution and acceptable-use requirements. Review the whole agreement for the exact release rather than treating the user threshold as the only condition.

Hosted access is a separate decision

Do not use “API-only” as shorthand for every model sold through an API. Specific hosted-release examples include:

• GPT-4: OpenAI's launch announcement described text access through ChatGPT and its API.
• Claude 3.5 Sonnet: Anthropic's launch announcement listed Claude.ai, its iOS app, the Anthropic API, Amazon Bedrock and Google Cloud Vertex AI.

These are historical examples of hosted distribution, not a current availability shortlist. The announcements establish access channels; API access itself does not establish whether weights, training code or data information are separately released. Check those independently. DeepSeek-R1's downloadable weights and hosted API illustrate why that distinction matters.

What happens to business API data

The providers' current policies answer a different question: whether customer inputs become training material.

• OpenAI: API data is not used for training or improving models unless you explicitly opt in. Abuse-monitoring logs are retained for up to 30 days by default, with exceptions for legal requirements or protection from harm. Some features retain application state separately.
• Anthropic: commercial-product inputs and outputs are not used for training by default. Submitted feedback or other explicit permission can allow training use. Its policy distinguishes commercial offerings from consumer plans.

Do not read “not used for training” as “not stored.” Confirm the actual service, plan, endpoint, feedback settings and retention terms before sending customer information. For a third-party hosting platform, review that platform's terms too.

Quick comparison: separate artifacts from access

The first two columns describe release properties; the last describes a way of using a model. They can overlap. The OSI definition and release documentation above are the basis for this comparison.

Check	Meets OSAID 1.0	Downloadable weights alone	Hosted API access alone
Model parameters	Required under OSI-approved terms	Available; inspect license	Not guaranteed as a download
Training-data information	Required in sufficient detail	Not guaranteed	Not guaranteed
Complete training and running code	Required under OSI-approved licenses	Not guaranteed	Not guaranteed
Self-hosting decision	Inspect runtime and hardware requirements	Inspect license and runtime requirements	Check for a separate weight release and permission
Modification rights	Required by the definition	Read the exact license	Check provider features and contract
Customer-data handling	Assess your deployment	Assess your deployment	Assess the actual hosting service

What to record before approving a model

Use a short decision record for each proposed integration:

1. Exact release and base model: record the model version, not just a vendor name. Include the base of any distilled or fine-tuned variant.
2. Evidence of released artifacts: link the weight files, training code and data documentation separately. Mark missing evidence as not verified.
3. Permission for your use: record commercial-use conditions, attribution and redistribution duties. If separate permission is required, retain the grant—not merely the request.
4. Actual data route: identify who hosts inference and review training-use defaults, opt-ins, feedback handling and retention for that service.
5. Deployment review: test the proposed use, assign an owner for updates and decide what customer information may be sent. Do not treat self-hosting or an openness label as a complete privacy review.

For help evaluating an AI feature or chatbot, see our AI development and AI chatbot development services.