semaphore-third-party-licenses
Automates the creation and audit of license attributions for the Semaphore UI repository.
Install
mkdir -p .claude/skills/semaphore-third-party-licenses && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12447" && unzip -o skill.zip -d .claude/skills/semaphore-third-party-licenses && rm skill.zipInstalls to .claude/skills/semaphore-third-party-licenses
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Generate or update the THIRD-PARTY-LICENSES.md file for the Semaphore UI repository. Use this skill whenever the user asks to create, update, regenerate, audit, or refresh third-party license attributions, OSS notices, SBOM-style license inventories, or NOTICE files for Semaphore UI. Trigger on phrases like "third-party licenses", "OSS notices", "license attribution file", "SBOM for licenses", "NOTICE file", "audit dependencies", "licenses for go.mod / package.json", or any request that mentions compliance with customer agreements requiring an OSS components list. Also trigger when the user says "we added a new dependency, regenerate licenses". This skill knows the Semaphore UI layout (Go backend + Vue.js frontend), the project's license policy (allowlist/denylist), and the canonical output format.Key capabilities
- →Generate or update the THIRD-PARTY-LICENSES.md file.
- →Collect raw license data for Go backend and Vue.js frontend.
- →Run a policy check against detected licenses.
- →Generate markdown output using a specified template.
- →Sort entries alphabetically within each section.
- →Group licenses by component category (Go backend / npm frontend).
How it works
The skill collects raw license data from Go and npm dependencies, runs a policy check against allowed licenses, and then generates a markdown file with sorted and grouped license information.
Inputs & outputs
When to use semaphore-third-party-licenses
- →Regenerate license file
- →Audit third-party dependencies
- →Create OSS notice file
About this skill
Semaphore UI — Third-Party License Generator
This skill produces THIRD-PARTY-LICENSES.md for the Semaphore UI repository. The file lists every open-source
dependency shipped with Semaphore UI by name, version, license, and source URL, grouped by component. It
exists to satisfy contractual obligations toward customers (identification of OSS components by name, version,
and license type) and to preserve attribution required by permissive licenses (MIT/BSD/Apache-2.0).
Repository layout you can expect
Semaphore UI is a self-hosted product. The repository ships:
- Go backend — module file at
go.mod, source underpkg/,services/,db/, etc. - Vue.js frontend —
web/package.json(orweb2/package.jsonin some branches), built into static assets and embedded in the Go binary.
External CLI tools (Ansible, Terraform, OpenTofu, Pulumi, Bash) are invoked at runtime as separate operating-system
processes. They are NOT linked into the binary and NOT redistributed with Semaphore UI, so they are intentionally
not listed in THIRD-PARTY-LICENSES.md — their license terms apply to the user who installs them on the host,
not to Semaphore UI's distribution. The license policy still discusses why this is contractually safe (see
references/license_policy.md, "Subprocess exception").
If the layout differs (monorepo restructure, new submodule, etc.), inspect the repo first with
find . -name "go.mod" -o -name "package.json" -not -path "*/node_modules/*" and adapt.
Workflow
Follow these steps in order. Don't skip the policy check — it's the part that actually protects the project from accidentally shipping a GPL'd dependency.
1. Confirm scope with the user
Before generating anything, ask (briefly) which targets to include if it's not obvious from context:
- Backend only? Frontend only? Both?
- Production dependencies only, or also dev dependencies?
Default: both backend and frontend, production-only (dev dependencies are not distributed to customers and don't need attribution). Override only if the user explicitly asks for dev deps too.
2. Collect raw license data
Run scripts/collect_licenses.sh from the repo root. It does the following:
- Sets
GOWORK=offand runsgo-licenses report ./... --template scripts/go_template.tplfor the Go backend, so workspace siblings (e.g.pro_impl) are not pulled in. - Rolls sub-package rows up to their parent module (uses
go list -m allfor the module → version map) and drops any module path that belongs to the root module's namespace (first-party packages, includingreplace … => ./protargets). - Applies a small
OVERRIDEStable in the script for modules wherego-licensescan't auto-detect a license (e.g.modernc.org/mathutil→ BSD-3-Clause). Extend the table when new "Unknown" entries appear. - Runs
license-checker --production --json --excludePrivatePackagesin the frontend directory and strips the low-confidence*suffix from license strings soMIT*collapses intoMIT. - Writes raw output to
.licenses-cache/go.tsvand.licenses-cache/npm.json.
If the tools aren't installed, the script prints the install commands. Don't try to install them silently — show the user what needs to be added so they can decide whether to add them to CI.
3. Run the policy check
Run scripts/check_policy.py .licenses-cache/. This compares every detected license against the project policy in
references/license_policy.md:
- Allowed (green): MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Zlib, Unlicense, CC0-1.0, MPL-2.0 — proceed.
- Review (yellow): LGPL-2.1, LGPL-3.0, EPL-2.0, CDDL-1.0, custom/unknown — pause and ask the user. LGPL is fine for dynamic linking but Go statically links, so flag it for review.
- Forbidden (red): GPL-2.0, GPL-3.0, AGPL-3.0, SSPL-1.0, BUSL-1.1, Commons Clause, "non-commercial" clauses — STOP. Do not proceed with file generation. Report the offending package and ask the user how to handle it (replace, vendor, or accept and document the consequence).
This step is non-negotiable. A forbidden license slipping into THIRD-PARTY-LICENSES.md isn't just a documentation
problem — it's a contract breach with every customer. If check_policy.py returns a non-zero exit code, surface the
failures prominently and stop.
4. Generate the markdown
Run scripts/generate_md.py .licenses-cache/ > THIRD-PARTY-LICENSES.md. This produces the file using the structure
described in references/template.md. Key points the generator handles:
- Sorts entries alphabetically within each section.
- Groups by component category (Go backend / npm frontend).
- Deduplicates packages that appear at multiple versions (lists all versions on one line).
- Renders a summary table at the top with license counts.
- Adds a generation timestamp and a note pointing to
scripts/collect_licenses.shso the file is reproducible.
5. Verify and commit
After generation:
- Diff against the previous
THIRD-PARTY-LICENSES.md(if it exists). New rows = new dependencies — confirm with the user that they're expected. - Verify the file isn't truncated and ends with the closing footer (
<!-- end of generated file -->). - Suggest the commit message:
chore(licenses): regenerate THIRD-PARTY-LICENSES.md for vX.Y.Z. - If a CI pipeline exists (
.github/workflows/), suggest adding a job that runsscripts/check_policy.pyon every PR — that's how the project prevents regressions, not by re-checking manually each release.
Notes on edge cases
Vendored dependencies. If the repo has a vendor/ directory, go-licenses will read from it. That's fine —
vendored code still ships and still needs attribution.
Dual-licensed packages. Some packages are offered under "MIT OR Apache-2.0". Pick MIT (the simpler one) and note the
choice in the entry: License: MIT (also available under Apache-2.0).
Packages with no detectable license. go-licenses flags these as "Unknown". Don't ship the file with Unknowns —
manually inspect the repo, fill in the SPDX identifier, and if there's truly no license, treat the package as
forbidden (no license = "all rights reserved", which is incompatible with redistribution).
Ansible / Terraform / OpenTofu / Pulumi / Bash. Do NOT list them in THIRD-PARTY-LICENSES.md. They are invoked
as separate OS processes (os/exec), not linked, not redistributed. Their licenses bind the user who installs them
on the host, not Semaphore UI's distribution. Listing them would imply otherwise and is an unnecessary signal to a
reviewing customer's legal team. The "Subprocess exception" section in references/license_policy.md explains the
reasoning if a reviewer asks.
First-party packages with no LICENSE. The root module and any replace … => ./<dir> target (e.g. ./pro) live
inside this repo and don't need to be self-attributed. The collection script filters them out by the root module
prefix from go.mod. If you see "Unknown license" rows for github.com/<this-org>/<this-repo>/…, the filter is
working correctly — those rows shouldn't appear in the final cache.
Embedded license texts. For packages under MIT/BSD/ISC, the license requires preserving the copyright notice. The generator embeds the full LICENSE file text from each package's source. For Apache-2.0 packages, it embeds the NOTICE file if one exists.
What this skill does NOT do
- It does not generate a CycloneDX or SPDX SBOM. If the user wants a machine-readable SBOM (for compliance scanners,
customer attestations, etc.), point them at
syft packages dir:. -o cyclonedx-jsonas a separate step. THIRD-PARTY-LICENSES.md is the human-readable artifact. - It does not check for CVEs. That's a security concern, not a licensing one — use
govulncheckandnpm auditfor that. - It does not modify go.mod or package.json. The skill is read-only with respect to the dependency manifests; it only generates the attribution document.
See references/license_policy.md for the full policy and references/template.md for the output format.
When not to use it
- →When the user wants to generate a CycloneDX or SPDX SBOM.
- →When the user needs to check for CVEs.
- →When the user wants to modify go.mod or package.json.
Limitations
- →The skill does not generate a CycloneDX or SPDX SBOM.
- →The skill does not check for CVEs.
- →The skill does not modify go.mod or package.json.
How it compares
This skill provides a structured workflow for generating a `THIRD-PARTY-LICENSES.md` file, including a policy check for license compliance and specific handling for Go and Vue.js dependencies, unlike a generic license scanning tool.
Compared to similar skills
semaphore-third-party-licenses side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| semaphore-third-party-licenses (this skill) | 0 | 2mo | Review | Intermediate |
| supabase-debug-bundle | 1 | 26d | Caution | Beginner |
| hiddenroom-supabase | 0 | 1mo | No flags | Intermediate |
| backend-security-coder | 24 | 4mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
supabase-debug-bundle
jeremylongshore
Execute collect Supabase debug evidence for support tickets and troubleshooting. Use when encountering persistent issues, preparing support tickets, or collecting diagnostic information for Supabase problems. Trigger with phrases like "supabase debug", "supabase support bundle", "collect supabase logs", "supabase diagnostic".
hiddenroom-supabase
cuvo1903-ctrl
Hidden Room Supabase backend skill for migrations, generated database types, Edge Functions, RLS policies, auth/profile sync, storage buckets, Stripe integration, cloud_jobs, and database documentation. Use when editing supabase/migrations, supabase/functions, database.types.ts, or Supabase-backed f
backend-security-coder
sickn33
Expert in secure backend coding practices specializing in input validation, authentication, and API security. Use PROACTIVELY for backend security implementations or security code reviews.
custom-workers
ruvnet
Create and run custom background analysis workers with composable phases. Use when you need automated code analysis, security scanning, pattern learning, or API documentation generation.
audit-prep-assistant
trailofbits
Prepares codebases for security review using Trail of Bits' checklist. Helps set review goals, runs static analysis tools, increases test coverage, removes dead code, ensures accessibility, and generates documentation (flowcharts, user stories, inline comments).
bullmq-specialist
davila7
BullMQ expert for Redis-backed job queues, background processing, and reliable async execution in Node.js/TypeScript applications. Use when: bullmq, bull queue, redis queue, background job, job queue.