<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Kat,</p>
<p>I think you've misunderstood the role of OSI, why it approves
licenses, and what it does to those ends.</p>
<p>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.</p>
<p>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.</p>
<p>This is also not a bias against <a moz-do-not-send="true"
href="https://academic.oup.com/edited-volume/34877/chapter-abstract/298342571?redirectedFrom=fulltext&login=false">plain
language</a> drafting. The OSI has approved the <a
moz-do-not-send="true"
href="https://opensource.org/license/BlueOak-1.0.0">Blue Oak
Model License</a>, 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.</p>
<p>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.</p>
<p>Pam</p>
<div class="moz-signature">Pamela S. Chestek<br>
Chestek Legal<br>
4641 Post St.<br>
Unit 4316<br>
El Dorado Hills, CA 95762<br>
+1 919-800-8033<br>
<a class="moz-txt-link-abbreviated" href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a><br>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 6/8/2026 7:06 PM, Kat Suricata via
License-review wrote:<br>
</div>
<blockquote type="cite"
cite="mid:u0i7M9lw_cVfiy5xc7R0B3gOGRdB6wSj4Yyeda77zv0fi_KtFBkjaQinAGnPccFRaRQoEcNmNglj1DWZVboVrmhsCxP_2Wk2kNiJs-kiBk0=@katsuricata.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div
style="font-family: Verdana, sans-serif; font-size: 16px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><span>Dear
Pam,</span>
<div><br>
</div>
<div><span>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.</span></div>
<div><br>
</div>
<div><span>You're completely right about the lack of paragraph
numbering, and I've made a note to add it in the next
version.</span></div>
<div><br>
</div>
<div><span>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.</span></div>
<div><br>
</div>
<div><span>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.</span></div>
<div><br>
</div>
<div><span>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.</span></div>
<div><br>
</div>
<div><span>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".</span></div>
<div><br>
</div>
<div><span>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.</span></div>
<div><br>
</div>
<div><span>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\u2019s 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.</span></div>
<div><br>
</div>
<div><span>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.</span></div>
<div><br>
</div>
<div><span>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.</span></div>
<div><br>
</div>
<div><span>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.</span></div>
<div><br>
</div>
<div><span>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."</span></div>
<div><br>
</div>
<div><span>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.</span></div>
<div><br>
</div>
<div><span>Thanks again for writing.</span></div>
<div><br>
</div>
<span>--Kat</span><br>
</div>
<div
style="font-family: Verdana, sans-serif; font-size: 16px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br>
</div>
<div class="protonmail_quote"> On Monday, June 8th, 2026 at 9:08
PM, Pamela Chestek <a class="moz-txt-link-rfc2396E" href="mailto:pamela@chesteklegal.com"><pamela@chesteklegal.com></a> wrote:<br>
<blockquote class="protonmail_quote" type="cite">
<p>Dear Kat,</p>
<p>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. </p>
<p>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"? </p>
<p>"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. </p>
<p>"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.</p>
<p>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. </p>
<p>Not numbering paragraphs is a nightmare. It makes it very
difficult to refer to provisions of the agreement. </p>
<p>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," <a
href="https://en.wikipedia.org/wiki/Related_rights"
target="_blank" rel="noreferrer nofollow noopener"
moz-do-not-send="true">are a very specific thing</a>, is
that what you mean? </p>
<p>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.</p>
<p>Best regards,</p>
<p>Pam</p>
<div class="moz-signature">Pamela S. Chestek<br>
Chestek Legal<br>
4641 Post St.<br>
Unit 4316<br>
El Dorado Hills, CA 95762<br>
+1 919-800-8033<br>
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:pamela@chesteklegal.com"
rel="noreferrer nofollow noopener" moz-do-not-send="true">pamela@chesteklegal.com</a><br>
<a class="moz-txt-link-abbreviated"
href="http://www.chesteklegal.com" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">www.chesteklegal.com</a><br>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 6/5/2026 9:24 PM, Kat Suricata
via License-review wrote:<br>
</div>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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 <a
class="moz-txt-link-freetext"
href="https://codeberg.org/Mutualism/Mutualist-License"
style="word-break: break-word;" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">https://codeberg.org/Mutualism/Mutualist-License</a>, 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 <a class="moz-txt-link-freetext"
href="https://codeberg.org/TheMeerkat"
style="word-break: break-word;" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">https://codeberg.org/TheMeerkat</a>, 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 (<a
class="moz-txt-link-freetext"
href="https://www.drupal.org/project/hecapte_captcha"
style="word-break: break-word;" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">https://www.drupal.org/project/hecapte_captcha</a>) and an official Cloudron package (<a
class="moz-txt-link-freetext"
href="https://forum.cloudron.io/topic/14756/"
style="word-break: break-word;" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">https://forum.cloudron.io/topic/14756/</a>).
- <a class="moz-txt-link-freetext"
href="https://github.com/spiffytech/pi-safetynet/blob/main/LICENSE.md"
style="word-break: break-word;" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">https://github.com/spiffytech/pi-safetynet/blob/main/LICENSE.md</a>
- <a class="moz-txt-link-freetext"
href="https://git.secluded.site/sb-mcp"
style="word-break: break-word;" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">https://git.secluded.site/sb-mcp</a>
---
License steward: Kat Suricata
Email: <a class="moz-txt-link-abbreviated" href="mailto:kat@katsuricata.com">kat@katsuricata.com</a>
Signal: @Kat.73
---
Additional resources:
<a class="moz-txt-link-freetext"
href="https://codeberg.org/Mutualism/Mutualist-License/wiki/FAQ"
style="word-break: break-word;" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">https://codeberg.org/Mutualism/Mutualist-License/wiki/FAQ</a>
<a class="moz-txt-link-freetext"
href="https://codeberg.org/Mutualism/Mutualist-License/wiki/Development-Guidelines"
style="word-break: break-word;" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">https://codeberg.org/Mutualism/Mutualist-License/wiki/Development-Guidelines</a>
---
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</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
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
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:License-review@lists.opensource.org"
style="word-break: break-word;"
rel="noreferrer nofollow noopener" moz-do-not-send="true">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org"
style="word-break: break-word;" target="_blank"
rel="noreferrer nofollow noopener" moz-do-not-send="true">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
</blockquote>
<br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
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
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
</body>
</html>