Software dependencies and licence obligations

Direct dependencies

config/dependency-policy.json lists declared versions, purpose and claimed SPDX-style licence identifiers for the project's directly approved JavaScript packages. config/license-evidence.json records whether supporting evidence has actually been inspected. Do not convert declared MIT or Apache-2.0 to verified without reading the exact shipped package's licence and checking any bundled material.

MIT commonly permits commercial use, modification and redistribution subject to carrying its copyright and licence notice. Apache-2.0 commonly also requires licence and attribution notices and, when applicable, a NOTICE file and indication of changed files; it includes patent-related provisions. Follow the actual licence text of the exact version instead of relying on this summary.

Dependency closure

A direct npm .tgz or Gradle .jar may reference other packages. The entire resolved pnpm/Gradle/Composer trees must be inventoried at locked versions, including optional/native transitive components loaded into shipped artifacts. Record all licences and their notices. The source currently lacks an audited complete native lockfile/dependency closure; Android/iOS distribution is not cleared.

Build-time versus redistributed dependencies

Record whether a component is build-only, server-deployed, included in a WordPress plugin, packaged inside the Android/iOS binaries or dynamically loaded. Build-only does not make usage terms irrelevant. Publish a per-release third-party notices bundle for redistributed third-party software when required by licence terms.

Version changes

For each new or upgraded package: inspect its exact published LICENSE, NOTICE, transitive changes, platform permissions and any additional product/service terms. Update the machine-readable register and sign off before the commercial release gate. For removed packages, record removal instead of silently deleting the historical evidence.