<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>The definition of "Derivative Materials" includes Output in those
cases where the Output is for the purpose of creating of another
model. </p>
<p>We seem to be in agreement about the problem, an over-expansive
definition of derivative works, but we have identified it for
different reasons. I look at it theoretically and believe that the
attempt to control Output at all is not justified because it's not
limited to derivative works. It's particularly problematic for a
model license, because the output is highly unlikely to be
protected by copyright. You view it in operation and spot the
problem by realizing that the definition will reach agents, which
wasn't your intention. I think we get to the same place, just
through different lenses.</p>
<p>The unintended expansion is why tying a license scope to the
exclusive rights of authors, rather than trying to define the
scope by the type or purpose of a change, is, in my view, the
sounder approach. </p>
<p>If the attempt to control output that isn't a derivative work was
removed, I believe I would probably agree the license is
acceptable, although I'd have to review it again to be sure.</p>
<p>Pam</p>
<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>
pamela@chesteklegal<br>
<a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a><br>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 12/5/2025 6:23 PM, Moming Duan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:541EAF35-5686-48A5-8839-5808AA5E20FC@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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
<a class="moz-txt-link-rfc2396E" href="mailto:pamela@chesteklegal.com"><pamela@chesteklegal.com></a> 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"
moz-do-not-send="true">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 moz-txt-link-freetext"
href="mailto:pamela@chesteklegal.com"
moz-do-not-send="true">pamela@chesteklegal.com</a><br>
<a class="moz-txt-link-abbreviated"
href="http://www.chesteklegal.com/"
moz-do-not-send="true">www.chesteklegal.com</a><br>
<br>
<a
href="https://calendly.com/pamela-chesteklegal/30min"
moz-do-not-send="true">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 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>
</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>
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a><br>
<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><br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</body>
</html>