<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Pam,<div><br></div><div><br></div><div>I would like to add that, according to the current definition, Derivative Materials do not include AI agents created using the model and its output. From my personal understanding and background, this definition does not present significant ambiguity, but I am not certain whether the scope might be interpreted more broadly from a legal perspective. If this Output-related definition introduces further ambiguity, I will consider removing it.</div><div><br></div><div><br></div><div>Best,</div><div>Moming</div><div><div><div><br><blockquote type="cite"><div>On Dec 6, 2025, at 10:23, Moming Duan <duanmoming@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Pam,<div><br></div><div><br></div><div>For clarification, the definition of Derivative Materials does not include the Output of the model (at least that is my intention). It includes derivative models created by transferring patterns from the Output. However, I am reconsidering this definition: as more AI agent systems are built on top of model outputs, I am concerned that including \u201cderivative models developed by transferring patterns of Output\u201d may unintentionally broaden the scope of what counts as a derivative, thereby restricting downstream innovation and conflicting with the Open Source spirit, which is not the intention of this license. </div><div><br></div><div>I would appreciate further discussion on this issue, including the potential pros and cons of removing this Output-related element from the current definition. Thanks.</div><div><br></div><div><br></div><div>Best,</div><div>Moming<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Dec 6, 2025, at 01:22, Pamela Chestek <pamela@chesteklegal.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div>
I renew my objections to this license and the Attribution-ShareAlike
version for the same reasons I objected to the previous version,
starting with this email,
<a class="moz-txt-link-freetext" href="https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2025-May/005766.html">https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2025-May/005766.html</a>,
and as explained further in later emails in the thread. I do not
believe that putting conditions on output of a model is workable
and, where the output is not a derivative work under copyright law,
it violates OSD9, "License Must Not Restrict Other Software." <br>
<br>
The change "Narrows the definition of 'Derivative Materials' by
including the phrase: 'in order to replicate, approximate, or
otherwise achieve functional behavior that is similar to the Model'"
does not address this problem and, in fact, exacerbates it. Output
that will "replicate, approximate, or otherwise achieve functional
behavior that is similar to the Model" identifies output that is
highly likely to not be a derivative work under any stretch of the
imagination and therefore is well beyond the acceptable reach for an
open source license.<br>
<br>
I do not believe these two versions of the license can be approved.<br>
<br>
Pam<br>
<br>
<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>
<br>
<a href="https://calendly.com/pamela-chesteklegal/30min">Set a
meeting with me</a></div>
<div class="moz-cite-prefix">On 12/5/2025 9:04 AM, McCoy Smith
wrote:<br>
</div>
<blockquote type="cite" cite="mid:e325347c-0c66-4294-bfe9-0d01dddbd58f@lexpan.law">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><p>I'm going repeat my comments on the MG-0 license here since
they are equally applicable to this license (which appears to
replicate the text of MG-0, except for the addition of the
conditions in 2.2):</p><p>1. The disclaimers are not made "conspicuous" as that term is
defined in UCC 2-316: <a class="moz-txt-link-freetext" href="https://www.law.cornell.edu/ucc/2/2-316" moz-do-not-send="true">https://www.law.cornell.edu/ucc/2/2-316</a>
That has been interpreted as requiring something like ALL CAPS
or bold, or a different color, or a box (although the criteria
changed in 2022). This isn't necessarily a flaw (whether UCC is
relevant to open source licenses is an interesting question) but
the practice seems to be that most newer open source licenses
try to adhere to this requirement (most by using ALL CAPS since
that tends to be the only way to do this with .txt files or
ASCII -- which non-lawyers tend to dislike because they
interpret it as screaming without understanding why it's done
that way).<br>
<br>
2. I find the way the grants are structured sub-optimal in the
way that it handles the right of performance under copyright
law. Rather than being in the grant, it is subsumed into the
definition of "Distribution/Distribute" and then grants a right
to Distribute. All rights are granted (which is good, that way
you don't have to rely on implied grants) but you do need to dig
into the definitions to get there.</p><p>As to the Attribution version of the license, my only comment
is this license requires in Section 2.2(i) that a copy of the
license be provided. This is a fairly common provision of many
so called "permissive" or non-copyleft licenses although I've
always wondered what value this requirement provides, given that
this license is intended (I believe) to be non-copyleft.</p><p>Otherwise, this license seems OK.</p><p>McCoy</p><p>[in my personal capacity and not as a member of the board]</p>
<div class="moz-cite-prefix">On 6/18/2025 2:31 AM, Moming Duan
wrote:<br>
</div>
<blockquote type="cite" cite="mid:883778D3-40CF-4DCF-B65F-AD07D9F427AD@gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
Dear OSI Community,
<div><br>
</div>
<div><br>
</div>
<div><span style="caret-color: rgb(0, 0, 0);">Following our previous discussions in May, I have made
further revisions to the ModelGo </span>Attribution<span style="caret-color: rgb(0, 0, 0);"> License
(MG-BY-2.0). I am submitting this updated version for OSI
review via this email. The license text is attached.</span></div>
<div><br>
</div>
<div>
<div style="caret-color: rgb(0, 0, 0);"><font color="#ff0000">\u2014\u2014\u2014\u2014\u2014\u2014
Major Updates to Previous Submission</font></div>
<div style="caret-color: rgb(0, 0, 0);"><font color="#ff0000"><br>
</font></div>
<div style="caret-color: rgb(0, 0, 0);">
<li><font color="#ff0000">Removes restrictions on model
output.</font></li>
<li><font color="#ff0000">Revises the termination clause to
provide for automatic termination.</font></li>
<li><font color="#ff0000">Adds more explicit granting of
rights in Section 2.1. </font></li>
<li><font color="#ff0000">Narrows the definition of
\u201cDerivative Materials\u201d by including the phrase: \u201cin
order to replicate, approximate, or otherwise achieve
functional behavior that is similar to the Model.\u201d </font></li>
<li><font color="#ff0000">Removes \u201cDerivative Materials\u201d in
Section 5: \u201cNothing in this License permits You to
modify this License as applied to the Licensed
Materials.\u201d </font></li>
<li><font color="#ff0000">Fixes typos and formatting issues.</font></li>
</div>
</div>
<div><br>
</div>
<div><span style="caret-color: rgb(0, 0, 0);">\u2014\u2014\u2014\u2014\u2014\u2014 </span><span style="caret-color: rgb(0, 0, 0);">License </span><span style="caret-color: rgb(0, 0, 0);">Introduction</span></div>
<div><b><br>
</b></div>
<div><b>License Name</b>:<span class="Apple-tab-span" style="white-space: pre;"> </span><span style="caret-color: rgb(0, 0, 0);">ModelGo </span>Attribution<span style="caret-color: rgb(0, 0, 0);"> License</span></div>
<div><span style="caret-color: rgb(0, 0, 0);"><b>Version</b>: <span class="Apple-tab-span" style="white-space: pre;"> </span>2.0</span></div>
<div><font><b>Short Identifier: <span class="Apple-tab-span" style="white-space: pre;"> </span></b>MG-BY-2.0</font></div>
<div><b style="caret-color: rgb(0, 0, 0);">Copyleft:</b><span class="Apple-tab-span" style="caret-color: rgb(0, 0, 0); font-weight: bold; white-space: pre;"> </span><span style="caret-color: rgb(0, 0, 0);">No</span></div>
<div><b>Legacy or New</b>: <span class="Apple-tab-span" style="white-space: pre;"> </span>New
License</div>
<div><b>Drafted By Lawyer</b>: <span class="Apple-tab-span" style="white-space: pre;"> </span>Yes, Rajah
& Tann Singapore LLP</div>
<div><b>Approved or <span style="caret-color: rgb(0, 0, 0);">Used</span> by Projects</b>: <span class="Apple-tab-span" style="white-space: pre;"> </span>No</div>
<div><br>
</div>
<div><b>License URL</b>:<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://ids.nus.edu.sg/modelgo-mg-by.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://ids.nus.edu.sg/modelgo-mg-by.html</a></div>
<div><b>Introduction and Video</b>:<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://www.modelgo.li/" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.modelgo.li/</a></div>
<div><br>
</div>
<div><b>Overview</b>:</div>
<div><br>
</div>
<div>ModelGo Attribution License Version 2.0 (MG-BY-2.0) is a
new license designed for publishing models (typically neural
networks like Llama2, DeepSeek). It is one of the variants in
the ModelGo License family. MG-BY-2.0 is the a permissive
license in the ModelGo family, requiring that the original
license <font color="#ff0000">and attribution</font> be
provided when distributing the original Licensed Materials or
Derivative Materials (<span style="caret-color: rgb(0, 0, 0);">Licensed Materials and </span><span style="caret-color: rgb(0, 0, 0);">Derivative
Materials are</span><span style="caret-color: rgb(0, 0, 0);"> </span>defined in Clause 1). <font color="#ff0000">A statement of modification is required, if
applicable.</font></div>
<div><font color="#ff0000">(Red content represents the
differences from MG0-2.0 license)</font></div>
<div><br>
</div>
<div><b>Complies with OSD:</b></div>
<div><b><br>
</b></div>
<div>OSD 3 Derived Works \u2014 MG-BY-2.0 <span style="caret-color: rgb(0, 0, 0);"> </span><span style="caret-color: rgb(0, 0, 0);">Clause
2.1 (a) grants copyright and patent rights to create
derivatives.</span></div>
<div>OSD 5 and OSD 6 \u2014 No discrimination clause is included in
MG-BY-2.0.</div>
<div>OSD 9 License Must Not Restrict Other Software \u2014 No such
restriction is included in MG-BY-2.0.</div>
<div><br>
</div>
<div><b>The Gap to Fill:</b></div>
<div>Model sharing is very common on the web, with over 1.4
million models currently listed on Hugging Face (<a href="https://huggingface.co/models" moz-do-not-send="true" class="moz-txt-link-freetext">https://huggingface.co/models</a>).
However, most of these models are not properly licensed. When
publishing their models, developers typically choose from
three main options (as seen in the model license tags on the
Hugging Face website):</div>
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>OSS licenses, e.g., Apache-2.0, MIT</li>
<li>Open responsible AI licenses (OpenRAILs),
e.g., CreativeML-OpenRAIL-M, OpenRAIL++</li>
<li>Proprietary Licenses, e.g., Llama2, Llama3</li>
</ul>
</div>
<div><br>
</div>
<div>However, not all licenses are well-suited for model
publishing.</div>
<div><br>
</div>
<div><b>Why not use OSS licenses? </b></div>
<div>Traditional OSS licenses lack clear definitions regarding
machine learning concepts, such as Models, Output, and
Derivatives created through knowledge transfer. This
ambiguity can result in certain ML activities (e.g.,
Distillation, Mix-of-Expert) being beyond the control of the
model owner.</div>
<div><br>
</div>
<div><b>Why not use OpenRAILs? </b></div>
<div>Recently, Responsible AI Licenses (<a href="https://www.licenses.ai/" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.licenses.ai/</a>)
have been widely advocated to govern AI technologies, aiming
to restrict unlawful and unethical uses of models. While I
acknowledge the growing need for such governance, these
copyleft-style restrictions do not comply with the OSD and may
cause incompatibility with licenses like GPL-3.0. Another
concern is that these behavioral restrictions may proliferate
within the AI model ecosystem, increasing the risk of license
breaches.</div>
<div><br>
</div>
<div><b style="caret-color: rgb(0, 0, 0);">Why
not use Llama2 or Llama3 Licenses?</b></div>
<div><font>These licenses are proprietary
licenses that are not reusable. </font>Furthermore, they
include exclusive terms such as "You will not use the Llama
Materials or any output or results of the Llama Materials to
improve any other large language model" and copyleft-style
behavioral restrictions.</div>
<div><br>
</div>
<div>In fact, the dilemma in current model publishing is the
lack of a general-purpose license for model developers.
Additionally, since no single license meets diverse model
publishing needs, some developers resort to using CC licenses
with different elements. However, CC licenses are ill-suited
for this purpose as they do not grant patent rights. This
motivated the drafting of ModelGo License family, which
provides different licensing elements similar to CC but
specifically designed for model publishing.</div>
<div><br>
</div>
<div><b>Comparison with Existing OSI-Approved Licenses:</b></div>
<div>Since I could not find an OSI-approved model license, I can
only compare MG-BY-2.0 with one similar OSS license \u2014
Apache-2.0</div>
<div>
<div><br>
</div>
<div>
<li style="caret-color: rgb(0, 0, 0);">MG-BY-2.0
defines licensed materials and derivative works
differently from Apache-2.0, tailoring them to models.</li>
<li style="caret-color: rgb(0, 0, 0);">MG-BY-2.0
can govern the remote access (e.g., chatbot) scenario.</li>
</div>
</div>
<div><br>
</div>
<div>If further comparisons or supporting evidence are needed to
strengthen my claims, please let me know. I am more than
willing to engage in further discussions with the OSI
community about this license and contribute to promoting
standardized model publishing. <span style="caret-color: rgb(0, 0, 0);">\U0001f917</span></div>
<div><br>
</div>
<div><br>
</div>
<div>Best,</div>
<div>Moming</div>
<div><br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
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 moz-txt-link-freetext" href="mailto:License-review@lists.opensource.org" moz-do-not-send="true">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" moz-do-not-send="true">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
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>
<br>
</div>
_______________________________________________<br>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.<br><br>License-review mailing list<br>License-review@lists.opensource.org<br>http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org<br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></body></html>