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

[Michael Dolan]

Pam, Sado-san, thank you for stating your positions clearly. Three brief
responses below.

1. Pam, you are right that I missed a fourth configuration: Y unmodified,
under both MIT and OpenMDW-1.1. I should have included it. I do not think
it changes the outcomes. MIT grants permission directly to any person
obtaining a copy, and every recipient of the distribution has obtained a
copy, so B's direct grant reaches each recipient in parallel with whatever
narrower sublicense A conveys. A's layering cannot subtract from B's own
offer. The layered consequence you describe, where noncompliance with the
second license costs the licensee the licensor's own materials but not the
third-party code, is how multi-license distributions already work today,
including in your GPL example. And no configuration changes the termination
analysis, because termination reaches only rights and grants made
hereunder, and B's MIT grants are not among them.

2. On "someone whose code was infringed cannot bring a claim": that is not
what the provision does, and I want to be precise about it because the
distinction matters. B can bring the claim, including for willful
infringement, with every remedy intact, and A must defend it fully. There
is no immunity of any kind. What B cannot do is keep exercising A's license
to X while maintaining the suit.

Practically, I have to look at the consequence of that choice for a
genuinely wronged developer. A developer who sues A asserting that X was
built by deliberately and unlawfully copying the developer's code is
asserting that X is itself unlawful. At the same time, many alternative
models are available to the developer – X is not even remotely their only
option. A developer with a genuine copyright claim has no realistic need
(and I would suspect… no desire) to keep building on the very model they
have told a court is the product of copyright infringement. For that
developer, the provision costs nothing they actually want – why would they
want to use or distribute a model someone else created and published that
infringes their copyright?

The only party the provision binds is one who insists on both attacking X
as unlawful and continuing to exploit X at the same time. This community
has seen that pattern before, and it has a name. I was at IBM during the
SCO litigation. SCO asserted that the Linux kernel infringed rights SCO
claimed to hold, while continuing to distribute the kernel and offering
paid licenses to it, demanding that the world pay SCO for the very
materials it was attacking in court. The answer, including in the
litigation itself, was that this posture is incoherent: a party should not
be able to exploit a work while maintaining that the work is unlawful.
OpenMDW-1.1 writes that expectation into the license prospectively and
neutrally, for everyone equally, instead of leaving it to after-the-fact
estoppel and waiver arguments. It does not stop the next SCO from suing. It
stops the next SCO from suing while keeping its license to the accused
materials. I would suggest that is not antithetical to open source
principles. It is one of the harder lessons this ecosystem (or at least
IBM) paid to learn.

And as noted earlier, if B prevails, distribution of X ends for everyone in
any case.

3. The Adams citation is probably fair drafting criticism, and I guess the
collective of drafters missed this opportunity to clarify it. I could also
argue many licenses approved by OSI have worse drafting issues but made it
through review. As noted in my reply to Sado-san, we can state the
risk-allocation interpretation in the OpenMDW FAQ, and we can take a
clarifying sentence to the drafting community. I have noted your view that
1.0 would be acceptable with that ambiguity removed; however, both versions
are already in use in the field. A reason a steward's interpretation would
be more appropriate. The steward's guidance and this public record may do
more to help inform the interpretation of licenses already granted, while a
future text revision would not reach them, since released models keep the
license text they shipped with.

4. A closing observation on the standard of review.

As this review moves toward the committee/board's deliberation, I want to
offer one observation about the standard being applied. Lawyers on this
list will recognize the flavor of this debate from US constitutional
practice, where textualists and originalists argue over how to read a
governing text. On the OSD, happily, the two schools converge. The OSD's
text contains no provision addressing termination triggers. And the
approval practice from the era of the OSD's adoption shows that none was
understood: this body approved a license terminating on any intellectual
property infringement claim (OCLC-2.0), licenses terminating in their
entirety upon any patent action against the licensor, related to the
software or not (RPSL-1.0, Watcom-1.0), and, in the modern era, a license
terminating all permissions upon suits against any recipient (CAL-1.0). I
have tried to anchor every response in this thread to text: the license's
text, the OSD's text, and approved precedent.

Some of the remaining objections, thoughtful as they are, rest instead on
views about what open source licenses ought to do about copyright
enforcement. That is a legitimate and important policy conversation, and
the OSI is an appropriate place to have it. However, I think this
discussion is more appropriately labeled as a conversation about amending
the OSD or the written review criteria, to be had prospectively, rather
than a conformance standard applied for the first time to a pending
submission that meets the previously published requirements.

Mike

On Sun, Aug 23, 2026 at 9:20 PM Pamela Chestek <pamela at chesteklegal.com>
wrote:

> On 8/20/2026 9:31 AM, Michael Dolan wrote:
>
> <snip>
>
> 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.
>
> You've missed a fourth configuration, where Y is unmodified and under both
> the MIT License and the OpenMDW-1.1 license. This scenario is the selling
> point of the license, "*A single, easy-to-apply license enabling
> openness, consistency, and clarity across all components of an AI model
> distribution.* <https://openmdw.ai/>" In that case the user must comply
> with both licenses.
>
> This can be effected in two ways: the MIT license in particular is
> sublicensable, and a sublicensor can grant few of the rights than they
> obtained in the license. So it is quite feasible for the OpenMDW-1.1
> licensor to claim that it only sublicensed the MIT-licensed material, which
> are therefore subject to the additional constraints in the OpenMDW-1.1
> license.
>
> Secondly, the concept that, absent the ability to sublicense, someone can
> add a new license to a third-party work is odd, but everyone seems to go
> along with the concept. If the $GPLs are the model, what happens is that,
> if you don't comply with the additional requirements (such as providing
> source code) even for third party code, then you lose you license to the
> code for which the licensor is the owner -- not for the third-party code
> (because, as you say, the original MIT license is still valid), but the
> rest of the code. We have to consider the possibility that the same will be
> the case in this layered licensing scenario, so FWIW you can't dismiss the
> possibility that unmodified third-party code will also be subject to the
> OpenMDW-1.1 license.
>
>
> 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.
>
> So the answer is yes, that someone whose code was infringed cannot bring a
> claim for infringement, even where the OpenMDW 1.1 licensor is an
> intentional, willful infringer.
>
> <snip>
>
> 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.
>
> Then why is it there? What is it for? It is a principle of contract
> interpretation that a document should be read to give effect to all its
> provisions. So if you already have an "as-is" disclaimer, what does this
> add?
>
> I also disagree that the language could never be construed as language of
> obligation. It doesn't say "you shall clear" or "you must obtain," but it
> does say "you are solely responsible for." According to Kenneth Adams, *A
> Manual of Style for Contract Drafting* § 3.99 (3rd ed.), this wording is
> in the category of language of obligation, albeit a form he does not
> recommend because "it is potentially confusing, as it's not clear whether a
> provision using *is responsible for* itself creates a duty or
> acknowledges the existence of a duty that derives from some other source."
> Exactly so here.
>
> Because the language may be construed as having some scope different from
> the "as-is" representation, is quite detailed, and uses language of
> obligation, it can be read as an obligation. If you don't mean for it to be
> obligatory, then you should add language to make that clear, something as
> easy as changing "You are solely responsible for" to "It is recommended
> that you." I think we're past the days when we can just cross our fingers
> that open source licenses will be construed as we hope (or intended).
>
> <snip>
>
> 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.
>
> I would be open to approving version 1.0 if my concerns about the
> paragraph enumerating the licensee's obligations to clear rights are
> addressed, ensuring it can only be interpreted as a recommendation, not an
> obligation.
>
> I am opposed to version 1.1 because of the trigger of termination for a
> copyright infringement claim. You say it's just an extension of patent
> termination to a new threat vector, but I don't agree that means you can
> apply the same principles. The reason for treating patent and copyright
> infringement differently is that copyright infringement requires copying.
> That means that there was a volitional act (whether lawful or unlawful) on
> the part of the licensor, and the license gives them blanket immunity for
> that act. Taking AI entirely out of the picture, you confirmed that the
> copyright owner of an MIT-licensed package would be precluded from bringing
> a lawsuit against the OpenMDW-1.1 licensor for that licensor's failure to
> comply with the terms of the MIT license. So what you are proposing is
> that a completely non-culpable party has to give up a claim against what
> might be a deliberate, intentional, unlawful act, which is not the patent
> scenario. This seems to me to be antithetical to open source principles -
> open source developers get exploited enough without being exploited by
> their own community. If the model provider believes their deliberate use of
> someone else's copyrighted work is non-infringing they should be willing to
> defend the claim, not absolve themselves of liability through contract.
>
> Whether the use of FOSS for training LLMs is lawful is irrelevant. I think
> the concept is objectionable for an open source software license too, it's
> only that the copying of the entire open source corpus by LLMs has shown
> that the self-serving use of a copyright termination provision is not an
> unlikely or uncommon possibility.
>
> Pam
> Pamela S. Chestek
> Chestek Legal
> 4641 Post St.
> Unit 4316
> El Dorado Hills, CA 95762
> +1 919-800-8033
> pamela at chesteklegal.com
> www.chesteklegal.com
>
>
>
> 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 listLicense-review at lists.opensource.orghttp://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260824/83db320c/attachment-0001.htm>