[License-review] For Approval: OpenMDW License Agreement, versions 1.1 (OpenMDW-1.1)

Shuji Sado shujisado at gmail.com
Sun Aug 30 08:01:05 UTC 2026


Richard-san and All,

I have been busy for a few days, and in the meantime this discussion seems
to have branched into quite a few more specific issues. In particular, I
think the way you have developed the Model Materials question deserves
careful consideration.

The boundary issue now seems to have moved beyond the question of whether
the boundary itself is unclear. The deeper question is whether
cross-termination between unrelated artifacts can be problematic even where
the boundary is perfectly clear. That seems to me to be one of the
important remaining issues. You raised NVIDIA Nemotron-Parse-2.0 and its
`latex2html.py` file as a concrete example.

However, I have some doubts about that particular example.

"latex2html.py" does not appear to be merely a general-purpose utility that
happens to sit in the same repository. The official "postprocessing.py" in
the initial release artifacts directly imports functions from
"latex2html.py", including functions for converting LaTeX tables to HTML
and for converting the resulting tables into Markdown, JSON, and CSV. In
other words, it is actually used in the post-processing of the model's
table output.

https://huggingface.co/nvidia/NVIDIA-Nemotron-Parse-2.0/blob/2a82cb1d2bfd6b25ec3778c5496b53201a4dd0a2/postprocessing.py

Of course, "latex2html.py" may also be useful as general-purpose software
outside this model. But I do not think that necessarily makes it unrelated
software in the context of this particular model release. I think this
factual point is worth noting when evaluating the example.

More generally, I do not think that treating heterogeneous artifacts as a
single licensed unit is itself unprecedented in OSI-approved licenses.

SIL OFL 1.1, for example, defines "Font Software" as a clearly marked set
of files released under the license, and expressly says that this set may
include source files, build scripts, and documentation. These are
technically different kinds of artifacts, but the license treats them as
one licensed unit in the context of the font domain.
I also think the history of the IPA Font License review is relevant here.
During that review, there was substantial discussion about the fact that
font programs are created differently from ordinary software and that the
usual source/binary model does not map neatly onto fonts. OSI did not relax
the OSD because fonts were special. Rather, the review took the
domain-specific characteristics of font development seriously and adjusted
the license accordingly before approval.

Today, both the SIL OFL and the IPA Font License are listed by OSI in the
Special Purpose category.

If OpenMDW is approved, I would naturally expect it to fall into the
Special Purpose category as well. I do not mean that an AI-related license
should be reviewed under a looser standard. I mean almost the opposite:
when applying the same OSD to a Special Purpose license, we also need to
recognize what constitutes a natural licensed unit in that particular
domain. This is something OSI has already had to do with font licenses.

For that reason, I am still not convinced that treating the Model Materials
as a single unit is, by itself, an OSD 9 problem. I think one more step in
the argument is necessary. If the fact that a component can also be used
independently is enough to make it "other software" rather than part of the
same licensed work, similar questions could arise in many conventional
software packages as well.

At the same time, I do not think a licensor should be able to expand the
termination scope simply through ambiguous packaging. Here I think the OFL
phrase "clearly marked as such" provides a useful analogy.

For OpenMDW, I still think the practical answer may be to strongly
recommend in the guidance that licensors explicitly enumerate the Model
Materials making up each release, using a MOF configuration file, manifest,
model card, or similar mechanism. That seems consistent with current Model
Openness Framework practice and would make the licensed unit legible to
downstream users.

If we can resolve the Model Materials issue along those lines, I think
Pamela-san's suggestion of considering OpenMDW 1.0 first also becomes
easier to evaluate.

The Model Materials question is common to both 1.0 and 1.1. If that common
issue can be resolved, then 1.0 is left with the more conventional question
of patent-triggered defensive termination, for which there is substantial
precedent among OSI-approved licenses. The 1.1-specific question can then
be considered separately and more cleanly: whether copyright assertions
should themselves be a termination trigger in an Open Source license.

--
Shuji Sado
Chairman, Open Source Group Japan
https://opensource.jp/
English blog: https://shujisado.org/
Japanese blog: https://shujisado.com/


2026/8/30 8:57 Richard Fontana via License-review <
license-review at lists.opensource.org>:

> Here's an example of a "Model Materials" problem I found in an
> OpenMDW-1.1 repository/model release (this was the second one I looked
> at when filtering by license in the Hugging Face landing page):
> NVIDIA has released this:
> https://huggingface.co/nvidia/NVIDIA-Nemotron-Parse-2.0
> Regarding licensing, the repo README says:
> "This model and its associated configuration files are licensed under
> the OpenMDW License Agreement, version 1.1 (OpenMDW-1.1). Use of the
> tokenizer included in this model is governed by the CC-BY-4.0 license.
> This project will download and install additional third-party open
> source software projects. Review the license terms of these open
> source projects before use."
>
> So already there is something unclear because if you look at the
> repository, it includes stuff besides what I think this text means by
> "model and its associated configuration files", but we don't really
> know. That's not an indictment of the license itself. But I took a
> look at what is in this repository and my attention immediately fell
> on this file:
> https://huggingface.co/nvidia/NVIDIA-Nemotron-Parse-2.0/blob/main/latex2html.py
> [Aside: I assume this has nothing to do with a widely used
> LaTeX-to-HTML script from decades ago that I mainly remember as being
> under some non-FOSS license]
>
> This is a Python script of several hundred lines. There is no
> copyright or license notice. It seems to have been developed at least
> in part by an NVIDIA employee.
> This file has *nothing* in particular to do with
> NVIDIA-Nemotrol-Parse-2.0 as far as I can tell. There is nothing in
> this file that relates to AI, machine learning, models, weights,
> neural network architectures, or the like.
>
> What is its license? I think we have to assume it's under OpenMDW-1.1.
> The LICENSE file contains the text of OpenMDW-1.1 and says at the top:
> "All binary model files and source code files are licensed under the
> OpenMDW-1.1 License." latex2html.py is clearly a source code file.
>
> So it must be in some sense part of some "Model Materials". But is it
> the unit of "Model Materials" that encompasses (presumably) most of
> the rest of the repository? ""Model Materials" means the materials
> provided to
> you under this agreement, consisting of: (1) one or more machine learning
> models (including architecture and parameters); and (2) all related
> artifacts
> (including associated data, documentation and software) that are provided
> to
> you hereunder."
> I don't know if this latex2html script is a "related artifact" with
> respect to the rest of the Nemotron-Parse-2.0 release. That would be
> at least the naive conclusion. If it's *not*, then we have at least
> two instances of "Model Materials" in this repository, with presumably
> the latex2html.py script being its own "Model Materials" and not quite
> fitting the definition of Model Materials well.
>
> So maybe we are better off assuming that there is one instance of
> "Model Materials" and latex2html.py is part of it. But if that's true,
> then we have to think about the impact of the copyright and patent
> defensive termination provision as it relates to everything (under
> OpenMDW-1.1) in this repository.
>
> This script has, in a technical sense, nothing to do with
> Nemotron-Parse-2.0 or any other model. It's apparently a script having
> some general utility in parsing LaTeX tables and converting them to
> HTML and other formats. So suppose I bring a copyright claim accusing
> the model as such of infringement. Is it fair that NVIDIA can
> terminate my license to use this general-purpose LaTeX table
> conversion tool, which I might well be using in some context far
> removed from anything to do with AI, let alone this particular model?
> Or, let's imagine that this is based on the original LaTeX2HTML script
> from ancient times and the copyright holder sues NVIDIA for breaching
> the license. The copyright holder happens to be using the
> Nemotron-Parse-2.0 model for purposes having no connection to the
> latex2html.py script. Is it fair for NVIDIA to be able to terminate
> that person's license to the model proper because they brought a
> copyright lawsuit having to do with a technically unrelated code file?
> This is what I mean when I say there may be an OSD 9 problem with this
> license. "The license must not place restrictions on other software
> that is distributed along with the licensed software." OpenMDW-1.1, in
> this repository, as it applies to some of what's in this repository,
> is placing restrictions on one discrete thing that is *also* under
> OpenMDW-1.1 but which seems to be "other software . . . distributed
> along with" that stuff. The separateness, as I said in an earlier
> comment, is masked in a sense by the fact that the same license is
> used for everything - as I keep saying, this is the whole purpose of
> OpenMDW.
>
> I suspect this is not an atypical sort of example.
>
> Richard
>
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not
> necessarily those of the Open Source Initiative. Communication from the
> Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260830/bd7de01b/attachment-0001.htm>


More information about the License-review mailing list