Publish model files on Hugging Face so developers can run them on their own GPUs, and it gets called an "open source model" in plenty of contexts. But that's not quite accurate. What's actually released are the weights (parameters) obtained through training—and the freedom to run a model is a separate matter from the freedom to verify how it was built, improve it, and redistribute it. The Open Source Initiative (OSI) draws a clear line between the two, and James Landay, Director of Stanford HAI, notes that "can you run it" and "can you trust and improve it" are fundamentally different questions. Understanding why the OpenMDW license—an attempt to codify this boundary legally—still hasn't cleared OSI review will help you decide which standard matters for your own AI deployments.
What actually separates open-weight and open-source AI
Weights are the numerical parameters an AI model acquires through training. Only when combined with model architecture and inference code does a large language model (LLM) actually run. Developers can download these weights, self-host them on their own GPUs, fine-tune them on internal documents, and avoid sending prompts to a proprietary API. The appeal of controlling data, cost, and vendor lock-in in-house has fueled a substantial ecosystem of runtime infrastructure, inference services, and fine-tuning tools built around local models.
OSI calls this state "open weight," defining it as "the final weights and biases of a trained neural network." These weights alone provide only "part of the information necessary for full accountability." Without the training data itself, or sufficiently detailed documentation, outsiders can't verify what sources were used, whether copyrighted or private material slipped in, or whether benchmark data leaked into training. Weights are an outcome, not evidence of the process.
Landay describes this state as "open distribution" rather than an "open model." "The weights are runnable. You can execute them on your own machine, decoupled from anyone else's data pipeline. But you can't see how it was built, what it was trained on, or why it behaves the way it does." The freedom to download and the freedom to verify sit on different levels entirely.
Why publishing weights alone doesn't enable verification
Landay goes further, arguing that unless developers disclose their training data or provide "thoroughly documented and auditable records," no one can fully test, reproduce, or challenge a model in the fullest sense. His conclusion: there's "a huge gap" between open-weight and open-source AI.
This gap isn't abstract. With a weights-only release, there's no way to know which languages or communities were underrepresented in the data, or what safety adjustments (alignment) were applied after pretraining. When a company integrates such a model into its own services, it ends up adopting it without any external means of verifying copyright-infringement risk or the source of outputs biased toward particular groups.
Landay's framing is even simpler: "Open weight answers 'can I run this?' Open source answers 'can I trust this, improve it, and build the next thing on top of it?'" He points out that nearly every developer—including labs in both the U.S. and China—answers only the first question. This asymmetry is the foundation for the conflict over definitions and license design that follows.
How far apart are OSAID compliance and OpenMDW in what they actually disclose?
Separate from simply publishing weights, OSI maintains its own "Open Source AI Definition" (OSAID 1.0). It requires that model parameters, including weights, be provided under OSI-approved terms, but it doesn't specify what legal mechanism should achieve that. This ambiguity makes it hard to know exactly what gets disclosed in practice.
Here's how the three disclosure approaches differ in practical terms:
| Disclosure Method | Weights | Training Code | Training Data | Redistribution Terms |
|---|---|---|---|---|
| Open weight only | Published | Typically undisclosed | Typically undisclosed | No explicit provisions |
| OSAID 1.0 compliant | Mandatory | Mandatory | Requires disclosure of sufficient detail to reconstruct an equivalent system (raw data release not mandatory) | Under OSI-approved terms (legal mechanism unspecified) |
| OpenMDW license | Covered if provided (completeness not required) | Covered if provided | Covered if provided (no disclosure obligation) | Grants a single blanket license to "Model Materials," with explicit legal terms including a termination clause |
An open-weight release requires only the weights themselves. OSAID-compliant open-source AI mandates disclosure of training code and detailed information about training data. OpenMDW, meanwhile, simply grants a blanket license to weights, training data, and code bundled together as "Model Materials," without requiring disclosure of completeness. Three distinct designs, three different philosophies. The fact that OSAID demands "documentation" rather than "release of raw data" is precisely why Landay's gap isn't fully closed even by OSAID-compliant models.
The OpenMDW (Open Model, Data, and Weights) license, submitted by Mike Dolan, Senior Vice President at the Linux Foundation, is an attempt to give this ambiguity legal shape. Traditional open source software is designed around source code, but LLMs are something different—a combination of code, architecture, and numerical parameters derived from copyrighted or private training datasets. OpenMDW bundles the model (architecture and weights) together with related data, documentation, and software under a single definition called "Model Materials," granting a blanket license to use all rights—including copyright and patents—freely. What gets included is up to the licensor; there's no requirement to disclose completeness or make training data auditable. Amazon, Meta, IBM, Microsoft, and NVIDIA are listed as contributors, giving it substantial industry backing.
Why has OSI's definition drawn so much criticism?
OSAID 1.0 was published in October 2024. OSI acknowledged at the time that the definition would continue to evolve, but critics see central flaws that remain unresolved.
Luca Antiga, CTO of Lightning AI and a known PyTorch contributor, takes issue with OSAID's failure to address licensing of training data. "By not addressing licensing of training data, OSI leaves a big hole that makes the contractual terms largely ineffective," he says, arguing that even if a model formally meets OSAID's requirements, it's hard to adopt in practice if the terms governing training data usage can't be verified.
Antiga isn't alone in his criticism. Bruce Perens, author of the original Open Source Definition (OSD), condemned OSAID in 2024 and later stated, "This isn't open source. OSI itself is engaged in open-washing." Bradley Kuhn, Policy Fellow at the Software Freedom Conservancy, and Richard Fontana, Senior Commercial Counsel at Red Hat, have called for OSAID to be withdrawn, arguing: "OSI hastily imposed an overreaching policy compromise on the community. OSAID has created a rift within the FOSS community and damaged OSI's reputation, authority, and influence. We see no positive policy impact for machine learning practitioners, the FOSS community, or regulators either."
There are defenders too. Stefano Maffulli, former OSI Executive Director who led the organization during OSAID's development, characterizes the OpenMDW review as tainted by an ideological bias: "They hate Big Tech, and since AI today is Big Tech, they hate AI. So they'll try to block it by any means necessary." He counters that critics' motives are similarly skewed. The dispute over definitions is as much a technical debate as it is a power struggle over who has the standing to define "open" AI.
Why hasn't the OpenMDW review been resolved?
The OpenMDW license has existed since 2025, and a Linux Foundation AI & Data blog post published July 22, 2025, notes that OpenMDW-1.0 was already in place at that time. Version 1.1 was released on May 28, 2026, alongside NVIDIA's announcement of plans to adopt it going forward across its Cosmos, Isaac GR00T, Ising, and Nemotron model families.
At 17:00:51 UTC on August 13, 2026, Dolan formally submitted OpenMDW for OSI's official license review. The same submission noted that NVIDIA's adoption had moved from planning to execution, with 19 models—including Cosmos, Ising, and Nemotron—already adopting OpenMDW-1.1. Most recently, the same license is reportedly being used for the Alpamayo model announced by Jensen Huang.
But from October 2024, when OSAID 1.0 was published, through August 2026, as the review over OpenMDW's termination clause continues, the dispute over "what qualifies as open AI" has dragged on for nearly two years without resolution. Eight days after the submission, as of an LWN.net article published August 21, 2026, OSI reviewers still hadn't reached agreement.
The most contentious provision is the termination clause. At its center is a passage stating that all rights granted under the agreement terminate if the licensee "initiates, maintains, or voluntarily participates in litigation asserting that a Model Distribution directly or indirectly infringes a patent or copyright—unless that litigation is a response to a counterclaim first brought against the licensee." Richard Fontana of Red Hat warns that this clause's scope is too broad—filing an infringement suit over one specific model's weights could risk forfeiting rights to unrelated Python code bundled in the same distribution. OpenMDW also explicitly states that "rights processing that may apply to others is the sole responsibility of the user," meaning the license itself makes no guarantee that copyright on training data is clear. An attempt to give legal shape to this ambiguity ends up pushing the burden of verification right back onto the user.
What Japanese developers and companies should decide now
For Japanese companies and teams choosing an AI model, this distinction has direct practical consequences. If you're simply fine-tuning on internal documents and running the model on your own infrastructure, an open-weight model is often sufficient. But in situations where you must explain, in a way that withstands external audit, how copyright issues in training data were handled or why outputs are biased in a particular domain, publishing weights alone isn't enough—that's the case for choosing an OSAID-compliant model, which mandates disclosure of detailed information about training data. On the other hand, when you need contractual clarity around redistribution or patent litigation risk, the OpenMDW license—which bundles model, data, and code under a blanket grant, though it doesn't guarantee completeness—becomes a relevant factor in your decision.
Procurement and audit teams shouldn't take a vendor's "open source" label at face value. It's worth verifying, at the contract level, the level of documentation applied to training data and which party bears legal responsibility for redistribution or modification. If a license like OpenMDW, which handles model, data, and weights under a single framework, becomes an industry standard, that verification process itself could become simpler.
Whether OpenMDW will ultimately earn OSI certification remains an open question. Still, the fact that the Linux Foundation and its backing companies are working to establish legal terms that treat code, data, and weights as a unified whole doesn't change. Unless someone succeeds in bringing this effort to fruition, "open AI" risks becoming either a contradiction in terms or an empty marketing phrase. In judging that turning point, the outcome of the termination-clause review will serve as an early litmus test.