<div dir="ltr"><div dir="ltr"><br>Richard-san,<br><br>I can agree with Dolan-san\u2019s basic idea of treating a single model release as one unit. At the same time, I agree with your point that the OpenMDW text itself does not define that unit.<br><br>At this point, I am not convinced that this necessarily rises to an OSD 9 issue. Nor do I yet think that copyright assertions should be removed altogether as a termination trigger.<br>However, I do think the scope of termination should be clear to the licensee in advance. Would it therefore make sense to limit the Model Materials to a specific release, or to a set of materials explicitly identified by the licensor?<br><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><br></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">2026/8/17 8:38 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">On Fri, Aug 14, 2026 at 1:09\u202fPM Michael Dolan<br>
<<a href="mailto:mdolan@linuxfoundation.org" target="_blank">mdolan@linuxfoundation.org</a>> wrote:<br>
><br>
> Treating the choice of a single license for a package of components released together as an OSD 9 problem seems challenging to me.<br>
<br>
OpenMDW doesn't say the Model Materials have to be released together,<br>
for one thing. In a separate response I pointed out the possibility of<br>
splitting up the Model Materials across differently hosted<br>
repositories in a way that might deprive the licensee of adequate<br>
understanding of the risk theoretically imposed by the defensive<br>
termination provision.<br>
<br>
<br>
<br>
I do not think OSD 9 is relevant here, honestly. OSD 9 prohibits a<br>
license from restricting other software distributed with the licensed<br>
software. Specifically, it says:<br>
><br>
><br>
><br>
> The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open source software.<br>
><br>
><br>
><br>
> A simple example would be a license insisting that other programs on the same medium be open source. The Model Materials are not other software distributed along with the licensed work. They are the licensed work \u2013 they\u2019re packaged and built to work together. The premise that a single license covering a bundle of components violated OSD 9 would implicate most software package releases I can think of. Every software distribution is a bundle of conceptually separate components under one license: code, documentation, build tooling, test data. The OSD has never required per-component granularity in the grant or the remedy.<br>
[ . . . ]<br>
> Regarding separateness: a model release functions as a unit. The weights are not usable without the architecture, configuration, and tokenizer, and the documentation describes that specific release. Many apps bundle presentation code, backend logic code, SQLite for data, and security libraries into a release.<br>
<br>
I think this is right, but OpenMDW doesn't talk at all about "a<br>
release" as some sort of clear act that can be pointed to. It doesn't<br>
say that the things making up the Model Materials must be "packaged<br>
and built to work together". Perhaps it could? In another response I<br>
noted that Model Materials can include more than one model, which<br>
means more than one model release (including multiple sets of<br>
materials related in some sense to those models). By definition, I<br>
think, if you have more than one model, you don't have a unit that is<br>
packaged and built to work together. For example you might have a<br>
copyright claim against model A (hosted on Hugging Face) leading to<br>
termination of licenses to documentation for possibly-unrelated models<br>
B and C (published on GitHub repositories or websites, say, or maybe<br>
this even extends to things like arxiv papers). I know this is<br>
probably not what was intended or contemplated. Again, a way to<br>
address this might be for the licensor to clearly identify all the<br>
elements of a specific "release". My basic thought here is that the<br>
copyright assertion termination feature would be at least somewhat<br>
less problematic if it were clearer in principle what the Model<br>
Materials is supposed to cover in any one licensing instance. If, for<br>
example, you intend Model Materials to be truly open ended - anything<br>
the licensor ever releases under OpenMDW, now or in the future - that<br>
strikes me as a radical idea, but possibly worth considering by the<br>
OSI as a valuable evolution of open source licensing. But I contend<br>
that the meaning of Model Materials in the current license is unclear.<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>