This is not a semantic quarrel. The gap affects procurement, reproducibility, vendor dependence, licensing, and the credibility of claims made about AI products. The Open Source Initiative’s Open Source AI Definition 1.0, commonly called OSAID, supplies one influential test. The public debate over the proposed OpenMDW-1.1 licence shows why rights in supplied artifacts and completeness of a model release are separate questions.
What open weights actually provide
Weights and biases are the learned numerical parameters of a trained neural network. Releasing them can enable useful downstream work: a developer may run the model on suitable hardware, integrate it into an application, or in some cases fine-tune it for a narrower task.
That is a real capability, not an empty marketing term. A team that needs a specific model behavior and has a compatible runtime may find an open-weight release entirely sufficient. It can reduce dependence on a particular hosted model provider and make experimentation more practical.
But weights are the output of a much larger development process. They do not inherently include the model architecture, training and inference code, training configurations, information about data provenance and processing, filtering decisions, labelling practices, evaluation tooling, or an account of excluded material. A model can therefore be modifiable at the parameter level while remaining difficult to examine or improve at the system level.
Stanford HAI’s James Landay puts the distinction in operational terms: open weights answer whether someone can run a model, while open source concerns whether they can study, improve, and build subsequent work on it. That is an argument for a more demanding openness standard, not evidence that every open-weight model is unsafe or unsuitable.
For a Windows development team, the limitation can become visible quickly. A group might package downloadable weights into an on-device assistant and obtain acceptable results in testing. Without the surrounding code, configurations, evaluation materials, and data information, it may be unable to reproduce the original assessments, investigate a surprising behavior, determine why a safeguard appeared, or rebuild the model for a changed hardware and software environment. The team can use an artifact without possessing the full means to understand how it was made.
OSAID asks for more than a licence and more than parameters
OSAID 1.0 defines Open Source AI around the established freedoms to use, study, modify, and share an AI system. Its central technical requirement is that the preferred form for making modifications to a machine-learning system include three elements: Data Information, code, and parameters.
- Data Information is sufficiently detailed information about data used to train the model.
- Code includes the complete source code used to train and run the system.
- Parameters are the learned values normally described as model weights.
Together, these components are intended to let a skilled person understand and alter the system, rather than merely invoke a finished model. The definition does not demand an exact rerun of the original training process. Instead, it focuses on enabling a skilled person to build a substantially equivalent system. That distinction reflects the reality that modern training processes may be difficult to reproduce reliably, including for their original creators.
OSAID itself does not take a position on whether model parameters are copyrightable. Instead, it provides for the relevant freedoms through OSI-approved terms and recognizes that parameters may be free by their nature, through a licence, or through another legal instrument. This is an attempt to accommodate unresolved legal questions without making a categorical legal conclusion. It also means that technical completeness and legal permissions need separate examination.
A permissive-looking licence is not proof that the materials needed for modification were delivered. Conversely, a technically extensive release can still impose terms that limit use, sharing, or modification in ways that do not fit the definition.
Transparency is not the same as publishing every training record
A common objection to a fuller AI openness standard is that training data cannot always be redistributed. Data may contain personal information, proprietary material, content obtained under contractual restrictions, or material whose release could create fresh privacy and rights risks.
OSAID does not require that every raw training item be published. It permits unshareable nonpublic training data when it is described in detail. The needed Data Information is intended to cover such matters as provenance, scope, collection, selection, labelling, processing, filtering, and characteristics relevant to understanding likely biases or categorisation. Publicly available or otherwise obtainable data can be listed rather than copied and republished.
That compromise has an important benefit: responsible transparency need not mean placing every input dataset on the internet. Yet it has a clear limit. Documentation is not equivalent to access. A developer may know where data originated and how it was handled while still being unable to inspect individual examples, reproduce a result, or assess a disputed training input.
The practical strength of an Open Source AI claim therefore depends on the specificity and usefulness of the Data Information supplied. Landay’s preferred Open Science tier goes further, calling for code, training data or an auditable account of it, and tooling. The underlying concern is that a model’s final parameters alone cannot explain all of its behavior. That concern is particularly relevant where a system is intended for consequential work or an organisation needs a defensible evidence trail for its risk assessment.
What this means for Windows deployment decisions
Running a model on a Windows PC, workstation, or private server can be a sensible design choice, but the benefits should not be assumed from downloadable weights alone. Prompt confidentiality, lower latency, and the ability to keep working without an internet service depend on the complete application design: telemetry, logging, cloud-connected components, retrieval systems, update paths, hardware, network policy, and operational configuration all matter. A local model can still be embedded in a system that transmits data or relies on remote services.
Open weights may be enough for a team whose requirement is simply to execute a model under its stated terms. But calling the result “open source” can lead buyers and technical leads to infer control, auditability, or rebuildability that they do not actually receive.
Before selecting a model for a Windows product or internal deployment, teams should separate four practical questions:
- Can we run it? Check hardware requirements, runtime support, performance, and the terms governing inference and distribution.
- Can we change it? Establish whether fine-tuning is technically feasible and legally permitted, and whether the parameters work with the intended toolchain.
- Can we inspect and rebuild it? Look for architecture details, complete training and runtime code, configuration, evaluation tooling, and meaningful Data Information.
- Can we redistribute our result? Review the actual terms for weights, code, data-related materials, and dependencies. Rights need not be identical across every component described around a model.
These questions also prevent a governance error. Downloadable parameters do not make a model automatically auditable, secure, compliant, trustworthy, or high quality. OSAID is a definition of openness and modification freedoms; it is not a safety, security, trustworthiness, compliance, or model-quality certification. A release that meets OSAID may still require rigorous security testing, privacy review, supply-chain controls, evaluation for its intended use, and legal assessment.
Likewise, where surrounding materials or evidence are limited, “usable with bounded trust” should be understood as a procurement-risk judgment: an organisation may decide that the available artifact and documentation are sufficient for a particular low-risk use under defined controls. It is not a consequence of OSAID compliance, nor a substitute for security and governance work.
OpenMDW-1.1: licence scope is not release completeness
The Linux Foundation’s Mike Dolan submitted OpenMDW-1.1 to OSI for approval in August 2026. The submitted proposal describes a single permissive instrument for “Model Materials,” including supplied model architecture, parameters, associated data, documentation, and software across relevant intellectual-property regimes. Its contributor list names people affiliated with organisations including Amazon, Meta, IBM, Microsoft, NVIDIA, the Linux Foundation, and the PyTorch Foundation.
Those affiliations establish participation by individuals with major-industry connections. They do not establish broad corporate endorsement, industry consensus, or that every listed organisation has adopted the proposed licence.
More importantly, OpenMDW’s stated scope should not be confused with a mandatory bundle of all materials relevant to an AI system. In the public review, the licence steward explained the intended scope this way: artifacts a provider does not include are not subject to OpenMDW. Under that explanation, a provider can license the materials it supplies without supplying every potentially relevant artifact.
That is the key distinction. Licence analysis asks, “What may we do with the materials we received?” Release-completeness analysis asks, “Did we receive the materials and information needed to study and modify the system in the broader OSAID sense?” The submitter and steward’s explanation describes their intended licence scope; it is not an adjudicated conclusion that a particular release is complete or OSAID-compliant.
The reviewed record showed objections, not a final ruling
The public licence-review material examined from August 13 to August 29, 2026 showed active discussion of OpenMDW-1.1 and no decision in that reviewed record. That limited record should not be treated as a conclusive statement of OSI’s current status, whether approval, rejection, withdrawal, or another outcome.
The discussion contained substantive objections to the proposed defensive-termination provision, including concern about how it might affect rights involving third-party material included under other licences. One participant offered an example in which an MIT-licensed contributor could lose its OpenMDW licence after suing an OpenMDW licensor over an alleged MIT-licence breach. That was a review participant’s interpretation and warning, not an adjudicated legal outcome. It nevertheless identifies a practical compatibility and enforcement question that adopters would need to assess carefully.
There is also broader criticism of OSAID itself. Bradley Kuhn and Richard Fontana have advocated repealing the definition, arguing that OSI adopted an overly ambitious compromise too quickly. Their position is a reform argument, not an established finding that the definition has failed. It does, however, expose a genuine tension: a framework accommodating AI data restrictions and legal uncertainty may be criticised for diverging from older software-centred assumptions about source availability.
The opposite problem is just as real. If “open source” applies to any model with downloadable weights, the label loses much of its value as a signal of inspectability and meaningful modification. Maintaining “open weights” as a distinct term can preserve recognition for a useful form of availability without overstating what was released.
Read AI openness claims as an inventory, not a brand
The practical response is neither to dismiss open-weight models nor to accept an “open” label without further questions. Weights can enable local experimentation, adaptation, and reduced dependence on a single hosted provider. They can be highly useful for Windows developers.
But weights are not a complete account of an AI system’s origins, controls, or reproducibility. For organisations evaluating models, a concrete inventory is more reliable than branding: identify the parameters, code, Data Information, evaluation materials, software dependencies, and terms governing each item. Then conduct separate security, privacy, legal, and performance assessment for the actual deployment architecture.
If a provider offers only weights, “open weight” is the precise description. If it supplies the broader materials and freedoms contemplated by OSAID, the case for calling the release Open Source AI is stronger. Neither label, however, certifies that the model is safe or suitable for a particular Windows workload. Precision here gives developers more realistic expectations and gives procurement teams a clearer view of the risks they still need to manage.