Third-party code and attribution notices

Two different questions arrive from legal review under this heading, and they have different answers: what third-party material is embedded in TOVIO, and what dependencies does a build pull in.

Embedded third-party material

Material vendored into the source tree — code or data that travels inside TOVIO rather than being pulled from a package registry — is recorded in THIRD-PARTY-NOTICES.md at the repository root, with the full licence text reproduced. Those notices travel with both source and binary distributions, which is what the upstream licences require.

The list is short today. The one entry is the default ruleset behind the secret scanner: an MIT-licensed detection ruleset, vendored verbatim at a pinned upstream commit, from which the scanner's embedded rules are generated at build time. The notice records the project, the exact commit, and the licence text.

One quirk worth knowing before a scanner flags it during your own review: the vendored ruleset contains example tokens inside some rules' allowlist filters — a sample API-key literal, for instance. Those are the upstream project's own non-secret test values, shipped verbatim under its licence. They are documented in the notice rather than stripped, because altering a vendored file is worse than explaining it.

Dependency licences

Ordinary build dependencies are not vendored, so they are not in that file. Each release generates an SPDX 2.3 software bill of materials alongside its binaries, with SHA-256 sidecars, signed by a keyless attestation service. The bill of materials, not a hand-maintained list, is the artifact to hand a licence-scanning tool.

TOVIO's own per-component licences

Every package declares its own SPDX identifier in its own manifest — Apache-2.0 for the engine, CLI, bindings, SDKs, plugin SDK, and the runner-neutral CI job contract, and LicenseRef-TOVIO-Commercial for the Forge crates, the CI platform, and the authentication stack. A scanner reads the split correctly without anyone interpreting a prose document for it.

The rule that keeps the artifacts clean

None of the commercial code is included in any Apache-licensed package, container, software bill of materials, or release artifact. Releases build named public packages rather than a whole workspace, and the commercial code lives in a separate build workspace excluded from the public one, with packaging and artifact guards that fail closed if any private marker reaches a release definition.

The practical consequence for a licence review: if a file is in the Apache-2.0 release artifact, it is Apache-2.0. You do not have to reason about mixed content inside a single distribution.

What to ask for

If your process needs a dependency licence inventory for a specific build, ask for that build's bill of materials rather than reading the manifests — it is generated from the exact locked dependency set that produced the binary, which a manual reading cannot guarantee.