[License-review] [2nd Resubmission] ModelGo Attribution License, Version 2.0

Sat Dec 6 20:34:20 UTC 2025

The definition of "Derivative Materials" includes Output in those cases 
where the Output is for the purpose of creating of another model.

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.

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.

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.

Pam

Pamela S. Chestek
Chestek Legal
4641 Post St.
Unit 4316
El Dorado Hills, CA 95762
+1 919-800-8033
pamela at chesteklegal
www.chesteklegal.com

On 12/5/2025 6:23 PM, Moming Duan wrote:
> Hi Pam,
>
>
> 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 “derivative models developed by transferring patterns of 
> Output” 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.
>
> 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.
>
>
> Best,
> Moming
>
>> On Dec 6, 2025, at 01:22, Pamela Chestek <pamela at chesteklegal.com> wrote:
>>
>> 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, 
>> https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2025-May/005766.html, 
>> 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."
>>
>> 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.
>>
>> I do not believe these two versions of the license can be approved.
>>
>> Pam
>>
>> Pamela S. Chestek
>> Chestek Legal
>> 4641 Post St.
>> Unit 4316
>> El Dorado Hills, CA 95762
>> +1 919-800-8033
>> pamela at chesteklegal.com
>> www.chesteklegal.com
>>
>> Set a meeting with me <https://calendly.com/pamela-chesteklegal/30min>
>> On 12/5/2025 9:04 AM, McCoy Smith wrote:
>>>
>>> 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):
>>>
>>> 1. The disclaimers are not made "conspicuous" as that term is 
>>> defined in UCC 2-316: https://www.law.cornell.edu/ucc/2/2-316 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).
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Otherwise, this license seems OK.
>>>
>>> McCoy
>>>
>>> [in my personal capacity and not as a member of the board]
>>>
>>> On 6/18/2025 2:31 AM, Moming Duan wrote:
>>>> Dear OSI Community,
>>>>
>>>>
>>>> Following our previous discussions in May, I have made further 
>>>> revisions to the ModelGo Attribution License (MG-BY-2.0). I am 
>>>> submitting this updated version for OSI review via this email. The 
>>>> license text is attached.
>>>>
>>>> —————— Major Updates to Previous Submission
>>>>
>>>> # Removes restrictions on model output.
>>>> # Revises the termination clause to provide for automatic termination.
>>>> # Adds more explicit granting of rights in Section 2.1.
>>>> # 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.”
>>>> # Removes “Derivative Materials” in Section 5: “Nothing in this 
>>>> License permits You to modify this License as applied to the 
>>>> Licensed Materials.”
>>>> # Fixes typos and formatting issues.
>>>>
>>>> —————— License Introduction
>>>> *
>>>> *
>>>> *License Name*:ModelGo Attribution License
>>>> *Version*: 2.0
>>>> *Short Identifier: *MG-BY-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.html
>>>> *Introduction and Video*:https://www.modelgo.li/
>>>>
>>>> *Overview*:
>>>>
>>>> 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 and 
>>>> attribution be provided when distributing the original Licensed 
>>>> Materials or Derivative Materials (Licensed Materials and 
>>>> Derivative Materials aredefined in Clause 1). A statement of 
>>>> modification is required, if applicable.
>>>> (Red content represents the differences from MG0-2.0 license)
>>>>
>>>> *Complies with OSD:*
>>>> *
>>>> *
>>>> OSD 3 Derived Works — MG-BY-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-2.0.
>>>> OSD 9 License Must Not Restrict Other Software — No such 
>>>> restriction is included in MG-BY-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-2.0 with one similar OSS license — Apache-2.0
>>>>
>>>> # MG-BY-2.0 defines licensed materials and derivative works 
>>>> differently from Apache-2.0, tailoring them to models.
>>>> # MG-BY-2.0 can govern the remote access (e.g., chatbot) scenario.
>>>>
>>>> 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
>>>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>>
>>> _______________________________________________
>>> 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
>>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>
>> _______________________________________________
>> 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
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20251206/733bdc24/attachment-0001.htm>