OpenMDW 1.1: A practical guide for companies adopting AI models
What the licence permits, what remains outside its scope, and what companies should check before adopting an OpenMDW model.
Contents
- 011. What is OpenMDW 1.1, and why was it created?
- 022. Is OpenMDW 1.1 OSI approved?
- 033. What does OpenMDW 1.1 permit?
- 044. Does OpenMDW 1.1 mean everything in a model distribution has the same licence?
- 055. What happens to outputs generated with an OpenMDW model?
- 066. What does OpenMDW’s copyright defensive-termination clause mean?
- 077. How is OpenMDW 1.1 being used in practice? The NVIDIA Nemotron example
- 088. What should a company check before adopting an OpenMDW model?
AI models are difficult things to license. A single model release can contain weights, software, data and documentation, each raising different questions about what rights exist and what permissions are needed. The licensing practice that developed around them reflects that complexity: different components of the same model are often released under different licences.
OpenMDW 1.1 takes a different approach. Developed by the Linux Foundation in 2025 and updated to version 1.1 in May 2026, it is a short, permissive licence designed to cover the different components of an AI model release within a single licensing framework. Commercial use, modification and redistribution are permitted, and the licence imposes no restrictions of its own on model outputs. NVIDIA is already using it for parts of its Nemotron model family.
The simplicity is appealing, particularly for companies trying to understand whether an AI model can be used in a commercial product. In practice, much of the review lies beyond the licence text itself: in establishing what the distribution actually contains, which materials OpenMDW covers and which other terms or rights still matter.
This article examines several of the more important considerations that arise when evaluating a model released under OpenMDW 1.1:
1. What is OpenMDW 1.1, and why was it created?
The problem OpenMDW addresses begins with the object being licensed. A conventional software licence such as Apache 2.0 was drafted around software. An AI model release can contain a much more varied collection of material: the model architecture and parameters, training or evaluation data, inference code, training scripts, documentation, metadata, evaluation assets and supporting tools.
The Linux Foundation’s Model Openness Framework originally reflected this diversity by recommending different categories of licence for different artifacts: conventional open-source licences such as Apache 2.0 or MIT for software, open-data licences for model weights and datasets, and Creative Commons licences for documentation. A sufficiently complete model release could therefore require several licences simply because its components were legally different kinds of material. The Linux Foundation introduced OpenMDW as a way of placing those different components within a single licensing framework.
The central legal concept introduced is Model Materials. OpenMDW defines them by reference to the machine-learning model, including its architecture and parameters, together with related artifacts such as data, documentation and software that are provided under the licence. The definition is intentionally capable of covering material that would ordinarily be treated separately.
The rights grant follows the same structure. OpenMDW grants permission to deal in the Model Materials under the copyright, patent, database and trade-secret rights included or embodied in them. The licence therefore does not depend on every component having the same legal character. Where a relevant right exists in the Model Materials, OpenMDW seeks to provide the corresponding permission.
This is an important difference from simply applying a conventional software licence to a model repository. OpenMDW was drafted around the fact that an AI model distribution may contain several kinds of intellectual-property rights. A provider can place weights, associated software, data and documentation within the same licensing framework.
This is a possibility rather than an obligation. OpenMDW can cover all of those materials, but it does not require the provider to release them. An AI model can therefore be distributed under OpenMDW without its training data, evaluation data, source code or other components being made available. The licence governs the Model Materials that the provider actually releases under it.
That distinction is important. The presence of OpenMDW tells a company something about the legal terms governing the materials that have been released. It does not, by itself, establish how complete the release is.
2. Is OpenMDW 1.1 OSI approved?
OpenMDW 1.1 is already being used for real model releases, but its status within the wider open-source ecosystem remains under review.
The Linux Foundation formally submitted version 1.1 to the Open Source Initiative on 13 August 2026 for approval as a new open-source licence. At the time of writing, the public review remains unresolved and OpenMDW 1.1 has not received formal OSI approval.
OSI approval serves a different function from the licence itself. The OpenMDW grant exists and can be relied upon without OSI approval. The OSI process examines whether a licence conforms to the Open Source Definition and, for new licences, whether it satisfies additional criteria concerning issues such as clarity, reusability and whether the licensor receives a structurally favoured position. Approval is therefore an ecosystem classification rather than a condition for the licence to exist.
For a company evaluating OpenMDW today, the immediate conclusion is limited: the licence is in active use, and its permissions can be assessed from its existing text, while OSI approval remains pending. The practical implications a disputed termination provision are addressed below.
3. What does OpenMDW 1.1 permit?
The practical starting point is that OpenMDW is a permissive licence. It grants, free of charge, permission to use, copy, modify and distribute the Model Materials, including modified versions. The licence itself does not limit use to research, non-commercial projects or a particular territory.
For a company considering an OpenMDW model, this permits the ordinary commercial uses that matter most. The model can be deployed internally, integrated into a commercial product or service, modified or fine-tuned, and redistributed. OpenMDW does not require a modified or fine-tuned model to be published merely because the original model was released under OpenMDW.
A company can therefore fine-tune OpenMDW Model Materials using its own data, keep the resulting modifications private and use them within a proprietary product. If the Model Materials themselves are redistributed, the obligations are comparatively limited: the distribution must retain the OpenMDW licence and the applicable copyright and origin notices. The licence does not impose a copyleft or share-alike obligation on modifications.
This is one of OpenMDW’s clearest commercial advantages. The licence gives broad freedom to work with the materials without creating an obligation to disclose the company’s own modifications.
The qualification is that these permissions apply to Model Materials governed by OpenMDW. A model distribution may contain other components governed by different terms, and those terms have to be considered separately.
4. Does OpenMDW 1.1 mean everything in a model distribution has the same licence?
One of the principal advantages of OpenMDW is that it can place very different types of material under a single licence. A provider does not necessarily need one licence for the weights, another for accompanying software and another for documentation. Where those artifacts are provided as OpenMDW Model Materials, the same licence can govern all of them.
That does not make every OpenMDW distribution legally uniform.
The OpenMDW FAQ expressly contemplates distributions that also contain separately licensed material. A third-party software component may remain under Apache 2.0 or MIT. A dataset may have its own terms. The model provider can also choose to make some of its own artifacts available under another licence. The FAQ recommends identifying those exceptions clearly in the principal documentation and explaining which materials the separate terms govern.
NVIDIA’s Nemotron Labs Puzzle model shows exactly what this can look like. Its licensing file begins by identifying OpenMDW 1.1 as the primary model licence. Further down, the same file contains a separate section for files under different licences. Two Python files, `configuration_nemotron_h.py` and `modeling_nemotron_h.py`, are expressly licensed under Apache 2.0, which NVIDIA states applies only to those files and not to the remainder of the repository.
For a company assessing the model, stopping at the licence displayed on the model card would therefore produce an incomplete answer. The relevant question is which materials have actually been provided under OpenMDW, and which materials within the distribution remain subject to separate terms.
In practice, this can require reading beyond the model card. The repository licence, README, notices attached to individual files and documentation relating to third-party components may all matter. This is familiar territory from open-source software compliance, but the range of artifacts contained in a model distribution makes the exercise potentially wider.
There is a second issue. Even after every applicable licence has been identified, the rights analysis may still be incomplete.
OpenMDW expressly disclaims a warranty of non-infringement. More unusually, the licence places responsibility on the recipient for clearing rights belonging to other persons, obtaining any necessary permissions and carrying out due diligence into the Model Materials and anything incorporated or embodied in them.
This separates two questions that are easy to collapse into one. Which licence applies to a particular artifact? And does somebody else hold rights that may affect the intended use of that artifact?
Identifying OpenMDW answers the first question for the Model Materials covered by it. The licence itself makes clear that the provider is not giving a warranty that resolves the second.
For a company carrying out licensing due diligence, the OpenMDW label therefore provides an important part of the legal analysis. It does not operate as a complete inventory of the rights relevant to the model.
5. What happens to outputs generated with an OpenMDW model?
Licensing the model raises an obvious downstream question: does the licence also follow the content produced with it?
OpenMDW addresses this directly. Its text states that the agreement imposes no restrictions or obligations on the use, modification or sharing of outputs generated using the Model Materials. The FAQ confirms that OpenMDW itself does not restrict commercialisation of those outputs.
For a company providing a service built around an OpenMDW model, this has an important consequence. The requirement to preserve the licence and applicable notices when Model Materials are distributed does not follow ordinary generated content downstream merely because the model produced it. Text, images, predictions or other outputs do not need to carry the OpenMDW licence for that reason.
The wording needs to be kept precise. OpenMDW’s absence of output restrictions does not establish that every generated output can be used without legal constraint. Copyright, data protection, confidentiality, personality rights and other applicable rules remain capable of affecting a particular output. A third party may also claim that an output reproduces material in which it owns rights.
Those issues arise independently of OpenMDW. The narrower and commercially important point is that OpenMDW does not add another licensing layer to ordinary model outputs.
6. What does OpenMDW’s copyright defensive-termination clause mean?
Most of OpenMDW’s permissions are straightforward. One provision deserves closer attention because it creates a circumstance in which all of them can terminate.
If an OpenMDW licensee files, maintains or voluntarily participates in a lawsuit against any person or entity asserting that the Model Materials directly or indirectly infringe one of its patents or copyrights, all rights and grants made to that licensee under OpenMDW terminate. The exception is a lawsuit brought in response to a corresponding lawsuit first filed against the licensee.
The concept has a familiar ancestor. Apache 2.0 contains a defensive-termination mechanism for patents: a recipient receives an express patent licence from contributors, and specified patent litigation concerning the work can terminate that patent licence. OpenMDW extends the mechanism in two significant ways. Copyright litigation is also capable of triggering termination, and the consequence is the loss of the entire OpenMDW grant rather than only a patent licence.
For a company using an OpenMDW model, the significance extends beyond the team that downloaded or deployed it. A business may have integrated OpenMDW Model Materials into a product and later conclude, through a completely different part of the organisation, that those materials infringe copyright or patent rights owned by the company. Bringing proceedings of the kind described in the clause could terminate the licence rights on which the technical team relies.
The provision therefore creates an unusual connection between IP enforcement strategy and continued permission to use the model.
The scope of the copyright trigger has already required clarification during the OSI review. One question was whether a copyright owner who alleges that its work was copied unlawfully during the training of a model would trigger the clause simply by bringing that claim.
Michael Dolan, speaking for the Linux Foundation in the review, said that this is not the intended effect. According to his explanation, a claim about copying that occurred during training does not trigger Section 5 merely because training material was allegedly used unlawfully. The allegation must concern the Model Materials themselves directly or indirectly infringing the claimant’s rights. He also explained that “indirectly” is intended to address secondary-liability claims, for example an allegation that using or distributing the Model Materials contributes to infringement by somebody else.
That clarification is practically important. A claim that a protected work was unlawfully used somewhere in the process of training a model is different from a claim that the resulting Model Materials themselves infringe copyright. Under the interpretation given by the licence steward during the OSI review, Section 5 is directed at the latter category.
There is a limitation to relying on that clarification: it comes from the Linux Foundation, which developed OpenMDW, during an ongoing review. The wording of the licence remains the wording a court would ultimately have to interpret. Still, for a company evaluating the provision today, the explanation given by the organisation behind OpenMDW, provides useful evidence of how the clause is intended to operate.
The practical point can be stated without resolving it. OpenMDW gives broad commercial rights, and specified patent or copyright litigation concerning the Model Materials can terminate those rights. A company with a substantial IP portfolio, or one operating in an area where rights disputes around AI models are foreseeable, should account for that provision before the model becomes operationally important.
7. How is OpenMDW 1.1 being used in practice? The NVIDIA Nemotron example
NVIDIA’s Nemotron releases show that OpenMDW is already being used in commercial model distributions rather than remaining a licensing experiment.
They also provide a useful illustration of why the practical analysis cannot stop with the words “OpenMDW 1.1”.
Nemotron 3 Embed, for example, is identified by NVIDIA as ready for commercial use. NVIDIA states that the model and associated configuration files are licensed under OpenMDW 1.1. The same documentation explains that it was built using Mistral AI’s Ministral-3-3B-Instruct-2512, released under Apache 2.0, and warns that the project downloads and installs additional third-party open-source software whose licences should be reviewed before use.
The Puzzle release provides the second version of the same lesson. OpenMDW is identified as the primary model licence, while two source files are separately governed by Apache 2.0.
These are well-documented releases from a sophisticated technology company. The presence of several licensing layers reflects the way modern model distributions are assembled, even in well-documented releases.
For a company considering Nemotron, OpenMDW answers several questions quickly. Commercial use is permitted. The Model Materials can be modified and fine-tuned. OpenMDW does not require those modifications to be released, and its restrictions do not propagate into ordinary model outputs.
The same documentation also demonstrates what OpenMDW does not eliminate. Base models can have their own licences. Individual source files can remain under different terms. Additional software can bring further licences into the deployment.
This is perhaps the most useful way to understand OpenMDW. It gives heterogeneous materials a common licensing framework where the provider chooses to place them under that framework. It simplifies the licensing architecture without making the architecture disappear.
8. What should a company check before adopting an OpenMDW model?
OpenMDW makes several parts of the adoption decision unusually straightforward. Commercial use is permitted, modifications can remain private, redistribution carries relatively light obligations, and OpenMDW does not impose restrictions on ordinary model outputs. The remaining work is therefore concentrated in a smaller number of questions that should be answered before the model becomes embedded in a product or service.
Establish what has actually been provided under OpenMDW. The model card is a starting point. The licence file, README, notices attached to individual artifacts and any third-party licensing documentation should establish which weights, code, data, documentation and other materials the provider has actually placed under OpenMDW. The licence applies to Model Materials provided under it; it does not require every component of a model release to be included.
Identify the materials governed by other licences. An OpenMDW distribution can contain Apache, MIT, Creative Commons or other separately licensed components. Those terms continue to govern the relevant material. NVIDIA’s own OpenMDW releases demonstrate why this step matters in practice.
Determine whether the model is actually being received or only accessed as a service. OpenMDW defines Model Materials as materials “provided” under the agreement. During the OSI review, Michael Dolan explained that a user merely accessing a hosted model through an API would ordinarily receive no Model Materials and would instead operate under the provider’s service terms. The distinction changes the starting legal framework entirely.
Review the rights behind the licence where they matter to the intended use. OpenMDW expressly leaves responsibility for clearing applicable third-party rights with the recipient and disclaims a warranty of non-infringement. For higher-risk deployments, identifying the licence attached to a model may therefore need to be followed by questions about base models, datasets, incorporated software and other material from which relevant third-party claims could arise.
Consider the termination clause before the model becomes difficult to replace. A company that owns or actively enforces patent or copyright portfolios should understand that specified litigation concerning the Model Materials can terminate the entire OpenMDW grant. That risk is easier to assess before a model becomes technically or commercially embedded than after a dispute arises.
Record the licensing position at adoption. Model distributions evolve. Dependencies change, files are added, base models are replaced and licence documentation can be updated. Preserving the model version, relevant licence files and third-party notices considered when the model was approved gives the company a reference point for future upgrades, customer questions and due diligence.
OpenMDW succeeds at something genuinely difficult: it turns a legally heterogeneous collection of model materials into an unusually short and permissive licensing framework. That simplicity is valuable. It also makes the boundary of the licence important. For a company adopting an OpenMDW model, the central question is therefore wider than whether the licence permits commercial use. It is what exactly has been licensed, what sits outside that grant, and whether the resulting position fits the way the model will actually be used.
Stay in the conversation
New analysis sent when it is published.
