<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 8/24/2026 2:05 PM, Michael Dolan
wrote:<br>
</div>
<p><snip></p>
<blockquote type="cite"
cite="mid:CAFV=PSEyd7Ly8aWtkdcm9X96bpTXBFZToKW0pADpwrhNhXPtog@mail.gmail.com">
<div dir="ltr">
<div><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>
</div>
</div>
</blockquote>
This may be the crux of the problem that I have (and some developers
on social media and on this list have). I agree and apologize for
mischaracterizing the legal effect, and thanks for calling me out on
it (not for the first time either!). But I believe that "but there
are other options!" is a red herring. I was thinking of the
theoretical situation where the license is widely adopted. Assume
for the sake of argument that all AI models have either proprietary
licenses or this license. This puts the FOSS developer in the
situation of either not using AI at all or being forced to use a
proprietary model if they still want to have a claim against the
open source model. I believe the fact that this license drives
developers to a proprietary solution rather than an open source one
is an indication that there is a systematic failure of the license
to support the open source ecosystem.
<blockquote type="cite"
cite="mid:CAFV=PSEyd7Ly8aWtkdcm9X96bpTXBFZToKW0pADpwrhNhXPtog@mail.gmail.com">
<div dir="ltr">
<div><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.</div>
</div>
</blockquote>
<p>The developer may just want to run the model, but with this
license they have to give up any infringement claim in return.
Your solution, with its prospective prohibition, is a much blunter
instrument than examining the facts of the case and evaluating
whether the plaintiff is acting in an inequitable way. Here, the
FOSS developer may be acting perfectly equitably but still
couldn't bring a claim. So it may be an over-correction for the
problem it is trying to solve.</p>
<p>At the end of the day I think we disagree on whose interests are
more important to protect and it's up to OSI to decide.</p>
<p><snip></p>
<blockquote type="cite"
cite="mid:CAFV=PSEyd7Ly8aWtkdcm9X96bpTXBFZToKW0pADpwrhNhXPtog@mail.gmail.com">
<div dir="ltr">
<div><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>
</div>
</div>
</blockquote>
<p>Yes, the review process certainly creates a Catch-22. We want to
see licenses early to correct them, but are less inclined to
approve a license that doesn't have a track record. </p>
<p>For the record, the license steward's viewpoint may not be
relevant to the contract interpretation, particularly when the
license steward isn't the licensor. That's why I prefer the
license language itself be corrected rather than hoping the
extraneous evidence in an FAQ will carry the day.</p>
<p>That said, if others are in agreement that MDW-1.0 is acceptable,
I would defer to their judgment.</p>
<blockquote type="cite"
cite="mid:CAFV=PSEyd7Ly8aWtkdcm9X96bpTXBFZToKW0pADpwrhNhXPtog@mail.gmail.com">
<div dir="ltr">
<div><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>
</div>
</div>
</blockquote>
<p>Richard already commented on this, and I agree. The OSI has
reserved the right to decline approval of licenses in the interest
of software freedom. As I mentioned in another email, the OSI's
role (primary, IMHO) is to ensure the health of the open source
ecosystem. Indeed the OSD could have been drafted better, but the
OSI shouldn't approve licenses, even if they meet the letter of
the OSD, if the effect is harmful. During my tenure as license
chair we added a number of other considerations that would merit a
rejection, such as putting the licensor in a more favored
position. My goal was to state as many non-OSD bases as I could,
but there is no limit to the creativity of license drafters.</p>
<p>In this case, I also don't think you can ignore the current
environment in which this license is being offered. We are in a
world where probably every single line of code by every single
FOSS developer is in every single LLM. Many FOSS developers are
unhappy about it and believe it is unlawful, a question that will
not have any clear answer for a number of years. At the same time
the proposed license expands the termination trigger beyond
anything in the past (edge-case licenses you identified excepted),
to copyright infringement, for a new type of technology that we
are all still struggling with. Further, you said that "the NVIDIA
Open Model License ... was the inspiration behind the change in OpenMDW-1.1."
NVIDIA is a defendant in eight lawsuits against its AI models, so
it is highly motivated to reduce the threat vector in any way it
can. I assume this is the motive for adding this new trigger, and
my view is that, on balance, it harms the ecosystem more than
advances it.</p>
<p>Pam</p>
<div class="moz-signature">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 class="moz-txt-link-abbreviated" href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a></div>
</body>
</html>