<div dir="ltr"><div dir="ltr"><br>Richard-san and All,<br><br>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.<br><br>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.<br><br>However, I have some doubts about that particular example.<br><br>"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.<br> <a href="https://huggingface.co/nvidia/NVIDIA-Nemotron-Parse-2.0/blob/2a82cb1d2bfd6b25ec3778c5496b53201a4dd0a2/postprocessing.py">https://huggingface.co/nvidia/NVIDIA-Nemotron-Parse-2.0/blob/2a82cb1d2bfd6b25ec3778c5496b53201a4dd0a2/postprocessing.py</a><br><br>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.<br><br>More generally, I do not think that treating heterogeneous artifacts as a single licensed unit is itself unprecedented in OSI-approved licenses.<br><br>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.<br>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.<br><br>Today, both the SIL OFL and the IPA Font License are listed by OSI in the Special Purpose category.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br><span class="gmail_signature_prefix">--</span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Shuji Sado</div><div>Chairman, Open Source Group Japan<br><a href="https://opensource.jp/" target="_blank">https://opensource.jp/</a><br>English blog: <a href="https://shujisado.org/" target="_blank">https://shujisado.org/</a></div><div>Japanese blog: <a href="https://shujisado.com/" target="_blank">https://shujisado.com/</a></div></div></div></div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">2026/8/30 8:57 Richard Fontana via License-review <<a href="mailto:license-review@lists.opensource.org">license-review@lists.opensource.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Here's an example of a "Model Materials" problem I found in an<br>
OpenMDW-1.1 repository/model release (this was the second one I looked<br>
at when filtering by license in the Hugging Face landing page):<br>
NVIDIA has released this:<br>
<a href="https://huggingface.co/nvidia/NVIDIA-Nemotron-Parse-2.0" rel="noreferrer" target="_blank">https://huggingface.co/nvidia/NVIDIA-Nemotron-Parse-2.0</a><br>
Regarding licensing, the repo README says:<br>
"This model and its associated configuration files are licensed under<br>
the OpenMDW License Agreement, version 1.1 (OpenMDW-1.1). Use of the<br>
tokenizer included in this model is governed by the CC-BY-4.0 license.<br>
This project will download and install additional third-party open<br>
source software projects. Review the license terms of these open<br>
source projects before use."<br>
<br>
So already there is something unclear because if you look at the<br>
repository, it includes stuff besides what I think this text means by<br>
"model and its associated configuration files", but we don't really<br>
know. That's not an indictment of the license itself. But I took a<br>
look at what is in this repository and my attention immediately fell<br>
on this file: <a href="https://huggingface.co/nvidia/NVIDIA-Nemotron-Parse-2.0/blob/main/latex2html.py" rel="noreferrer" target="_blank">https://huggingface.co/nvidia/NVIDIA-Nemotron-Parse-2.0/blob/main/latex2html.py</a><br>
[Aside: I assume this has nothing to do with a widely used<br>
LaTeX-to-HTML script from decades ago that I mainly remember as being<br>
under some non-FOSS license]<br>
<br>
This is a Python script of several hundred lines. There is no<br>
copyright or license notice. It seems to have been developed at least<br>
in part by an NVIDIA employee.<br>
This file has *nothing* in particular to do with<br>
NVIDIA-Nemotrol-Parse-2.0 as far as I can tell. There is nothing in<br>
this file that relates to AI, machine learning, models, weights,<br>
neural network architectures, or the like.<br>
<br>
What is its license? I think we have to assume it's under OpenMDW-1.1.<br>
The LICENSE file contains the text of OpenMDW-1.1 and says at the top:<br>
"All binary model files and source code files are licensed under the<br>
OpenMDW-1.1 License." latex2html.py is clearly a source code file.<br>
<br>
So it must be in some sense part of some "Model Materials". But is it<br>
the unit of "Model Materials" that encompasses (presumably) most of<br>
the rest of the repository? ""Model Materials" means the materials<br>
provided to<br>
you under this agreement, consisting of: (1) one or more machine learning<br>
models (including architecture and parameters); and (2) all related artifacts<br>
(including associated data, documentation and software) that are provided to<br>
you hereunder."<br>
I don't know if this latex2html script is a "related artifact" with<br>
respect to the rest of the Nemotron-Parse-2.0 release. That would be<br>
at least the naive conclusion. If it's *not*, then we have at least<br>
two instances of "Model Materials" in this repository, with presumably<br>
the latex2html.py script being its own "Model Materials" and not quite<br>
fitting the definition of Model Materials well.<br>
<br>
So maybe we are better off assuming that there is one instance of<br>
"Model Materials" and latex2html.py is part of it. But if that's true,<br>
then we have to think about the impact of the copyright and patent<br>
defensive termination provision as it relates to everything (under<br>
OpenMDW-1.1) in this repository.<br>
<br>
This script has, in a technical sense, nothing to do with<br>
Nemotron-Parse-2.0 or any other model. It's apparently a script having<br>
some general utility in parsing LaTeX tables and converting them to<br>
HTML and other formats. So suppose I bring a copyright claim accusing<br>
the model as such of infringement. Is it fair that NVIDIA can<br>
terminate my license to use this general-purpose LaTeX table<br>
conversion tool, which I might well be using in some context far<br>
removed from anything to do with AI, let alone this particular model?<br>
Or, let's imagine that this is based on the original LaTeX2HTML script<br>
from ancient times and the copyright holder sues NVIDIA for breaching<br>
the license. The copyright holder happens to be using the<br>
Nemotron-Parse-2.0 model for purposes having no connection to the<br>
latex2html.py script. Is it fair for NVIDIA to be able to terminate<br>
that person's license to the model proper because they brought a<br>
copyright lawsuit having to do with a technically unrelated code file?<br>
This is what I mean when I say there may be an OSD 9 problem with this<br>
license. "The license must not place restrictions on other software<br>
that is distributed along with the licensed software." OpenMDW-1.1, in<br>
this repository, as it applies to some of what's in this repository,<br>
is placing restrictions on one discrete thing that is *also* under<br>
OpenMDW-1.1 but which seems to be "other software . . . distributed<br>
along with" that stuff. The separateness, as I said in an earlier<br>
comment, is masked in a sense by the fact that the same license is<br>
used for everything - as I keep saying, this is the whole purpose of<br>
OpenMDW.<br>
<br>
I suspect this is not an atypical sort of example.<br>
<br>
Richard<br>
<br>
<br>
_______________________________________________<br>
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 <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br></div></div></div></div>