| name | oss-license-governance |
| description | Use when changing Apache-2.0 licensing, SPDX/REUSE coverage, package license metadata, or third-party notice generation across consent-protocol and hushh-research. |
Hussh OSS License Governance Skill
Purpose and Trigger
- Primary scope:
oss-license-governance-intake
- Trigger on Apache-2.0 transition work,
LICENSE or NOTICE updates, SPDX/REUSE coverage, package license metadata changes, or third-party notice inventory generation.
- Avoid overlap with
docs-governance, repo-operations, and backend.
Coverage and Ownership
- Role:
owner
- Owner family:
oss-license-governance
Owned repo surfaces:
LICENSE
LICENSES
NOTICE
REUSE.toml
THIRD_PARTY_NOTICES.md
consent-protocol/LICENSE
consent-protocol/NOTICE
consent-protocol/THIRD_PARTY_NOTICES.md
scripts/licenses
.codex/skills/oss-license-governance
Non-owned surfaces:
docs-governance
repo-operations
backend
frontend
subtree-upstream-governance
Do Use
- Apache-2.0 license-surface changes across root and subtree.
- SPDX/REUSE coverage and notice-generation policy.
- Package-manifest license cleanup for first-party published packages.
- Third-party notice inventory generation and verification.
Do Not Use
- Generic docs-home placement work.
- CI/deploy operations work unless the issue is license-gate specific.
- Broad backend or frontend implementation that only incidentally touches licensed files.
Read First
LICENSE
NOTICE
REUSE.toml
consent-protocol/pyproject.toml
hushh-webapp/package.json
packages/hushh-mcp/package.json
Workflow
- Keep Apache-2.0 as the first-party default across root and subtree unless an explicit exception is documented.
- Keep
NOTICE, REUSE coverage, and third-party inventories aligned in the same change.
- Treat package-manifest license drift as a release blocker for public packages.
- Generate notice artifacts from real lockfiles and dependency metadata rather than hand-editing lists.
- Run a second verification pass after editing the license surface.
- For root plus subtree licensing changes, run a third check from the canonical repo entrypoint before closing the work.
Handoff Rules
- If the task is broader repo governance, use
repo-operations.
- If the task is documentation-home governance, use
docs-governance.
- If the task is subtree routing or optional-mirror sync policy, use
subtree-upstream-governance.
- If the task is package-runtime behavior beyond the license surface, use
backend or frontend.
Required Checks
python3 scripts/licenses/verify_apache_surface.py
python3 scripts/licenses/generate_third_party_notices.py
./bin/hushh docs verify