<html><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 Pamela,<div><br></div><div><br></div><div>Thank you for your comments and discussions. I'm afraid I need more time to digest them, and I am seeking legal support for interpretation. I will clarify some of the questions later.</div><div><br></div><div><br></div><div>Best,</div><div>Moming<br><div><div><br><blockquote type="cite"><div>On 3 Mar 2025, at 10:14 AM, 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><p>Dear Moming,</p><p>First off, thank you for submitting the licenses. I've attached a
.odt version of the BY-OS license with extensive comments. This is
more about using your license as a teaching opportunity than
directed at your licenses specifically. Since you plan to revise
and resubmit the licenses, I took advantage of an opportunity to
provide some suggestions on improvements. They are intentionally
very detailed, some admittedly picayune, because I am using them
to educate more broadly.<br>
</p><p>Open source licenses are quite different from ordinary commercial
licenses. Open source licenses are meant to give away as much as
possible, with only a few conditions that the licensor requires as
their benefit from granting the license (attribution, copyleft),
and some protection from claims.</p><p>On the other hand, commercials licenses are designed to grant as
few rights as possible and shift as much of the risk and burden to
the licensee as the licensor can get away with. For that reason
stylistically they are quite different from the open source
license, where there is not generally a shift of risk or burden
but just protection for the licensor. Think of the open source
license as a gift - when you give a gift you protect yourself
("I'll give you the car but you have to register it in your own
name") but when you start to impose too many burdens on the gift
recipient ("you have to pay me $50 a week or I'll take the car
back") it's no longer a gift. Open source as a practice is
successful only because licensees know that they can used the
software (or model, in this case) freely without worrying about
what limits there might be on their use because there are only
very few, well-known limits. Imposing too many burdens and
obligations on the licensee means that benefits of the open source
ecosystem won't be realized.<br>
</p><p>Another difference is that commercial licenses are low risks as
documents. They are between only a few parties; even a
click-through license pales in the number of licensees compared to
an open source license. We now know that open source licenses have
lifespans of decades but commercial licenses generally don't. The
commercial licensor will generally be able to modify and improve
their license over time as they discover weaknesses or
ambiguities, but that doesn't happen in open source licenses
because they are perpetual. In open source one might be able to
change a license for a later version of the software (depending on
whether the open source licensor own all the rights), but anyone
who has either updated a license version or changed licenses will
tell you what a difficult, multiyear process it is. This means
that the open source license can't be sloppy; it has to be as
perfect as possible.<br>
</p><p>The ModelGo licenses were written in the style of commercial
licenses and so have terms that perhaps shouldn't be included an
open source license. I've also taken the liberty to point out many
areas with imprecise drafting that creates interpretive problems.
To the extent poor drafting creates ambiguity about whether all
necessary rights are granted, it will mean that, in my view, the
license shouldn't be approved. <br>
</p><p>In that category, unintended ambiguities that I think are fatal
to the license are:</p><p>Definition of Licensed Materials -- you say "'Licensed Materials'
means, collectively, the Model and/or Complementary Materials
...." Are you saying that what is licensed under this license must
include both the Model AND the Complementary Materials (as
indicated by the word "collectively") or can the license be
applied to only a Model (as indicated by the words "and/or")? I
don't know if this license is meant for everything for an AI
system except the data or it can be used for a model alone without
all the supporting materials. This ambiguity about what is being
licensed creates a lot of interpretive problemes. Say for example
that I receive both the Model and Complementary Materials but I
want to Distribute only the Model - is it ok that I don't give my
distributees all the materials I received? Or must I Distribute
the full package? If it's ok that I distribute the Model only, do
I still need to provide the Source Code for the Complementary
Materials? If I create both a new model and have new Complementary
Materials, but I plan to distribute only my new model as the
Derivative Materials, do I have to nevertheless have to provide my
own Complementary Materials? <br>
</p><p>2.1(a) -- you grant a license to "worldwide right and license
(including the relevant copyrights and patent rights) ..."
However, you have defined "Intellectual Property Rights" more
broadly than patent and copyright, so by negative implication you
appear not to have granted all rights that the user might need,
i.e., you have not granted Intellectual Property Rights that
aren't copyright or patent. <br>
</p><p>2.1(a)(i)-(ii) -- as worded, it sounds like you are NOT granting
rights to use, reproduce and Distribute Derivative Materials, so
you are not granting all rights needed for someone to exercise all
rights required for an open source license. I think there is an
argument around it (i.e., romanette (i) grants the necessary
rights for any Licensed Materials that are embodied in the
Derivative Materials, and the Licensor can't grant any rights for
the portion of the Derivative Materials the Licensor did not
create because the Licensor doesn't own them, its the person who
created the Derivative Materials who has to grant the license for
their share of the Derivative Materials), but it could be worded
more clearly. <br>
</p><p>2.5(a) -- you have reserved rights that may be needed for someone
to exercise the full grant required for an open source license, in
particular because you expressly aren't granting rights in
database. One theory for the protection of models is database
rights, so you might have unintentionally withheld the right to
reproduce the Model.</p><p>I'm not suggesting that all of my comments are right or you have
to adopt them. My suggestions may also be inconsistent; making
sure licenses are internally consistent is quite time consuming.
License drafting is also iterative; you have to see changes before
you spot the problems the new changes created or exposed. So don't
take these suggestions as absolute truth or necessary, but food
for thought about how to draft a higher quality open source
license.</p><p>Pam<br>
</p>
<div class="moz-signature">Pamela S. Chestek (in my personal
capacity)<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 2/12/2025 5:26 AM, Moming Duan
wrote:<br>
</div>
<blockquote type="cite" cite="mid:8043D0AF-08C0-4712-812C-3DEEF2359F6A@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Dear OSI Community,
<div><br>
</div>
<div><br>
</div>
<div>I am Moming Duan, a researcher at the National University of
Singapore and the submitter and license steward of <b>ModelGo Attribution-OpenSource License
2.0</b>, which I am submitting for OSI review through this
email. The license TEXT file is attached, and below is a brief
overview of this license.</div>
<div><br>
</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-OpenSource<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><span style="caret-color: rgb(0, 0, 0);">MG-BY-OS-2.0</span></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-os.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://ids.nus.edu.sg/modelgo-mg-by-os.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-OpenSource License Version 2.0
(MG-BY-OS-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-OS-2.0 is the
a <font color="#07ff00">copyleft</font> license in the ModelGo
family, requiring tha<font>t the original
license and attribution be provided when </font>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.1). <font>A statement of
modification is required, if applicable. </font><font color="#07ff00">Derivative Materials should be licensed under
the same terms as MG-BY-OS-2.0, and redistribution of original
works or derivatives should include the source code. This
license is intended to be an open-source model license that
provides as much openness as possible within the scope of the
model itself (in contrast to Llama2 license and OpenRAIL
licenses). While it is not a determining factor for an
open-source AI system, it can be considered one of its
requirements.</font></div>
<div><font color="#07ff00">(Green content represents the
differences from MG-BY-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 — MG-BY-OS-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 — No discrimination clause is included in
MG-BY-OS-2.0.</div>
<div>OSD 9 License Must Not Restrict Other Software — No such
restriction is included in MG-BY-OS-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 class="moz-txt-link-freetext" href="https://huggingface.co/models">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-OS-2.0 with one similar OSS license —
Apache-2.0</div>
<div>
<div><br>
</div>
<div>
<li style="caret-color: rgb(0, 0, 0);">MG-BY-OS-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-OS-2.0
Clause 2.4 includes provisions regarding model output.</li>
<li style="caret-color: rgb(0, 0, 0);">MG-BY-OS-2.0
Clause 2.2(a) clarifies the ownership of Derivative
Materials.</li>
<li style="caret-color: rgb(0, 0, 0);">MG-BY-OS-2.0
Clause 7 specifies the governing law.</li>
<li style="caret-color: rgb(0, 0, 0);">MG-BY-OS-2.0
Annex A includes a Model Sheet to help users choose and
understand the license content.</li>
<li style="caret-color: rgb(0, 0, 0);">MG-BY-OS-2.0
can govern the remote access (e.g., chatbot) scenario.</li>
<li style="caret-color: rgb(0, 0, 0);"><font color="#07ff00">MG-BY-OS-2.0
is a copyleft license and requires the source code to be
provided during redistribution.</font></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);">🤗</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" 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>
</div>
<span id="cid:4E023FBE-1AC1-4447-B339-63FE380C9853"><MG-BY-OS-2.0 redlined.odt></span></div></blockquote></div><br></div></div></body></html>