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

Richard Fontana rfontana at redhat.com
Sun Aug 16 23:36:03 UTC 2026


On Fri, Aug 14, 2026 at 1:09 PM Michael Dolan
<mdolan at linuxfoundation.org> wrote:
>
> Treating the choice of a single license for a package of components released together as an OSD 9 problem seems challenging to me.

OpenMDW doesn't say the Model Materials have to be released together,
for one thing. In a separate response I pointed out the possibility of
splitting up the Model Materials across differently hosted
repositories in a way that might deprive the licensee of adequate
understanding of the risk theoretically imposed by the defensive
termination provision.



I do not think OSD 9 is relevant here, honestly. OSD 9 prohibits a
license from restricting other software distributed with the licensed
software. Specifically, it says:
>
>
>
> 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.
>
>
>
> 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 – they’re 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.
[ . . . ]
> 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.

I think this is right, but OpenMDW doesn't talk at all about "a
release" as some sort of clear act that can be pointed to. It doesn't
say that the things making up the Model Materials must be "packaged
and built to work together". Perhaps it could? In another response I
noted that Model Materials can include more than one model, which
means more than one model release (including multiple sets of
materials related in some sense to those models). By definition, I
think, if you have more than one model, you don't have a unit that is
packaged and built to work together. For example you might have a
copyright claim against model A (hosted on Hugging Face) leading to
termination of licenses to documentation for possibly-unrelated models
B and C (published on GitHub repositories or websites, say, or maybe
this even extends to things like arxiv papers). I know this is
probably not what was intended or contemplated. Again, a way to
address this might be for the licensor to clearly identify all the
elements of a specific "release". My basic thought here is that the
copyright assertion termination feature would be at least somewhat
less problematic if it were clearer in principle what the Model
Materials is supposed to cover in any one licensing instance. If, for
example, you intend Model Materials to be truly open ended - anything
the licensor ever releases under OpenMDW, now or in the future - that
strikes me as a radical idea, but possibly worth considering by the
OSI as a valuable evolution of open source licensing. But I contend
that the meaning of Model Materials in the current license is unclear.

Richard



More information about the License-review mailing list