You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The binding native roadmap requires explicit distribution-compliance work before the future Qt desktop line can be considered release-ready. It already calls out the need to:
define LGPL relinking obligations where that path is used;
provide required notices/source offers/materials;
inventory third-party licenses;
produce an SBOM;
avoid accidentally introducing GPL-only Qt modules into an incompatible distribution model;
obtain appropriate legal review before commercial distribution.
Those requirements currently have no dedicated open issue owner.
This is broader than Qt alone. WorldScript Studio distributes or consumes a heterogeneous dependency/artifact set across:
Supply-chain provenance is partly tracked in #529, but provenance answers where an artifact came from, not whether WorldScript has the right to redistribute/use it under the intended product/distribution model.
Likewise, generating an SBOM without license-policy/admission semantics would only inventory the problem.
Goal
Establish one durable distribution-compliance contract that can answer, for every shipped component:
WHAT IS IT?
WHO OWNS / LICENSES IT?
UNDER WHAT LICENSE/NOTICE TERMS?
HOW DOES WORLDSCRIPT USE OR DISTRIBUTE IT?
WHAT OBLIGATIONS ARE TRIGGERED?
WHERE ARE THOSE OBLIGATIONS SATISFIED?
IS THE COMPONENT ADMITTED FOR THIS DISTRIBUTION SURFACE?
The contract must apply to the current PWA/Tauri distributions and be strong enough for future Qt packaging without forcing renderer-specific compliance rules.
This issue is engineering/compliance tracking, not legal advice. Where interpretation depends on legal judgment, record the question and obtain qualified review rather than having CI or an agent invent a legal conclusion.
1. Canonical third-party inventory
Create or generate a current inventory of all redistributed/runtime-relevant third-party material.
At minimum classify:
JavaScript / npm
direct production dependencies;
transitive runtime dependencies materially included in web/native bundles;
build-only tooling where licenses/notices still matter for source distribution or repository compliance;
vendored/forked JavaScript packages such as collaboration transport.
Rust / Cargo
src-tauri dependency graph;
renderer-neutral crates/ graph;
native linked libraries where Cargo metadata does not fully describe the distribution.
Native / Qt
When Qt is admitted, inventory every Qt module actually linked/packaged, including plugins and platform modules rather than assuming “Qt” is one license record.
Binary/WASM artifacts
Examples include, where actually shipped or downloaded:
DuckDB-WASM;
ONNX/WASM/WebGPU runtime artifacts;
Whisper/Kokoro/local-AI runtime assets;
native helper binaries;
installer/runtime redistributables.
Models / datasets / AI artifacts
Model licenses are not npm/Cargo licenses. For every model WorldScript bundles, mirrors, recommends, automatically downloads, or identifies in a curated manifest, record:
model/artifact
upstream source
version/revision
license
redistribution allowed?
commercial-use restrictions if any
attribution/notice requirements
derivative/quantization implications where relevant
who downloads it: WorldScript distribution vs user direct from upstream
Coordinate model lifecycle/integrity with #556/#483; this issue owns license/distribution truth only.
Assets
Audit fonts, icons, images, sample content and other embedded assets for explicit source/license provenance.
2. Machine-readable license metadata
Prefer machine-readable identifiers where licenses have standard SPDX expressions.
Required policy:
KNOWN SPDX / VERIFIED CUSTOM LICENSE
→ classify under policy
UNKNOWN / NOASSERTION / AMBIGUOUS
→ not silently accepted
→ investigate / explicitly waive with rationale if appropriate
Do not automatically convert an ambiguous upstream LICENSE file into a guessed SPDX identifier.
For dual/multi-licensed packages, record the license branch under which WorldScript actually relies on the component where that choice matters.
3. Qt licensing admission
Before substantial Qt production implementation, establish an explicit Qt module/license matrix.
For each proposed Qt module record:
Qt module/plugin
Needed capability
License path
Dynamic/static linkage
Distribution obligations
Admitted?
The architecture should default to the distribution model intentionally selected by the project; do not let CMake/qmake/package defaults accidentally choose a different compliance posture.
LGPL path
Where Qt is used under LGPL terms, document and technically preserve the applicable obligations for the chosen packaging/linkage model, including as relevant:
user ability to replace/relink the LGPL-covered library when the license requires it;
no technical restriction that unlawfully prevents permitted replacement/relinking;
required license texts/notices;
required source/source-offer or modification disclosure for LGPL-covered components if modified;
distinction between WorldScript proprietary/project code and LGPL-covered library code;
how platform packaging (AppImage, .deb, Windows installer, macOS app bundle, etc.) affects the practical replacement/relinkability path.
Do not assume “the app is free/non-commercial” eliminates LGPL/GPL obligations. Distribution obligations depend on the license and distribution method, not simply whether money is charged.
GPL-only modules
Maintain a deny/admission rule for Qt modules/components whose available license would impose obligations incompatible with the project's chosen distribution model.
A new Qt import/module must not enter production merely because it solves a UI problem technically.
If a GPL-licensed component is intentionally proposed, require an explicit distribution/license architecture decision before adoption.
Commercial Qt option
A commercial Qt license may change some obligations, but should not be assumed. If considered later, record it as a separate product/legal decision rather than silently changing the baseline contract.
4. Current Tauri/PWA distribution compliance
Do not wait for Qt to begin the inventory.
Audit current release surfaces:
GitHub Pages / PWA bundle
Vercel/Cloudflare deployment where applicable
Docker/GHCR image
Tauri Linux bundles
Tauri Windows bundles
Tauri macOS bundles
GitHub source repository/source archive
Determine which third-party license texts/notices must accompany which surfaces.
A browser bundle containing minified third-party code may have different practical notice delivery than a native installer, but neither should rely on an undocumented assumption.
5. THIRD-PARTY-NOTICES / license bundle
Create one maintainable mechanism to ship required notices/license texts with distributions that need them.
Possible architecture:
canonical machine-readable inventory
↓
generated/curated THIRD-PARTY-NOTICES
↓
web About/Legal surface where useful
native installer/app legal resources
release/source artifacts as required
Generated output must be reviewable and deterministic enough to detect meaningful changes.
Do not dump thousands of duplicate license texts into the repository without a maintenance model.
Preserve exact upstream license text when redistribution requires it.
6. SBOM relationship
Produce SBOMs at appropriate release boundaries, but keep semantics clear:
Prefer a standard machine-readable format such as SPDX or CycloneDX according to current release tooling and ecosystem support. The exact format should be selected at implementation time based on integration quality, not fashion.
For native releases, include both npm and Rust/native components that actually ship; do not publish a JavaScript-only SBOM and call the desktop artifact complete.
For Docker, reconcile image-level packages/layers where feasible with #529's container provenance work.
7. License-policy gate
Define a repository policy that classifies newly introduced licenses, for example:
Coordinate security maintenance of the y-webrtc fork with #60. Do not duplicate #60's code-security audit here; ensure its license/provenance record is present in the compliance inventory.
9. AI/model and content-license truth
WorldScript's privacy/local-AI roadmap creates a distinct licensing risk: a technically downloadable model is not automatically redistributable or commercially usable.
For every curated model path distinguish:
BUNDLED BY WORLDSCRIPT
DOWNLOADED FROM WORLDSCRIPT-CONTROLLED HOSTING
DOWNLOADED DIRECTLY FROM UPSTREAM
USER-SUPPLIED MODEL
LOCAL SERVER (OLLAMA/LM STUDIO) USER-OWNED
The UI/docs should not imply WorldScript grants rights it does not possess.
If a model is user-supplied or fetched directly from an upstream provider, display upstream license/source information where appropriate without treating it as part of WorldScript's redistributed binary.
Do not silently mirror upstream model files to WorldScript-controlled hosting without an explicit redistribution check.
Plugin authors' third-party dependencies/licenses are not automatically WorldScript's own source license obligations, but a WorldScript-operated registry still needs a policy for:
plugin license declaration;
provenance/author metadata;
prohibited/missing license state;
redistributing plugin binaries/packages through WorldScript infrastructure;
display of license information before install where appropriate.
Keep marketplace trust/install mechanics in #348 and central distribution-license policy here.
If different subcomponents intentionally use different licenses, document them explicitly rather than allowing accidental mismatch.
Do not perform a license relicensing exercise under this issue unless separately authorized and legally valid with contributor rights established.
12. Release evidence and verification
For each production release, preserve enough evidence to answer:
source SHA/tag
SBOM version/digest
third-party notice version/digest
license-policy gate result
new/changed license decisions
Qt module/license set when applicable
known waivers/review decisions
Coordinate artifact identity with #574 and provenance with #529.
Do not make license compliance dependent on a transient external SaaS result that cannot be reproduced later; preserve the canonical inventory/policy evidence in the repository or release artifacts.
13. Legal-review boundary
Some decisions cannot be made by automated tooling alone.
Escalate instead of guessing when questions include, for example:
compatibility of a proposed GPL component with the selected distribution model;
interpretation of unusual/custom/non-SPDX licenses;
redistribution rights for model weights/datasets;
trademark/patent clauses with material product implications;
commercial Qt licensing strategy;
relicensing existing project code;
country/jurisdiction-specific distribution obligations.
Record the engineering facts needed for review; do not encode an agent's legal interpretation as repository policy without maintainer approval.
Sequencing
Recommended:
NOW / PRE-QT:
current npm/Cargo/vendor/model/asset inventory
policy vocabulary
notice/SBOM prototype
↓
BEFORE QT MODULE SELECTION BECOMES STICKY:
Qt LGPL/GPL module admission matrix
linkage/distribution design
↓
BEFORE QT BETA / STABLE:
packaged notices/relinkability/source-material evidence
release SBOM
compliance gate green
This issue should not block current S5/#564 design convergence. It is a pre-Qt distribution/admission requirement, with useful current Tauri/PWA cleanup that can proceed independently.
Context
The binding native roadmap requires explicit distribution-compliance work before the future Qt desktop line can be considered release-ready. It already calls out the need to:
Those requirements currently have no dedicated open issue owner.
This is broader than Qt alone. WorldScript Studio distributes or consumes a heterogeneous dependency/artifact set across:
Supply-chain provenance is partly tracked in #529, but provenance answers where an artifact came from, not whether WorldScript has the right to redistribute/use it under the intended product/distribution model.
Likewise, generating an SBOM without license-policy/admission semantics would only inventory the problem.
Goal
Establish one durable distribution-compliance contract that can answer, for every shipped component:
The contract must apply to the current PWA/Tauri distributions and be strong enough for future Qt packaging without forcing renderer-specific compliance rules.
This issue is engineering/compliance tracking, not legal advice. Where interpretation depends on legal judgment, record the question and obtain qualified review rather than having CI or an agent invent a legal conclusion.
1. Canonical third-party inventory
Create or generate a current inventory of all redistributed/runtime-relevant third-party material.
At minimum classify:
JavaScript / npm
Rust / Cargo
src-tauridependency graph;crates/graph;Native / Qt
When Qt is admitted, inventory every Qt module actually linked/packaged, including plugins and platform modules rather than assuming “Qt” is one license record.
Binary/WASM artifacts
Examples include, where actually shipped or downloaded:
Models / datasets / AI artifacts
Model licenses are not npm/Cargo licenses. For every model WorldScript bundles, mirrors, recommends, automatically downloads, or identifies in a curated manifest, record:
Coordinate model lifecycle/integrity with #556/#483; this issue owns license/distribution truth only.
Assets
Audit fonts, icons, images, sample content and other embedded assets for explicit source/license provenance.
2. Machine-readable license metadata
Prefer machine-readable identifiers where licenses have standard SPDX expressions.
Required policy:
Do not automatically convert an ambiguous upstream
LICENSEfile into a guessed SPDX identifier.For dual/multi-licensed packages, record the license branch under which WorldScript actually relies on the component where that choice matters.
3. Qt licensing admission
Before substantial Qt production implementation, establish an explicit Qt module/license matrix.
For each proposed Qt module record:
The architecture should default to the distribution model intentionally selected by the project; do not let CMake/qmake/package defaults accidentally choose a different compliance posture.
LGPL path
Where Qt is used under LGPL terms, document and technically preserve the applicable obligations for the chosen packaging/linkage model, including as relevant:
.deb, Windows installer, macOS app bundle, etc.) affects the practical replacement/relinkability path.Do not assume “the app is free/non-commercial” eliminates LGPL/GPL obligations. Distribution obligations depend on the license and distribution method, not simply whether money is charged.
GPL-only modules
Maintain a deny/admission rule for Qt modules/components whose available license would impose obligations incompatible with the project's chosen distribution model.
A new Qt import/module must not enter production merely because it solves a UI problem technically.
If a GPL-licensed component is intentionally proposed, require an explicit distribution/license architecture decision before adoption.
Commercial Qt option
A commercial Qt license may change some obligations, but should not be assumed. If considered later, record it as a separate product/legal decision rather than silently changing the baseline contract.
4. Current Tauri/PWA distribution compliance
Do not wait for Qt to begin the inventory.
Audit current release surfaces:
Determine which third-party license texts/notices must accompany which surfaces.
A browser bundle containing minified third-party code may have different practical notice delivery than a native installer, but neither should rely on an undocumented assumption.
5. THIRD-PARTY-NOTICES / license bundle
Create one maintainable mechanism to ship required notices/license texts with distributions that need them.
Possible architecture:
Generated output must be reviewable and deterministic enough to detect meaningful changes.
Do not dump thousands of duplicate license texts into the repository without a maintenance model.
Preserve exact upstream license text when redistribution requires it.
6. SBOM relationship
Produce SBOMs at appropriate release boundaries, but keep semantics clear:
These complement one another.
Prefer a standard machine-readable format such as SPDX or CycloneDX according to current release tooling and ecosystem support. The exact format should be selected at implementation time based on integration quality, not fashion.
For native releases, include both npm and Rust/native components that actually ship; do not publish a JavaScript-only SBOM and call the desktop artifact complete.
For Docker, reconcile image-level packages/layers where feasible with #529's container provenance work.
7. License-policy gate
Define a repository policy that classifies newly introduced licenses, for example:
The actual allow/deny matrix must be reviewed deliberately.
Automate drift detection where sound:
The gate should block on unknown/new policy decisions, not pretend a scanner can resolve legal ambiguity automatically.
8. Vendored/forked code
Vendored code deserves stronger tracking because ordinary dependency metadata no longer updates automatically.
At minimum for each fork/vendor record:
Coordinate security maintenance of the y-webrtc fork with #60. Do not duplicate #60's code-security audit here; ensure its license/provenance record is present in the compliance inventory.
9. AI/model and content-license truth
WorldScript's privacy/local-AI roadmap creates a distinct licensing risk: a technically downloadable model is not automatically redistributable or commercially usable.
For every curated model path distinguish:
The UI/docs should not imply WorldScript grants rights it does not possess.
If a model is user-supplied or fetched directly from an upstream provider, display upstream license/source information where appropriate without treating it as part of WorldScript's redistributed binary.
Do not silently mirror upstream model files to WorldScript-controlled hosting without an explicit redistribution check.
10. Plugin ecosystem relationship
#348 owns future end-user plugin install/marketplace admission.
Plugin authors' third-party dependencies/licenses are not automatically WorldScript's own source license obligations, but a WorldScript-operated registry still needs a policy for:
Keep marketplace trust/install mechanics in #348 and central distribution-license policy here.
11. Source-code license / contribution consistency
Verify repository-owned license metadata remains internally consistent across:
LICENSE;package.json;If different subcomponents intentionally use different licenses, document them explicitly rather than allowing accidental mismatch.
Do not perform a license relicensing exercise under this issue unless separately authorized and legally valid with contributor rights established.
12. Release evidence and verification
For each production release, preserve enough evidence to answer:
Coordinate artifact identity with #574 and provenance with #529.
Do not make license compliance dependent on a transient external SaaS result that cannot be reproduced later; preserve the canonical inventory/policy evidence in the repository or release artifacts.
13. Legal-review boundary
Some decisions cannot be made by automated tooling alone.
Escalate instead of guessing when questions include, for example:
Record the engineering facts needed for review; do not encode an agent's legal interpretation as repository policy without maintainer approval.
Sequencing
Recommended:
This issue should not block current S5/#564 design convergence. It is a pre-Qt distribution/admission requirement, with useful current Tauri/PWA cleanup that can proceed independently.
Relationships
Acceptance criteria
Non-goals