<div dir="ltr"><div>Pam, Sado-san, thank you for stating your positions clearly. Three brief responses below.<br><br>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. <span class="Asgive ng" style="border-style:none;background:none">And no</span> configuration changes the termination analysis, because termination reaches only rights and grants made hereunder, and B's MIT grants are not among them.<br><br>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. <br><br>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 \u2013 X is not even remotely their only option. A developer with a genuine copyright claim has no realistic need (and I would suspect\u2026 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 \u2013 why would they want to use or distribute a model someone else created and published that infringes their copyright?<br><br>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.<br><br>And as noted earlier, if B prevails, distribution of X ends for everyone in any case. <br><br>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 <span class="Asgive ng" style="border-style:none;background:none">do more to help</span> 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.<br><br>4. A closing observation on the standard of review.<br><br>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. <br><br>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. <br><br>Mike</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Aug 23, 2026 at 9:20\u202fPM Pamela Chestek <<a href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div>On 8/20/2026 9:31 AM, Michael Dolan
wrote:<br>
</div>
<p><snip></p>
<blockquote type="cite">
<div dir="ltr">
<div><span id="m_2677272154049414216gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2">
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">3. Pam's MIT package example.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">Let me propose a cast of characters whom I will reuse below: </span></p>
<br>
<ul style="margin-top:0px;margin-bottom:0px">
<li dir="ltr" style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" role="presentation"><span style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">A publishes Model Materials X under OpenMDW-1.1.</span></p></li>
<li dir="ltr" style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" role="presentation"><span style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">As part of its distribution of X, A includes a component Y that B owns and previously licensed under MIT. </span></p></li>
<li dir="ltr" style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" role="presentation"><span style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">C is a downstream recipient and user of X and, by extension, also of B. </span></p></li>
</ul>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">Then, there are, in theory, three different license configurations that A could be distributing Y:</span></p>
<ul style="margin-top:0px;margin-bottom:0px">
<li dir="ltr" style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" role="presentation"><span style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">under MIT alone; or</span></p></li>
<li dir="ltr" style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" role="presentation"><span style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">under OpenMDW-1.1 alone; or</span></p></li>
<li dir="ltr" style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" role="presentation"><span style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">under the combination of both licenses (MIT AND OpenMDW-1.1, in SPDX license expression terms).</span></p></li>
</ul>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">The first option (MIT alone) is probably the natural outcome for a \u201cmere aggregation\u201d 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 \u201cModel Materials\u201d, as it is not \u201cprovided to you hereunder\u201d -- 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.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">The second option (OpenMDW-1.1 alone) is probably not a real option. Presumably, A does not have the authority to unilaterally replace Y\u2019s MIT license with OpenMDW-1.1, absent B\u2019s permission.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
</span></div>
</div>
</blockquote>
<p>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 href="https://openmdw.ai/" target="_blank"><i href="https://openmdw.ai/">A single, easy-to-apply license
enabling openness, consistency, and clarity across all
components of an AI model distribution.</i></a>" In that case
the user must comply with both licenses. </p>
<p>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.</p>
<p>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.</p>
<blockquote type="cite">
<div dir="ltr">
<div><span id="m_2677272154049414216gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2"><br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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\u2019s 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\u2019s distribution and licensing of X to B </span><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-style:italic;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">and to the world at large</span><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap"> is probably going to end in any case.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
</span></div>
</div>
</blockquote>
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.
<div dir="ltr">
<div><br>
</div>
<div><snip></div>
<div><br>
</div>
</div>
<blockquote type="cite">
<div dir="ltr">
<div><span id="m_2677272154049414216gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2">
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">5. The "solely responsible" paragraph is a disclaimer, not a covenant.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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\u2019ll repost it below:</span><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">
</span></p>
<p dir="ltr" style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">I\u2019ll 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 (\u201c</span><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-style:italic;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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.</span><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">\u201d), and EPL-2.0 section 5 (\u201c</span><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-style:italic;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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\u2026</span><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">\u201d) 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.</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
</span></div>
</div>
</blockquote>
<p>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? </p>
<p>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, <i>A Manual of Style for Contract
Drafting</i> § 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 <i>is responsible for</i> itself creates a duty or
acknowledges the existence of a duty that derives from some other
source." Exactly so here.</p>
<p>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). </p>
<p><snip></p>
<blockquote type="cite">
<div dir="ltr">
<div><span id="m_2677272154049414216gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2">
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">8. OpenMDW 1.0?</span></p>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></p>
</span></div>
</div>
</blockquote>
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.<br>
<p>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. </p>
<p>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.</p>
<p>Pam</p>
<div>Pamela S. Chestek<br>
Chestek Legal<br>
4641 Post St.<br>
Unit 4316<br>
El Dorado Hills, CA 95762<br>
+1 919-800-8033<br>
<a href="mailto:pamela@chesteklegal.com" target="_blank">pamela@chesteklegal.com</a><br>
<a href="http://www.chesteklegal.com" target="_blank">www.chesteklegal.com</a><br>
</div>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><span id="m_2677272154049414216gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2"><br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">Mike</span></p>
</span><br>
</div>
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<p><font face="arial, sans-serif">---<br>
Mike Dolan<br>
The Linux Foundation<br>
Cell: +1.440.552.5322<br>
<a href="mailto:mdolan@linuxfoundation.org" target="_blank">mdolan@linuxfoundation.org</a></font></p>
<p><font face="arial, sans-serif">For
help scheduling a meeting, please
contact Jackline Mbithi <<a href="mailto:jmbithi@linuxfoundation.org" target="_blank">jmbithi@linuxfoundation.org</a>>.</font></p>
<p><font face="arial, sans-serif">---</font></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Aug 16, 2026 at
7:36\u202fPM Richard Fontana <<a href="mailto:rfontana@redhat.com" target="_blank">rfontana@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
Fri, Aug 14, 2026 at 1:09\u202fPM Michael Dolan<br>
<<a href="mailto:mdolan@linuxfoundation.org" target="_blank">mdolan@linuxfoundation.org</a>>
wrote:<br>
><br>
> Treating the choice of a single license for a package of
components released together as an OSD 9 problem seems
challenging to me.<br>
<br>
OpenMDW doesn't say the Model Materials have to be released
together,<br>
for one thing. In a separate response I pointed out the
possibility of<br>
splitting up the Model Materials across differently hosted<br>
repositories in a way that might deprive the licensee of
adequate<br>
understanding of the risk theoretically imposed by the
defensive<br>
termination provision.<br>
<br>
<br>
<br>
I do not think OSD 9 is relevant here, honestly. OSD 9
prohibits a<br>
license from restricting other software distributed with the
licensed<br>
software. Specifically, it says:<br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> 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 \u2013 they\u2019re 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.<br>
[ . . . ]<br>
> 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.<br>
<br>
I think this is right, but OpenMDW doesn't talk at all about
"a<br>
release" as some sort of clear act that can be pointed to. It
doesn't<br>
say that the things making up the Model Materials must be
"packaged<br>
and built to work together". Perhaps it could? In another
response I<br>
noted that Model Materials can include more than one model,
which<br>
means more than one model release (including multiple sets of<br>
materials related in some sense to those models). By
definition, I<br>
think, if you have more than one model, you don't have a unit
that is<br>
packaged and built to work together. For example you might
have a<br>
copyright claim against model A (hosted on Hugging Face)
leading to<br>
termination of licenses to documentation for
possibly-unrelated models<br>
B and C (published on GitHub repositories or websites, say, or
maybe<br>
this even extends to things like arxiv papers). I know this is<br>
probably not what was intended or contemplated. Again, a way
to<br>
address this might be for the licensor to clearly identify all
the<br>
elements of a specific "release". My basic thought here is
that the<br>
copyright assertion termination feature would be at least
somewhat<br>
less problematic if it were clearer in principle what the
Model<br>
Materials is supposed to cover in any one licensing instance.
If, for<br>
example, you intend Model Materials to be truly open ended -
anything<br>
the licensor ever releases under OpenMDW, now or in the future
- that<br>
strikes me as a radical idea, but possibly worth considering
by the<br>
OSI as a valuable evolution of open source licensing. But I
contend<br>
that the meaning of Model Materials in the current license is
unclear.<br>
<br>
Richard<br>
<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
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 <a href="http://opensource.org" target="_blank">opensource.org</a> email address.
License-review mailing list
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
</div>
</blockquote></div>