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

[Michael Dolan]

A few points raised since Friday were new, so I will share my view on those
in case it helps everyone's understanding. It’s challenging to keep up with
all the points raised and comments. I will then summarize our position
regarding the more contentious points and areas of confusion that resurface
throughout this thread.

1. "Voluntarily participate" (Richard's point).

Richard, you are correct in tracing this to the patent non-assert language
from the Microsoft promises through OWFa 1.0, whose agreements we use today
across a number of specification communities. For example, the Open
Container Initiative releases specifications under the OWFa 1.0 patent-only
variant alongside Apache-2.0, and GraphQL is licensed under OWFa. The
phrase does specific, narrow work. "File or maintain" alone would invite an
obvious dodge: fund, direct, join, or control litigation nominally brought
by someone else. The word "voluntarily" excludes compelled participation. A
subpoenaed witness, a deposed employee, a juror, and a party joined
involuntarily do not voluntarily participate. I can only confirm our intent
in OpenMDW. David Rudin, who chimed in earlier on this thread, was part of
drafting the OWFa (and maybe also the Microsoft promises). I'll defer to
him on the OWFa's intent - we weren’t involved in that drafting work.

2. "Corresponding lawsuit" (Richard and John).

The termination provision targets voluntary first aggression, so a party
who was sued first does not lose its license by responding, whether by
counterclaim, cross-claim, or a separately filed responsive action.
"Lawsuit" rather than "counterclaim" is deliberate. Responsive claims
sometimes must be brought as separate actions, in a different forum or a
declaratory posture, and the exception should not turn on civil procedure.
"Corresponding" ties the responsive suit to the litigation first brought
against you. Without it, any unrelated suit anyone had ever filed against a
party would immunize that party's later aggression indefinitely. I would
also note that compulsory counterclaim rules in some jurisdictions require
a defendant to assert related claims or lose them. The exception ensures
the license never forces a choice between complying with those rules and
keeping the license. So Richard is right that it does not require the two
suits to share underlying subject matter, and it is not merely "another":
it means responsive to the action first brought against you.

3. Use in litigation. (Kevin’s points)

Kevin, regarding your concern about retained experts and counsel and access
in litigation, I had a couple of reactions. First, termination operates
only as of filing or participation, so all pre-suit investigation and
testing happens under a full license. Second, use as evidence after filing
does not depend on the license.

Use for purposes of judicial proceedings is protected independent of any
license, in the US as fair use, and analysis of accused materials proceeds
through discovery. This isn’t just a license steward’s claim; see, e.g.,
Bond v. Blum, 317 F.3d 385, 392-397 (4th Cir. 2003) (finding fair use of
copyrighted materials when used as evidence in a court proceeding), and I’m
sure dozens of other cases out there.

I’ll point out that the same situation would apply, for example, for a case
relating to software under MPL-2.0 where a plaintiff brings both patent and
copyright claims (the Oracle v. Google litigation is an example where both
types of claims were brought together, albeit not for MPL-2.0-licensed
software). Section 5.2 of MPL-2.0 would terminate all license grants (both
patent and copyright) due to the patent claim. The plaintiff would
presumably have to investigate their copyright claims using mechanisms
other than an explicit license grant under MPL-2.0. I can't claim to know
how that would work outside the U.S., but at least in the U.S., we have
other avenues than the license grant.

4. The API and RAG hypo (Moming's point).

Moming, I don't think your hypothetical works as stated under the
definition of Model Materials. Model Materials means the materials
"provided to you" under the agreement. A provider's server-side store of
user inputs is never provided to the user and is therefore not part of any
user's Model Materials. A user of a hosted API typically receives no Model
Materials at all and needs no copyright license to use a hosted service;
the provider's terms of service govern that relationship, not this license.
A claim that a provider is misusing your inputs is a claim about the
provider's conduct, not a claim that materials provided to you infringe. I
do not see how OpenMDW would apply in this scenario, as that conduct likely
falls under their terms of use or service agreement.

5. Downstream recipients (Carlo, in response to your point (a)).

Yes, the definition and grant are per recipient. Each recipient's license
runs directly from the providers under that recipient's own agreement, not
through a chain from an intermediate distributor, and termination reaches
only the rights and grants made to the litigant. A downstream recipient who
is not a participant in the litigation holds their own grant and is
unaffected.

I would note again that OpenMDW licenses are already in use in the field,
and many licensors have published model materials under them. I accept your
point that it could be clearer, but I'm also not aware of any perfectly
drafted open source license… so I'll request a similarly fair evaluation as
other licenses in use, warts and all. :-)

6. On the software freedom subthread, I'll stay out of the definitional
debate, but Luis, your reframing toward the health of the software commons
resonates with me. That is the test this license was built for: moving
model publishers from bespoke restrictive terms into the commons. I
couldn’t justify to a business decision-maker that they couldn’t use
OpenMDW-1.1 licensed models because of the arguments playing out in this
thread. At some point in the analysis, this thread has gone to a strange
place.

7. Finally, since several earlier points keep resurfacing as the thread grows,
and it appears people are not going back to read everything (which is
understandable), I thought I’d provide a short summary of our positions as
the steward, which we have already stated in this thread. Perhaps this will
help bring this debate to a close:

(a) The termination provision does not preclude or waive any claim or
remedy, and it is merits-neutral. It presumes nothing about whether any
claim, patent or copyright, is valid, and it operates identically either
way, as patent retaliation always has. It does not prevent anyone from
filing any litigation on any topic. It ends only the claimant's own license
to the materials claimed to be infringing upon filing such a lawsuit.
Pre-litigation enforcement is also out of scope. The license termination
provision puts the parties back into the same position they were in before
any license was conveyed.

(b) The trigger reaches only claims that the licensed materials themselves
infringe, the class of claims that attacks the subject of the grant itself.
Broader triggers, such as any IP claim or any lawsuit, were considered and
rejected.


(c) Terminating copyright grants as a remedy appears in OSI-approved
licenses (e.g., MPL 1.1 §8.2, CDDL 1.1 §6.2, OSL 3.0 §10, CAL-1.0 §5.3),
and OSI has approved a trigger broader than patent claims in OCLC-2.0 §5.

(d) OpenMDW does not relicense third-party code, and it doesn’t “grab”
third-party code into its scope. The grant conveys only rights the
providers hold or can pass through for the materials identified as being
provided, and third-party components keep their own licenses and notices.
Unlike other licenses, which may have narrower grants, the grant is
intended to encompass all possible rights a user of an OpenMDW-license
model may need to practice/use the model. This is intentional and designed
to overcome potential lack of clarity in other licenses when used in an AI
model context. For example, Apache-2.0’s grants are centered on copyright
via “the Work” which is “the work of authorship” (copyright), and then the
patent grant is scoped to “the Work”.

(e) “Model Materials” is transaction-scoped to the materials provided to
you under one agreement. Separate releases are separate agreements, and
there is no ever-expanding covered work. The definition's own word
"related" bounds the unit of materials concern that keeps coming up. I
understand that the OpenMDW is novel in the scope of Model Materials, but
honestly, for how many years have we debated “what is the Work” under
Apache-2.0 or “the Program” under EPL-1.0 without ever questioning if they
satisfy the OSD requirements?


(f) The clearance paragraph is a risk-allocation disclaimer. The license
has one affirmative condition, notice retention, and one termination
mechanism, the litigation provision. Where this license family intends a
condition, it says so expressly. And licenses such as §2(c) of EPL-1.0 and
EPL-2.0 show that even if such risk-allocation terms were an explicit
condition of the license grant (which they are not for OpenMDW), an
explicit condition would still not conflict with the OSD.

(g) We can clarify many of the concerns raised here with FAQ updates
stating these interpretations and publishing guidance for model publishers
that recommends enumeration of each release's Model Materials.


---
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 Tue, Sep 1, 2026 at 1:19 AM Luis Villa <luis at lu.is> wrote:

> On Sun, Aug 30, 2026 at 2:51 PM Pamela Chestek <pamela at chesteklegal.com>
> wrote:
>
>> McCoy, you asked for a definition of "software freedom" and Moming's
>> response is similar to my thoughts:
>>
>> On 8/29/2026 11:10 PM, Moming Duan wrote:
>>
>> Here is a simple test of my own: *if 99% of the world's models were
>> released under license X, would our ecosystem be better off?*
>>
>> My premise is that the everyone benefits from a software commons, so,
>> does the license encourage or discourage sharing?
>>
> "Software freedom" is the ability to do anything you want with the
>> software. A few conditions/impairments are allowed because they indirectly
>> encourage the growth of the software commons - giving credit (copyright
>> notice/attribution), telling people what their rights are (the license),
>> the appropriate distribution of risk (the "as-is" rep and disclaimer of
>> warranty), and compulsory sharing (copyleft). The balance is very delicate.
>> It's questionable whether the GPLv3, and then the AGPL, contribute to the
>> health of the open source software commons because they are commonly used
>> as the antagonist to encourage people to get a commercial license instead.
>> It does, though, seem that lever isn't as successful anymore, since people
>> are more willing to comply with the copyleft licenses and these two
>> licenses are more often being used for their intended benefit.
>>
>> This, I think, is the piece that's missing from the OSD. We've seen the
>> OSD gamed when it has been formally met but it is nevertheless clear that
>> the license is designed to give one entity superior rights in the software
>> or has mechanisms that will discourage the use of the software. "Providing
>> software freedom" as a requirement is a check on that.
>>
> FWIW any or all of Pam's formulations of "encouraging sharing of software"
> or "contributing to the health of the software commons" or "protecting the
> open software ecosystem" (from an opensource.com essay of yours, Pam,
> IIRC) would be vastly superior to "providing software freedom".
>
> Besides the obvious point that software doesn't have freedom, any of those
> would be much clearer to argue about, with less baggage. (There would still
> be plenty of arguing; all of those still require value judgments. But at
> least it'd be a value that one can attempt to decipher from the words.)
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260901/a5386c6c/attachment-0001.htm>