diff --git a/docs/REPO_LICENSE_TRACKING.md b/docs/REPO_LICENSE_TRACKING.md index 7afc041..39ee2ac 100644 --- a/docs/REPO_LICENSE_TRACKING.md +++ b/docs/REPO_LICENSE_TRACKING.md @@ -199,6 +199,8 @@ This file now also preserves the current truth that future models must not lose: - permissive live lanes: `23` - boundary-sensitive live lanes: `6` - restrictive live lanes: `5` +- the dedicated current doctrine note for `MPL`-side non-`GPL` usage is: + - [HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md](C:/HyperTwist/docs/ops/HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md:1) The twenty-three permissive live lanes are: diff --git a/docs/ops/HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md b/docs/ops/HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md index c522102..cde4b7b 100644 --- a/docs/ops/HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md +++ b/docs/ops/HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md @@ -39,6 +39,8 @@ Current verified product-side reality is: - the landed `coqui-ai/TTS` code-side slice is not a clean-room lane by current doctrine; model and payload review remains separate from the package code license +- the dedicated current doctrine note for `MPL`-side non-`GPL` usage is: + - [HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md](C:/HyperTwist/docs/ops/HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md:1) - the closed `0R-E` packet still retains these non-live benchmark, oracle, or clean-room-later rows: - `cs0x7f/cstimer` diff --git a/docs/ops/HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md b/docs/ops/HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md new file mode 100644 index 0000000..4f72d51 --- /dev/null +++ b/docs/ops/HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md @@ -0,0 +1,242 @@ +# HyperTwist MPL Boundary And Non-GPL Usage Doctrine + +Created on `2026-05-25`. + +## Status + +This is an active HyperTwist doctrine note. + +It exists to remove recurring ambiguity about the current live HyperTwist use +of: + +- `cubing/cubing.js` +- `coqui-ai/TTS` + +It is meant to answer, in one place: + +- whether those rows currently require clean-room implementation +- whether HyperTwist is intentionally relying on any `GPL` grant for the + current landed lanes +- what the current operational obligations are if HyperTwist distributes + product builds using `MPL`-covered code +- what facts would force a legal or architectural re-review + +## Canonical inventory surfaces + +The full current `75`-row repo inventory remains: + +- [repo_portfolio_unified_copyleft_strategy_matrix_v6_3.csv](C:/HyperTwist/docs/repo_portfolio_unified_copyleft_strategy_matrix_v6_3.csv:1) + +The current HyperTwist live-lane rollups remain: + +- [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1) +- [ROADMAP.md](C:/HyperTwist/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md:1) +- [HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md](C:/HyperTwist/docs/ops/HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md:1) + +This note does not replace those files. It clarifies the `MPL` route that +those files already authorize. + +## Non-advice boundary + +This file is a HyperTwist engineering and compliance doctrine note. + +It is not outside-counsel legal advice, and it cannot promise that no one will +ever threaten or file a legal claim. + +What it can do is state the current documented HyperTwist position: + +- which license path HyperTwist is intentionally relying on +- which obligations HyperTwist must satisfy for that path +- which actions HyperTwist must avoid if it wants to stay on that path + +## Hard yes/no answers + +### `cubing/cubing.js` + +- current HyperTwist route: `MPL`-side dependency / adapter / library route +- current clean-room requirement: `no` +- current reliance on `GPL` permission: `no` +- current doctrine position: + - HyperTwist uses the dual-licensed row through the `MPL` path + - HyperTwist does not need to reclassify this row as a restrictive + clean-room lane under the current implementation route + - HyperTwist must not copy `GPL`-only material into this lane if it wants to + preserve that position + +### `coqui-ai/TTS` + +- current HyperTwist route: `MPL-2.0` code-side bounded donor / sidecar route +- current clean-room requirement: `no` +- current reliance on `GPL` permission: `no` +- current doctrine position: + - the package code is used under the `MPL-2.0` code posture + - the model and payload side is a separate review surface + - the separate payload review requirement is not a clean-room requirement for + the package code + +## What "MPL side" means + +### For `cubing/cubing.js` + +`MPL side` does not mean there is a separate physical directory called +`mpl/`. + +It means HyperTwist is relying on the dual-license grant for the same +upstream-covered source files under `MPL-2.0`, rather than choosing the `GPL` +grant for those files. + +For the current HyperTwist landed route: + +- the practical path is the `MPL` side +- no upstream `cubing.js` source files were modified in the landed packet +- HyperTwist does not need `GPL` permission for the current landed adapter lane +- HyperTwist must preserve notices and comply with `MPL` obligations for any + `MPL`-covered files it distributes + +Important nuance: + +- the `cubing` package README states that all original code in the project is + dual-licensed as both `GPL` and `MPL` +- the same README also states that the codebase contains additional vendored + code under `Apache`, `MIT`, and `Ubuntu Font` licenses +- for library use, the published package guidance says users can effectively + treat `cubing.js` as `MPL`-licensed + +That means the current HyperTwist doctrine is: + +- rely on the `MPL` grant for the dual-licensed original code +- preserve any separate notice obligations for vendored `Apache`, `MIT`, or + font material +- do not import `GPL`-only material from some other source and then pretend the + whole resulting lane is still purely `MPL` + +### For `coqui-ai/TTS` + +`MPL side` means the package code itself. + +It does not automatically include: + +- downloaded model weights +- bundled voice payloads +- third-party datasets +- model registries whose entries have their own licenses or `tos_required` + constraints + +For the current HyperTwist landed route: + +- the code-side lane is under `MPL-2.0` +- the model and payload side remains separately reviewed +- HyperTwist must not treat the package-code license as blanket permission to + ship every model listed in the upstream registry + +## Distribution obligations for `MPL`-covered code + +If HyperTwist keeps an `MPL`-using build entirely inside the organization and +does not distribute it outside the organization, Mozilla's `MPL 2.0 FAQ` +treats that as private distribution. Under that fact pattern, the external +distribution obligations discussed below do not activate. + +If HyperTwist distributes product builds outside the organization and those +builds contain or are built from `MPL`-covered code, the safe HyperTwist +operational posture is: + +1. Preserve copyright and license notices in the `MPL`-covered files. +2. Include the `MPL 2.0` license text in the distribution or in a clearly + referenced third-party notices surface. +3. Inform recipients where the source for the `MPL`-covered code can be + obtained. +4. If HyperTwist modified any `MPL`-covered file, make the modified source for + that file available under the `MPL`. +5. Keep first-party files that contain no copied `MPL` code separate, so the + file-level `MPL` copyleft does not spread unnecessarily. +6. Preserve third-party notices for non-`MPL` vendored materials that come with + their own notice requirements. +7. For `coqui-ai/TTS`, separately review each model or payload before shipping + or auto-downloading it. + +## What HyperTwist does not need to do under the current route + +Under the current documented route, HyperTwist does not need to: + +- clean-room `cubing/cubing.js` +- clean-room `coqui-ai/TTS` +- publish unrelated first-party HyperTwist source files merely because they are + distributed in the same product as `MPL`-covered files +- adopt the `GPL` for HyperTwist as a whole merely because `cubing/cubing.js` + is dual-licensed + +## What would force re-review + +Future instances must reopen legal and architecture review if any of the +following becomes true: + +1. HyperTwist copies `GPL`-only material into the `cubing/cubing.js` lane. +2. HyperTwist directly modifies upstream `cubing.js` source files and then + fails to publish those modified files under the `MPL` route it selected. +3. HyperTwist removes copyright or permission notices from `MPL`-covered code. +4. HyperTwist distributes `MPL`-covered executables or libraries without + telling recipients where the corresponding `MPL`-covered source can be + obtained. +5. HyperTwist ships `coqui-ai/TTS` model weights or voice payloads without a + per-payload license and terms review. +6. HyperTwist widens either row beyond the currently accepted bounded packet + family without a fresh packet-level review. + +## Current landed fact pattern + +### `cubing/cubing.js` + +Current accepted landed fact pattern: + +- `Phase 4R-A` is closed +- `cubing/cubing.js` is live as a first-party classic-cubing semantic/runtime + adapter lane +- no upstream `cubing.js` source files were modified in that landed packet +- HyperTwist currently treats the row as a boundary-sensitive `MPL`-side lane, + not as a restrictive clean-room lane + +### `coqui-ai/TTS` + +Current accepted landed fact pattern: + +- the first bounded advanced narration slice is landed +- the landed row is still bounded to orchestration and service-health style + surfaces +- broad voice output, downloadable model shipping, and payload review remain + separate questions +- the current landed code-side slice is not a clean-room lane + +## Current operational rule + +Unless a future packet explicitly changes the route, HyperTwist should operate +under the following assumptions: + +- `cubing/cubing.js`: + - `MPL` route + - no current `GPL` reliance + - no current clean-room requirement +- `coqui-ai/TTS`: + - `MPL` code route + - separate payload review + - no current clean-room requirement + +If a future operator wants a stricter first-party-only or clean-room-only +policy, that is a policy escalation beyond the current doctrine. It is not a +correction of current documented truth. + +## External source anchors + +Official or upstream-facing references used for this clarification: + +- Mozilla `MPL 2.0 FAQ`: + - https://www.mozilla.org/en-US/MPL/2.0/FAQ/ +- Mozilla `MPL 2.0` license text: + - https://www.mozilla.org/en-US/MPL/2.0/ +- Mozilla `MPL in GPL` developer guidance: + - https://www.mozilla.org/en-US/MPL/2.0/combining-mpl-and-gpl/ +- `cubing` package page and published license explanation: + - https://www.npmjs.com/package/cubing +- `coqui-ai/TTS` repository: + - https://github.com/coqui-ai/TTS +- `coqui-ai/TTS` model registry: + - https://github.com/coqui-ai/TTS/blob/dev/TTS/.models.json diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md b/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md index bf3fc4f..19d9123 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md @@ -207,6 +207,8 @@ Donor-strength rule: - boundary-sensitive live lanes are implementation-authorized without clean-room by default; they land only through bounded dependency, subtree, allowlist, package-split, or adapter routes - `cubing/cubing.js` is live through the accepted `MPL`-side adapter/dependency route, not through a restrictive clean-room route - `coqui-ai/TTS` is live as a bounded `MPL` code-side lane, while model and payload review remains separate from the code-license judgment; that separation is not a clean-room requirement for the package code +- the dedicated current doctrine note for this route is: + - [HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md](C:/HyperTwist/docs/ops/HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md:1) - `Phase 0R` is now closed for the remaining `47` non-live rows - `Phase 1R` is now closed as the retained-set contract and handoff overhaul - `Phase 2R` is now closed as the retained-set ownership and acceptance packet sequence