Our approach
● 12 questions before buying AI● How to respond when AI fails● Why AI citations are not proof● AI agents: who signs off?● Why smaller AI models matter● AI rules for product teams● 12 questions before buying AI● How to respond when AI fails● Why AI citations are not proof
Models7 min read · Updated 2026-10-09

Open weights, open source and AI licenses are not the same thing

A model can publish its weights without meeting the broader definition of open-source AI. Developers need to read the actual license before building on a model.

By Satya PrasadSource-led, independent technology analysis. See our editorial policy.
'Open' is one of the most useful - and most overloaded - words in AI. For developers, the important question is not the label. It is what the license and release actually let you do.

Topic diagram

A model release is a bundle of rights

ArtifactsWeights, code, data and documentation
TermsLicense, restrictions and obligations
Use decisionMatch rights to deployment and distribution
Quick answer: “Open” is not one legal or technical category in AI. Buyers should separately check whether weights are available, whether code and data are available, what the license permits and which restrictions apply.

Key takeaways

  • The main capability is useful only when it works in the real workflow.
  • Reliability, limitations and failure handling should be evaluated alongside headline performance.
  • Teams should define success with measurable operational outcomes.
  • Good product design makes uncertainty and responsibility explicit.

What are model weights?

Weights are the learned parameters that allow a trained model to produce outputs. Publishing weights can let developers download a model and run it themselves instead of relying entirely on a hosted API.

That can provide control over deployment, infrastructure and data flows. But access to weights alone does not tell you what you are legally or technically allowed to do with them.

Open weights are not automatically open source

The Open Source Initiative's Open Source AI Definition takes a broader view. It describes an open-source AI system as providing the freedoms needed to use, study, modify and share the system, and it addresses components such as source code, data information and model parameters.

A model publisher may therefore describe a release as 'open' while imposing conditions that differ from what developers expect from traditional open-source software.

Read the license, not the headline

Before using an AI model commercially, check the actual license. Look for restrictions on commercial use, redistribution, derivatives, user scale, geography, prohibited applications and trademark use. Also check whether the license applies to weights, code and other components separately.

A model may be free to download but still require a commercial agreement for certain uses.

There is also a technical question

Legal permission and practical usability are different. Developers should check hardware requirements, quantisation options, inference libraries, context limits, supported languages and model quality for their workload.

A model with permissive terms can still be a poor engineering choice if operating it costs more than using an API or if the team cannot maintain the infrastructure.

A simple due-diligence checklist

Record the model version, publisher, license URL and download source. Keep a copy of the license with the project. Document any changes made to the model. Confirm commercial rights before launch. Review dependencies and third-party components.

The result is a much safer approach to 'open' AI: treat openness as something you verify, not something you assume.

Why the word “open” causes confusion

In software, open source has a relatively established meaning tied to licenses and source-code availability. AI systems are more complicated because a model is produced from data and training processes, and the deployable artifact may be a set of learned weights rather than the original source code or training dataset.

A model provider can publish weights while withholding training data, training code or parts of the surrounding system. That can be useful for developers without meaning that every part of the system is open.

Weights are powerful, but they are not the whole stack

Model weights allow people to run or adapt a trained model under the terms of the applicable license. That can create more deployment flexibility than a closed API. Teams may be able to host the model themselves, customize inference or integrate it into environments where sending data to an external service is undesirable.

But the license still matters. “Downloadable” does not mean “do anything you want.” The rights granted by the license determine what users can legally do with the artifact.

What to check before adoption

  • Weights: Are the actual model files available?
  • License: What uses, redistribution and modifications are permitted?
  • Code: Is relevant source code available, and under what license?
  • Data: Is information about training data and provenance available?
  • Restrictions: Are there additional acceptable-use or application limits?
  • Support: Who maintains the model and handles security issues?

Open can change the economics

Self-hosting can reduce dependence on a vendor’s API pricing and allow tighter control over infrastructure. It can also create new costs: GPU capacity, deployment engineering, monitoring, upgrades, security and maintenance.

The correct comparison is not “open is free” versus “API costs money.” It is total cost and control across the lifecycle.

Questions readers ask

Is open-weight the same as open source?

No. The terms can describe different levels of availability. A model can publish weights without meeting the definition of an open-source license for all relevant components.

Can a company use any downloadable model commercially?

Not automatically. Commercial use depends on the license and applicable restrictions. Legal review is appropriate for important production deployments.

What should procurement ask for?

Ask for the exact license, model version, available artifacts, known restrictions, security process and documentation about provenance. Store the version and terms used for production so the organization can audit its decisions later.

The durable lesson is simple: treat “open” as a question to investigate, not a conclusion. Understanding exactly what is available and what rights are granted is part of responsible AI procurement.

Why this matters: The goal is not to predict the future with certainty. It is to give readers a practical framework for understanding the technology, its limitations and the decisions it creates.

A practical checklist before using model weights

Before adopting a model, teams should read the license attached to the exact release they intend to use and check whether additional acceptable-use terms apply. Confirm whether commercial deployment is permitted, whether redistribution is allowed, what notices must be retained, and whether there are restrictions based on usage, company size, geography or application. Do not assume that a model's label or a repository's popularity answers these questions.

Also examine the model card and release documentation. They may describe training data at a high level, evaluation methods, known weaknesses, intended uses and prohibited uses. That information does not necessarily provide a complete audit of training data or guarantee that every output is safe, but it helps the team understand what is known and what remains uncertain.

Operational ownership continues after download

Running weights yourself transfers responsibilities to the deploying organization. Teams may need to secure model files, monitor vulnerabilities, manage inference infrastructure, evaluate outputs, protect user data and keep track of upstream changes. A model that is easy to download may still be expensive to operate reliably at scale.

Legal and engineering reviews should be connected. Engineering can record the exact version, hash, dependencies and runtime configuration; legal or procurement can document the license interpretation and any obligations. Product owners should identify how the system will be tested for the intended use and what happens if the upstream project changes its terms or publishes a new version.

Open weights can create real flexibility, but flexibility is not the same as unrestricted use. A disciplined adoption process checks rights, technical fitness, security and operating cost together. That makes the decision defensible and reduces the risk of discovering a license or maintenance problem only after a product depends on the model.

Ninth Post analysis · Open weights, open source and AI licenses are not the same thing

What this means in practice

“Open weights” does not settle whether a model is open source, commercially usable, or safe to redistribute. Review the actual license, acceptable-use terms, restrictions on fields of use, attribution, derivative-model obligations, and hosting conditions. Record the exact model version and license snapshot at approval because releases and terms can change.

Sources & further reading

This article is original explanatory analysis. The sources below are provided so readers can verify the underlying information and explore the topic further.

← Back to Ninth Post