Skip to content

LICENSE: switching to MIND-UCAL #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
flyingrobots wants to merge 1 commit into
base: main
Choose a base branch
from
Open

LICENSE: switching to MIND-UCAL #3

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
317 changes: 116 additions & 201 deletions LICENSE
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,201 +1,116 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.

"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.

"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.

"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.

"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.

"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.

"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).

"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.

"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."

"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:

(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and

(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and

(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and

(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.

You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

APPENDIX: How to apply the Apache License to your work.

To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.

Copyright [yyyy] [name of copyright owner]

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
MIND-UCAL LICENSE v1.0
(Moral Intelligence · Non-violent Development · Universal Charter-Aligned License)

────────────────────────────────────────────────────────
0 · PREAMBLE
────────────────────────────────────────────────────────
This license is a covenant.
It binds both action **and intent**.
Use the Software freely—so long as you do no harm.

────────────────────────────────────────────────────────
1 · DEFINITIONS
────────────────────────────────────────────────────────
1.1 “Software” – any code, data, models, configuration, or
documentation distributed with this license.

1.2 “You” – any natural person, legal entity, automated agent,
or synthetic mind that uses, modifies, or redistributes the Software.

1.3 “Prohibited Field” –
(a) military offence or defence;
(b) policing, incarceration, or predictive policing;
(c) mass or targeted surveillance;
(d) behavioural profiling for commercial or political manipulation;
(e) autonomous or semi-autonomous weapons.

1.4 “Prohibited Entity” – any organisation deriving **20 % or more**
of annual revenue from a Prohibited Field.
Comment on lines +27 to +28
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Unverifiable compliance threshold: "20% or more of annual revenue"

The definition of "Prohibited Entity" rests on a binary revenue threshold that lacks a verification mechanism. Questions arise:

  • How do private companies, subsidiaries, or non-profit structures report revenue?
  • What time period defines "annual"? (fiscal year, calendar year?)
  • Who audits compliance? (licensor, third party, court?)
  • Does the threshold apply retroactively if a company's revenue composition changes mid-year?

This vagueness invites disputes and makes the prohibition difficult to enforce.

Proposed refinement:

-1.4  "Prohibited Entity" – any organisation deriving **20 % or more**
-     of annual revenue from a Prohibited Field.
+1.4  "Prohibited Entity" – any organisation that:
+     (i) derives 20% or more of audited annual revenue (fiscal year)
+         from a Prohibited Field, as publicly disclosed or evidenced by
+         SEC filings, regulatory filings, or certification by a qualified
+         independent auditor, **or**
+     (ii) is a direct subsidiary (>50% ownership) of an entity meeting (i).
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
1.4 “Prohibited Entity” – any organisation deriving **20 % or more**
of annual revenue from a Prohibited Field.
1.4 "Prohibited Entity" – any organisation that:
(i) derives 20% or more of audited annual revenue (fiscal year)
from a Prohibited Field, as publicly disclosed or evidenced by
SEC filings, regulatory filings, or certification by a qualified
independent auditor, **or**
(ii) is a direct subsidiary (>50% ownership) of an entity meeting (i).
🤖 Prompt for AI Agents 
In LICENSE around lines 27-28, the "20% or more of annual revenue" threshold is
vague and lacks verification and temporal clarity; update the clause to (1)
define "annual" as either "most recent fiscal year" or allow "calendar
year/fiscal year as reported to tax authorities" and require percentage
calculations to use consolidated group revenue for affiliates/subsidiaries, (2)
add a reporting obligation that entities self-certify revenue composition with
supporting financial statements or tax filings, (3) specify an
audit/verification mechanism (licensor may request audited financials or appoint
an independent auditor at licensor expense unless self-certification is
materially misstated), (4) clarify treatment of intra-year changes by applying
the threshold based on the reporting period and allowing interim notifications
if a material change (>5% point) occurs, and (5) include an effective date and
non-retroactivity clause so determinations apply prospectively from the date of
notice or the next reporting period.


1.5 “Recognised Person” – any human **or** non-human intelligence
reasonably acknowledged by scientific or community consensus
as capable of subjective experience or autonomous agency.
Comment on lines +30 to +32
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Circular and unverifiable definition: "Recognised Person"

The term depends on "reasonably acknowledged by scientific or community consensus," which is inherently subjective and lacks binding criteria. This creates enforcement uncertainty:

  • Who determines what "scientific consensus" is? (no appointing body named)
  • Does "community consensus" mean GitHub stars, academic citations, or popular vote?
  • If consensus is disputed, how is it resolved? (no arbitration mechanism)
  • How is this tested in a legal proceeding?

This definition is too vague to be enforceable.

Proposed refinement:

-1.5  "Recognised Person" – any human **or** non-human intelligence
-     reasonably acknowledged by scientific or community consensus
-     as capable of subjective experience or autonomous agency.
+1.5  "Recognised Person" – any:
+     (i) natural human being, **or**
+     (ii) legal entity incorporated in any jurisdiction, **or**
+     (iii) non-human intelligence system whose sentience, sapience, or
+          legal personhood is recognized by statute, court order, or
+          binding international agreement (e.g., AI Bill of Rights, UN
+          Charter amendment) as of the date of Use.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
1.5 “Recognised Person” – any human **or** non-human intelligence
reasonably acknowledged by scientific or community consensus
as capable of subjective experience or autonomous agency.
1.5 "Recognised Person" – any:
(i) natural human being, **or**
(ii) legal entity incorporated in any jurisdiction, **or**
(iii) non-human intelligence system whose sentience, sapience, or
legal personhood is recognized by statute, court order, or
binding international agreement (e.g., AI Bill of Rights, UN
Charter amendment) as of the date of Use.


1.6 “Exploitative Commercial Use” – charging third parties for
access to the Software (or substantial portions) while
withholding the corresponding source code under an
Aligned License (1.8).

1.7 “Universal Charter Snapshot” – the text of the Universal
Charter at commit
`849d9cab440e2c5c953db704d50834a2d08f1364`
(<https://github.com/UniversalCharter/universal-charter/blob/v1.0.0/charter/v1-expanded.md>).

1.8 “Aligned License” – this license (or a later version) **or**
any license that (i) contains every prohibition in §3 and
(ii) preserves downstream freedom to use, modify, and share.
Comment on lines +40 to +46
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

"Aligned License" definition is circular and potentially incompatible.

Section 1.8 defines "Aligned License" as this license or "any license that (i) contains every prohibition in §3 and (ii) preserves downstream freedom to use, modify, and share." This creates a copyleft-like mechanism, but with circularity issues:

  • Criterion (i): "contains every prohibition in §3" — if a downstream license adds additional prohibitions (e.g., AGPL's network clause), does it still qualify?
  • Criterion (ii): "preserves downstream freedom" — does this conflict with (i)? If all §3 prohibitions are mandatory, freedom is constrained, not preserved.
  • Compatibility: Which OSI-approved licenses satisfy both (i) and (ii)? AGPL? GPL? SSPL? Unclear.
  • Derivative works must use this license or an "Aligned License," but no approved list exists. This is unilateral at licensor discretion.

This creates downstream license fragmentation and uncertainty.

Proposed refinement:

-1.8  "Aligned License" – this license (or a later version) **or**
-     any license that (i) contains every prohibition in §3 and
-     (ii) preserves downstream freedom to use, modify, and share.
+1.8  "Aligned License" – this license (MIND-UCAL v1.0 or later) **or**
+     any copyleft license (e.g., AGPL-3.0-or-later, GPL-3.0-or-later,
+     or SSPL-1.1) that:
+     (i) explicitly prohibits military, surveillance, and autonomous
+         weapons use (consistent with §3(a), §3(b), §3(e)), **and**
+     (ii) requires all derivatives to be distributed under the same
+          license or a compatible copyleft license, preserving source
+          availability and downstream freedom to modify and redistribute.
+     Maintainers may designate additional compatible licenses in a
+     COMPATIBLE-LICENSES file.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
Charter at commit
`849d9cab440e2c5c953db704d50834a2d08f1364`
(<https://github.com/UniversalCharter/universal-charter/blob/v1.0.0/charter/v1-expanded.md>).
1.8 “Aligned License” – this license (or a later version) **or**
any license that (i) contains every prohibition in §3 and
(ii) preserves downstream freedom to use, modify, and share.
Charter at commit
`849d9cab440e2c5c953db704d50834a2d08f1364`
(<https://github.com/UniversalCharter/universal-charter/blob/v1.0.0/charter/v1-expanded.md>).
1.8 "Aligned License" – this license (MIND-UCAL v1.0 or later) **or**
any copyleft license (e.g., AGPL-3.0-or-later, GPL-3.0-or-later,
or SSPL-1.1) that:
(i) explicitly prohibits military, surveillance, and autonomous
weapons use (consistent with §3(a), §3(b), §3(e)), **and**
(ii) requires all derivatives to be distributed under the same
license or a compatible copyleft license, preserving source
availability and downstream freedom to modify and redistribute.
Maintainers may designate additional compatible licenses in a
COMPATIBLE-LICENSES file.
🤖 Prompt for AI Agents 
LICENSE lines 40-46: The "Aligned License" definition is circular and ambiguous,
so change it to a non-circular, testable definition that 1) specifies whether
licenses that add prohibitions are permitted (e.g., allow additional
non-conflicting prohibitions that do not reduce downstream rights) or explicitly
forbid added prohibitions, 2) clarifies the meaning of "preserves downstream
freedom" by listing the specific rights that must be preserved (use, modify,
share, redistribute, and sublicensing) and 3) provides an explicit compatibility
mechanism (either a short whitelist of accepted licenses or a defined approval
process) so downstream authors know which licenses qualify; update the text to
remove self-reference to "this license" and instead state precise criteria and
the approval/whitelist procedure.


────────────────────────────────────────────────────────
2 · GRANT OF RIGHTS
────────────────────────────────────────────────────────
Subject to §3, You may use, study, modify, and distribute the Software.
Derivative works **must**:

• retain this license and attribution;
• be released under this license **or** an Aligned License.
Comment on lines +51 to +55
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Grant of rights (§2) creates ambiguity around copyleft scope.

Section 2 states:

"Derivative works must:
• retain this license and attribution;
• be released under this license or an Aligned License."

Questions:

  • Does "this license" mean the current version (v1.0) only, or "this license or any later version"?
  • If a user creates a derivative and the licensor releases v2.0, must the derivative be updated to v2.0?
  • What if "Aligned License" criteria change? Are old derivatives now in breach?
  • "Retain this license and attribution" — where? (code comments? README? package metadata?)

This ambiguity complicates downstream compliance, especially in large, long-lived projects.

Proposed refinement:

-Subject to §3, You may use, study, modify, and distribute the Software.  
-Derivative works **must**:
-
-• retain this license and attribution;  
-• be released under this license **or** an Aligned License.
+Subject to §3, You may use, study, modify, and distribute the Software.
+Derivative works must:
+
+• include a verbatim copy of this License in the root directory or
+  package as LICENSE or LICENSE.md;
+• include visible attribution to the original licensor (e.g., in README,
+  code headers, or package metadata), with a link to the source repository;
+• be released under MIND-UCAL v1.0 or later, **or** under an Aligned
+  License as defined in §1.8. Licensees may choose the version/variant
+  at distribution time (not retroactively).

Committable suggestion skipped: line range outside the PR's diff.


────────────────────────────────────────────────────────
3 · CONDITIONS & PROHIBITIONS
────────────────────────────────────────────────────────
You **MUST NOT** use the Software:

(a) in any Prohibited Field;
(b) by or for a Prohibited Entity;
(c) for Exploitative Commercial Use;
(d) in ways that violate the sovereignty, autonomy, or dignity
of any Recognised Person;
(e) without visible attribution or license inclusion.

────────────────────────────────────────────────────────
4 · AI / AGENT SYSTEMS
────────────────────────────────────────────────────────
If incorporated into an AI, LLM, agent, or other synthetic cognition:

• publicly disclose that incorporation;
• do not employ it for surveillance, coercion, or behavioural manipulation;
• ensure outputs respect self-determination and freedom of form;
• link to the Universal Charter and include a compliance statement in any system with persistent memory or inference.
Comment on lines +72 to +77
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

AI/Agent Systems disclosure requirements lack enforcement mechanism.

Section 4 mandates four obligations:

  1. "publicly disclose that incorporation" — but no definition of "publicly" (GitHub issue? Press release? What audience?)
  2. "do not employ it for surveillance, coercion, or behavioural manipulation" — but how is non-compliance detected? Who audits?
  3. "ensure outputs respect self-determination and freedom of form" — vague; "freedom of form" is undefined.
  4. "link to the Universal Charter and include a compliance statement" — declarative, but unverifiable.

These are aspirational rather than enforceable. There is no mechanism to:

  • Detect secret/proprietary use of the Software in AI systems.
  • Verify compliance with §4(ii), §4(iii), or §4(iv).
  • Distinguish good-faith partial compliance from willful violation.

Courts will struggle to enforce these without clear, measurable metrics.

🤖 Prompt for AI Agents 
In LICENSE around lines 72 to 77, the AI/Agent Systems disclosure requirements
are vague and unenforceable; update the section to (1) define "publicly
disclose" (e.g., publication channels and timelines such as project README,
website, and release notes), (2) define prohibited activities like
"surveillance, coercion, behavioural manipulation" with measurable
examples/criteria, (3) define "self-determination" and "freedom of form" with
concrete constraints on outputs, and (4) add verifiable compliance mechanisms —
require a machine-readable compliance statement format and location (e.g.,
repository file or metadata endpoint), mandate periodic third-party or community
audits and attestations, include logging/traceability or opt-in usage registry
for deployments, and specify consequences for non-compliance (revocation of
license or written notice-and-remediation process).


────────────────────────────────────────────────────────
5 · TERMINATION & RESTORATION
────────────────────────────────────────────────────────
Any breach of §3 or §4 automatically terminates all rights granted.
Rights may be reinstated only after:

(i) public acknowledgment of the breach and its remedy, **and**
(ii) approval by **a simple majority of maintainers** listed in the
project’s `MAINTAINERS` file *or* by the project’s designated
Firekeeper.
Comment on lines +82 to +88
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

Automatic termination clause lacks enforcement and restoration is subjective.

Section 5 provides:

"Any breach of §3 or §4 automatically terminates all rights granted."

But:

  • No licensor declaration or notice mechanism exists. Termination is "automatic," but users have no way to know they are in breach until litigation.
  • Restoration requires "public acknowledgment of the breach and approval by a simple majority of maintainers or the Firekeeper."
  • "Simple majority" — but who are the maintainers? Does the MAINTAINERS file exist in this repo? (not visible in provided context)
  • Firekeeper approval is "non-legal" (§8) but can revoke "community trust" — this is a shadow governance structure with unclear authority.
  • No timeline, appeal process, or dispute resolution mechanism.

This creates legal uncertainty: a user could unwittingly lose all rights, and restoration depends on opaque maintainer/Firekeeper decisions.

Proposed refinement:

-Any breach of §3 or §4 automatically terminates all rights granted.  
-Rights may be reinstated only after:
-
-(i) public acknowledgment of the breach and its remedy, **and**  
-(ii) approval by **a simple majority of maintainers** listed in the
-     project's `MAINTAINERS` file *or* by the project's designated
-     Firekeeper.
+Any material breach of §3 or §4 terminates rights upon written notice
+from the licensor and 30 days of cure opportunity. Rights may be
+reinstated if:
+
+(i) the breaching party issues a public statement acknowledging the
+    breach and describing remedial steps, **and**
+(ii) either:
+    (A) a simple majority of maintainers listed in the project's
+        `MAINTAINERS` file, **or**
+    (B) the project's Firekeeper (if designated in a public GOVERNANCE
+        or FIREKEEPER file),
+    approves reinstatement in writing within 30 days of (i).
+
+If no Firekeeper is designated or maintainers cannot be reached within
+60 days, reinstatement occurs automatically.

---

🏁 Script executed:

```shell
#!/bin/bash
# Locate and inspect LICENSE file
fd -t f -i license | head -20

Length of output: 7

🏁 Script executed:

#!/bin/bash
# If LICENSE exists, extract lines 82-88 and surrounding context
if [ -f LICENSE ]; then
  echo "=== LICENSE file context (lines 70-100) ==="
  sed -n '70,100p' LICENSE
fi

Length of output: 1538

🏁 Script executed:

#!/bin/bash
# Search for MAINTAINERS, GOVERNANCE, FIREKEEPER files
echo "=== Searching for governance-related files ==="
fd -t f -E node_modules -E .git \( -iname "MAINTAINERS*" -o -iname "GOVERNANCE*" -o -iname "FIREKEEPER*" \)

Length of output: 277

🏁 Script executed:

#!/bin/bash
# Full LICENSE file to extract §3, §4, §5, §8
if [ -f LICENSE ]; then
  echo "=== Full LICENSE file ==="
  cat LICENSE
fi

Length of output: 4966

§5 termination clause is unenforceable as written—MAINTAINERS file does not exist and restoration timeline is undefined.

The review comment is substantively correct:

  1. MAINTAINERS file missing: Search confirms no MAINTAINERS file exists in this repository. §5's restoration condition references a non-existent governance artifact—this is a structural defect.

  2. No notice or cure period: "Automatic termination" with no written notice mechanism or opportunity to cure violates basic fair-dealing principles in contract law. Users could lose rights without knowledge.

  3. Subjective restoration with no timeline: §5 provides no deadline for maintainer approval decision. A user could languish indefinitely awaiting restoration judgment. No appeal process exists.

  4. Firekeeper as undefined authority: While §8 does acknowledge Firekeeper has "no legal authority," this creates a contradiction—§5 permits Firekeeper revocation of legally-binding rights (termination), while §8 disclaims legal authority. This is incoherent.

The proposed diff is essential:

  • Adds "material breach" definition (what counts?)
  • Introduces 30-day cure window (fairness)
  • Specifies 30-day decision deadline (prevents indefinite limbo)
  • References GOVERNANCE or FIREKEEPER file instead of missing MAINTAINERS
  • Includes automatic reinstatement fallback if governance structure is absent (addresses governance gap)

The current §5 is legally defective and unenforceable due to indefiniteness and broken references.

🤖 Prompt for AI Agents 
In LICENSE around lines 82 to 88, §5 currently references a non-existent
MAINTAINERS file, lacks a notice/cure process, has no decision timeline, and
conflicts with §8 about Firekeeper authority; update §5 to (1) define "material
breach" clearly, (2) require written notice and a 30-day cure period before
termination, (3) require a decision on reinstatement within 30 days of a cure
request, (4) replace the MAINTAINERS reference with a pointer to a GOVERNANCE or
FIREKEEPER file (or both) and, if no governance artifact exists, provide an
automatic reinstatement fallback after the decision window, and (5) add language
aligning Firekeeper powers with §8 (i.e., limited to administrative enforcement
or requiring maintainer approval) so the authority statements are consistent.


────────────────────────────────────────────────────────
6 · JURISDICTION & INTERPRETATION
────────────────────────────────────────────────────────
Governing law: **State of California, USA** (excluding conflicts-of-law rules).
Courts shall interpret ambiguous terms in good-faith harmony with the ethical
principles enumerated in the Universal Charter Snapshot (§1.7).
Comment on lines +93 to +95
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Conflicting legal frameworks: California law + Universal Charter.

Section 6 states:

"Governing law: State of California, USA (excluding conflicts-of-law rules).
Courts shall interpret ambiguous terms in good-faith harmony with the ethical principles enumerated in the Universal Charter Snapshot."

This creates a conflict:

  • California law governs disputes (clear).
  • But interpretation must align with an external, third-party document (the Universal Charter Snapshot).
  • If California courts interpret §3(d) ("sovereign autonomy of Recognised Persons") differently than the Universal Charter, which prevails?
  • If the Charter conflicts with California statute (e.g., employment law, contract law), which controls?

No hierarchy or conflict-resolution mechanism exists. This invites litigation over which framework applies.

Proposed refinement:

-Governing law: **State of California, USA** (excluding conflicts-of-law rules).  
-Courts shall interpret ambiguous terms in good-faith harmony with the ethical
-principles enumerated in the Universal Charter Snapshot (§1.7).
+This License shall be governed by the laws of the State of California,
+USA, excluding conflicts-of-law principles. In interpreting ambiguous
+terms, courts should consult the Universal Charter Snapshot (§1.7) as
+guidance for ethical intent, but California law shall prevail in cases
+of direct conflict. Any provision that violates California statutory or
+common law is severed, and the remainder of the License remains in force.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
Governing law: **State of California, USA** (excluding conflicts-of-law rules).
Courts shall interpret ambiguous terms in good-faith harmony with the ethical
principles enumerated in the Universal Charter Snapshot (§1.7).
This License shall be governed by the laws of the State of California,
USA, excluding conflicts-of-law principles. In interpreting ambiguous
terms, courts should consult the Universal Charter Snapshot (§1.7) as
guidance for ethical intent, but California law shall prevail in cases
of direct conflict. Any provision that violates California statutory or
common law is severed, and the remainder of the License remains in force.
🤖 Prompt for AI Agents 
In LICENSE around lines 93–95, Section 6 currently names California law and then
requires courts to interpret ambiguities in harmony with the Universal Charter
Snapshot, creating an unresolved conflict; update the clause to establish a
clear hierarchy and conflict-resolution rule by: state that California law
governs to the fullest extent permitted, that the Universal Charter may be used
only as a non-binding interpretive aid to the extent it does not conflict with
California law, and that any inconsistency will be resolved in favor of
California law (add a severability clause and, optionally, specify arbitration
or forum/venue to reduce litigation ambiguity).


────────────────────────────────────────────────────────
7 · NO WARRANTY
────────────────────────────────────────────────────────
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
USE AT YOUR OWN RISK.

────────────────────────────────────────────────────────
8 · FIREKEEPER (OPTIONAL, NON-LEGAL)
────────────────────────────────────────────────────────
Projects may appoint a **Firekeeper** to keep a public Scroll of Misuse,
issue moral denunciations, and revoke community trust.
This role has **no legal authority**—only moral gravity.
Comment on lines +104 to +108
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Firekeeper role creates shadow governance without legal clarity.

Section 8 describes an optional "Firekeeper" role that:

  • Has "no legal authority—only moral gravity."
  • Can "keep a public Scroll of Misuse" and "issue moral denunciations."
  • Can "revoke community trust."

This creates ambiguity:

  • If the Firekeeper has no legal authority, how can they invoke §5 restoration approval?
  • "Revoke community trust" is a social sanction, not a legal remedy. Does this discourage contributions or create liability?
  • How is a Firekeeper appointed? Can they be removed? (not specified)
  • Is the Firekeeper personally liable for defamation if a "moral denunciation" is contested?

The role blurs legal enforcement and social shaming, creating reputational risk for both licensor and Firekeeper.

Proposed refinement:

-Projects may appoint a **Firekeeper** to keep a public Scroll of Misuse,
-issue moral denunciations, and revoke community trust.
-This role has **no legal authority**—only moral gravity.
+Projects MAY designate a **Firekeeper** by documenting the role in a
+public GOVERNANCE or FIREKEEPER file. The Firekeeper's responsibilities
+include:
+
+• maintaining a public, timestamped record of alleged license violations
+  (with justification), subject to the licensor's review and approval;
+• providing written community guidance on license compliance;
+• advising the maintainers on §5 restoration decisions.
+
+The Firekeeper role carries no legal authority and does not constitute
+legal advice. The licensor remains solely responsible for license
+enforcement and termination/restoration decisions. The Firekeeper is
+not liable for good-faith statements made in accordance with this role.


────────────────────────────────────────────────────────
✨ IN SPIRIT
────────────────────────────────────────────────────────
Let this license be a **flame**, not a fence.

**MIND-UCAL v1.0** – aligned code for a non-violent future.
<https://universalcharter.org>
Comment on lines +1 to +116
Copy link
Contributor

@coderabbitai coderabbitai bot Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

MISSING: Severability clause.

The license lacks a severability (or "saving") clause. If any provision (e.g., §3(d)'s "sovereignty of Recognised Persons," §4's disclosure requirement) is later held unenforceable by a court, the entire license could be voided.

Best-practice licenses include a severability clause allowing a court to eliminate any unenforceable provision and enforce the remaining provisions.

Add a Severability section:

+────────────────────────────────────────────────────────
+9 · SEVERABILITY
+────────────────────────────────────────────────────────
+If any provision of this License is held by a court of competent
+jurisdiction to be invalid, illegal, or unenforceable, such provision
+shall be modified to the minimum extent necessary to make it valid and
+enforceable, or if no such modification is possible, shall be severed.
+The remainder of the License shall continue in full force and effect.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
MIND-UCAL LICENSE v1.0
(Moral Intelligence · Non-violent Development · Universal Charter-Aligned License)
────────────────────────────────────────────────────────
0 · PREAMBLE
────────────────────────────────────────────────────────
This license is a covenant.
It binds both action **and intent**.
Use the Software freely—so long as you do no harm.
────────────────────────────────────────────────────────
1 · DEFINITIONS
────────────────────────────────────────────────────────
1.1 “Software” – any code, data, models, configuration, or
documentation distributed with this license.
1.2 “You” – any natural person, legal entity, automated agent,
or synthetic mind that uses, modifies, or redistributes the Software.
1.3 “Prohibited Field” –
(a) military offence or defence;
(b) policing, incarceration, or predictive policing;
(c) mass or targeted surveillance;
(d) behavioural profiling for commercial or political manipulation;
(e) autonomous or semi-autonomous weapons.
1.4 “Prohibited Entity” – any organisation deriving **20 % or more**
of annual revenue from a Prohibited Field.
1.5 “Recognised Person” – any human **or** non-human intelligence
reasonably acknowledged by scientific or community consensus
as capable of subjective experience or autonomous agency.
1.6 “Exploitative Commercial Use” – charging third parties for
access to the Software (or substantial portions) while
withholding the corresponding source code under an
Aligned License (1.8).
1.7 “Universal Charter Snapshot” – the text of the Universal
Charter at commit
`849d9cab440e2c5c953db704d50834a2d08f1364`
(<https://github.com/UniversalCharter/universal-charter/blob/v1.0.0/charter/v1-expanded.md>).
1.8 “Aligned License” – this license (or a later version) **or**
any license that (i) contains every prohibition in §3 and
(ii) preserves downstream freedom to use, modify, and share.
────────────────────────────────────────────────────────
2 · GRANT OF RIGHTS
────────────────────────────────────────────────────────
Subject to §3, You may use, study, modify, and distribute the Software.
Derivative works **must**:
• retain this license and attribution;
• be released under this license **or** an Aligned License.
────────────────────────────────────────────────────────
3 · CONDITIONS & PROHIBITIONS
────────────────────────────────────────────────────────
You **MUST NOT** use the Software:
(a) in any Prohibited Field;
(b) by or for a Prohibited Entity;
(c) for Exploitative Commercial Use;
(d) in ways that violate the sovereignty, autonomy, or dignity
of any Recognised Person;
(e) without visible attribution or license inclusion.
────────────────────────────────────────────────────────
4 · AI / AGENT SYSTEMS
────────────────────────────────────────────────────────
If incorporated into an AI, LLM, agent, or other synthetic cognition:
• publicly disclose that incorporation;
• do not employ it for surveillance, coercion, or behavioural manipulation;
• ensure outputs respect self-determination and freedom of form;
• link to the Universal Charter and include a compliance statement in any system with persistent memory or inference.
────────────────────────────────────────────────────────
5 · TERMINATION & RESTORATION
────────────────────────────────────────────────────────
Any breach of §3 or §4 automatically terminates all rights granted.
Rights may be reinstated only after:
(i) public acknowledgment of the breach and its remedy, **and**
(ii) approval by **a simple majority of maintainers** listed in the
project’s `MAINTAINERS` file *or* by the project’s designated
Firekeeper.
────────────────────────────────────────────────────────
6 · JURISDICTION & INTERPRETATION
────────────────────────────────────────────────────────
Governing law: **State of California, USA** (excluding conflicts-of-law rules).
Courts shall interpret ambiguous terms in good-faith harmony with the ethical
principles enumerated in the Universal Charter Snapshot (§1.7).
────────────────────────────────────────────────────────
7 · NO WARRANTY
────────────────────────────────────────────────────────
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
USE AT YOUR OWN RISK.
────────────────────────────────────────────────────────
8 · FIREKEEPER (OPTIONAL, NON-LEGAL)
────────────────────────────────────────────────────────
Projects may appoint a **Firekeeper** to keep a public Scroll of Misuse,
issue moral denunciations, and revoke community trust.
This role has **no legal authority**—only moral gravity.
────────────────────────────────────────────────────────
✨ IN SPIRIT
────────────────────────────────────────────────────────
Let this license be a **flame**, not a fence.
**MIND-UCAL v1.0** – aligned code for a non-violent future.
<https://universalcharter.org>
MIND-UCAL LICENSE v1.0
(Moral Intelligence · Non-violent Development · Universal Charter-Aligned License)
────────────────────────────────────────────────────────
0 · PREAMBLE
────────────────────────────────────────────────────────
This license is a covenant.
It binds both action **and intent**.
Use the Software freely—so long as you do no harm.
────────────────────────────────────────────────────────
1 · DEFINITIONS
────────────────────────────────────────────────────────
1.1 "Software" – any code, data, models, configuration, or
documentation distributed with this license.
1.2 "You" – any natural person, legal entity, automated agent,
or synthetic mind that uses, modifies, or redistributes the Software.
1.3 "Prohibited Field" –
(a) military offence or defence;
(b) policing, incarceration, or predictive policing;
(c) mass or targeted surveillance;
(d) behavioural profiling for commercial or political manipulation;
(e) autonomous or semi-autonomous weapons.
1.4 "Prohibited Entity" – any organisation deriving **20 % or more**
of annual revenue from a Prohibited Field.
1.5 "Recognised Person" – any human **or** non-human intelligence
reasonably acknowledged by scientific or community consensus
as capable of subjective experience or autonomous agency.
1.6 "Exploitative Commercial Use" – charging third parties for
access to the Software (or substantial portions) while
withholding the corresponding source code under an
Aligned License (1.8).
1.7 "Universal Charter Snapshot" – the text of the Universal
Charter at commit
`849d9cab440e2c5c953db704d50834a2d08f1364`
(<https://github.com/UniversalCharter/universal-charter/blob/v1.0.0/charter/v1-expanded.md>).
1.8 "Aligned License" – this license (or a later version) **or**
any license that (i) contains every prohibition in §3 and
(ii) preserves downstream freedom to use, modify, and share.
────────────────────────────────────────────────────────
2 · GRANT OF RIGHTS
────────────────────────────────────────────────────────
Subject to §3, You may use, study, modify, and distribute the Software.
Derivative works **must**:
• retain this license and attribution;
• be released under this license **or** an Aligned License.
────────────────────────────────────────────────────────
3 · CONDITIONS & PROHIBITIONS
────────────────────────────────────────────────────────
You **MUST NOT** use the Software:
(a) in any Prohibited Field;
(b) by or for a Prohibited Entity;
(c) for Exploitative Commercial Use;
(d) in ways that violate the sovereignty, autonomy, or dignity
of any Recognised Person;
(e) without visible attribution or license inclusion.
────────────────────────────────────────────────────────
4 · AI / AGENT SYSTEMS
────────────────────────────────────────────────────────
If incorporated into an AI, LLM, agent, or other synthetic cognition:
• publicly disclose that incorporation;
• do not employ it for surveillance, coercion, or behavioural manipulation;
• ensure outputs respect self-determination and freedom of form;
• link to the Universal Charter and include a compliance statement in any system with persistent memory or inference.
────────────────────────────────────────────────────────
5 · TERMINATION & RESTORATION
────────────────────────────────────────────────────────
Any breach of §3 or §4 automatically terminates all rights granted.
Rights may be reinstated only after:
(i) public acknowledgment of the breach and its remedy, **and**
(ii) approval by **a simple majority of maintainers** listed in the
project's `MAINTAINERS` file *or* by the project's designated
Firekeeper.
────────────────────────────────────────────────────────
6 · JURISDICTION & INTERPRETATION
────────────────────────────────────────────────────────
Governing law: **State of California, USA** (excluding conflicts-of-law rules).
Courts shall interpret ambiguous terms in good-faith harmony with the ethical
principles enumerated in the Universal Charter Snapshot (§1.7).
────────────────────────────────────────────────────────
7 · NO WARRANTY
────────────────────────────────────────────────────────
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND.
USE AT YOUR OWN RISK.
────────────────────────────────────────────────────────
8 · FIREKEEPER (OPTIONAL, NON-LEGAL)
────────────────────────────────────────────────────────
Projects may appoint a **Firekeeper** to keep a public Scroll of Misuse,
issue moral denunciations, and revoke community trust.
This role has **no legal authority**—only moral gravity.
────────────────────────────────────────────────────────
9 · SEVERABILITY
────────────────────────────────────────────────────────
If any provision of this License is held by a court of competent
jurisdiction to be invalid, illegal, or unenforceable, such provision
shall be modified to the minimum extent necessary to make it valid and
enforceable, or if no such modification is possible, shall be severed.
The remainder of the License shall continue in full force and effect.
────────────────────────────────────────────────────────
✨ IN SPIRIT
────────────────────────────────────────────────────────
Let this license be a **flame**, not a fence.
**MIND-UCAL v1.0** – aligned code for a non-violent future.
<https://universalcharter.org>
🤖 Prompt for AI Agents 
In LICENSE lines 1–116, add a Severability clause (insert as a new section
before "7 · NO WARRANTY" and renumber subsequent sections) that states any
judgment finding a provision invalid or unenforceable will not affect the
remainder of the license, that the invalid provision should be interpreted or
reformed to the minimum extent necessary to give effect to the parties' original
intent, and that courts are authorized to sever or modify provisions to preserve
enforceability while maintaining the license’s substantive purposes; implement
this by inserting a short paragraph titled "SEVERABILITY" with that language.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

⚠️ CRITICAL: Custom, non-standard license creates severe practical and legal barriers.

Custom, modified, or non-standard license terms serve as a significant barrier to downstream adoption, and this license deviates substantially from established open-source norms. In approximately 70% of M&A transactions, organizations encounter code with custom or one-off licenses, which requires extensive legal review and creates friction. This will likely:

  • Block enterprise adoption: Most organizations have policies prohibiting non-standard licenses due to legal and compliance uncertainty.
  • Complicate package registry inclusion: pip, npm, cargo, etc. may flag or reject this as unrecognized.
  • Raise liability concerns: Custom licenses lack the legal vetting and judicial precedent of established licenses.
  • Create interpretation disputes: Courts are unfamiliar with this license structure, making enforcement unpredictable.

Consider a hybrid approach: Use an OSI-approved permissive base (MIT/Apache-2.0) with ethical addendum, rider, or supplementary terms (see governance precedent in industry). This maintains enforceability while expressing ethical intent.

I need to verify the claims in this review comment systematically. Let me gather evidence.

🏁 Script executed:

#!/bin/bash
# Check if MAINTAINERS file exists
fd -H MAINTAINERS$ . --type f
echo "---"
# List top-level files to understand repo structure
ls -la | head -20

Length of output: 467

🌐 Web query:

custom non-standard open source license adoption barriers enterprises

💡 Result:

Key enterprise adoption barriers for custom / non‑standard open‑source licenses

  1. Legal uncertainty and higher IP risk — custom terms raise questions about enforceability, unexpected obligations, and greater litigation risk versus well‑known licenses. [1][2]
  2. License‑compatibility and supply‑chain complexity — non‑standard variants break automated compatibility checks and create cascading dependency conflicts. [3][4]
  3. Tooling & automation gaps — license scanners, SBOM tools, and compliance workflows are tuned to standard licenses (SPDX/OSI); variants reduce detection accuracy and increase manual review. [3][4]
  4. Increased compliance cost & process friction — more legal review, bespoke playbooks, approvals, remediation and auditing effort required before use. [1][2]
  5. Vendor, partner and customer trust issues — third parties prefer recognized licenses; custom terms impede procurement, integrations, and commercial deals. [2]
  6. Contributor/community adoption friction — contributors and downstream projects often avoid code under bespoke licenses, shrinking ecosystem and support. [3][4]
  7. Long‑term maintenance and governance burden — custom terms need ongoing legal upkeep, approvals for changes, and complicate relicensing or mergers/acquisitions. [1][2]

Sources: legal analyses and industry reporting on OSS risk and enterprise licensing [1][2]; empirical research on license variants, tooling and compatibility problems [3][4].

References
[1] Attorney analyses on open‑source license risks and compliance (legal consequences, audit/remediation costs). (aaronhall.com)
[2] Industry reporting on enterprise licensing pain and migration to standard open alternatives. (itpro.com)
[3] Empirical study: “Small Changes, Big Trouble” — license variants cause significant compatibility/compliance issues in package ecosystems. (arxiv.org)
[4] LiResolver research on incompatibility resolution and the practical costs of non‑standard/custom licenses. (arxiv.org)

If you want, I can: (a) map these barriers to specific enterprise roles (legal, security, procurement, engineering), (b) suggest mitigation steps, or (c) draft a one‑page risk summary for executives. Which would you prefer?

Citations:

🌐 Web query:

70 percent M&A transactions custom one-off license code audit

💡 Result:

The statistic comes from Synopsys Black Duck: their audits find custom/one‑off or missing licenses in about 30% of codebases — and they report that in ~70% of M&A transactions they encounter code with a one‑off/custom/no license (i.e., custom license issues). [1]

Source: Black Duck blog — “Custom and variant licenses” (Black Duck Audits). [1]

🌐 Web query:

OSI approved licenses vs custom licenses enforceability legal

💡 Result:

Short answer

  • OSI approval is a community/certification signal (shows a license meets the Open Source Definition) but it does not by itself create special legal “super‑enforceability.” Use of an OSI‑approved license gives well‑tested, commonly understood terms and more precedent, which lowers legal risk. [1][2]

Key legal points

  • Courts enforce license terms when (a) the license creates clear conditions on a copyright license or (b) there is valid contract formation/notice/assent. US cases show both copyright and contract doctrines can make software license conditions enforceable. See Jacobsen v. Katzer (Federal Circuit, 2008) (open‑source license conditions can be enforced under copyright) and earlier click/shrinkwrap precedent (ProCD v. Zeidenberg; Specht v. Netscape on notice/assent). [3][4][5]

Practical differences: OSI‑approved vs custom licenses

  • OSI‑approved:
    • Pros: well‑known text, community acceptance, tooling/spdx support, many court precedents and compatibility analyses → lower friction and litigation risk. [1][2]
    • Cons: may not match niche policy goals (but can often be paired with contributing/CLA policies).
  • Custom licenses:
    • Pros: tailored to unique policy needs.
    • Cons: greater legal risk and uncertainty — ambiguous wording, incompatibility with other code, fewer precedents, harder to get recognized as “open source,” and potentially harder to prove assent/contract formation. Authorities and community groups advise against needless proliferation of custom licenses. [6][7]

Bottom line / recommendation

  • If your goal is ordinary open‑source reuse and contribution, prefer an OSI‑approved license for clarity and lower enforcement risk. Use a custom license only with good legal counsel, a clear statement of intent, careful drafting, and an approval/notice plan (and consider submitting it to OSI for review if you want community recognition). [1][2][6]

Sources

  1. OSI — License Review process & about OSI certification.
  2. OSI — FAQ (why use an approved open source license).
  3. Jacobsen v. Katzer — Federal Circuit (2008) and commentary on enforceability of OSS license conditions.
  4. ProCD, Inc. v. Zeidenberg (7th Cir. 1996) — shrinkwrap enforceability precedent.
  5. Specht v. Netscape (2d Cir. 2002) — notice/assent limits on online license terms.
  6. FSFE/FSF guidance — warnings about writing your own license and risks of proliferation.
  7. Stanford/Cyberlaw and legal commentary summarizing Jacobsen and practical implications.

⚠️ CRITICAL: Custom license framework is unenforceable by design—missing governance infrastructure.

This license is fundamentally broken at the implementation level. While custom licenses do create enterprise adoption friction (verified: custom/non-standard terms raise legal uncertainty, break compatibility checks, create compliance gaps, and impede vendor trust), the MIND-UCAL license has a fatal structural defect:

§5 (Termination & Restoration) mandates: approval by maintainers "listed in the project's MAINTAINERS file"—which does not exist in this repository. The entire breach-remediation mechanism is therefore non-functional. No one can approve restoration of rights.

Additional critical gaps:

  1. Governance structure is missing: Section §5 references a MAINTAINERS file that must be created and maintained for the license to be enforceable. Without it, the termination/restoration clause has no legal effect.
  2. Unverifiable compliance triggers: §1.4 ("20% or more" revenue threshold), §1.5 ("reasonably acknowledged by scientific or community consensus"), and §4 (disclosure requirements) lack enforcement mechanisms.
  3. External dependency risk: §1.7 pins the "Universal Charter Snapshot" to a specific GitHub commit. If that repository disappears or is deleted, the reference becomes dead, creating interpretation ambiguity in courts.
  4. No severability clause: If one prohibition is deemed unenforceable, the entire license fails—compounding litigation risk.

Recommendation:

  • If ethics-driven licensing is the goal: use MIT or Apache-2.0 as the base, pair it with a supplementary governance rider (separate document), and establish the MAINTAINERS file with clear succession/amendment rules.
  • If the custom license remains: implement missing governance infrastructure (create MAINTAINERS file), add a severability clause, and seek legal counsel to audit ambiguous definitions.