Frequently asked questions

What the Mutualist License is

What are the goals of MutuaL? Why make it?

The goal is to be humane, equitable, clear, robust, sovereign without being isolationist, and modern. Ideally, both the OSI and the FSF would approve it. At the same time, we want to avoid the pitfalls that come from bending the knee to licenses written before the turn of the millennium, or to corporate agendas.

We think this license fills a role that nothing else in the F(L)OSS world covers right now. We would like to hear what you make of it.

Is a “flipped form” license actually precise enough to be enforceable?

We believe so. The term was coined by a technology lawyer who has written several software licenses in a flipped form style.

(Note: Kyle E. Mitchell has no affiliation or involvement with this license or the people who make it, and does not endorse this license in any way.)

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 makes an agreement inherently more, or less, able to fulfill these criteria. The Mutualist License chooses to achieve these goals in natural, everyday language.

Compare how MutuaL writes about patents in Innovation with just one paragraph of the AGPL-3.0:

If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients.

Legally precise? Yes, of course. Intelligible to regular people? We think it loses them somewhere around the third idea you have to hold in your head to understand the seven that follow.

There are exceptions, where the law actually does prefer or require certain specific words or phrases. In these cases, MutuaL does include them where necessary; the gloss for that clause explains why they are there and what they actually mean. This is most notable in Reliability and especially Non-Liability.

Is MutuaL actually “open source” or “free software”?

Short version: MutuaL is designed to meet both the Free Software Definition and the Open Source Definition, so we would argue “yes”, but it has not (yet) gone through formal FSF or OSI approval.

In spirit and in structure, MutuaL is meant to be a free/open license. It gives you rights to use, run, study, copy, change, share, and sell the software, as long as you follow the rules. It has strong copyleft and network provisions, but no "ethical use" or field-of-use restrictions. It expressly aligns its Cooperation clause with licenses that satisfy the Free Software Definition and Open Source Definition. We do intend to go through the formal approval processes, but organizations like OSI and FSF have their own review processes and politics. Until that happens, MutuaL is, strictly speaking, “designed to be free/open” rather than formally blessed by the usual stewards of those terms. For high-stakes contexts, your lawyers should evaluate it on its own.

Does MutuaL impose ethical or field of use restrictions? The documentation keeps using values-driven words like “fair” and “humane”

No. The values words are there to communicate about MutuaL and its design goals, not to control what you’re allowed to do with software that uses it.

MutuaL does not restrict who can use the software or for what purpose. It only cares that everyone who receives it keeps the same technical freedoms it granted to you. You won’t find any “you may not use this software for X” language in the license.

If you’re just here for the practical answer, you can stop there. If you want our philosophy on this, please read the philosophy, which goes into more detail. It is sympathetic, not insulting.

Do you mean “mutualism” in a political way?

No, except insofar as F(L)OSS goals are inherently political (or, as Thomas Mann put it, “everything is politics”). We don’t use it in the economic sense, but in the biological sense.

The author of the first version hadn’t actually even heard of the economic use of the word until she presented an early draft to a friend, who asked her, “wait… like, anarchy?” She was attached to the name by that point, though, and figured that meaning of the word was not especially well-known.

If you are familiar with the term, our apologies for any unintentional false advertising! We’re not against that meaning, either, and feel like MutuaL ends up fitting that pretty well too.

How the copyleft works

What does “strong-as-it-needs-to-be copyleft” mean? Is it strong or is it weak?

It is adaptive.

If you’ll forgive the personification: MutuaL is polite to licenses that are polite to it. It does not feel the need to bully well-meaning guests. It is not a pushover, though, and it does not tolerate being bullied.

Against proprietary software, the copyleft is strong. If MutuaL comes into contact with a closed-source or proprietary license that denies users their rights, it is unyielding. In this context, it behaves like a very strong copyleft: it ensures you cannot “wrap” MutuaL code into a closed product, or into a permissively-licensed wrapper, to get around the rules. It stays with the software like a bodyguard watching out for proprietary muggers.

With open source software, it’s cooperative. If it comes into contact with a F(L)OSS license that already ensures users retain their freedoms, it stands down. It doesn’t try to force the other software to adopt MutuaL’s rules, provided the other software plays nice.

How does “Cooperation” work?

In traditional strong copyleft (like the GPL family), the license is often described as “viral.” If you combine a GPL file with an MIT file to make a single program, the copyleft usually insists that the entire combined program must be released under the GPL. It effectively swallows the permissive license.

MutuaL takes a different approach.

If you link or combine MutuaL software with other software that is also free/open (specifically, software whose license gives everyone the rights to use, run, study, copy, change, share, and sell it, and lets anyone have, use, change, and share its source code), MutuaL agrees to stay in its own lane.

Imagine you are building a web app. You write the main logic and license that part under MutuaL, but you import a logging library licensed under MIT.

1. The MutuaL parts stay MutuaL. You must still share the source code for your main logic, and if others use it over a network—directly, or as the core of a service you run—you must offer them that source (the Mutualism and network rules).
2. The MIT parts stay MIT. You do not have to re-license the MIT library under MutuaL. You do not have to provide the source code for the MIT library if the MIT license doesn’t require it (though it usually is available anyway).
3. The Combined Work. You do not have to license the whole finished application under MutuaL. You can release the combined bundle under a mixed license, or simply respect the terms of both licenses side-by-side.

Note that this only works if you keep the code distinct. If you copy-paste MutuaL code into an MIT file (mixing them so they cannot be separated), the full Mutualism rule kicks in and covers everything by necessity.

As mentioned above, this exception does not apply to proprietary or closed-source libraries. If you link MutuaL-licensed code with a closed-source library, the Cooperation exception fails, and the full Mutualism rule applies to the whole work (which usually means you can’t distribute that combination at all, because the closed license won’t let you fulfill MutuaL’s requirements).

MutuaL doesn’t want to colonize your dependencies; it just wants to make sure its own code stays free, and isn’t used to prop up software that denies users their rights.

Please note: We chose MIT for demonstration purposes. Though we believe the MIT license allows this kind of cooperation too, we do not specifically guarantee that it, or any other license, does. Please see the next answer.

Is MutuaL compatible with [other license] under Cooperation?

Nothing in this FAQ is legal advice, and we suggest you seek a qualified lawyer for any high-stakes context.

As general guidance: any OSI-approved or FSF-free license that does not contain a copyleft or share-alike component, frequently called a “permissive license”, is almost certainly compatible. Without a copyleft requirement, a conflict with Mutualism is very unlikely, and the approval already guarantees the license meets the minimum standards.

As mentioned in the license text, this is not the only way a license can qualify, and permissive licenses that are not approved by either body are not inherently disqualified.

Copyleft licenses are harder to judge and need expert analysis. In general, the more “selfish” a copyleft provision is, the less likely it is to be compatible. At a minimum, it must be alright with the combined or linked software containing code that is dual-licensed (as in “both,” not “either”, sometimes called multi-licensed) under both itself and the Cooperation-softened MutuaL.

Are ethical licenses compatible under Cooperation?

Sadly, no, or at least not right now. As stated in the Cooperation section of the license (emphasis added):

[…] if that other software’s license gives everyone the rights to use it, and lets anyone have, use, change, and share its source code.

We would love this to be different. But an exception that covers most ethical licenses and still excludes every proprietary one turns out to be as hard to write as an effective ethical license.

The goal is to prevent proprietary exploitation. Boil a proprietary license down and you get a restriction on what people can do with the software, plus a limit on who may use it: the people the Licensor approves of (employees, affiliates, paying customers, contractors). That is the same mechanism ethical licenses use: selective inclusion and exclusion.

The exception would also have to keep bad-faith unethical licenses out, which is harder still. Imagine a regressive individual drafts an antagonistic “ethical” license excluding use by specific demographics or political opponents. That one cannot get a free pass, obviously.

So the exception would have to be selective on two different axes at once. In essence: allow “good” (not bad) use, by “most” (not few) people, in a way that is just, immutable, and built to last. If we believed that was easy, or even possible, we wouldn’t be skeptical of ethical licenses; we would have just made one ourselves!

Does the patent rule stop patent trolls?

Partly. Anyone who accepts this license gives up their rights under it if they start a patent attack over this software. Someone who never accepted the license is not bound by that rule, so the patent grant and the patent-peace rule cannot disarm a troll or a stranger. They protect people inside the commons from each other.

Using it in a project

Can I use MutuaL-licensed software in commercial products?

You can use MutuaL software in commercial settings, including for-profit products and services. Copyleft and free software is fine with people making money: WordPress is GPL-2.0-or-later software, and Automattic is hardly hurting for money.

The important part is what happens to the code: if you share the MutuaL-licensed software or software based on it with others, modified or not, you must license those MutuaL-based parts under MutuaL and follow the source rules in Mutualism.

If you let “others” use a modified version over a network (customers, users, clients, etc.), you must also offer them its source. The same duty applies with no change on your part when a service you run depends on MutuaL-licensed software for core functionality.

If you just use it internally inside one legal entity and don’t share it or let others use it, you can keep your changes private. Clarity’s definition of “others” explicitly carves out people inside the same entity and certain contractors.

What you can’t do is fold MutuaL-covered code into a closed-source product and deny your users the freedoms MutuaL gave you.

I’m hiring a contractor to modify MutuaL-licensed software for my company. Does this trigger Mutualism, and do I automatically need to release the source code to the public?

No. The definition of “others” in Clarity excludes a contractor while all three of these hold: they are under direct contract to do specific work for you, they are bound by confidentiality obligations to your entity, and they work under your direction and control. This extends the private/internal use exception. Once the work ends, or any of those conditions stops applying, a contractor who keeps the code becomes one of the “others” again, so ensure your contracts are clear on this.

(Consider doing so anyway, though, for the good of the commons!)

What exactly triggers the network-source requirement?

There are two separate situations that trigger the requirement to provide source code over a network:

1. You run a modified version for others to use

If both of these are true:

1. You’re running a modified version of the MutuaL-licensed software, and
2. Others (as defined in Clarity) can interact with it over a network—including public users, customers, clients, and federated peers, even if access is invite-only or gated.

… then you must give those users a clear and easy way to get the source code and this license for that exact version (for example, a “Source code” link in the UI). You must keep that source available for as long as you are offering that modified version over the network.

There is one exception: If you are running an unchanged copy and people interact with it as the software itself (straightforward hosting), you don’t have to provide the source yourself—as long as you keep any existing links or references to the software’s home that were already present. This exception does not apply if the MutuaL software is acting as a hidden component or backend of something else you built; in that case, see situation #2 below.

2. You run any software that depends on MutuaL-licensed software for core functionality

This applies even if your copy of MutuaL-licensed software is unchanged and even if users never interact with it directly.

If you run software for others over a network, and that service depends on MutuaL-licensed code for core functionality (meaning it couldn’t operate in its current form without it, and it provides substantial functionality that its users benefit from), you must provide source code for the MutuaL-licensed parts as if you were sharing the software itself.

This does not apply when MutuaL-licensed software is merely a tool—like an operating system or compiler—that happens to be used in your stack but is not a core part of what makes your service valuable to users.

In all cases where the requirement applies, you must:

• Offer the source code under the same license, without extra contracts or terms.
• Keep it available for as long as you are running the service. If you stop running it entirely, the obligation ends.

What if I break a rule by mistake?

You have a 30-day period, as specified in Redemption, to fix the issue without losing your rights. The clock only starts with a valid written notice. To count, a notice must come from a copyright holder, name the rule or rules that were broken, say which copies or versions are affected, and warn that your rights may end if you do not fix the problem. A notice that is not accurate in a material way does not start the clock, and a corrected notice starts a new one. Once you have fixed a mistake, no one can use that same past mistake to send you another notice. To avoid ambiguous legal situations, your rights do not terminate until after the Redemption period is over; no one can sue you for the days you were still using the software while you were working to fix the issue.

Versions and upgrades

What is the difference between MutuaL-1.3 and MutuaL-1.3-only?

MutuaL-1.3 lets people follow this version or any later one. MutuaL-1.3-or-later is an explicit way to write the same thing. MutuaL-1.3-only locks the software to this exact version and refuses upgrades. We recommend the upgradeable form for most projects, because a later version only counts if it is an official release and does not add restrictions that would make someone who follows this version non-compliant. In other words: a future version can improve the license, but it can never take your rights away or add a poison pill.

If you combine inseparable code under different versions, the newest version governs the combined work. Code marked -only is the exception: it may combine with code under that same version, and the combined work stays there without upgrading. You cannot combine -only code with code under a different version into one inseparable work. Separable linking is still allowed under Cooperation.

Will you make different versions of MutuaL?

Probably not. MutuaL was made to address a real deficiency in the strong copyleft space; we don’t see the same need in other spaces.

• Public domain: Use 0BSD.
• Permissive licenses: Use the Blue Oak Model License.
• Weak copyleft: We don’t plan a Mutualist entry in this space: weak copyleft tends to be the least-used kind of license, and we don’t see significant demand for another one. It’s harder to read, but the MPL 2.0 is the gold standard here and we see no reason to compete with it. (We recommend going one step up or one step down in license strength from weak copyleft; we’re not convinced weak copyleft itself accomplishes much good.)
• Strong copyleft, but no network clause: It’s hard to see the point. Strong copyleft implies a sincere desire to prevent proprietary code exploitation, but asking us to remove the network clause at the same time implies the desire to… allow some kinds of exploitation back in? We hope the flipped form and a careful design make the infamous ‘AGPL interpretative minefield’ less of a reason to choose a non-network copyleft. (Worst case: the network clause doesn’t apply to your program, which is another way of saying it is harmless to include.)