Development guidelines

Please note: all development of MutuaL happens exclusively on the devel branch. We do not live-update anything that is not a trivial documentation change on the main branch.

MutuaL defaults to auto-upgrading, so the license can keep evolving. That carries a real obligation: we must not betray the people who adopt it. Future versions must hold to the same design philosophy.

We use one fixed set of words for the license’s ideals: humane, equitable, clear, robust, sovereign without being isolationist, and modern.

Here is what those words mean when you sit down to propose a change.

Humane

MutuaL treats different actors differently based on their behavior, and always assumes good faith first.

• Assume good faith… Be kind, charitable, and flexible. We assume violations are mistakes until proven otherwise. Always provide clear “off-ramps” (like the Redemption clause) to help people get back in compliance.
• … Until proven otherwise. When someone tries to take advantage, be rigid, inflexible, and bulletproof. If someone tries to exploit a loophole, the license must snap shut. If someone tries to weaponize patents, we revoke all rights immediately.
• Aspirational, not punitive. We organize the document by values (Generosity, Reliability, Cooperation), not just legal mechanics. The reader should understand the moral weight of a section by its title.
• No poison pills. As MutuaL defaults to allowing upgrades, future versions must never add a restriction that makes a compliant user of the previous version non-compliant in a way they cannot fix. You cannot ban a field of use out of nowhere.

Equitable

• Developer = User. Whenever possible, the license must be equally beneficial for users, developers, remixers, and maintainers. MutuaL should never favor one group more than the other unless absolutely necessary to preserve the freedom of the software.
• We educate, not berate. Where possible without diluting the terms, the text should help the reader understand why a restriction exists and what it means for them, not just that it exists.
• All jurisdictions are equal. The license should describe rights and relationships in a way that makes sense under general copyright principles, regardless of country.

Clear

MutuaL is a flipped form. The goal is always “if you can read, you can read the license”.

• Users are the experts. We do not write for attorneys; we write for the developer, the small business CTO, and the hobbyist.
• Plain English only. Use everyday language rather than legalese. Sentences should convey no more than two ideas at once.
• Readability comes first. Aim for a Flesch Reading Ease score of 60–70 for the body text (not section titles). If you must use a complex word, make the context define it.

Robust

Speak simply, but carry a big stick.

• No legal sacrifice. We do not sacrifice legal strength for vibes. MutuaL must be strong, leakproof, and unambiguous. “Clear” does not mean “weak.”
• Clarity ≠ brevity. Simple does not mean short. A completely unambiguous, easy-to-read paragraph is always preferable to an ambiguous, easy-to-read sentence. We’re making a legal document people can read, not a SparkNotes® summary.
• Explain what you can’t rewrite. If a legal concept cannot be made watertight in simple English (e.g., the disclaimer of warranties, labeled Non-Liability), use the required legal text. The plain-English explanation belongs in the gloss for that clause, not in the license file, so a reader can never mistake commentary for a term.
• Don’t reinvent the wheel, but do repaint it. Do not burden the license with more complexity than full-legalese licenses contain. If GPL-3.0 or EUPL-1.2 uses “reasonably” for rules we share, that works for us. However, do not copy-paste legalese definitions, either. We adopt standard legal concepts, but we must translate their definitions into the Mutualist License voice (as seen in Clarity).

Sovereign, Not Isolationist

We are gracious, but we are not browbeaten.

• Equal, not lesser. We do not allow MutuaL to be subsumed by other licenses. If a proprietary license tries to wrap MutuaL, MutuaL fights back. If another copyleft license tries to push it around, MutuaL maintains its own boundaries. The selfishness and/or shortsightedness of other licenses is not our problem to fix.
• Maximize compatibility. We innovate, but we do not isolate. MutuaL should be as compatible as possible with other Free/Libre/Open Source licenses via the Cooperation clause, without weakening itself.

Modern

The license must work for the world as it exists today, not 1990.

• Know how developers work. Rules must not break standard development practices. Using a cloud provider, hiring a contractor, or running a CI/CD pipeline should never trigger copyleft provisions unless the intent (or result) is to share with the public.

• Know what year it is. Avoid tying rules to specific technologies that may fade or be replaced. Many flaws in older licenses come from being written with floppy disks in mind rather than global, distributed code forges. Focus on the interaction and the relationship (e.g., “interacting over a network”).

  Note: If Modern conflicts with Robust (e.g., being technologically agnostic makes the license too vague to enforce), Robust wins. We can always update it later.