scriptoriumadmin/hypertwist
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add MPL non-GPL usage doctrine

Browse source
This commit is contained in:
axiomlogicnexus 2026-05-25 02:32:06 +02:00
parent bd6d525b3d
commit 574ecb49b1
4 changed files with 248 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/REPO_LICENSE_TRACKING.md
View file

@ -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:

2
docs/ops/HYPERTWIST_IMPLEMENTATION_PHASE_1_KICKOFF.md
View file

@ -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`

242
docs/ops/HYPERTWIST_MPL_BOUNDARY_AND_NON_GPL_USAGE_DOCTRINE_2026-05-25.md Normal file
View file

@ -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

2
docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md
View file

@ -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