[License-review] ModelGo Zero License, Version 2.0

Mon Feb 24 08:00:03 UTC 2025

A very quick comment on something that lingered in the back of my mind and I am not confortable with. It is not probably something relevant to the approval of the license, but a quirk nonetheless. 

The license provides a conditional permission to create derivative, that should suffice. I would remove entirely section 2.2 

> 2.2	Grant of Rights to Derivative Materials

> (a)	Subject to Your compliance with all Your obligations under this License and
> without

> prejudice to any other terms under this License, all rights (including
> Intellectual Property

> Rights) in any Derivative Materials shall automatically vest in and be owned by
> You.

This is -- at least in some jurisdiction -- the operation of the law, not a grant. If you create a work based on someone else's copyright, the right such new work is yours regardless whether you have received a proper permission. That means the the owner of the original work will not have more rights in your work than you have in yours. Both should receive the other owner's permission to perform any act reserved to the rightsholder. 2.2 conditions this basic tenet of copyright law to the compliance, but that is simply not something you can achieve by operation of a copyright grant, and even with a full contract you can only transfer the right, not make them be born in another subject, unless it's an employment work or another similar situation.

I have already commented on Section 7 and on the Annex.

Also, I would strongly advise against using "term", which would imply a time-based agreement of an unlimited duration, which in my jurisdiction, at least, would imply that you can terminate it with reasonable notice. That is by all means not compatible with the irrevocable right required for an Open Source license. Conversely, the main effect of an Open Source (no hyphen, please) license is the grant, which means, the transfer of a right, which is a one-off action that is consummated at the time the consensus is given, once and forever, subject to conditions. I strongly advise to remove Section 5.1.

The above comments can be extended, ceteris paribus, to the other licenses.

Thank you.

Carlo, in his own capacity.

----- Messaggio originale -----
> Da: "Pamela Chestek" <pamela.chestek at opensource.org>
> A: "License submissions for OSI review" <license-review at lists.opensource.org>, "Moming Duan" <duanmoming at gmail.com>
> Inviato: Venerdì, 21 febbraio 2025 19:47:21
> Oggetto: Re: [License-review] ModelGo Zero License, Version 2.0

> Hi License-review list,

> Just to bring to your attention that Moming submitted three licenses, the Zero,
> BY and BY-OS licenses. They are asking for comments on at least the BY-OS
> version before going back for edits on the licenses, so just flagging it for
> you if you have time. the BY-OS version differs from the Zero version by the
> addition of sections 2.3 (ii) - (vi).

> Pam

> Pamela S. Chestek
> Board Member
> Open Source Initiative

> On 2/20/2025 6:35 PM, Moming Duan wrote:

>> Dear Pamela,

>> Thanks for the previous feedback on the MG0 license! I’m especially impressed by
>> the heated discussion on open-source AI. I have gathered some concerns, and
>> some of MG0 clauses are likely not OSD-compliant. I plan to resubmit it for
>> amendment. Before that, would it be possible to open the discussion on
>> MG-BY-OS? This is a variant ModelGo license I submitted for OSI review. Since
>> lawyers may charge per amendment round, I’d like to collect all comments
>> together to optimize costs. Thanks!

>> Best,
>> Moming

>>> On 15 Feb 2025, at 2:47 AM, Pamela Chestek [ mailto:pamela at chesteklegal.com |
>>> <pamela at chesteklegal.com> ] wrote:

>>> Moming,

>>> The OSI is not likely to approve a license that has this particular use
>>> restriction. To understand why, I suggest you read this article: [
>>> https://the.webm.ink/just-obey-the-law | https://the.webm.ink/just-obey-the-law
>>> ]

>>> 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.

>>> 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.

>>> 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 realize some of my comments seem to go against what lawyers who don't work in
>>> the field believe are good drafting practices. However, our standards are
>>> time-tested, with 20 years of analysis and review of these licenses to
>>> understand what makes them good or bad. We have also learned that these
>>> licenses have incredibly long lifespans, so it's very important to get them as
>>> right as possible. As Carlo also noted, this is the first candidate for an AI
>>> license, so we will be exceptionally careful in the review. I haven't looked at
>>> it carefully myself yet, but I expect that I will have more comments on the
>>> drafting once I have. I personally am rooting for you, I would be very happy to
>>> have an OSI-approved OSAID license, so I hope we can all collaborate to make
>>> this an acceptable license.

>>> Pam

>>> Pamela S. Chestek (in my personal capacity)
>>> Chestek Legal
>>> PLEASE NOTE OUR NEW MAILING ADDRESS
>>> 4641 Post St.
>>> Unit 4316
>>> El Dorado Hills, CA 95762
>>> +1 919-800-8033
>>> [ mailto:pamela at chesteklegal.com | pamela at chesteklegal.com ]
>>> [ http://www.chesteklegal.com/ | www.chesteklegal.com ]

>>> On 2/13/2025 10:50 PM, Moming Duan wrote:

>>>> Hi Eric,

>>>>> On 14 Feb 2025, at 10:56 AM, Eric Schultz [ mailto:eric at wwahammy.com |
>>>>> <eric at wwahammy.com> ] wrote:

>>>>> To me, that implies that the usage of licensed works are dependent upon the
>>>>> usage being legal. That's not a requirement that an OSD compliant license can
>>>>> have; additionally, it's unnecessary, the state already enforces those rules,
>>>>> you don't need the license holder to do so as well.

>>>> I am not a lawyer, but my intuition is that a license will be ineffective or
>>>> unenforceable if its terms do not comply with applicable law.
>>>> Regarding OSD compliance, I think 2.3(a)(i) is not a discrimination clause
>>>> against persons or groups, as every entity can be sued and suspected of
>>>> breaking the law.
>>>> My lawyer also advised retaining this clause, as we do not intend for the
>>>> licensor to be liable for the illegal use of licensed materials.
>>>> I failed to convince my lawyer to remove this clause because I cannot identify
>>>> who would be harmed by it, and its removal may increase potential risks.

>>>>> PS: While the Open Source AI definition says you don't have to include the
>>>>> source data to be an "Open Source AI", I would disagree with that conclusion.
>>>>> But that's my own two cents.

>>>> My personal view is that open-source AI systems require open-source datasets,
>>>> but open-source models do not. I believe the scope of open source should not
>>>> extend to parts governed by another license or applicable law, as such
>>>> proliferation could cause inconsistencies and conflicts in license terms. As an
>>>> open-source model, it should, at a minimum, keep its parameters and
>>>> architecture available and should not prohibit any kind of use of its generated
>>>> output, such as reverse engineering or distillation.

>>>> 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 [ mailto:License-review at lists.opensource.org |
>>>> License-review at lists.opensource.org ] [
>>>> http://lists.opensource.org/mailman/listinfo/license-review_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
>>> [ mailto:License-review at lists.opensource.org |
>>> License-review at lists.opensource.org ]
>>> [
>>> http://lists.opensource.org/mailman/listinfo/license-review_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 [ mailto:License-review at lists.opensource.org |
>> License-review at lists.opensource.org ] [
>> http://lists.opensource.org/mailman/listinfo/license-review_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