[License-review] The Mutualist License (MutuaL) v1.2
Kat Suricata
kat at katsuricata.com
Sat Jun 6 04:24:39 UTC 2026
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MutuaL-1.2.md
Type: text/markdown
Size: 23603 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260606/66065cce/attachment-0001.bin>
-------------- next part --------------
THE MUTUALIST LICENSE v1.2
© 2026 <https://codeberg.org/Mutualism/Mutualist-License>
Short ID: MutuaL-1.2
Please note that not including "only" automatically allows license upgrades.
"Mutualist License" and "MutuaL" should be seen as the same name everywhere
one of them is used after this.
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. You may not change the terms of this license and still call it the
Mutualist License, except for clearly marked excerpts, quotations, or
commentary. You are free to use this text as a starting point for your own
license under a different name. If you do, credit back to us is appreciated,
but not required.
This license is not legal advice and does not create an attorney-client
relationship.
CREDIT
Name of this software: (name)
Project home: (link)
Original copyright holder(s): (name(s))
PURPOSE
This license's goal is to allow you to use this software as freely as possible,
while protecting the people who make it from harm and making sure everyone
plays fair. 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.
This section is only here to explain why the Mutualist License exists. It is
not a rule or permission by itself. Those are found in the sections to follow.
MutuaL is a flipped form (https://flippedform.com/) in everyday English. If
something doesn't make sense, that's MutuaL's fault, not yours. Please open an
issue (https://codeberg.org/Mutualism/Mutualist-License/issues) so we can fix
it.
ACCEPTANCE
In order to receive any benefits from this license, you must agree to all of
its rules. These rules are the conditions of the deal. If you do not follow the
rules, you do not have a license. Do not use this software if you cannot or
will not follow these rules.
Please read this license as a whole; different sections rely on each other to
make sense.
You agree to these rules if you use, run, study, copy, change, share, or sell
this software in any way that normally needs permission. From now on, we'll
just use "use" when we want to refer to this long list. In this license, "Use"
should always be read to mean the full list in this paragraph.
GENEROSITY
The copyright holders and contributors allow you to do everything with this
software that would otherwise break that contributor's copyright and related
rights. You must follow this license's rules to get and keep these rights.
This license, by itself, does not give you any rights to use any names, logos,
or trademarks in promotion.
SYMMETRY
This section should be read as a basic contributor agreement. It describes what
you agree to when you contribute changes to this software, separate from your
rights as a user or distributor.
If you change this software and then make your changes available to anyone that
makes or shares this software, you license those changes under this same
license for everyone.
You "make them available" when you:
- open a pull request, merge request, or patch submission,
- post them in a public project space, forum, or issue tracker,
- include them in any public sharing, or
- let people use them in the project.
Your license for your changes applies only to the parts you made or changed.
It does not apply to separate code you mixed with your changes unless you own
that code or have permission to license it this way.
By making your changes available, you promise that:
- you have the right to share those changes under this license, and
- you are not adding code that has rules you aren't allowed to give.
If someone claims your changes include code they own or that needs different
terms, that dispute is between you and the person making the claim. Other
contributors and copyright holders are not responsible for verifying your
contributions.
NOTICE
Everyone who receives a copy of this software from you, with or without
changes, must also receive:
- this license or a link to it (https://codeberg.org/Mutualism/Mutualist-License), and
- the current Credit block from the copy you received, if any.
You may include the license and Credit in any reasonable way. For example, you
can put them in a "LICENSE" file, document, an about box, or other place where
people normally look for license and copyright information.
You may add your own Credit, or update facts in the Credit block, if:
- you keep the original Credit block somewhere in the project, and
- you do not suggest that anyone approves of you or your changes unless they
actually do.
If you add credit, the original Credit block must be at least as easy to find.
If the copy you received didn't have a Credit block, you do not have to add
one. If you want, you can still add one for your own changes.
Metadata like SPDX® headers count as a "reasonable way" to follow this
section's rules about including the license.
MUTUALISM
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.
You must not add technical measures to this software that are designed or used
mostly to stop others from using their own rights under this license. You are
allowed to use security measures whose purpose is to protect users, systems, or
data, and that do not stop people from using their rights under this license.
If you change this software and allow others (as defined in Clarity) to
interact with it over a network, like the internet, you must give them a clear
and easy way to get the source code and this license. The source code must be
for that exact version. For example, a clear link in the user interface that
lets them download the source for the version they're using.
You must keep that source available for as long as you are letting others
interact with a modified version over a network. If you stop running or
offering that modified version, you no longer need to offer source. If you
start offering a modified version again later, you must provide the source code
again.
If you run an unchanged copy of this software over a network, and others can
use it directly as you offer it, you do not have to provide source code. This
exception applies only when people interact with this software as itself. It
does not apply when this software acts as a hidden component of something else
you have made. To use this exception, you must keep any links or references to
this software's home that were already present. You do not have to add new
links to the software's home if none were included when you received your copy.
This exception is for straightforward hosting. It applies when someone connects
to your instance and gets the software as it was made, without a separate layer
of your own software between them and it. It does not apply if this software is
a backend or component of a different product or service you have built, or if
what users primarily interact with is something you made that depends on this
software to run.
If you run software for others (as defined in Clarity) over a network that
depends on this software for core functionality, you must also follow the rules
above for sharing source code, as if you were sharing this software itself.
This applies even if others never use this software directly, and even if your
copy of this software is unchanged.
A service "depends on this software for core functionality" when it could not
operate in its current form without this software, and this software provides
substantial functionality that users of the service benefit from. This does not
apply when this software is merely a tool-like an operating system, compiler,
or utility-that happens to be used in the stack but is not a core part of what
makes the service valuable to users.
If you share this software or software based on it with others in a form people
can run off of a network, you must also offer them the source code for those
parts. You can do this by including the source code with the sharing or by
letting them know about a standard and no-cost way to get the source code over
a network.
Any time you must provide others with source code, it must not require separate
contracts or extra terms beyond this license.
INNOVATION
Every copyright holder and contributor, and everyone who gives you this
software under this license, also gives you a patent license to use this
software as this license allows. It covers any patents of theirs that you would
break by using the software as this license allows.
If they later get new patents, those patents are also covered if they would be
broken by using this software as this license allows.
If you start what we will call a "patent attack," you immediately and
permanently lose all rights under this license for this software.
A "patent attack" means starting a patent lawsuit or making a legal demand
(such as a cease-and-desist letter or a request for royalty payment).
For an action to count as a patent attack, ALL of the following must be true:
- The action claims that someone using this software (or software based on
it, or any contribution to it) has broken a patent you control.
- The action is aimed at someone who is using this software under this
license.
- The person you are suing or demanding from has accepted this license for
that use.
WHAT IS NOT A PATENT ATTACK
A patent attack does not include legal actions against people who don't have
rights under this license. For example:
- Someone who never accepted this license, or
- Someone who lost their rights under Redemption and did not fix the
problem in time, or
- Someone who already lost their rights under this Innovation section in a
past patent attack.
None of these count as patent attacks.
DEFENSE EXCEPTION
This rule does not apply if you are only defending yourself. You are only
defending yourself if all of the following are true:
- Someone else sued you first over patents about this software (or software
based on it).
- You were following this license's rules when they sued you.
- Your response stays within that same dispute, or a dispute covering the
same core issue.
If you meet all three conditions above, you may:
- Argue that their patent is invalid, not broken by your use, or can't be
enforced, and/or
- Bring a counterclaim or cross-claim about their use of this software (or
software based on it).
If you do anything beyond these defensive actions in that dispute, or if you
start a separate patent action, this exception does not apply.
UNRELATED PATENT CASES
This rule also does not apply to patent cases that are only about software or
technology clearly unrelated to this software, which does not include it or
software based on it.
This patent rule does not affect any other rights you might have under other
agreements for the same software.
WHAT THIS MEANS IN PLAIN ENGLISH
Patent law requires precise language. Here is what the rules above mean in
simple terms:
A "patent attack" is when you use patents you control to stop someone from
using this software as this license allows. If you do this, you lose all your
rights to the software immediately and forever. There is no Redemption period.
The "defense exception" protects you if someone else attacks you first. You
can fight back in that same lawsuit without losing your license. However, you
cannot start a separate patent action and claim it is "defense." Your response
must stay in the dispute they started.
You can sue people who never accepted this license, who already lost their
rights under Redemption, or who already lost rights under this Innovation
section. None of those count as patent attacks under this license.
This section explains these terms for your understanding, but are not
themselves the binding terms. Everything from "Innovation" to just before
"What this means in plain English" are the legally binding terms you need to
listen to.
COOPERATION
You are allowed to link or combine this software with other software licensed
under different terms if that other software's license gives everyone the
rights to use it. The other software's source code must be shared to others to
fit this description.
If the other software's license fits that description, the Mutualism rule
changes. MutuaL still applies to this software; however, it does not force you
to share the other software's source code. You must still follow the source
sharing and network rules from Mutualism for the MutuaL-licensed parts, but you
do not have to license the combined work as a whole under this license.
If the other software does not meet that condition (like if it's closed source),
this Cooperation exception does not apply. In that case, the full Mutualism
rule applies to the entire combined work.
This exception only applies if the source code remains separable; that is, the
MutuaL-licensed source files remain separate from other source files and are
not mixed in a way that prevents easy separation. What happens when source code
is compiled into binaries does not change whether the source is separable. Code
becomes inseparable when:
- It is copy-pasted across file boundaries, OR
- Source files are merged so the MutuaL-licensed portions cannot be spotted
and separated by reasonable effort.
Separable means the MutuaL-licensed source code stays in its own identifiable
files, even if those files are later compiled into a combined binary. If the
source code becomes inseparable, the full Mutualism rule applies to everything.
Static and dynamic linking are both allowed under this exception as long as the
source files remain separate and identifiable.
Any license that fits the Free Software Definition
(https://www.gnu.org/philosophy/free-sw.html) or Open Source Definition
(https://opensource.org/osd) meets this condition. This is not the only way for
a license to qualify.
This exception is offered by the Mutualist License, but please make sure the
other license also plays nice by allowing this on its end. Ask a legal expert
if you are unsure.
REDEMPTION
If any copyright holder of this software lets you know in writing that you have
not followed any of the rules of this license except for Innovation, you can
keep your license by fixing the problem. The notice must reasonably identify
which rule or rules were broken so you know what to fix.
To fix the problem, you must, within 30 days after you receive the notice:
- stop doing the thing that breaks the rules of this license, and
- do what is needed to fix the mistake and make things right, such as giving
people missing source code, Notice, or license copies.
If you do this in time, your rights under this license continue as if you never
broke its rules. You have done this successfully either when the person who let
you know agrees with your fix, or when you have let them know about your fix
but they have not responded after seven days. If these seven days extend beyond
the 30 day Redemption period, the Redemption period extends to cover this time.
If you do not do this in time, all your rights under this license for this
software end automatically at the end of the 30 days. Any copyright holder may
choose to give you a new license if they choose, but they do not have to. If
they do, it must be in writing.
You do not get this Redemption period if you violate the Innovation rule. In
that case, your rights under this license end immediately and permanently when
you start the patent attack.
RELIABILITY
This license, along with its rights and grants, lasts forever. No one can
revoke them or ask you to stop using the software, except where this license
states that your rights may end (for example, under Innovation and Redemption).
The law likes to see certain terms here, so legally speaking: this counts as a
worldwide, non-exclusive, perpetual, royalty-free license that lasts as long as
copyright and related rights and patent law allows, unless otherwise ended under
this license.
FORESIGHT
If you are using this license for your own software, please read this section
carefully and choose the wording that matches what you actually want.
New versions of the Mutualist License may be released over time. You can tell a
version is newer by its higher number.
Each copy of the software will say which version it uses at the top of its
license section.
If your copy does not say "only," you may follow that version or any later one.
If it says "only," you must follow that exact version and not a later one.
If you combine code under different versions, the newest version applies to the
whole combined work. You cannot mix code that requires "only" a specific
version with code that does not, unless all code uses "only" that same version.
Updating the license in the software does not change the license for copies you
already received. You can only move to a higher version number, never lower.
CLARITY
By "this software," we are including both its source code and any form built
from that source code.
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.
By "source code," we mean the best form for making changes. This includes the
code itself, plus the scripts and files needed to build, install, connect, and
run it.
By "share," we mean giving copies of this software or software based on it to
someone else, in any form, by any method, for free or for money.
By "copyright and related rights," we mean that besides copyright, we're also
including neighboring rights, database rights, and similar rights in any
country.
By "standard interface," we mean a public way for software to talk to other
software. This includes things like APIs, protocols, or file formats. It must
be documented in a way that allows independent implementation, and available
for anyone in the general public to use.
By "others," we mean any person, company, or group that is not you, and not
part of the same single legal entity as you.
- If you are acting as an individual, "others" means people you don't live
with and who aren't part of your immediate family. Regardless of how your
jurisdiction defines "immediate family", your spouse, romantic partner(s),
parents, siblings, and children always count as part of your immediate
family as far as this license is concerned.
- If you are acting for a legal entity, "others" are anyone outside that
entity. Contractors do not count as "others" while they are:
- Under direct contract to do specific work for you, AND
- Bound by confidentiality obligations to your entity, AND
- Working under your direction and control (not as an independent service
provider)
Once a contractor's work ends or these conditions no longer apply, they
become "others" if they retain access to the software.
- Public users, customers, clients, federated groups, and unrelated
organizations always count as "others," even if access to the service is
limited, invite-only, or requires registration.
- Cloud providers, CDNs, and similar outside services do not count as
"others" or a group that "shares" the software if they just run or deliver
what you tell them to.
We need to use "legal entity" here, but it means a company, non-profit, or
organization that the law treats as one single person.
By "core functionality," we mean the essential features that make a service
valuable to its users. Software provides core functionality when the service
could not operate in its current form without it, and it provides substantial
value that users benefit from.
A version of the software is "unchanged" if you have not modified any part of
its code or build configuration in a way that creates a derivative work under
copyright or related rights. Changing only how the software is configured, such
as setting environment variables, editing configuration files, or adjusting
settings through the software's own interface, does not count as modifying its
code or build configuration. A copy remains unchanged even if you have
configured it for your environment or use case.
By "in writing," we mean a physical document or digital message. It must
clearly show who sent it and what they mean.
A version of the Mutualist License is only considered real and applicable to
Foresight if it appears, or has ever appeared, at the license's home
(https://codeberg.org/Mutualism/Mutualist-License) or a future home that the
original author(s) designate.
This license is only valid in English. If a court or regulatory body looks at
it, they must use the English text. Translations are just for help and have no
legal power.
HOLISM
If any part of this license is invalid or can't be enforced, the rest still
applies. The invalid part will be changed to make it valid if possible. If it
can't be fixed, that part will be removed, but the rest of the license stays in
effect.
NON-LIABILITY
Unless the law says we have to, or unless we signed a separate written
agreement with you, we provide this software to you "AS IS."
We do not make any promises about the software. We do not guarantee that it
works perfectly. This includes, but is not limited to, the legal warranties of
TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
Unless the law forces us to be, WE ARE NOT RESPONSIBLE TO YOU OR ANYONE ELSE
FOR ANY KIND OF LOSS OR DAMAGE THAT COMES FROM USING THIS SOFTWARE, EVEN IF WE
KNEW IT COULD HAPPEN. This includes things like lost data, broken systems, or
money you lose because the software did not work the way you hoped.
You are the one who has to decide if this software is safe or right for you to
use or share. You take all the risks when you use it.
Some of the capitalized words in this section break the flipped form goal. This
is because the law requires us to use those specific words, often in capital
letters, to make sure you see them. Unfortunately, because they are legal terms,
they can be confusing. Here is what they mean in simple English:
AS-IS: In the state the software is in when you receive a copy of it, no
matter what state that may be.
TITLE: This means we formally promise that we own the software or have the
right to give it to you. We are not making that promise.
NON-INFRINGEMENT: This means we promise the software does not steal anyone
else's work or break copyright rules. We are not making that promise.
MERCHANTABILITY: This means the software is good enough to be sold in a store
and works like a normal person would expect. We are not making that promise.
FITNESS FOR A PARTICULAR PURPOSE: This means the software will work for the
specific job or goal you have in mind. We are not making that promise.
This list explains these terms for your understanding, but the capitalized
phrases are the binding terms.
More information about the License-review
mailing list