[License-review] For Approval: OpenMDW License Agreement, versions 1.1 (OpenMDW-1.1)
Pamela Chestek
pamela at chesteklegal.com
Mon Aug 24 01:20:03 UTC 2026
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 largeis 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 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/20260823/e7710ff9/attachment-0001.htm>
More information about the License-review
mailing list