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

[Michael Dolan]

I’m consolidating responses to a few posts since my last reply. Apologies
for the length, but it was easier to consolidate my thoughts than reply to
each message individually - especially with some of the overlapping points.

1. Prior OSI instances of “copyright litigation as trigger for termination”.

Much of the discussion has revolved around whether OSI would approve
licenses which terminate upon instituting copyright litigation (as opposed
to patent litigation). While we haven’t done an exhaustive search of the
OSI database, one example of approval of a license with a comparable
provision that I’m aware of is the OCLC Research Public License 2.0
(OCLC-2.0), https://opensource.org/license/OCLC-2.0:

Section 5. Termination of Rights

This non-exclusive license (with respect to the grant from a particular
Contributor) automatically terminates for any entity that initiates legal
action for intellectual property infringement (with respect to the Program)
against such Contributor as of the initiation of such action.

OCLC-2.0’s provision is arguably broader than OpenMDW-1.1, as it applies to
any “intellectual property infringement” claims, whatever scope that might
include. It appears also to terminate the license upon claims in a defensive
context (arguably; perhaps depending on how one would interpret “initiates
legal action” and whether that would include counterclaims, etc.).

I’ll be honest that I’m not familiar with OCLC-2.0. I suspect that most of
us on the list are not, since it hasn’t come up yet in this discussion. OSI
might consider to whatever extent they view it as relevant precedent. I’m
just raising it as an example of at least one existing, OSI-approved
license which includes more than patent litigation claims as a trigger for
termination.


There are also interesting provisions in the RPSL-1.0 (see section 11.1,
https://opensource.org/license/rpsl-1-0), Watcom-1.0 (see section 12.1,
https://opensource.org/license/watcom-1-0), APL-1.0 (see section 7,
https://opensource.org/license/apl-1-0), CAL-1.0 (see section 5.3,
https://opensource.org/license/cal-1-0), RSCPL (see section 8.2,
https://opensource.org/license/rscpl) and Jabber (see section 9(b) and
9(c), https://opensource.org/license/jabberpl). While these are all
examples of terminations relating to patent infringement claims, each of
these has aspects or effects that go well beyond the Apache-2.0
termination, which I suspect most on this list consider to be the
norm/extent of termination. In the case of CAL-1.0 at least, it does also
include a license that was approved in the relatively more modern era of
OSI license approvals.

2. The scope of “Model Materials”.

The definition of “Model Materials” relates to several of the comments that
were received, and since it’s central to the operation of the license, I
want to spend a few minutes focused on clarifying that term.

The drafters sought to create a license which would apply to many different
scenarios involving distributions of AI model weights and other related
artifacts, in particular as framed by the structure and terminology of the
Model Openness Framework (MOF) (
https://lfaidata.foundation/wp-content/uploads/sites/3/2025/01/05_White_paper_MOF_Specification.pdf).
The goal was to create a license which was broad enough to apply generally,
while also being short enough to be generally comprehensible to non-lawyers.

Some of the contemplated scenarios included the following:

a) Academic researchers who were adopting the MOF, and who wanted to
provide a single license flexible enough to apply to many different types
of content.

b) Model providers who might be distributing some, but not all, of the
types of components described by the MOF. For example, a MOF Class II (Open
Tooling Model) distribution might include inference code and evaluation
data, but omit some of the MOF Class I (Open Science Model) components such
as research papers and data preprocessing code.

c) Or, model providers who might have a distribution package consisting of
some materials provided under OpenMDW together with other materials that
are provided under other licenses.  This could be in a mere aggregation
sense; and/or where materials under a different license are more directly
used by the OpenMDW materials.

The intention of the “Model Materials” definition, then, is for it to
include the model weights and all related artifacts that are provided to
the recipient under OpenMDW. For use case (b) described above, this means
that only those materials provided to the recipient under OpenMDW are
subject to its license grants and provisions. If the model provider does
not include any particular “related artifacts (including associated data,
documentation and software)” in the distributed materials, then those are
not subject to OpenMDW.

Or for use case (c), if those materials are included in the distribution
under a different license, then that license would apply rather than
OpenMDW. A point of comparison for an open source software license could be
Apache-2.0 section 1, in its definition of “Work” as “the work of
authorship, whether in Source or Object form, made available under the
License…”. For a project that uses multiple licenses (such as Apache-2.0
for code and CC-BY-4.0 for documentation, as is common for many
LF-supported projects), a repository might have a top-level LICENSE file
containing Apache-2.0, while also containing documentation files under
CC-BY-4.0. Similarly, the language in OpenMDW is meant to reflect its
intention to be a license generally applicable to various packaged and
distributed materials, without precluding the possibility that a package
might include some content under other licenses.

The specific situation that Pam raised regarding an OpenMDW distribution
that includes third-party content under a different license is an important
one, and I’ll describe that in the next item below.

3. Pam's MIT package example.

OpenMDW-1.1 does not automatically relicense third-party code, and I think
that premise may be the misunderstanding. A provider can only grant the
rights it holds or can pass through. OpenMDW does not include a
representation that the providers hold or have cleared every such right,
and the license says so expressly: the disclaimers state that rights of
other persons may apply to the Model Materials. The definition of Model
Materials identifies which artifacts are covered, those "that are provided
to you hereunder," and the grant then conveys, as to those artifacts, only
the rights the providers hold or can pass through.

Let me propose a cast of characters whom I will reuse below:


   -

   A publishes Model Materials X under OpenMDW-1.1.
   -

   As part of its distribution of X, A includes a component Y that B owns
   and previously licensed under MIT.
   -

   C is a downstream recipient and user of X and, by extension, also of B.


Then, there are, in theory, three different license configurations that A
could be distributing Y:

   -

   under MIT alone; or
   -

   under OpenMDW-1.1 alone; or
   -

   under the combination of both licenses (MIT AND OpenMDW-1.1, in SPDX
   license expression terms).


The first option (MIT alone) is probably the natural outcome for a “mere
aggregation” sort of situation, or also for many situations where a
component is included unmodified. If a component labeled as being
MIT-licensed is included in a distributed package, then it probably would
not be part of the OpenMDW-1.1 “Model Materials”, as it is not “provided to
you hereunder” -- e.g., under OpenMDW-1.1. This is probably akin to many
typical open source software cases where a package includes a distribution
of many unmodified components under a variety of different OSS licenses.

The second option (OpenMDW-1.1 alone) is probably not a real option.
Presumably, A does not have the authority to unilaterally replace Y’s MIT
license with OpenMDW-1.1, absent B’s permission.

The third option (MIT AND OpenMDW-1.1) might apply in cases where the model
distributor is modifying a pre-existing MIT component, and also for some
reason wants those modifications to be under OpenMDW-1.1 rather than under
MIT. In these situations, if they did occur, downstream recipients of e.g.
a file subject to both licenses would be looking at the license grants,
compliance obligations, etc., from both licenses -- the same as any other
OSS situation involving multiple licenses.

Even if A labels Y as OpenMDW-1.1, that does not diminish B's ownership of
Y or the terms on which B offers it, and it does not negate C's rights
under MIT, because MIT grants permission directly to any person obtaining a
copy. C's rights in Y run from B, not from A's labeling. For the same
reason, termination under OpenMDW-1.1 never reaches the licenses B grants
under MIT. Termination ends only "rights and grants made to you hereunder,"
and B's MIT grants are not among them.

On the second half of Pam's example: the MIT licensor is B, the owner of Y,
who is also using X as an OpenMDW licensee. If B files a lawsuit asserting
that X infringes B's copyright in Y, the termination provision applies by
its terms. Three observations. First, nothing before litigation is affected
by or relevant to the license. Compliance demands, cure negotiations, and
every enforcement tool short of a filed lawsuit remain fully available, and
community enforcement norms have long treated litigation as the last
resort. Second, when B does sue, every remedy remains available, including
damages and an injunction that could halt distribution of X entirely. B
needs no license from anyone to bring the claim. Third, what B gives up is
B's own license to X while B maintains an offensive suit asserting X’s
distribution is unlawful. B's ownership of Y, B's MIT licensing of Y to the
world, and B's remedies are all untouched. Additionally, and as a practical
matter, if B prevails in its copyright litigation, then A’s distribution
and licensing of X to B and to the world at large is probably going to end
in any case.

A carve-out for good faith license enforcement suits would, in my view, be
unadministrable, since every plaintiff characterizes its own claim as
legitimate enforcement, and a license term cannot adjudicate motive. The
responsive suit exception is the administrable line.


4. Pam's question on why the trigger stops at patent and copyright.

The trigger tracks the realistic assertion risks for publicly released
model materials, not exact alignment with the grant. Apache-2.0 grants both
copyright and patent licenses but terminates on patent claims only, so a
trigger narrower than the grant is common. The omitted IP regimes also fit
poorly. Trade secrets are misappropriated rather than infringed, and a
trade secret claim about openly published materials is close to a
contradiction, since publication destroys secrecy. Sui generis database
rights exist in only some jurisdictions. The drafting initially started
with OpenMDW-1.0 using a patent trigger but was expanded in OpenMDW-1.1 to
include copyright, where infringement suits about model materials
realistically arise, without going as far as terminating for any
“intellectual property infringement” claims as OCLC-2.0 does.

5. The "solely responsible" paragraph is a disclaimer, not a covenant.

I want to respond to this carefully, because the scenario described depends
on a reading the OpenMDW-1.0 and -1.1 texts do not support, and one the
drafters did not intend. Speaking as the license steward: that paragraph
allocates risk between the parties. It imposes no duties on the licensee
and cannot support termination. The full paragraph has 3 parts, which are
also relevant, so I’ll repost it below:

YOU ARE SOLELY RESPONSIBLE FOR (1) CLEARING RIGHTS OF OTHER PERSONS THAT
MAY APPLY TO THE MODEL MATERIALS OR ANY USE THEREOF, INCLUDING WITHOUT
LIMITATION ANY PERSON'S COPYRIGHTS OR OTHER RIGHTS INCLUDED OR EMBODIED IN
THE MODEL MATERIALS; (2) OBTAINING ANY NECESSARY CONSENTS, PERMISSIONS OR
OTHER RIGHTS REQUIRED FOR ANY USE OF THE MODEL MATERIALS; OR (3) PERFORMING
ANY DUE DILIGENCE OR UNDERTAKING ANY OTHER INVESTIGATIONS INTO THE MODEL
MATERIALS OR ANYTHING INCORPORATED OR EMBODIED THEREIN.

The paragraph contains no obligation language. There is no "you shall
clear" or "you must obtain." "You are solely responsible for" allocates
risk between the providers and the recipient. The providers bear no
responsibility for rights clearance. The paragraph is the recipient-side
complement of the preceding paragraph, in which the providers disclaim the
warranties of title and noninfringement. The structure also confirms it.
The three items are joined by "or," where a list of affirmative duties
would be conjunctive. And item (3), read as a duty, would require every
licensee to perform due diligence and investigations before any use. No
known permissive license imposes that, and this one similarly does not. The
paragraph says that whatever clearance, consents, or diligence a licensee's
particular use may need, that work and that risk are the licensee's
responsibility, because the providers promise nothing.

I’ll note that similarly structured language appears in the disclaimers for
some of the other widely used OSI-approved software licenses, such as
Apache-2.0 section 7 (“You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any risks
associated with Your exercise of permissions under this License.”), and
EPL-2.0 section 5 (“Each Recipient is solely responsible for determining
the appropriateness of using and distributing the Program and assumes all
risks associated with its exercise of rights under this Agreement…”) and
its predecessors. As with OpenMDW-1.1, these provisions in the context of a
warranty disclaimer reflect an allocation of risk, not an affirmative duty.

Because the paragraph imposes no requirement, there is nothing in it to
comply with from a license obligations perspective. The "subject to your
compliance" language does not trigger based on an allocation of potential
risk. The license has one termination mechanism, the litigation provision,
and one affirmative condition, notice retention on distribution. There is
no lever for a licensor to terminate a licensee for failing to clear
training materials. No such duty exists under this license.

6. Richard's question/points on the scope of Model Materials.

Richard, you wrote that the open-ended reading is probably not what was
intended. Correct, and I will state the LF’s position here so it is on the
record. Model Materials means the materials provided to the licensee under
the agreement that accompanies a provision of materials. The definition
says this twice: "provided to you under this agreement" and "that are
provided to you hereunder." It is not the licensor's catalog. It does not
reach materials the licensor separately releases under the same license
text, whether before or after, and it does not expand over time. Each
provision of materials under the license is its own agreement covering what
was provided. If Acme Corp releases component D under GPL-2.0 and then
releases component E under GPL-2.0, they are not combined or treated as a
single licensed work. A claim asserting that E infringes does not terminate
rights received under D’s separate agreement, and I couldn’t imagine
GPL-2.0’s statement that a violation “will automatically terminate your
rights under this License” being read as terminating rights to multiple
different GPL-2.0 components.

Richard’s email: >> 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).

So in your example, a claim against model A does not reach documentation
for unrelated models B and C provided separately, because those were not
provided under the agreement involved in the claim against model A. The
plural "one or more machine learning models" covers releases that genuinely
ship multiple models together, such as a family of variants provided as one
set, not every model a licensor has ever published - and even a publisher
may release artifacts separate from the OpenMDW model release. Though it
would make things more fun to evaluate other licenses and publishers’
practices, publisher practices don’t make a license noncompliant with the
OSD.

You are right that the license does not define "release," or use that term,
and that the operative act is what is provided to the licensee. Where a
licensor provides one set of materials across multiple repositories as one
release, what was provided together under the agreement is what the
agreement covers, and I agree the licensor should make that boundary
clearly legible. Our drafting discussions considered using SPDX short
identifiers / SBOMs as a simple way to meet this intent - to ensure the
license identifier and/or list of artifacts travels with the artifacts.
Your enumeration suggestion is constructive, and we can likely publish
guidance encouraging OpenMDW licensors to also enumerate the contents of
each release, for example in a manifest or model card, consistent with the
Model Openness Framework practice of itemizing release components. I do not
believe this requires a change to the license text, since the definition
already turns on what is provided.

7. Richard's question on scoping termination to the parameters alone.

David made the conceptual point already: a single instrument granting one
bargain across overlapping regimes should not let a licensee attack part of
the bargain while retaining the rest. The same holds across the materials
provided together. If termination reached only the parameters, a licensee
could sue asserting the weights are infringing while keeping their license
to the architecture, configuration, and tokenizer provided with those
weights, components with little use apart from them. That recreates the
asymmetry the provision closes. It would also invite pleading gamesmanship,
since a complaint can frame the same theory against whichever component
preserves the most license value. And no precedent structure carves the
remedy by component within the covered work.

8. OpenMDW 1.0?

As in the submission, we remain glad to have the committee review
OpenMDW-1.0 in parallel if it prefers. However, I want to be clear that we
expect OpenMDW-1.1 to be the path forward and a more widely adopted
license. If this review also satisfies the requirement to include
OpenMDW-1.0 that would be welcome as well.

Mike

---
Mike Dolan
The Linux Foundation
Cell: +1.440.552.5322
mdolan at linuxfoundation.org

For help scheduling a meeting, please contact Jackline Mbithi <
jmbithi at linuxfoundation.org>.

---


On Sun, Aug 16, 2026 at 7:36 PM Richard Fontana <rfontana at redhat.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260820/365ba991/attachment-0001.htm>