[License-review] ModelGo Attribution-OpenSource License, Version 2.0
Moming Duan
duanmoming at gmail.com
Tue Mar 11 05:27:12 UTC 2025
Dear Pam,
Thanks for your professional review. I realize that some clauses in ModelGo License are poorly drafted or not OSD-compliant. I am currently looking for legal experts or students to help amend these clauses and prepare for resubmission.
> 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?
>
Yes, maybe there is a writing issue. What I intended with "and/or" here is to account for cases where Complementary Materials may not be necessary. For example, if you create an adapter for a foundation model (like a browser add-on), you might only need to call a Python package to use the adapter, without requiring additional code/scripts for running, testing, or preparing data. However, for complex large models like DeepSeek, Complementary Materials become relatively important for users who want to deploy or reproduce the model. My intention is that if such materials are modified from the original, they should remain open source under MG-BY-OS. But we do not require the licensor to provide these materials in the first place when using MG-BY-OS.
BTW, I think this ambiguity is similar to the concept of "Corresponding Source" in GPL-3.0. In practice, it's difficult to define the exact boundary of all materials necessary for running, testing, and reproducing a model. At the same time, I don't think it's within the scope of a license to prohibit its use if certain addtional items are not included. As a result, under MG-BY-OS, if Complementary Materials are entirely created by the licensee, they have the choice not to release them with the derivative model and may use a different license for that part.
> 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.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 agree that database rights may be relevant in an AI system, and our current clauses have narrowed our license to apply only to AI models.
I believe my lawyers define IP rights not to grant all IP rights to the licensee but rather to assert ownership of IP rights in derivatives (if they exist), while reserving IP rights for the original works.
> 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.
>
I agree, this is common practice in OSS licenses. I will amend it to make it clearer.
> 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.
>
I am very thankful for your suggestions in the ODT file. However, I cannot respond to each question because some of the comments are outside my expertise. I am currently looking for legal experts to help me interpret and amend our license. I hope we can resubmit it for OSI review soon. I also appreciate the other reviewers who have helped improve the ModelGo License. Let’s work together toward a more standardized way to model sharing.
Best,
Moming
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20250311/2fe05ba2/attachment.htm>
More information about the License-review
mailing list