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

[Pamela Chestek]

On 8/24/2026 2:05 PM, Michael Dolan wrote:

<snip>

>
>
> 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?
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.
>
> 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.

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.

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.

<snip>

>
> 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.

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.

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.

That said, if others are in agreement that MDW-1.0 is acceptable, I 
would defer to their judgment.

>
> 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.

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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260826/85382c17/attachment-0001.htm>