docs(licensing): charter §2 scoping, Module API Exception draft, spec decision record (HT-5/HT-82) - #99

_{Comment @coderabbitai help to get the list of available commands.}

Independent different-vendor review — Codex (codex-cli 0.142.4, read-only, 2026-07-19)

Adversarial pass per the tiered-review-escalation rule (sacred licensing boundary). Findings below verbatim; lead adjudication follows in the PR conversation.

/ JUDGMENT — legal/module-api-exception.md § removal/fork symmetry, lines 51-61; CHARTER.md §3, line 33**
The charter says the exception “travels with every conveyed copy, so a fork keeps it,” but AGPLv3 §7 expressly lets a conveyor remove additional permissions. The exception also acknowledges removability. So the fork-symmetry proviso cannot prevent a fork from removing the exception and stranding modules; it only prevents a fork from narrowing while retaining the named exception.
Suggested fix: stop claiming forks “keep” the exception unconditionally; state the accepted AGPL §7 removal risk, or pick a different licensing structure.
3. MAJOR — legal/module-api-exception.md § “Helpthread Module”, lines 42-49
The anti-smuggling rule relies on “not itself a modified version of this Program,” but does not handle split works that copy core implementation into a nominal module while keeping a thin API-only integration layer. A hostile actor can argue the wrapper is the Module and the copied core-like component is merely its private implementation.
Suggested fix: make the exclusion cover works containing, derived from, replacing, or substituting for Program implementation code, not only works that are “itself” a modified Program.
4. MAJOR / JUDGMENT — legal/module-api-exception.md § grant, lines 24-32
The grant excludes “source code of those Helpthread Modules” from Corresponding Source, but does not explicitly exclude module object code/build artifacts, installation metadata, or bundled/minified module forms from AGPL Corresponding Source obligations. In a build-time npm bundle, that omission invites an argument that non-source module materials are still required as Corresponding Source for the combined work.
Suggested fix: counsel should decide whether to exclude the Module and its source/object/build artifacts from Corresponding Source obligations to the maximum intended extent.
5. MINOR — legal/module-api-exception.md § safe harbors, lines 63-67
The “safe harbors” paragraph is inside the exception text but reads like practical guidance, including a broad legal conclusion that public HTTP/webhook integrations “need no additional permission at all.” That can become operative license text or an unintended admission.
Suggested fix: move guidance outside the legal text or mark it expressly non-operative.
6. MAJOR — CHARTER.md §2 “Own your data”, line 19
“The core never sits in the data path” is internally wrong: the operator-run core mail engine and system of record necessarily process conversation data. The intended subject appears to be Helpthread/Resonant IQ infrastructure, not the AGPL core.
Suggested fix: replace with “Resonant IQ/Helpthread-operated infrastructure never sits in the core mail/data path except for opt-in managed modules…”
7. MAJOR — CHARTER.md §7 appendix, lines 92 and 94; marketplace-v1.md §8/§10.13, lines 914 and 1019-1021/1125-1139
The managed-hosting appendix says the own-your-data reconciliation is “not settled,” while the later same-day appendix says it is decided; marketplace §10 says RESOLVED, but §8 and the retained §10.13 body still say “not settled here/not resolved.”
Suggested fix: make all four locations agree that charter §2 is resolved, while data-handling terms remain a pre-revenue gate.
8. MAJOR — CHARTER.md §5 Phase 3, line 66; marketplace-v1.md §10.4, lines 1051-1080
The charter promises launch-leading KB plus AI modules through the marketplace dogfood path, while the marketplace spec says KB may not fit the pipeline and deliberately leaves that charter-affecting conflict unresolved. That is not just product detail; it changes what the amended charter promises.
Suggested fix: either amend Phase 3 to match a draft-assistant-led marketplace or resolve/spec the KB artifact path now.
9. MAJOR — marketplace-v1.md §2/§3 refund handling, lines 143-146, 172-176, 311; §10 resolved block, lines 994-997
§10 says partial refunds do not terminate entitlement, but the state table and webhook mapping still say charge.refunded / refund.created → refunded without the full-refund qualifier. Implementation following §3 will terminate partial-goodwill refunds.
Suggested fix: propagate “only cumulative full refund flips to refunded” into §2 and the Stripe webhook table.
10. MAJOR — marketplace-v1.md §2 License key row, line 105; §10 provenance decision, lines 1023-1034
§10 adopts signed provenance with “licensed domain,” but §2 says nothing records the deployment/domain and “nothing can.” Those cannot both be true. Without a licensed-domain field captured at purchase/provisioning, the provenance feature is impossible.
Suggested fix: add a contractual licensed_domain field/source-of-truth, or drop “licensed domain” from provenance.
11. MINOR — marketplace-v1.md §3d/§5.3/§8/§11 vs §10.11, lines 529, 710-715, 912, 1013-1015, 1107-1115, 1163-1164
§10.11 confirms 14-day refund and 7-day grace, but earlier/later sections still say “working figure,” “exact number OPEN,” or “exact windows are counsel’s/the maintainer’s call.”
Suggested fix: replace stale OPEN wording with confirmed figures, leaving only policy drafting open.
12. MINOR — marketplace-v1.md §10 resolved “Latest”, lines 1000-1002; §2/§3b, lines 102, 142-143, 384-392
“Latest stays publish-order” is decided only in §10, but the entity and endpoint specs use “latest” without defining whether it means semver max or latest published_at. That can break lapsed entitlements and download defaults.
Suggested fix: define latest as highest published_at/publish sequence everywhere release selection is specified.
Verdict: FIX-FIRST. The exception has two load-bearing legal ambiguities, and the charter/marketplace amendments still contain contradictory resolved-vs-open language.
Checked against the GNU AGPLv3 §7/§13 text: https://www.gnu.org/licenses/agpl-3.0.html.en

1. BLOCKER — legal/module-api-exception.md § “Module API” / fork proviso, lines 34-40 and 51-57
   “Module API” is defined as interfaces “this Program’s copyright holders publish and document,” which reads as the original Helpthread copyright holders, but the fork proviso later says a modified version’s recipients get the API “as you publish and document it.” Those two rules fight; a hostile fork or copyleft plaintiff can argue fork-published APIs are not “Module API” at all.
   Suggested fix: define the Module API by the documentation shipped/published for the conveyed version, and separately define original upstream documentation if needed.
2. MAJOR / JUDGMENT — legal/module-api-exception.md § removal/fork symmetry, lines 51-61; CHARTER.md §3, line 33
   The charter says the exception “travels with every conveyed copy, so a fork keeps it,” but AGPLv3 §7 expressly lets a conveyor remove additional permissions. The exception also acknowledges removability. So the fork-symmetry proviso cannot prevent a fork from removing the exception and stranding modules; it only prevents a fork from narrowing while retaining the named exception.
   Suggested fix: stop claiming forks “keep” the exception unconditionally; state the accepted AGPL §7 removal risk, or pick a different licensing structure.
3. MAJOR — legal/module-api-exception.md § “Helpthread Module”, lines 42-49
   The anti-smuggling rule relies on “not itself a modified version of this Program,” but does not handle split works that copy core implementation into a nominal module while keeping a thin API-only integration layer. A hostile actor can argue the wrapper is the Module and the copied core-like component is merely its private implementation.
   Suggested fix: make the exclusion cover works containing, derived from, replacing, or substituting for Program implementation code, not only works that are “itself” a modified Program.
4. MAJOR / JUDGMENT — legal/module-api-exception.md § grant, lines 24-32
   The grant excludes “source code of those Helpthread Modules” from Corresponding Source, but does not explicitly exclude module object code/build artifacts, installation metadata, or bundled/minified module forms from AGPL Corresponding Source obligations. In a build-time npm bundle, that omission invites an argument that non-source module materials are still required as Corresponding Source for the combined work.
   Suggested fix: counsel should decide whether to exclude the Module and its source/object/build artifacts from Corresponding Source obligations to the maximum intended extent.
5. MINOR — legal/module-api-exception.md § safe harbors, lines 63-67
   The “safe harbors” paragraph is inside the exception text but reads like practical guidance, including a broad legal conclusion that public HTTP/webhook integrations “need no additional permission at all.” That can become operative license text or an unintended admission.
   Suggested fix: move guidance outside the legal text or mark it expressly non-operative.
6. MAJOR — CHARTER.md §2 “Own your data”, line 19
   “The core never sits in the data path” is internally wrong: the operator-run core mail engine and system of record necessarily process conversation data. The intended subject appears to be Helpthread/Resonant IQ infrastructure, not the AGPL core.
   Suggested fix: replace with “Resonant IQ/Helpthread-operated infrastructure never sits in the core mail/data path except for opt-in managed modules…”
7. MAJOR — CHARTER.md §7 appendix, lines 92 and 94; marketplace-v1.md §8/§10.13, lines 914 and 1019-1021/1125-1139
   The managed-hosting appendix says the own-your-data reconciliation is “not settled,” while the later same-day appendix says it is decided; marketplace §10 says RESOLVED, but §8 and the retained §10.13 body still say “not settled here/not resolved.”
   Suggested fix: make all four locations agree that charter §2 is resolved, while data-handling terms remain a pre-revenue gate.
8. MAJOR — CHARTER.md §5 Phase 3, line 66; marketplace-v1.md §10.4, lines 1051-1080
   The charter promises launch-leading KB plus AI modules through the marketplace dogfood path, while the marketplace spec says KB may not fit the pipeline and deliberately leaves that charter-affecting conflict unresolved. That is not just product detail; it changes what the amended charter promises.
   Suggested fix: either amend Phase 3 to match a draft-assistant-led marketplace or resolve/spec the KB artifact path now.
9. MAJOR — marketplace-v1.md §2/§3 refund handling, lines 143-146, 172-176, 311; §10 resolved block, lines 994-997
   §10 says partial refunds do not terminate entitlement, but the state table and webhook mapping still say charge.refunded / refund.created → refunded without the full-refund qualifier. Implementation following §3 will terminate partial-goodwill refunds.
   Suggested fix: propagate “only cumulative full refund flips to refunded” into §2 and the Stripe webhook table.
10. MAJOR — marketplace-v1.md §2 License key row, line 105; §10 provenance decision, lines 1023-1034
    §10 adopts signed provenance with “licensed domain,” but §2 says nothing records the deployment/domain and “nothing can.” Those cannot both be true. Without a licensed-domain field captured at purchase/provisioning, the provenance feature is impossible.
    Suggested fix: add a contractual licensed_domain field/source-of-truth, or drop “licensed domain” from provenance.
11. MINOR — marketplace-v1.md §3d/§5.3/§8/§11 vs §10.11, lines 529, 710-715, 912, 1013-1015, 1107-1115, 1163-1164
    §10.11 confirms 14-day refund and 7-day grace, but earlier/later sections still say “working figure,” “exact number OPEN,” or “exact windows are counsel’s/the maintainer’s call.”
    Suggested fix: replace stale OPEN wording with confirmed figures, leaving only policy drafting open.
12. MINOR — marketplace-v1.md §10 resolved “Latest”, lines 1000-1002; §2/§3b, lines 102, 142-143, 384-392
    “Latest stays publish-order” is decided only in §10, but the entity and endpoint specs use “latest” without defining whether it means semver max or latest published_at. That can break lapsed entitlements and download defaults.
    Suggested fix: define latest as highest published_at/publish sequence everywhere release selection is specified.
    Verdict: FIX-FIRST. The exception has two load-bearing legal ambiguities, and the charter/marketplace amendments still contain contradictory resolved-vs-open language.