[License-review] ModelGo Zero License, Version 2.0

[Moming Duan]

Dear Pamela, 

> On 15 Feb 2025, at 2:47 AM, Pamela Chestek <pamela at chesteklegal.com> wrote:
> 
> Although the OSI has approved licenses with jurisdictional clauses in the past, they are disfavored. Stating a specific jurisdiction is not a good idea (as you recognize), since neither of the parties may be in that jurisdiction, making it inconvenient for both parties.  Trying to define it as tied to the licensor's place of business is problematic for the reasons Carlo described. Experience has shown that defining jurisdiction only causes more problems that it solves.

Thank you for your clarification. I recognize your concerns and will try to remove this clause in future amendments.

> I consider not only Annex A, but any annex, a problem. Your license allows a licensor to add unknown content to the license in the form of "annexes" ("'License' means the terms and conditions for use, reproduction and distribution as set out in [Sections 1 to 8 and the annexes] of this License"). The OSI will not approve licenses that are not self-contained because of the high likelihood that the added content will not comply with the OSD or OSAID. So the possibility of undefined "annexes" isn't acceptable.

Thanks for pointing that out. I just noticed that "the annexes" refer to nothing and may be a loophole. It would be better to amend it to something like "Annex A — Model Sheet" to specify it clearly.

> Further, in my opinion this Annex A is not acceptable. As I understand it, Annex A is meant to be redundant to what the text of the license says. If so, it is superfluous. However, its existence invites others to change an X to a check, or vice versa, changing the actual license itself to one that is non-free. For example someone could change the X to a check for "Use Restrictions (RAI) on Licensed Materials, Derivative Materials and Output" and nevertheless claim that their system is open source because they used the ModelGo Zero License. To be approved, licenses must be immutable. You have described the Annex as informative - it's perfectly fine to use as an educational or informational tool elsewhere, but it shouldn't be part of the license itself.

I think the table in Annex A can greatly help reduce divergences in the interpretation of license terms. From my perspective as a developer, making the license more user-friendly is beneficial and meaningful for promoting transparency in licensing. In my experience, most model users lack the patience or legal knowledge to fully understand a license and often choose the most popular option or a random license with a catchy name, which creates a mess where some end up using CC or database licenses for their models.

To be immutable, MG0-2.0 Clause 8.1 state the modify of license should:

You may modify the text of this License and copy, distribute or communicate Your modified version and apply it to other original works of authorship, provided that You furnish a readable notice describing Your modifications to this license.

If stricter restrictions on license modification are needed, I can amend it by adding: “You may not indicate in any way that your Modified License is the ModelGo Zero License”. 
Additionally, even without Annex A, someone could still modify the ModelGo Zero License and pretend it is the original. While we can use file checksums for identification, it is difficult to prevent this solely through license terms.
Currently, I have just begun promoting ModelGo Licenses, and no known projects are using them yet. I am very willing to amend the license to make it more OSD-compliant. Please share your feedback, and I will gather input to consult a lawyer for amendments.


Best,
Moming
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20250215/f5f99e2b/attachment.htm>