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

Michael Dolan mdolan at linuxfoundation.org
Tue Sep 1 21:05:30 UTC 2026


On Tue, Sep 1, 2026 at 1:12 PM Pamela Chestek <pamela at chesteklegal.com>
wrote:

> ...
>
> These are all statements of how you believe that the license should be
> interpreted. But a number of people have explained how a party or a court
> could find ways to construe it differently. As an example, you say in (f)
> that "the clearance paragraph is a risk-allocation disclaimer." But I
> previously pointed out, and you acknowledged, that it could be construed as
> an obligation on the part of the licensee. You have also acknowledged that
> some of the content could be double-licensed with the OpenMDW-1.1 license
> and the original third-party license, which is somewhat contrary to how you
> say the license operates in (d). So I would take all of these statements as
> what your intention was, not how the license actually operates. And the
> problem with trying to correct ambiguities with FAQs is that there is no
> requirement for a court to consider statements outside the four corners of
> the license itself, particularly when the author of the statements isn't a
> party to the lawsuit. So you can't count on FAQs to prevent an unintended
> interpretation.
>

Pam, three responses to your latest email, which, in my opinion,
characterized our position in a way I feel compelled to correct.

On dual licensing: I do not see the inconsistency with (d). Passing
third-party code through under a sublicense that the third party's own
license permits is exactly what (d) describes, a grant conveying rights the
providers hold or can pass through. What (d) denies, and what held true in
every scenario we walked through, is that OpenMDW strips or replaces the
third party's terms or diminishes any recipient's rights received directly from
the third party. B's MIT offer and C's rights under it were untouched in
all four scenarios we went through.

On the clearance paragraph: what I acknowledged is that the drafting could have
been clearer (which is also true of clauses in every OSI-approved license),
and I stated the reading I consider correct and why. Those positions are
consistent, and they are the posture every license steward I'm aware of
takes toward imperfect text. If there's a perfect text with zero ambiguity,
I apparently haven't seen it yet. Furthermore, if the concern is that a
“you are solely responsible for clearing rights” disclaimer might be
misread as an implicit license condition, then I think this would have
significant implications for OSI-approved licenses such as the EPL family,
which make comparable “solely responsible” terms an explicit license
condition with no ambiguity.

On intention versus operation: part 7 of my prior email was labeled what it
is: a summary of our positions as the steward. You take those as statements
of intention rather than of how the license operates. But the standard
implied by your objection asks me to prove a negative: that no party could
ever propose a different construction. No license drafter could ever meet
that burden. You are right that a steward's statements do not bind courts,
and right that a motivated party can propose an alternative construction of
any license. But that has been the condition of every license OSI has ever
approved. "The Work" under Apache-2.0, "the Program" under the EPL, and
GPLv2, acquired stable meaning over decades through the same combination of
text, structure, published steward interpretation, and community practice.
If "a court might read it otherwise" were the standard, I can't see how any
license would ever pass OSI's review.


I am surprised by the level of scrutiny being applied here, and while I
welcome the thoughtful analysis, I want to make sure our position and
statements are not misunderstood.


Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260901/00d76c94/attachment.htm>


More information about the License-review mailing list