Check Licensing

Check Licensing

Paths. analysis-results/… and progress-tracker/… in this skill are the default workspace layout. They resolve through locations.yaml in $TRAUST_CONFIG_HOME (docs/setup.md, Storage locations); substitute your configured roots.

The licensing gate for the harness's own tree. Two jobs:

1. Guard — verify nothing in the repo re-imports restrictively-licensed framework content. Deterministic, zero-judgment, enforced on every push.
2. Intake — when the harness adopts a new external tool, framework, data feed, or rule pack, drive the verification-and-documentation checklist so docs/external-dependencies.md stays the single source of truth.

Background for both: docs/external-dependencies.md (the verified license inventory and commercialization assessment).

Job 1 — run the guard

python3 -m traust.cli check content-licenses

Exit 0 = clean. Exit 1 prints each violation with file:line. The three violation classes:

How to fix: remove or rewrite the flagged text — never edit the guard's patterns to make it pass. The rationale for each rule is in docs/external-dependencies.md → Security frameworks & content licenses. If a legitimately-licensing-focused doc needs to name a license, that is what the guard's ALLOWLIST is for — extending it is a deliberate, reviewed act, not a fix for a violation.

Enforcement points (all must stay wired; verify when touching them):

• .githooks/pre-push runs the guard on every push, independently of the doc-consistency checker. git config core.hooksPath .githooks enables it per clone.
• tests/test_check_content_licenses.py runs the guard against the live tree in every test run.
• This skill runs it on demand.

Job 2 — license intake for a new external dependency

Gate-enforced for Python packages since v0.73.2: adding a dependency to pyproject.toml without its docs/external-dependencies.md row fails the guard (and therefore the push) — the intake below stops being optional at exactly the moment it used to get forgotten (the sigstore retroactive intake is the cautionary example). CLI tools, data feeds, and frameworks remain convention-enforced; add their rows with the same rigor.

When a skill or script gains a new tool, framework, data feed, or rule pack:

1. Verify upstream, never from memory — read the actual LICENSE file or terms page; record the SPDX ID (or terms name) and the evidence URL.
2. Classify the usage model, because obligations differ: subprocess CLI (weakest obligations) < imported library < referenced content (framework text, rule packs — binds hardest and is where every commercialization blocker so far has lived).
3. Add the row to the matching table in docs/external-dependencies.md (tools / Python / MCP / data feeds / frameworks), with the licensing note; a risk tier of Medium or above is recorded in the deployment's commercialization assessment (progress-tracker).
4. Install note — add the tool to config/external-tools.yaml (pin + consumers) and to the capability row in docs/requirements.md if users must install it.
5. Pin for reproducibility — version (and data/DB or ruleset SHA) must be recordable in metadata.tools by the consuming skill.
6. Extend the guard when a new protected content class enters — new fingerprint phrases or text signatures go into python3 -m traust.cli check content-licenses's pattern lists, with matching fixture tests.
7. Re-run Job 1 plus python3 -m traust.cli check docs-consistency (the new row's paths and any count claims must resolve).

Job 3 — retirement review (quarterly)

Intake has a gate; exit needs one too, or the tool list only ever grows. Once a quarter (or when asked "do we have too many tools"), review the CLI-tools table in docs/external-dependencies.md for retirement candidates:

1. Usage evidence, two sources per tool. (a) Is it still invoked by any script/skill? — grep -rl '<tool>' scripts/ harnessing/ (the /check-harness-docs gate guarantees invoked tools have rows, but nothing removes rows when the last invocation goes). (b) Did it actually run this quarter? — search recent report metadata.tools entries across the findings trees: grep -rl '"<tool>' ../analysis-results/findings --include='*-security-audit.json' | head.
2. Classify each zero-use tool: dormant-but-wired (invocable, no recent runs — usually fine: seasonal skills like provisioning), fallback shadowed by a better default (e.g. second/third LoC counter never selected), or orphaned (no invocation site remains — retire now).
3. Retire deliberately, not silently: remove the invocation site (if any), the docs/external-dependencies.md row, the manifest entry in config/external-tools.yaml, and the docs/requirements.md mention in one commit whose message names the replacement or the reason; note the retirement in the Maintenance section of docs/external-dependencies.md so the license history stays reconstructable.
4. Overlap check while you're there: any two tools claiming the same detection role must have a documented decision rule (the govulncheck/osv-scanner and opengrep/k8s-scanner precedents) — if the rule is missing, either write it or retire the weaker tool.

The review's deliverable is a short verdict per flagged tool (keep / retire / consolidate), not a mass deletion.

Constraints

• The guard detects re-importation of known text shapes, not novel paraphrases — derivative-work judgment on new prose stays with counsel (flagged items in docs/external-dependencies.md).
• Never vendor an externally-licensed rule pack or framework text into the repo; swappable-input patterns (run_opengrep.py --rules) exist so that never becomes necessary.