[License-review] The Mutualist License (MutuaL) v1.2

Wed Jun 10 04:24:51 UTC 2026

Hi Kat,

I think you've misunderstood the role of OSI, why it approves licenses, 
and what it does to those ends.

The OSI primary purpose is to ensure and advance the health of the open 
source ecosystem, and that is the lens through which licenses are 
reviewed and approved. During review, the reviewers, some of whom are 
open source lawyers who have been practicing for decades, do the best 
they can to pressure test the licenses to make sure that they would be 
correctly interpreted, that is, to ensure that a court will construe the 
license in a way that protects and advances the purposes, values and 
goals of the open source ecosystem as a whole. Something as simple as a 
misplaced comma might create an unintended loophole, allowing someone to 
undermine or defeat the openness that the license is meant to protect. 
So the OSI is reviewing licenses with a more exacting purpose than just 
whether it's kinda sorta in the ballpark.

Canons of contract interpretation do not save the day. They aren't 
invoked unless the language is unclear, so even having to invoke them 
means there is a chance that the legal conclusion about the meaning will 
not be what you intended. The better approach is to write a license that 
is clear on its face without ambiguity -- an impossibility, but we do 
the best we can. Using substitutes for well-known and well-understood 
terms of art is an invitation to misinterpretation.

This is also not a bias against plain language 
<https://academic.oup.com/edited-volume/34877/chapter-abstract/298342571?redirectedFrom=fulltext&login=false> 
drafting. The OSI has approved the Blue Oak Model License 
<https://opensource.org/license/BlueOak-1.0.0>, a plain language license 
written by, if recollection serves, Kyle Mitchell, Heather Meeker and 
Luis Villa, all highly skilled open source lawyers who fully understand 
how contracts are read and interpreted. Plain language drafting requires 
as much knowledge about contract interpretation as writing in so-called 
"legal" language, and probably more skill in writing. It's not the 
writing style that is the problem, it is the inexactness with which it 
is done that is the problem.

This is nothing against your license, but it is against OSI approval of 
your license, because the OSI's role is do what it can to ensure that 
any approved license will work as intended. In my opinion this license 
is too poorly drafted to assure that will happen.

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

On 6/8/2026 7:06 PM, Kat Suricata via License-review wrote:
> Dear Pam,
>
> Thank you for taking the time to read the Mutualist License and write 
> back! I sincerely appreciate that you engaged with it at all, even 
> briefly.
>
> You're completely right about the lack of paragraph numbering, and 
> I've made a note to add it in the next version.
>
> I also hear you on "break copyright", as "infringe" is the standard 
> term. I will say that I don't think "break" creates actual ambiguity 
> about what the grant covers: "do everything that would otherwise break 
> copyright" is ordinary English for "do everything copyright would 
> otherwise prohibit", as in the common phrase "break the law". You're 
> right that it's not the word courts and lawyers expect, and I may add 
> it to Clarify (Definitions) in the future.
>
> On the headings: I understand that "Generosity" isn't where you'd look 
> for a license grant. It isn't where I'd look for one either, if I were 
> a practicing lawyer briefly scanning for it. However, I'm writing for 
> someone who has never read a license before and isn't sure what any of 
> the sections do. "Grant" tells that person nothing, whereas 
> "Generosity" at least signals what's happening in concept. This is a 
> deliberate tradeoff, not an oversight; you're free to think it's the 
> wrong one, but please don't come away with the impression that it's 
> ill-considered. If the license ends up in court, I would certainly 
> hope that any lawyer would take care to read the whole thing and not 
> simply scan section titles.
>
> On the "exact copies" sentence: you read it as saying "exact copies" 
> and then immediately creating a contradictory category of permitted 
> alteration, but it serves as a definition narrowing what "exact" 
> means, clarifying that reformatting isn't the same as changing terms. 
> That distinction matters because someone will reasonably wonder 
> whether re-wrapping line lengths counts as making a "non-exact" copy. 
> The sentence answers that question. I believe it resolves ambiguity, 
> not creates it, though I'm very open to rewording it in the future.
>
> On "This license is not legal advice": you ask what would make someone 
> think it does. The same thing that makes every legal blog, bar 
> association website, and, yes, many licenses include it: someone reads 
> legal language from someone who seems knowledgeable and relies on it 
> as counsel. This is perhaps the most standard disclaimer in the legal 
> world. I'm genuinely surprised you singled it out. Just off the top of 
> my head, Creative Commons has: "Distributing, displaying, or linking 
> to this deed or the license that it summarizes does not create a 
> lawyer-client or any other relationship." I obviously do not mean to 
> imply that the license itself is the one giving legal advice, and I do 
> not see any reasonable reading where that would be the take-away 
> rather than "the authors/users of this license".
>
> On "related rights": you ask whether I mean neighboring rights as if 
> the license doesn't address this. Clarity defines it explicitly: "By 
> copyright and related rights, we mean that besides copyright, we're 
> also including neighboring rights, database rights, and similar rights 
> in any country." That's not vague.
>
> On OSD compliance: you say the grant "doesn't unquestionably grant all 
> the rights necessary," but you don't actually identify which rights 
> are missing. From the license: "As long as you follow all of this 
> license’s rules, you can use, run, study, copy, change, share, or sell 
> this software for any reason, without having to ask permission first." 
> The grant covers "everything with this software that would otherwise 
> break that contributor's copyright and related rights." Read with 
> Clarity's definitions, "everything" that copyright and related rights 
> would otherwise prohibit is, by definition, the full and complete 
> bundle of exclusive rights. That's use, reproduction, distribution, 
> modification, and everything else copyright law reserves to the 
> holder. Again, I find myself genuinely at a loss as to how to resolve 
> this complaint with the current wording.
>
> I'm aware that these are responding to individual points, which you 
> called out as not encompassing your full position, so on a more 
> general level: legal documents *aren't* code, like your metaphor 
> implies. Code either compiles or it doesn't. Legal documents are 
> interpreted by courts, and courts are perfectly capable of reading and 
> interpreting plain English (as I'm sure you're well aware!). The 
> contra proferentem rule, the principle of reading a contract as a 
> whole, the primacy of intent over form, etc.: these are all tools 
> courts use to enforce agreements that don't follow traditional 
> drafting conventions. I'm not asking courts to guess what I mean; I'm 
> asking them to read the words I wrote, which are in a register they 
> understand perfectly well and which are written with the express 
> intent of being as comprehensible as possible even to people without 
> their breadth of experience and expertise.
>
> The flipped form approach was coined by Kyle E. Mitchell, a technology 
> lawyer who has drafted and published several software licenses in this 
> style. He invented the concept precisely because he believes, and I 
> agree, that precision and plain language aren't opposites. You can 
> disagree, but it's a considered position held by people who do this 
> for a living.
>
> You wrote that you "have not reviewed the document in any depth," and 
> I believe you. What I'd ask is that if you *do* choose to look at it 
> more carefully, you engage with what the license actually says, 
> including its definitions section, rather than noting that it doesn't 
> immediately look like what you're used to and concluding it can't 
> work. Conventional drafting is a choice, not a law of nature.
>
> Per the FAQ I linked in the initial email: "For the most part (see 
> below), courts do not necessarily care about invoking the correct 
> magic words for a legal ritual; they care about ambiguity, 
> enforceability, and adherence to the law. No number of 'heretofore's 
> make an agreement inherently more, or less, able to fulfill this 
> criteria."
>
> I'm also genuinely open to being wrong about specific points. If you 
> read Clarity and still think "related rights" is inadequately defined, 
> tell me how! I would love to fix real problems. I feel our 
> disagreement, however, lies in whether "doesn't look like most 
> licenses" is a real problem in and of itself.
>
> Thanks again for writing.
>
> --Kat
>
> On Monday, June 8th, 2026 at 9:08 PM, Pamela Chestek 
> <pamela at chesteklegal.com> wrote:
>>
>> Dear Kat,
>>
>> I appreciate that you are trying to solve the problem that legal 
>> documents are often difficult to understand for a reader who is not 
>> legally trained. However, writing legal documents is not very 
>> different from writing code: there are drafting conventions, rules 
>> for interpretation, and specific words that are used when construing 
>> what the intended meaning is. Writing a legal agreement without 
>> following these rules is no different from writing code that doesn't 
>> follow the rules -- it just doesn't work.
>>
>> Just the intro alone has several examples of problematic drafting. 
>> "Please note that not including 'only' automatically allows license 
>> upgrades." Adding it where, and for what purpose? It takes until 
>> "Foresight" to understand the significance, but then it still 
>> requires some guessing about where and how the word "only" is to be 
>> added -- to the proposed SPDX identifier? Somewhere at the top, just 
>> add the random word "only"?
>>
>> "Everyone is allowed to share exact copies of this license, with or 
>> without changing the formatting, as long as the changes do not alter, 
>> remove, or add any terms." The comment about formatting is helpful, 
>> but saying "as long as the changes do not alter, remove, or add any 
>> terms" adds ambiguity. A principle of contract law is that, when 
>> interpreting legal instruments, every word is necessary and 
>> meaningful and not "mere surplusage." You have said you only allow 
>> "exact copies," but then go on to create a possible category of some 
>> alteration, removal or addition of "terms" that might still qualify 
>> as an exact copy.
>>
>> "This license is not legal advice and does not create an 
>> attorney-client relationship." What about it would make me think 
>> that? Documents don't have attorney-client relationships, people do.
>>
>> Non-traditional naming of headings is also an ill-considered idea. 
>> The license grant is under a section called "Generosity," not hardly 
>> where I would be looking for it. The definitions are in a section 
>> called "Clarity." Information about future versions of the license is 
>> under a heading called "Foresight." Headings are to help the readers 
>> so they can find what they are looking for quickly, but your language 
>> makes it much more difficult.
>>
>> Not numbering paragraphs is a nightmare. It makes it very difficult 
>> to refer to provisions of the agreement.
>>
>> From these brief, initial observations and a brief scan of the 
>> agreement it's quite clear this is not a document that can reliably 
>> function as an open source license. Just a quick look at the license 
>> grant shows that it doesn't meet the OSD because it doesn't 
>> unquestionably grant all the rights necessary. The grant is "to do 
>> everything with this software that would otherwise break that 
>> contributor's copyright and related rights." What does "break 
>> copyright" mean? Copyright owners have a specific set of rights and 
>> can grant licenses to them, so I don't know what "break" means in 
>> that legal context. What are "related rights" and how do you "break" 
>> those? "Related rights," also known as "neighboring rights," are a 
>> very specific thing <https://en.wikipedia.org/wiki/Related_rights>, 
>> is that what you mean?
>>
>> I have not reviewed the document in any depth and this is not a list 
>> of all the problems with it, so changing the very few things I 
>> mentioned will not solve the problems. I am writing only to point out 
>> to you that there are many, many problems with the document and you 
>> should not expect any kind of insightful review or feedback when it 
>> is so far away from any acceptable standard for legal writing.
>>
>> Best regards,
>>
>> 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
>>
>>
>> On 6/5/2026 9:24 PM, Kat Suricata via License-review wrote:
>>> Hello,
>>>
>>> My name is Kat Suricata, and I'm writing to submit the Mutualist License v1.2 (MutuaL-1.2) for formal OSI approval as a new license.
>>>
>>> I've attached the canonical Markdown version, as well as a plain-text version, as requested. The license lives athttps://codeberg.org/Mutualism/Mutualist-License, along with a fair bit of supporting documentation. The FAQ and Development Guidelines are probably the most useful if you want more detail on edge cases and design decisions.
>>>
>>> I'll walk through each requirement below. I've separated the requirements into sections for better readability.
>>>
>>> ---
>>>
>>> I affirm that MutuaL complies in full with the Open Source Definition, and specifically with OSD 3, 5, 6, and 9. Here's how it maps:
>>>
>>> 1. Free Redistribution: The license expressly grants the right to "use, run, study, copy, change, share, or sell [the] software in any way."
>>>
>>> 2. Source Code: "By 'this software', we are including both its source code and any form built from that source code."
>>>
>>> 3. Derived Works: "If you share this software or software based on it, you must use this same license for any copies that you share and follow the Notice rule. This applies whether or not you've made changes. You must not add rules to these copies that would limit or take away the rights people get under this license."
>>>
>>> 4. Integrity of the Author's Source Code: There are no restrictions on distribution in modified form except for the copyleft requirement.
>>>
>>> 5. No Discrimination Against Persons or Groups; and 6. No Discrimination Against Fields of Endeavor: "As long as you follow all of this license's rules, you can use, run, study, copy, change, share, or sell this software for any reason, without having to ask permission first."
>>>
>>> 7. Distribution of License: "If you share this software or software based on it, you must use this same license for any copies that you share and follow the Notice rule. This applies whether or not you've made changes. You must not add rules to these copies that would limit or take away the rights people get under this license." Also: "Any time you must provide others with source code, it must not require separate contracts or extra terms beyond this license."
>>>
>>> 8. License Must Not Be Specific to a Product: There is no clause limiting scope in this way.
>>>
>>> 9. License Must Not Restrict Other Software: "By 'software based on this software', we mean work that fits the legal definition of a derivative work under copyright law. Software is not 'based on this software' if it only runs alongside it or talks to it through a standard interface. This license does not touch separate software." (This just means independent software communicating over an API, or that is merely distributed alongside the MutuaL-licensed software, isn't pulled into copyleft. The copyleft on actual derivative works is unchanged.)
>>>
>>> 10. License Must Be Technology-Neutral: There is no clause limiting scope in this way.
>>>
>>> ---
>>>
>>> Software already using this license:
>>>
>>> - Several of my own projects athttps://codeberg.org/TheMeerkat, including HeCAPTe, a privacy-first, stateless CAPTCHA that uses Equihash proof-of-work to verify users without tracking them. This is probably the most widely used MutuaL-licensed project so far: it has a community Drupal port (https://www.drupal.org/project/hecapte_captcha) and an official Cloudron package (https://forum.cloudron.io/topic/14756/).
>>> -https://github.com/spiffytech/pi-safetynet/blob/main/LICENSE.md
>>> -https://git.secluded.site/sb-mcp
>>>
>>> ---
>>>
>>> License steward: Kat Suricata
>>> Email:kat at katsuricata.com
>>> Signal: @Kat.73
>>>
>>> ---
>>>
>>> Additional resources:
>>>
>>> https://codeberg.org/Mutualism/Mutualist-License/wiki/FAQ
>>> https://codeberg.org/Mutualism/Mutualist-License/wiki/Development-Guidelines
>>>
>>> ---
>>>
>>> What gap it fills: No existing license combines strong network copyleft, FOSS license cooperation, modern drafting, ease of updating, plain-language readability, and robust patent protection all in one.
>>>
>>> - AGPLv3 only requires source sharing for *modified* versions run over a network. If a company wraps an unmodified AGPL binary in a proprietary web service, AGPL does not trigger. With MutuaL, the copyleft applies when you modify the software, when you run it as a hidden component of a larger service, or when a network service depends on it for core functionality. This closes the "unmodified wrapper" loophole without being broader than necessary.
>>>
>>> - AGPLv3 and GPLv3 both force complete relicensing of combined works. AGPLv3 singles out GPLv3 as the only license it is willing to cooperate with. MutuaL's Cooperation clause allows combining with any FOSS license that meets the Free Software Definition or Open Source Definition, as long as the source files remain separable. The MutuaL-licensed parts stay under MutuaL; the other FOSS parts stay under their own terms. You don't have to choose between copyleft strength and ecosystem interoperability.
>>>
>>> - The GPL family still assumes physical distribution: they talk about "durable physical medium customarily used for software interchange" and written offers valid for three years. MutuaL assumes the internet. There are no physical-media clauses, no three-year offers, and no assumptions about shrink-wrap distribution.
>>>
>>> - AGPLv3's text is written for lawyers; most developers cannot parse it without help. MutuaL is written in plain English with extensive clarifications intended for the end user. The body text scores 60-70 on Flesch-Kincaid (roughly US eighth-grade reading level) without sacrificing legal precision. A software license that gives you rights you don't understand isn't much better than All Rights Reserved.
>>>
>>> - MutuaL's Redemption provision gives 30 days for all non-patent violations, automatically extends the deadline if the notifying party doesn't respond, and considers the cure successful if the notifier doesn't object within 7 days. The process is simple and the timeline is predictable.
>>>
>>> - MutuaL's patent provisions expressly cover patents acquired after licensing and define the defense exception in plain English.
>>>
>>> ---
>>>
>>> Compare and contrast:
>>>
>>> AGPLv3: The obvious point of comparison for network copyleft. MutuaL is stricter in some places and clearer in others. AGPL only triggers on "modified" versions, which means companies can build proprietary wrappers around unmodified AGPL binaries and never share source. MutuaL closes that: copyleft kicks in if you modify the software, run it as a hidden component, or operate a network service that depends on it for core functionality. On the flip side, AGPL has some genuinely confusing grey areas around what counts as "private" use, whether contractors count as external distribution, and where corporate boundaries actually lie. MutuaL tries to be explicit about all of that.
>>>
>>> GPLv3: Doesn't target the SaaS gap at all, so there's plenty of room for proprietary exploitation of otherwise copyleft software. MutuaL closes that loophole. Also, GPL's strict virality creates a monoculture that doesn't leave much room for flexibility. MutuaL's Cooperation provision works around this: if you combine MutuaL code with other FOSS-licensed code, the MutuaL parts stay under MutuaL, but the other FOSS code stays under its own license. You don't have to relicense the whole combined work under MutuaL.
>>>
>>> MPL 2.0: MPL uses file-level copyleft to allow combining with proprietary software. MutuaL's Cooperation provision lets you combine MutuaL code with other FOSS-licensed code without forcing the entire combined work under MutuaL, as long as the source files remain separable. This provision is not granted to proprietary software. You get MPL-like compatibility with the broader free software ecosystem, but with stronger protection against proprietary exploitation.
>>>
>>> Weak copyleft and permissive licenses: The FSF has long argued these don't adequately protect user freedoms for substantive software, and that's my view as well. They have their uses, but they aren't what MutuaL is trying to be.
>>>
>>> ---
>>>
>>> Legal review: MutuaL was drafted with a lot of care and reviewed informally by a lawyer friend, but it hasn't been through formal legal review yet. Fundraising for that is planned.
>>>
>>> ---
>>>
>>> Standards for new licenses:
>>>
>>> - OSD compliance: Covered above. I believe MutuaL meets all ten points.
>>> - Reusability: Yes. It isn't scoped to any specific project or licensor.
>>> - No favored position for the licensor: Correct.
>>> - Ambiguity: I've tried to be precise, and the FAQ goes into this at length. I don't think MutuaL is more ambiguous than any commonly-used software license available today.
>>> - Grammatically and syntactically clear: This is one of its greatest strengths.
>>> - Variations: Not applicable. There's only one Mutualist License.
>>> - Possible to comply: Yes. MutuaL's requirements are no harder to meet than GPL or AGPL, and in some respects they're easier because the definitions are more robust and clear; for example, who counts as "others" for network sharing, or what triggers the "hidden component" rule.
>>> - Fills a gap: Yes. As described above, MutuaL offers strong network copyleft with clearer scope boundaries than AGPL, cooperation with other FOSS licenses without GPL's strict virality, and modern drafting that doesn't assume physical media distribution. I don't believe any existing OSI-approved license combines all of these.
>>> - Complete, standalone license: Yes.
>>>
>>> ---
>>>
>>> I am ready to answer questions, clarify drafting choices, and engage with the review process in whatever form is most useful. MutuaL has been in active development for over a year and out/in use for about half of that, has been refined in response to real developer feedback, and is intended to be maintained as a living document with clear version-upgrade rules. I genuinely believe the open-source community would benefit from having this option alongside the existing copyleft family.
>>>
>>> Thank you for your time and consideration!
>>>
>>> -- Kat Suricata
>>>
>>> _______________________________________________
>>> 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/20260609/2d9184c9/attachment-0001.htm>