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

Tue Jun 9 01:06:12 UTC 2026

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260608/898da3b9/attachment-0001.htm>