<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 8/20/2026 9:31 AM, Michael Dolan
wrote:<br>
</div>
<p><snip></p>
<blockquote type="cite"
cite="mid:CAFV=PSE7swjqNpbLqLFoJJJOnf03khMJHa_FL_bP9ow40c0E2Q@mail.gmail.com">
<div dir="ltr">
<div><span
id="gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2">
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">3. Pam's MIT package example.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">OpenMDW-1.1 does not automatically relicense third-party code, and I think that premise may be the misunderstanding. A provider can only grant the rights it holds or can pass through. OpenMDW does not include a representation that the providers hold or have cleared every such right, and the license says so expressly: the disclaimers state that rights of other persons may apply to the Model Materials. The definition of Model Materials identifies which artifacts are covered, those "that are provided to you hereunder," and the grant then conveys, as to those artifacts, only the rights the providers hold or can pass through.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">Let me propose a cast of characters whom I will reuse below: </span></p>
<br>
<ul style="margin-top:0px;margin-bottom:0px">
<li dir="ltr"
style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre"><p
dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
role="presentation"><span
style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">A publishes Model Materials X under OpenMDW-1.1.</span></p></li>
<li dir="ltr"
style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre"><p
dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
role="presentation"><span
style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">As part of its distribution of X, A includes a component Y that B owns and previously licensed under MIT. </span></p></li>
<li dir="ltr"
style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre"><p
dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
role="presentation"><span
style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">C is a downstream recipient and user of X and, by extension, also of B. </span></p></li>
</ul>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">Then, there are, in theory, three different license configurations that A could be distributing Y:</span></p>
<ul style="margin-top:0px;margin-bottom:0px">
<li dir="ltr"
style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre"><p
dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
role="presentation"><span
style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">under MIT alone; or</span></p></li>
<li dir="ltr"
style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre"><p
dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
role="presentation"><span
style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">under OpenMDW-1.1 alone; or</span></p></li>
<li dir="ltr"
style="list-style-type:disc;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre"><p
dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"
role="presentation"><span
style="background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">under the combination of both licenses (MIT AND OpenMDW-1.1, in SPDX license expression terms).</span></p></li>
</ul>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">The first option (MIT alone) is probably the natural outcome for a \u201cmere aggregation\u201d sort of situation, or also for many situations where a component is included unmodified. If a component labeled as being MIT-licensed is included in a distributed package, then it probably would not be part of the OpenMDW-1.1 \u201cModel Materials\u201d, as it is not \u201cprovided to you hereunder\u201d -- e.g., under OpenMDW-1.1. This is probably akin to many typical open source software cases where a package includes a distribution of many unmodified components under a variety of different OSS licenses.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">The second option (OpenMDW-1.1 alone) is probably not a real option. Presumably, A does not have the authority to unilaterally replace Y\u2019s MIT license with OpenMDW-1.1, absent B\u2019s permission.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">The third option (MIT AND OpenMDW-1.1) might apply in cases where the model distributor is modifying a pre-existing MIT component, and also for some reason wants those modifications to be under OpenMDW-1.1 rather than under MIT. In these situations, if they did occur, downstream recipients of e.g. a file subject to both licenses would be looking at the license grants, compliance obligations, etc., from both licenses -- the same as any other OSS situation involving multiple licenses.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">Even if A labels Y as OpenMDW-1.1, that does not diminish B's ownership of Y or the terms on which B offers it, and it does not negate C's rights under MIT, because MIT grants permission directly to any person obtaining a copy. C's rights in Y run from B, not from A's labeling. For the same reason, termination under OpenMDW-1.1 never reaches the licenses B grants under MIT. Termination ends only "rights and grants made to you hereunder," and B's MIT grants are not among them.</span></p>
</span></div>
</div>
</blockquote>
<p>You've missed a fourth configuration, where Y is unmodified and
under both the MIT License and the OpenMDW-1.1 license. This
scenario is the selling point of the license, "<a
href="https://openmdw.ai/"><i moz-do-not-send="true"
href="https://openmdw.ai/">A single, easy-to-apply license
enabling openness, consistency, and clarity across all
components of an AI model distribution.</i></a>" In that case
the user must comply with both licenses. </p>
<p>This can be effected in two ways: the MIT license in particular
is sublicensable, and a sublicensor can grant few of the rights
than they obtained in the license. So it is quite feasible for the
OpenMDW-1.1 licensor to claim that it only sublicensed the
MIT-licensed material, which are therefore subject to the
additional constraints in the OpenMDW-1.1 license.</p>
<p>Secondly, the concept that, absent the ability to sublicense, someone
can add a new license to a third-party work is odd, but everyone
seems to go along with the concept. If the $GPLs are the model,
what happens is that, if you don't comply with the additional
requirements (such as providing source code) even for third party
code, then you lose you license to the code for which the licensor
is the owner -- not for the third-party code (because, as you say,
the original MIT license is still valid), but the rest of the
code. We have to consider the possibility that the same will be
the case in this layered licensing scenario, so FWIW you can't
dismiss the possibility that unmodified third-party code will also
be subject to the OpenMDW-1.1 license.</p>
<blockquote type="cite"
cite="mid:CAFV=PSE7swjqNpbLqLFoJJJOnf03khMJHa_FL_bP9ow40c0E2Q@mail.gmail.com">
<div dir="ltr">
<div><span
id="gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2"><br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">On the second half of Pam's example: the MIT licensor is B, the owner of Y, who is also using X as an OpenMDW licensee. If B files a lawsuit asserting that X infringes B's copyright in Y, the termination provision applies by its terms. Three observations. First, nothing before litigation is affected by or relevant to the license. Compliance demands, cure negotiations, and every enforcement tool short of a filed lawsuit remain fully available, and community enforcement norms have long treated litigation as the last resort. Second, when B does sue, every remedy remains available, including damages and an injunction that could halt distribution of X entirely. B needs no license from anyone to bring the claim. Third, what B gives up is B's own license to X while B maintains an offensive suit asserting X\u2019s distribution is unlawful. B's ownership of Y, B's MIT licensing of Y to the world, and B's remedies are all untouched. Additionally, and as a practical matter, if B prevails in its copyright litigation, then A\u2019s distribution and licensing of X to B </span><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-style:italic;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">and to the world at large</span><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap"> is probably going to end in any case.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">A carve-out for good faith license enforcement suits would, in my view, be unadministrable, since every plaintiff characterizes its own claim as legitimate enforcement, and a license term cannot adjudicate motive. The responsive suit exception is the administrable line.</span></p>
</span></div>
</div>
</blockquote>
So the answer is yes, that someone whose code was infringed cannot
bring a claim for infringement, even where the OpenMDW 1.1 licensor
is an intentional, willful infringer.
<div dir="ltr">
<div><br>
</div>
<div><snip></div>
<div><br>
</div>
</div>
<blockquote type="cite"
cite="mid:CAFV=PSE7swjqNpbLqLFoJJJOnf03khMJHa_FL_bP9ow40c0E2Q@mail.gmail.com">
<div dir="ltr">
<div><span
id="gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2">
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">5. The "solely responsible" paragraph is a disclaimer, not a covenant.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">I want to respond to this carefully, because the scenario described depends on a reading the OpenMDW-1.0 and -1.1 texts do not support, and one the drafters did not intend. Speaking as the license steward: that paragraph allocates risk between the parties. It imposes no duties on the licensee and cannot support termination. The full paragraph has 3 parts, which are also relevant, so I\u2019ll repost it below:</span><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">
</span></p>
<p dir="ltr"
style="line-height:1.38;margin-left:36pt;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">YOU ARE SOLELY RESPONSIBLE FOR (1) CLEARING RIGHTS OF OTHER PERSONS THAT MAY APPLY TO THE MODEL MATERIALS OR ANY USE THEREOF, INCLUDING WITHOUT LIMITATION ANY PERSON'S COPYRIGHTS OR OTHER RIGHTS INCLUDED OR EMBODIED IN THE MODEL MATERIALS; (2) OBTAINING ANY NECESSARY CONSENTS, PERMISSIONS OR OTHER RIGHTS REQUIRED FOR ANY USE OF THE MODEL MATERIALS; OR (3) PERFORMING ANY DUE DILIGENCE OR UNDERTAKING ANY OTHER INVESTIGATIONS INTO THE MODEL MATERIALS OR ANYTHING INCORPORATED OR EMBODIED THEREIN.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">The paragraph contains no obligation language. There is no "you shall clear" or "you must obtain." "You are solely responsible for" allocates risk between the providers and the recipient. The providers bear no responsibility for rights clearance. The paragraph is the recipient-side complement of the preceding paragraph, in which the providers disclaim the warranties of title and noninfringement. The structure also confirms it. The three items are joined by "or," where a list of affirmative duties would be conjunctive. And item (3), read as a duty, would require every licensee to perform due diligence and investigations before any use. No known permissive license imposes that, and this one similarly does not. The paragraph says that whatever clearance, consents, or diligence a licensee's particular use may need, that work and that risk are the licensee's responsibility, because the providers promise nothing.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">I\u2019ll note that similarly structured language appears in the disclaimers for some of the other widely used OSI-approved software licenses, such as Apache-2.0 section 7 (\u201c</span><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-style:italic;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.</span><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">\u201d), and EPL-2.0 section 5 (\u201c</span><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-style:italic;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">Each Recipient is solely responsible for determining the appropriateness of using and distributing the Program and assumes all risks associated with its exercise of rights under this Agreement\u2026</span><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">\u201d) and its predecessors. As with OpenMDW-1.1, these provisions in the context of a warranty disclaimer reflect an allocation of risk, not an affirmative duty.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">Because the paragraph imposes no requirement, there is nothing in it to comply with from a license obligations perspective. The "subject to your compliance" language does not trigger based on an allocation of potential risk. The license has one termination mechanism, the litigation provision, and one affirmative condition, notice retention on distribution. There is no lever for a licensor to terminate a licensee for failing to clear training materials. No such duty exists under this license.</span></p>
</span></div>
</div>
</blockquote>
<p>Then why is it there? What is it for? It is a principle of
contract interpretation that a document should be read to give
effect to all its provisions. So if you already have an "as-is"
disclaimer, what does this add? </p>
<p>I also disagree that the language could never be construed as
language of obligation. It doesn't say "you shall clear" or "you
must obtain," but it does say "you are solely responsible for."
According to Kenneth Adams, <i>A Manual of Style for Contract
Drafting</i> § 3.99 (3rd ed.), this wording is in the category
of language of obligation, albeit a form he does not recommend
because "it is potentially confusing, as it's not clear whether a
provision using <i>is responsible for</i> itself creates a duty or
acknowledges the existence of a duty that derives from some other
source." Exactly so here.</p>
<p>Because the language may be construed as having some scope
different from the "as-is" representation, is quite detailed, and
uses language of obligation, it can be read as an obligation. If
you don't mean for it to be obligatory, then you should add
language to make that clear, something as easy as changing "You
are solely responsible for" to "It is recommended that you." I
think we're past the days when we can just cross our fingers that
open source licenses will be construed as we hope (or intended). </p>
<p><snip></p>
<blockquote type="cite"
cite="mid:CAFV=PSE7swjqNpbLqLFoJJJOnf03khMJHa_FL_bP9ow40c0E2Q@mail.gmail.com">
<div dir="ltr">
<div><span
id="gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2">
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">8. OpenMDW 1.0?</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">As in the submission, we remain glad to have the committee review OpenMDW-1.0 in parallel if it prefers. However, I want to be clear that we expect OpenMDW-1.1 to be the path forward and a more widely adopted license. If this review also satisfies the requirement to include OpenMDW-1.0 that would be welcome as well.</span></p>
</span></div>
</div>
</blockquote>
I would be open to approving version 1.0 if my concerns about the
paragraph enumerating the licensee's obligations to clear rights are
addressed, ensuring it can only be interpreted as a recommendation,
not an obligation.<br>
<p>I am opposed to version 1.1 because of the trigger of termination
for a copyright infringement claim. You say it's just an extension
of patent termination to a new threat vector, but I don't agree
that means you can apply the same principles. The reason for
treating patent and copyright infringement differently is that
copyright infringement requires copying. That means that there was
a volitional act (whether lawful or unlawful) on the part of the
licensor, and the license gives them blanket immunity for that
act. Taking AI entirely out of the picture, you confirmed that the
copyright owner of an MIT-licensed package would be precluded from
bringing a lawsuit against the OpenMDW-1.1 licensor for that
licensor's failure to comply with the terms of the MIT license. So
what you are proposing is that a completely non-culpable party has
to give up a claim against what might be a
deliberate, intentional, unlawful act, which is not the patent
scenario. This seems to me to be antithetical to open source
principles - open source developers get exploited enough without
being exploited by their own community. If the model provider
believes their deliberate use of someone else's copyrighted work
is non-infringing they should be willing to defend the claim, not
absolve themselves of liability through contract. </p>
<p>Whether the use of FOSS for training LLMs is lawful is
irrelevant. I think the concept is objectionable for an open
source software license too, it's only that the copying of the
entire open source corpus by LLMs has shown that the self-serving
use of a copyright termination provision is not an unlikely or
uncommon possibility.</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><br>
</div>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAFV=PSE7swjqNpbLqLFoJJJOnf03khMJHa_FL_bP9ow40c0E2Q@mail.gmail.com">
<div dir="ltr">
<div><span
id="gmail-docs-internal-guid-bee04573-7fff-2004-8007-0793386f8fe2"><br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant:normal;vertical-align:baseline;white-space:pre-wrap">Mike</span></p>
</span><br class="gmail-Apple-interchange-newline">
</div>
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<p><font face="arial, sans-serif">---<br>
Mike Dolan<br>
The Linux Foundation<br>
Cell: +1.440.552.5322<br>
<a
href="mailto:mdolan@linuxfoundation.org" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">mdolan@linuxfoundation.org</a></font></p>
<p><font face="arial, sans-serif">For
help scheduling a meeting, please
contact Jackline Mbithi <<a
href="mailto:jmbithi@linuxfoundation.org" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">jmbithi@linuxfoundation.org</a>>.</font></p>
<p><font face="arial, sans-serif">---</font></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Sun, Aug 16, 2026 at
7:36\u202fPM Richard Fontana <<a
href="mailto:rfontana@redhat.com" moz-do-not-send="true"
class="moz-txt-link-freetext">rfontana@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
Fri, Aug 14, 2026 at 1:09\u202fPM Michael Dolan<br>
<<a href="mailto:mdolan@linuxfoundation.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">mdolan@linuxfoundation.org</a>>
wrote:<br>
><br>
> Treating the choice of a single license for a package of
components released together as an OSD 9 problem seems
challenging to me.<br>
<br>
OpenMDW doesn't say the Model Materials have to be released
together,<br>
for one thing. In a separate response I pointed out the
possibility of<br>
splitting up the Model Materials across differently hosted<br>
repositories in a way that might deprive the licensee of
adequate<br>
understanding of the risk theoretically imposed by the
defensive<br>
termination provision.<br>
<br>
<br>
<br>
I do not think OSD 9 is relevant here, honestly. OSD 9
prohibits a<br>
license from restricting other software distributed with the
licensed<br>
software. Specifically, it says:<br>
><br>
><br>
><br>
> The license must not place restrictions on other software
that is distributed along with the licensed software. For
example, the license must not insist that all other programs
distributed on the same medium must be open source software.<br>
><br>
><br>
><br>
> A simple example would be a license insisting that other
programs on the same medium be open source. The Model
Materials are not other software distributed along with the
licensed work. They are the licensed work \u2013 they\u2019re packaged
and built to work together. The premise that a single license
covering a bundle of components violated OSD 9 would implicate
most software package releases I can think of. Every software
distribution is a bundle of conceptually separate components
under one license: code, documentation, build tooling, test
data. The OSD has never required per-component granularity in
the grant or the remedy.<br>
[ . . . ]<br>
> Regarding separateness: a model release functions as a
unit. The weights are not usable without the architecture,
configuration, and tokenizer, and the documentation describes
that specific release. Many apps bundle presentation code,
backend logic code, SQLite for data, and security libraries
into a release.<br>
<br>
I think this is right, but OpenMDW doesn't talk at all about
"a<br>
release" as some sort of clear act that can be pointed to. It
doesn't<br>
say that the things making up the Model Materials must be
"packaged<br>
and built to work together". Perhaps it could? In another
response I<br>
noted that Model Materials can include more than one model,
which<br>
means more than one model release (including multiple sets of<br>
materials related in some sense to those models). By
definition, I<br>
think, if you have more than one model, you don't have a unit
that is<br>
packaged and built to work together. For example you might
have a<br>
copyright claim against model A (hosted on Hugging Face)
leading to<br>
termination of licenses to documentation for
possibly-unrelated models<br>
B and C (published on GitHub repositories or websites, say, or
maybe<br>
this even extends to things like arxiv papers). I know this is<br>
probably not what was intended or contemplated. Again, a way
to<br>
address this might be for the licensor to clearly identify all
the<br>
elements of a specific "release". My basic thought here is
that the<br>
copyright assertion termination feature would be at least
somewhat<br>
less problematic if it were clearer in principle what the
Model<br>
Materials is supposed to cover in any one licensing instance.
If, for<br>
example, you intend Model Materials to be truly open ended -
anything<br>
the licensor ever releases under OpenMDW, now or in the future
- that<br>
strikes me as a radical idea, but possibly worth considering
by the<br>
OSI as a valuable evolution of open source licensing. But I
contend<br>
that the meaning of Model Materials in the current license is
unclear.<br>
<br>
Richard<br>
<br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
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
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
</body>
</html>