[License-review] ModelGo Attribution-OpenSource License, Version 2.0

Moming Duan duanmoming at gmail.com
Tue Mar 4 02:21:58 UTC 2025


Hi Pamela,


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.


Best,
Moming

> On 3 Mar 2025, at 10:14 AM, Pamela Chestek <pamela at chesteklegal.com> wrote:
> 
> Dear Moming,
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> In that category, unintended ambiguities that I think are fatal to the license are:
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Pam
> 
> Pamela S. Chestek (in my personal capacity)
> Chestek Legal
> 4641 Post St.
> Unit 4316
> El Dorado Hills, CA 95762
> +1 919-800-8033
> pamela at chesteklegal
> www.chesteklegal.com <http://www.chesteklegal.com/>
> 
> 
> On 2/12/2025 5:26 AM, Moming Duan wrote:
>> Dear OSI Community,
>> 
>> 
>> I am Moming Duan, a researcher at the National University of Singapore and the submitter and license steward of ModelGo Attribution-OpenSource License 2.0, 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.
>> 
>> License Name:		ModelGo Attribution-OpenSource License
>> Version: 				2.0
>> Short Identifier: 		MG-BY-OS-2.0
>> Copyleft:			No
>> Legacy or New: 		New License
>> Drafted By Lawyer: 	Yes, Rajah & Tann Singapore LLP
>> Approved or Used by Projects: 	No
>> 
>> License URL:				https://ids.nus.edu.sg/modelgo-mg-by-os.html
>> Introduction and Video:	https://www.modelgo.li/
>> 
>> Overview:
>> 
>> 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 copyleft license in the ModelGo family, requiring that the original license and attribution be provided when distributing the original Licensed Materials or Derivative Materials (Licensed Materials and Derivative Materials are defined in Clause 1.1). A statement of modification is required, if applicable. 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.
>> (Green content represents the differences from MG-BY-2.0 license)
>> 
>> Complies with OSD:
>> 
>> OSD 3 Derived Works — MG-BY-OS-2.0  Clause 2.1 (a) grants copyright and patent rights to create derivatives.
>> OSD 5 and OSD 6 — No discrimination clause is included in MG-BY-OS-2.0.
>> OSD 9 License Must Not Restrict Other Software — No such restriction is included in MG-BY-OS-2.0.
>> 
>> The Gap to Fill:
>> Model sharing is very common on the web, with over 1.4 million models currently listed on Hugging Face (https://huggingface.co/models). 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):
>> 
>> OSS licenses, e.g., Apache-2.0, MIT
>> Open responsible AI licenses (OpenRAILs), e.g., CreativeML-OpenRAIL-M, OpenRAIL++
>> Proprietary Licenses, e.g., Llama2, Llama3
>> 
>> However, not all licenses are well-suited for model publishing.
>> 
>> Why not use OSS licenses? 
>> 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.
>> 
>> Why not use OpenRAILs? 
>> Recently, Responsible AI Licenses (https://www.licenses.ai/) 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.
>> 
>> Why not use Llama2 or Llama3 Licenses?
>> These licenses are proprietary licenses that are not reusable. 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.
>> 
>> 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.
>> 
>> Comparison with Existing OSI-Approved Licenses:
>> 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
>> 
>> MG-BY-OS-2.0 defines licensed materials and derivative works differently from Apache-2.0, tailoring them to models.
>> MG-BY-OS-2.0 Clause 2.4 includes provisions regarding model output.
>> MG-BY-OS-2.0 Clause 2.2(a) clarifies the ownership of Derivative Materials.
>> MG-BY-OS-2.0 Clause 7 specifies the governing law.
>> MG-BY-OS-2.0 Annex A includes a Model Sheet to help users choose and understand the license content.
>> MG-BY-OS-2.0 can govern the remote access (e.g., chatbot) scenario.
>> MG-BY-OS-2.0 is a copyleft license and requires the source code to be provided during redistribution.
>> 
>> 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. 🤗
>> 
>> 
>> Best,
>> Moming
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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
>> License-review at lists.opensource.org <mailto:License-review at lists.opensource.org>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> <MG-BY-OS-2.0 redlined.odt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20250304/4261caf4/attachment-0001.htm>


More information about the License-review mailing list