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

[Michael Dolan]

We have identified additional uses of OpenMDW since the original
submission. You can now track OpenMDW's use in public models at
https://models.openmdw.ai.

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 Fri, Aug 28, 2026 at 7:52 PM Joshua Gay via License-review <
license-review at lists.opensource.org> wrote:

>
> On Fri, Aug 28, 2026, 4:24 PM Luis Villa <luis at lu.is> wrote:
>
>> On Fri, Aug 28, 2026 at 3:10 PM Richard Fontana via License-review <
>> license-review at lists.opensource.org> wrote:
>>
>>> On Fri, Aug 28, 2026 at 5:45 PM McCoy Smith <mccoy at lexpan.law> wrote:
>>> >
>>> > For AI licenses, OSI doesn't have looser or stricter standards; they
>>> are evaluated against both OSD https://opensource.org/osd as with any
>>> license, and the OSAID
>>> https://opensource.org/ai/open-source-ai-definition which is applicable
>>> to licenses designed to be used on AI. Beyond that, the evaluation is the
>>> same.
>>> >
>>> > If, for whatever reason, people believe there should be other tests
>>> (like "advancing software freedom" or "Freedom Zero"), I'd be interested in
>>> hearing that (although several have already advanced those), but in order
>>> for the Board to understand what those tests are and how to apply them to
>>> licenses, I think we'd need to hear specificity on how to apply those tests
>>> in practice (both against the recently submitted AI licenses: ModelGo-Zero,
>>> ModelGo-Attribution, and OpenMDW-1.1, as well as against future licenses).
>>> I'd also like to understand if those tests are equally applicable to non-AI
>>> licenses, and if not, why not.
>>>
>>> Just to be clear, the OSI already is supposed to consider "software
>>> freedom", as I noted earlier, as stated at
>>> https://opensource.org/licenses/review-process
>>>
>>> The purpose of OSI license review is, in part, to "Ensure approved
>>> licenses conform to the Open Source Definition *and* provide software
>>> freedom".
>>> (emphasis added - the important thing is that "conformance to the OSD"
>>> and "providing software freedom" are not equivalent)
>>>
>>> and
>>>
>>> "[The license-review participants'] consensus that a license does not
>>> ensure software freedom may, in some cases, be the justification for
>>> rejecting a license even where they cannot identify a specific aspect
>>> of the OSD or the approval guidelines below that is not met."
>>>
>>> That's not an articulated "test" but since adoption of that language
>>> in . . . 2019 or so? . . . the OSI has at least in some cases made
>>> reference to the concept of "software freedom" in explaining its
>>> dispositions of particular submitted licenses.
>>
>>
>> Yes, and as I’ve pointed out repeatedly since 2019[1], the addition of
>> this test with zero articulation of any definition of the term, or any
>> tests, or anything other than “we know it when we see it” invites exactly
>> the sort of endless argument we see in this thread.
>>
>> Is CAL violating “software freedom”? no one can say, so we’ll argue over
>> it for a year. Is this license violating software freedom? no one knows
>> what that means, so no one can say, so wellllp
>>
>> I actually do think values should form a part of the license-review
>> process, and there’s an interesting discussion to be had (maybe[2]) about
>> some of what this license does. But “software freedom” isn’t a value anyone
>> at OSI can articulate (especially not “software freedom, but different from
>> what FSF means by it”) so instead of discussing values we’ll end up
>> screaming about an ineffable and undefined term, hoping the current board
>> agrees with us.
>>
>
>
> I would maybe be a little stronger than Luis and say that "Software
> freedom" is not undefined. It is an inherited, open-textured standard with
> a canonical formulation and a substantial interpretive tradition.
>
> And, also, yes, what OSI has failed to articulate is how it receives and
> applies that tradition.
>
> Maybe, though, OSI does not need to state a much more precise definition
> in advance. It seems a little like the way English common law carries over
> into American law. The meaning gets worked out in specific cases, through
> precedent and analogy, rather than having legislatures spell out every
> possible application beforehand.
>
> OSI could do something similar by explaining how it applies software
> freedom in particular license decisions and letting those decisions
> gradually build up a body of precedent.
>
> That could happen, for instance, as part of the Board's decision to
> approve or reject a license, or even now by going back and adding reasoning
> to important past decisions. It may only matter occasionally, but when
> software freedom is doing work beyond the OSD, a line or two explaining
> that reasoning would gradually give the standard more content.
>
>
>
>
>
> Joshua Gay
> Sr. Manager SA Open Source Community & Infrastructure
> https://saopen.ieee.org
> m: +1 617.966.9792 <(617)%20966-9792>
> meet: https://calendly.com/jgay-ieee
> _______________________________________________
> 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/20260828/8f911356/attachment-0001.htm>