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

[Shuji Sado]

Dolan-san,

Your explanation has largely addressed my concern about the intended scope
of the Model Materials. If OpenMDW guidance makes clear that the boundary
of each release should be identified through mechanisms such as a MOF
configuration file, manifest, or model card, I think guidance may be
sufficient.

However, because that boundary determines the scope of termination, it is
important information for licensees. I would therefore strongly encourage
the OpenMDW guidance to recommend explicitly enumerating the Model
Materials that make up each release.

Shuji


2026/8/21 1:33 Michael Dolan <mdolan at linuxfoundation.org>:

> 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
>>
>> _______________________________________________
> 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
>


-- 
Shuji Sado
Chairman, Open Source Group Japan
https://opensource.jp/
English blog: https://shujisado.org/
Japanese blog: https://shujisado.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260822/e73836ce/attachment-0001.htm>