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

Tue Jun 9 02:06:54 UTC 2026

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 at
>> https://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 at
>> https://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/20260609/db26beb7/attachment-0001.htm>