# 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)
- [HYPERTWIST_MPL_DISTRIBUTION_PLACEMENT_CHECKLIST_2026-05-25.md](C:/HyperTwist/docs/ops/HYPERTWIST_MPL_DISTRIBUTION_PLACEMENT_CHECKLIST_2026-05-25.md:1)

This note does not replace those files. It clarifies the `MPL` route that
those files already authorize.

For exact release-placement instructions, use the dedicated checklist:

- [HYPERTWIST_MPL_DISTRIBUTION_PLACEMENT_CHECKLIST_2026-05-25.md](C:/HyperTwist/docs/ops/HYPERTWIST_MPL_DISTRIBUTION_PLACEMENT_CHECKLIST_2026-05-25.md:1)

## 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.
   - if HyperTwist sells or delivers the build through a public website, store,
     checkout flow, release page, or download page, those public surfaces must
     also point recipients to the notices and source-availability materials
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
