# HyperTwist MPL Distribution Placement Checklist

Created on `2026-05-25`.

## Purpose

This file answers one narrow operational question for HyperTwist:

- where `MPL-2.0` notices, license text, and source-availability instructions
  must be placed when HyperTwist uses `MPL`-covered code from
  `cubing/cubing.js` and `coqui-ai/TTS`

This file does not replace the live-lane licensing doctrine. It is the
release-placement checklist for that doctrine.

Primary authority surfaces for this checklist are:

- [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)
- [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1)
- the official `MPL-2.0` text: <https://www.mozilla.org/en-US/MPL/2.0/>
- the official Mozilla `MPL-2.0` FAQ: <https://www.mozilla.org/en-US/MPL/2.0/FAQ/>

## One-line rule

If HyperTwist distributes a build or browser bundle containing `MPL`-covered
code, docs alone are not enough. The distributed product and its public
distribution surfaces must tell recipients:

- that `MPL`-covered code is present
- where to read the `MPL-2.0` license
- where to obtain the corresponding `MPL`-covered source

For HyperTwist, `public distribution surfaces` explicitly includes any public
website or marketplace page that sells, lists, checks out, or delivers a
downloadable build containing `MPL`-covered code, even when that website is not
itself serving `MPL`-covered browser JavaScript to the visitor.

These obligations are cumulative, not mutually exclusive. A single HyperTwist
release may need to satisfy all of the following at once:

- browser-delivered online use
- commercial product, store, checkout, or download pages
- bundled executable, installer, desktop package, or mobile package

## What HyperTwist is relying on today

For the current live lanes:

- `cubing/cubing.js`
  - HyperTwist relies on the accepted `MPL` route
  - HyperTwist does not rely on `GPL` permission for the current landed lane
  - HyperTwist must not copy `GPL`-only material into that lane without a new
    legal review
- `coqui-ai/TTS`
  - HyperTwist relies on the `MPL-2.0` code-side route for package code
  - model, voice, and payload artifacts remain separate per-artifact review
  - model or payload approval is not created by the package-code notice alone

## Current repo-state answer

For the current checked HyperTwist product state on `2026-05-25`, the answer is:

- no, the live HyperTwist product does not currently present evidence of a
  public website or browser bundle that ships `MPL`-covered `cubing/cubing.js`
  or `coqui-ai/TTS` code to end users

Why that answer is correct:

- the live product root is `UnrealHyperTwist/`, which is the current
  first-party Unreal application root, not a deployed browser app shell
- the top-level website-like folders at repo root are archive/reference storage
  rather than the active product shell
- the landed `cubing/cubing.js` packet is explicitly a first-party compiled
  contract and reference-bundle lane; it says no upstream app shell or Twizzle
  shell was landed
- the landed `rubix-cube-solver` browser/webcam shell packet is explicitly a
  first-party browser-shell profile and session-state contract; it explicitly
  excludes bundled frontend-asset redistribution
- the landed `coqui-ai/TTS` packet is explicitly a first-party advanced
  narration orchestration profile; it explicitly excludes downloadable
  voice/model shipping

So the website-specific `MPL` notice branch is not triggered today merely by
the current checked product code.

What still does apply today:

- if HyperTwist is sold or distributed as a downloadable desktop build that
  includes these lanes, the downloadable release package, in-product legal
  surface, public product page, checkout/store page, and release/download page
  still need the `MPL` notices and source-availability links described below
- if a future HyperTwist website later delivers browser code containing
  `MPL`-covered material, the website notice branch becomes active at that time

## Three HyperTwist deployment cases

This section is the operational default for future release engineering. Use it
even if the current checked repo has not yet activated every case.

### Case A. Browser-delivered online HyperTwist

This case applies if HyperTwist serves browser code to end users and that
browser code contains `MPL`-covered material or a bundle containing it.

How to include the licenses:

- maintain a public `Open Source Notices` or `Legal` page on the website
- identify `cubing/cubing.js` and `coqui-ai/TTS` package code by name on that
  page
- include the full `MPL-2.0` text there or provide a stable direct link to it
- include a stable source-availability link for the exact corresponding
  `MPL`-covered source used by the deployed browser build
- if `coqui-ai/TTS` models, voices, or payloads are also shipped to users,
  include or link their separate artifact-license disclosures on the same legal
  surface

How to present the licenses:

- place a visible `Legal`, `Licenses`, or `Open Source Notices` link in the
  website footer, account menu, or app settings
- if HyperTwist is a logged-in web app, expose the same notices from an
  in-product settings/help/about surface after login
- do not rely on a source repo alone as the only place where users can find the
  notices
- do not bury the legal surface behind an unstable or private-only URL

### Case B. Public product page, store page, checkout flow, or download page

This case applies if HyperTwist sells, licenses, lists, or distributes a build
through a public website, store, marketplace, checkout flow, release page, or
download page, even if the page itself does not serve `MPL` browser code.

How to include the licenses:

- add a stable link from the product page, pricing page, checkout page, release
  page, store page, and download page to a public `Open Source Notices` or
  `Legal` page
- that public legal page must include or link the full `MPL-2.0` text
- that public legal page must include the corresponding source-availability
  location for the exact shipped build
- if `coqui-ai/TTS` models, voices, or payloads ship with the downloadable
  build, that same public legal surface must include or link the separate
  artifact-license disclosures

How to present the licenses:

- the legal/notices link should be visible before or at the moment the user
  obtains the build
- if the marketplace allows only a single legal link, point it to the stable
  HyperTwist `Open Source Notices` page rather than scattering component links
- if HyperTwist controls the checkout confirmation page or delivery email, add
  the same legal/notices link there as well
- release notes for the shipped build should repeat the legal/notices link and
  source-availability link

### Case C. Bundled executable, installer, desktop package, or mobile package

This case applies if HyperTwist ships a native executable, installer, desktop
bundle, archive, or mobile application package containing `MPL`-covered code.

How to include the licenses:

- include `ThirdPartyNotices.txt` or an equivalent bundled notices file in the
  shipped package
- include `licenses/MPL-2.0.txt` or another bundled full copy of the
  `MPL-2.0` license text
- include a source-availability statement naming where recipients can obtain
  the exact corresponding `MPL`-covered source for that shipped build
- if HyperTwist modified any `MPL`-covered upstream files directly, publish
  those modified files under `MPL`
- if `coqui-ai/TTS` models, voices, or payloads are shipped, include separate
  artifact-level notice handling for them

How to present the licenses:

- expose an in-product `Open Source Notices`, `Licenses`, or `Legal` screen
- desktop default: `Help > About > Open Source Notices` or equivalent
- mobile default: `Settings > About > Open Source Notices` or equivalent
- keep the notices reachable after installation without requiring the user to
  locate the source repository manually
- if the installer supports a `Licenses` or `Third-Party Notices` step or file
  link, include it there too

## Scenario matrix

### 1. Internal-only use inside the organization

If HyperTwist is only used internally and is not distributed externally:

- external release-placement obligations do not activate in the same way
- keep internal compliance records anyway
- keep the doctrine note and this checklist available to release engineering

### 2. Downloadable desktop app or packaged native software

If HyperTwist is sold or distributed as a downloadable desktop product, put the
`MPL` materials in all of these places:

1. shipped artifact contents
   - `ThirdPartyNotices.txt` or equivalent
   - `licenses/MPL-2.0.txt` or another included full `MPL-2.0` text
   - a source-availability statement that tells recipients where the
     corresponding `MPL`-covered source can be obtained
2. installed app UI
   - `Open Source Notices`, `Legal`, or `About > Licenses`
3. public download or distribution page
   - link to the open-source notices
   - link to the corresponding source location
   - separate payload-license page if `coqui-ai/TTS` models or payloads are
     shipped
4. corresponding source location
   - host the exact corresponding `MPL`-covered source snapshot used by the
     release
   - if HyperTwist modified `MPL`-covered files directly, publish those
     modified files under `MPL`

### 3. Commercial website, checkout flow, store page, or direct download page

If HyperTwist is sold, licensed, or distributed through a public website,
checkout flow, store listing, marketplace page, or direct download page, and
the distributed build contains `MPL`-covered code:

1. treat those public pages as release/distribution surfaces
2. the product page, pricing page, checkout confirmation page, store listing,
   release page, or download page should expose or link all of the following:
   - an open-source notices page
   - the `MPL-2.0` license text or a stable link to it
   - the corresponding `MPL`-covered source location
3. the same rule applies even if the public website itself is only HTML,
   marketing copy, store UI, or payment flow and does not itself ship
   `MPL`-covered browser JavaScript
4. if `coqui-ai/TTS` models, voices, or payloads are shipped with the
   downloadable build, those pages or their linked legal materials must also
   point to the separate artifact-license disclosures

For HyperTwist, this is the important split:

- website sells or links a downloadable build containing `MPL` code:
  release-page obligations apply
- website serves `MPL` browser code directly:
  browser-bundle obligations also apply

### 4. Public website or SaaS with server-side code only

If the product is a hosted service and users do not receive the `MPL`-covered
code in the browser or as a download:

- server-side use alone is not the same as distributing the code to users
- a public website legal page is not required solely for that server-side use
- keep internal release records anyway

### 5. Public website that delivers client-side JavaScript or other browser code

If HyperTwist delivers browser code that includes `MPL`-covered files or a
bundle containing them:

1. the website should have a public `Legal`, `Open Source Notices`, or
   equivalent page
2. that page should identify the `MPL`-covered component
3. that page should include or link the full `MPL-2.0` text
4. that page should include a source-availability link for the corresponding
   `MPL`-covered source
5. the bundled asset or release notes should not hide the fact that the code is
   present

### 6. Source repo only, without distributed build

If HyperTwist only keeps the code in source control and does not yet distribute
it:

- preserve upstream notices
- keep the `MPL` doctrine note and this checklist
- prepare a release-ready notices surface before external shipment

## Exact HyperTwist placement checklist

Before selling or externally distributing HyperTwist in a form that includes
`MPL`-covered code, ship all of the following:

### Required release-file surfaces

- a root `ThirdPartyNotices.txt` or equivalent bundled notices file
- a bundled `licenses/MPL-2.0.txt` or another full-copy location for the
  `MPL-2.0` license text
- a source-availability statement naming where the corresponding
  `MPL`-covered source can be obtained

### Required product UI surfaces

- `Help > About > Open Source Notices`
- or another stable in-product `Legal` / `Licenses` surface that users can
  reach after installation

### Required public distribution surfaces for downloadable releases

- the public product page, pricing page, checkout page, store page, release
  page, or download page should reference the open-source notices
- those public pages should reference the `MPL-2.0` text directly or through a
  stable legal/notices page
- those public pages should reference the corresponding source location
- if `coqui-ai/TTS` models, voices, or payloads are shipped, the distribution
  materials should link to their separate artifact-license page

### Required public commercial website and marketplace surfaces

If HyperTwist is sold commercially through its own website or a marketplace,
the minimum public surfaces that should carry or link the legal materials are:

- the product overview page
- the pricing or purchase page
- the checkout or purchase confirmation page when HyperTwist controls it
- the release notes page for the shipped build
- the download page or installer-delivery page
- the marketplace or store listing where the platform allows legal links

At least one of those public surfaces should link to a stable HyperTwist
`Open Source Notices` or `Legal` page that contains:

- the `MPL-2.0` license text or a stable link to the full text
- the corresponding source-availability location for the exact shipped build
- component identification for `cubing/cubing.js` and `coqui-ai/TTS`
- separate artifact-license disclosures for any shipped `coqui-ai/TTS` models,
  voices, or payloads

### Required public distribution surfaces for browser-delivered bundles

- the website should have a public open-source notices page
- that page should expose the `MPL-2.0` license text or a stable link to it
- that page should expose the source-availability location for the
  corresponding `MPL`-covered source

## Component-specific notes

### `cubing/cubing.js`

HyperTwist should state all of the following in release materials:

- `cubing/cubing.js` is used through the accepted `MPL` route
- HyperTwist is not relying on `GPL` permission for the landed lane
- the `MPL-2.0` text is available in the shipped notices materials
- the corresponding `MPL`-covered source location is available to recipients

If HyperTwist later modifies `MPL`-covered upstream files directly, release
engineering must publish those modified files under `MPL` with the shipped
release.

### `coqui-ai/TTS`

HyperTwist should state all of the following in release materials:

- `coqui-ai/TTS` package code is used through the `MPL-2.0` code-side route
- the `MPL-2.0` text is available in the shipped notices materials
- the corresponding `MPL`-covered package-code source location is available to
  recipients
- any shipped model, voice, or payload artifact is licensed and disclosed
  separately from the package-code notice

## What the website must and must not do

If the public website is only marketing the product:

- it does not need a special `MPL` page solely because the product exists
- it is still cleaner to link to the downloadable product's legal/notices page

If the public website markets the product and also sells it or links the
download for a build containing `MPL`-covered code:

- it is no longer just a marketing-only surface
- it becomes a release/distribution surface for notice-placement purposes
- it should link to the open-source notices page
- it should link to the `MPL-2.0` text directly or through that notices page
- it should link to the corresponding source location
- if `coqui-ai/TTS` payloads are shipped, it should link to the separate
  payload or artifact-license disclosures

If the public website delivers browser code containing `MPL`-covered material:

- it should have a public legal or open-source notices page
- it should identify the component
- it should provide the `MPL-2.0` text or a stable link to it
- it should provide the corresponding source location

## Minimum safe HyperTwist release package

The minimum safe package for a distributed HyperTwist release that includes
these lanes is:

- `ThirdPartyNotices.txt`
- `licenses/MPL-2.0.txt`
- an in-product `Open Source Notices` or `Licenses` screen
- product-page, store-page, checkout-page, and release/download-page notice
  links when those surfaces sell or deliver the build
- a stable source URL for the corresponding `MPL`-covered files
- separate artifact-level notice handling for any shipped `coqui-ai/TTS`
  models, voices, or payloads

## Trigger for immediate re-review

Stop and re-review the lane immediately if any of these become true:

- HyperTwist copies `GPL`-only material into the `cubing/cubing.js` lane
- HyperTwist modifies upstream `MPL`-covered files but has no plan to publish
  those modified files on distribution
- HyperTwist ships `coqui-ai/TTS` models or payloads without separate
  artifact-level license review
- HyperTwist serves browser bundles with `MPL`-covered code but no public
  notices page or source-availability link

## Non-advice boundary

This is a HyperTwist engineering compliance checklist. It is not legal advice.
If release posture changes materially, escalate to formal counsel review.
