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

[Joshua Gay]

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
meet: https://calendly.com/jgay-ieee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260828/35cc4485/attachment-0001.htm>