[License-review] [Resubmission] ModelGo Zero License, Version 2.0

[Moming Duan]

Hi McCoy,

Thanks your feedback.

> On 15 May 2025, at 4:47 AM, McCoy Smith <mccoy at lexpan.law> wrote:
> 
> One concern that I have with this license is the nomenclature. "Zero" or "-0" with open source licensing typically means something akin to public domain or at least a license that imposes no (i.e., "zero") obligations on the recipient of the license.
> 
> The latest draft of this license does impose at least one obligation: in Section 2.2(a)(i) the licensee is obligated to pass along a copy of the license with any distribution.
> 
> Some people may not find this a big deal and relatively easy to comply with (particularly if/when this gets into SPDX), but there has been for quite some time a contention (which a recent informal poll I did at an event had surprisingly high traction) that that sort of condition (which is in BSD & MIT) causes any code upon which that license is attached to be perpetually under that license's terms. That's not really  a -0 license.
> 
> I'd suggest that at a minimum, either Section 2.2(a)(i) be removed to make it a true -0 license, or this license have a different name attached to it ("permissive"? although there are those object to the use of that term for only non-copyleft licenses; "non-reciprocal"?).
> 
I will consult my legal assistant regarding these concerns. I see no harm in making MG0 less burdensome, as it is intended to be highly permissive. However, I do not agree that encouraging users to remove the license file sends a responsible signal. 

> In terms of drafting, I dislike the articulation of the license grant here as it uses various license permissions in a way that is inconsistent with the rights the various intellectual property regimes articulate them, but more importantly, leaves out quite a number of them. This is in part the fault of using older licenses (BSD, I think) as a starting model.
> 
> In the USA, the copyright permissions are: reproduce, distribute, prepare derivative works, display
> 
> Outside of the USA, the patent permissions are (via Berne): reproduce, broadcast, communicate, adapt, arrange, recite, translate
> 
> In the USA, the patent permissions are: make, use, sell, offer for sale, import.
> 
> Outside of the USA, the patent permissions are similar in scope, but sometimes use dispose or other language rather than the above.
> 
> This license only grants the following rights under both copyright and patent:   use, reproduce, distribute. and "use the Licensed Materials to create Derivative Materials."  That means it leaves out 5 of the 6 enumerated patent rights in the USA. I think that newer licenses ought to be more rigorous in the way they articulate their permissions lest a court (or a licensor) argue that certain rights were reserved or not granted (such as, for example, the right to sell, offer for sale, or import the software under patents. I understand there are precedents from prior licenses (BSD is the best example) for not fully articulating all of these rights, but I think that precedent shouldn't be used to allow for incompletely written licenses now.
> 
Thanks for pointing that out. I’ll need to verify it with my legal assistant. Please note that the definition of “Distribution” may already cover some of the copyright permissions you mentioned.

“Distribution” (or “Distribute”) means any transmission, publication, public performance, sharing, or other methods of marking the Licensed Materials, Derivative Materials and/or Output available to a third party, including providing the Licensed Materials or any part thereof as a hosted service or remotely accessible service, such as API-based access or web access.

> Finally, the termination provision for patent assertions applies to Derivative Works. There's a long-standing debate about whether that sort of termination is overbroad, particularly as it prevents the assertion of patents against downstream modifiers of the upstream licensor's patents covering subsequent modification out of the control of the licensor. One of the reasons why the newer, popular licenses articulate their defensive termination/suspension clauses more narrowly than this is because of the concern that patent holders would be reluctant to grant an open-ended patent license to downstream licensees. I don't think that's an OSD violation, but it is an issue as to whether a license of this scope would gain significant uptake at least from patent holders.
> 
I’m not a lawyer, so it’s difficult for me to comment on this point. Shuji also raised similar concerns earlier. I’d prefer to share the feedback from my legal assistant, thanks.

The OSI feedback suggests that the termination provision may be overbroad, as it “prevents the assertion of patents against downstream modifiers of the upstream licensor’s patents covering subsequent modification out of the control of the licensor”. I’m not quite sure why this is an issue – preventing the assertion of patents against downstream modifiers/users is to prevent a "patent trap”. I’m also unsure why the original termination provision raises this issue at all.

In my understanding, a “patent trap” in open-source software typically refers to a situation where a Licensor (eg Microsoft) releases source code under an open-source license, but simultaneously holds patent rights in the same source code. The open-source license invites users to use the code (inviting users into a ’trap’), but the Licensor may still enforce its patent rights (ie activation of the patent trap). Even where a Licensor “promises” not to enforce its patents against users of the source code (for example Microsoft’s Patent Promise for .NET <https://raw.githubusercontent.com/dotnet/corefx/master/PATENTS.TXT>), this promise may not be effective/enforceable (especially if the Licensor transfers or sells the patent to someone else). The OSI feedback refers to “the assertion of patents against downstream modifiers of the upstream Licensor’s patents” – this, to me, describes a situation where the Licensor sues the Licensee for infringement of the Licensor’s patent.

In the original MG-BY, the termination provision 5.2 provides that “The Licensor may terminate this License if… You commence any legal action against the Licensor alleging that the Licensed Materials and/or Derivative Materials infringe any Intellectual Property Rights in the world”. In other words, this clause envisions a situation where the Licensee (user) sues the Licensor (author) (ie flipped), alleging that the Licensed Materials/Derivative Materials infringe IP rights. This (presumably) protects against the situation where the Licensor releases source code under copyright, but then the Licensee (downstream user) patents a method/idea in the source code, and then sues the Licensor. In any case, although it is technically possible for a Licensee (downstream user) to patent a method/idea in the source code, a requirement of patentability is that the invention must be ’novel’. Typically, prior publication of the invention means that it is no longer patentable. In other words, the publication of source code under an open-source license will itself prevent any downstream user from later applying for a patent based on the source code. In other words, this situation is unlikely to be significant, and this clause is simply more safeguarding for the Licensor.

In any case, the OSI feedback suggests that "the newer, popular licenses articulate their defensive termination/suspension clauses more narrowly… because… patent holders would be reluctant to grant an open-ended patent license to downstream licensees… it is an issue as to whether a license of this scope would gain significant uptake at least from patent holders”. I think this is a strategic decision – who does the MG licenses target? OSI is concerned with “significant uptake… from patent holders”, but patent holders are likely to be larger companies with the resources to file for patents and obtain legal advice on their IP rights. Would such patent holders be likely to use a template license, or would they have a bespoke license? My view is that MG licenses seem to be more akin to the general purpose licenses like MIT/GPL/Apache 2.0, and we might not need to be too concerned with uptake from patent holders.


Best,
Moming


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