open_source_license_review v1.0.0

name: open_source_license_review description: Review the open source licenses in a dependency tree before a product ships: build the full inventory, normalise SPDX expressions, map each license to its obligations for the actual distribution model (internal, binary, SaaS, embedded), run compatibility checks, and route every component through an approval tier with a written record. Use when adding a dependency, auditing a codebase for copyleft or AGPL risk, preparing a release, due diligence, or building the notices file and source offers a release owes.

Open Source License Review

Purpose

Decide, component by component, whether a product may use the third party code inside it, and what that code obliges the product to do. The output is a review record with verdicts, an obligations checklist a release can actually follow, and blocks that stop a shipment until a person clears them.

This is triage and process, not legal advice. Close cases go to counsel with the facts written down.

For the full license by license duties, compatibility table, and approval tiers, read references/license-obligation-matrix.md. For the record format, use references/review-record-template.md.

Workflow

1. Frame the use before judging any license. Write down: the distribution model (internal only, distributed proprietary binary, hosted SaaS, open source distribution, embedded in a device; more than one can apply), the product outbound license, whether any component is modified, how each component connects (dynamic link, static link, same process, separate process, network call), and who receives the product. No verdict exists without this frame. A license that is a non-issue internally can block a shipped binary.
2. Build the inventory, direct and transitive. Generate an SBOM in SPDX or CycloneDX form (Syft, ScanCode Toolkit, or the ecosystem SBOM tool) from the lockfiles, and record the NTIA minimum fields for each component: supplier, name, version, a unique identifier such as a package URL, dependency relationship, who or what produced the SBOM data, and a timestamp. Check build and test scope too, then mark which scope actually ships. Add what scanners miss by hand: container base images, vendored or copied code, bundled fonts, icons, data files, and anything pasted in from a public repo.
3. Verify the license, do not trust the metadata field. A package registry license field is a claim. Prefer the scanner concluded license read from the actual LICENSE or COPYING file in the artifact you ship. Where declared and concluded disagree, the artifact wins and the disagreement goes in the record. Empty field, NOASSERTION, or a missing license file means unknown, and unknown means Block.
4. Normalise to SPDX and parse the expression. Use SPDX identifiers (MIT, Apache-2.0, GPL-3.0-only, GPL-3.0-or-later). Handle the operators properly:

• OR: you may pick one license. Pick the one you will actually comply with and record the choice. An unrecorded choice is an open finding.
• AND: every license applies at once. Triage follows the strictest part.
• WITH: a named exception changes the base license. Read the exception text. Any WITH pushes the component to Review.
• The suffix matters: -only and -or-later are different grants, and GPL-2.0-only code cannot be combined with GPL-3.0 code.

1. Classify and map obligations. Put each component in a family from the matrix: permissive, Apache-2.0, weak copyleft file level (MPL, EPL, CDDL), weak copyleft library level (LGPL), strong copyleft (GPL), network copyleft (AGPL), source-available or restricted (SSPL, BUSL-1.1, Elastic-2.0, Commons Clause, noncommercial CC), non-code CC, or unknown. Then write the obligations that this distribution model triggers, from the matrix. Mind the classic trap: SPDX BSL-1.0 is the Boost Software License, a permissive license. BUSL-1.1 is the Business Source License, source-available. One letter flips the verdict.
2. Run the bundled triage script for a first pass, then correct it by hand where the facts need judgment:

   python3 bin/license_review.py inventory.json --distribution saas
   python3 bin/license_review.py inventory.json --distribution proprietary-binary --json
   

The input is a JSON list (or CSV) of components with name, version, spdx, modified, and linking fields, or an SPDX SBOM document. Verdicts are APPROVE_WITH_NOTICES, REVIEW, and BLOCK. The script handles OR, AND, WITH, and the BSL-1.0 versus BUSL-1.1 split. Its verdict is a starting point: it cannot see process boundaries, copied code, or a NOTICE file.

1. Check compatibility. Test the set against the product outbound license and against itself, using the matrix table. The conflicts that bite in practice: Apache-2.0 with GPL-2.0-only, GPL-2.0-only with GPL-3.0-only, any strong or network copyleft joined to a proprietary combined work, and a source-available license whose field of use bans what the product does for money.
2. Route through approvals and record exceptions. Permissive and Apache-2.0, unmodified, with notices done: self-approve. Weak copyleft, modifications, static LGPL linking, WITH exceptions, dual license choices, and aggregation arguments: a named approver decides in writing. Strong copyleft in a distributed or embedded product, AGPL in anything network facing, source-available in anything commercial, and unknown licenses: counsel or the policy owner. An exception record carries the component, version, use, reason, approver, and a revisit date.
3. Fulfil the obligations in the release itself. Rebuild the notices file from the current inventory (copyright notices plus full license texts for everything that ships). Carry every Apache-2.0 NOTICE file content into the distribution, docs, or a display, and mark changed Apache-2.0 files. Publish working source offers for copyleft components that need them, ship a relink path for statically linked LGPL components, put the network source offer where users of a modified AGPL component will see it, and include installation information when GPL-3.0 family code ships in a consumer device. Add or refresh the in-product open source licenses page.
4. Close blocks with the remediation ladder, in this order of preference: replace with a permissively licensed alternative; move to a version under a different license, checking both directions since vendors do relicense projects between versions; buy the commercial or dual license if one is offered; isolate the component behind a genuine process or service boundary and send that architecture to Review, because isolation is a legal argument, not a self-service fix; accept the copyleft and publish the source it requires; or remove the component. Record which rung closed each block and the evidence.
5. Gate it so the review stays true. Re-run the inventory and triage on every lockfile change and every release. A version bump can change a license without changing an API, so diff licenses on upgrades, not just code. Keep the review record with the release artifacts. A program that wants to match the OpenChain specification (ISO/IEC 5230) needs this in writing: a policy people inside the project have seen, named roles, a review process for supplied software, and compliance artifacts delivered with the software.

Output Contract

Deliver, every time:

• The frame: distribution model, outbound license, and scope of the inventory.
• A per-component finding list, sorted with blocks first: name, version, SPDX expression, family, verdict, and the obligations that apply.
• The dual license choices made, with the license picked for each.
• An obligations checklist for the release (notices, NOTICE files, source offers, relink paths, license page), each item done or named as outstanding with an owner.
• Every block, the remediation chosen, and the evidence it closed.
• Exceptions granted, with approver and revisit date.
• Open questions for counsel, stated as facts.

Operating Rules

• This skill gives triage, not a legal opinion. Say so in the record, and send close calls to counsel instead of resolving them by confidence.
• Never guess a license from a project name, a README badge, or a registry field alone. Read the license in the artifact.
• No license file means no permission. Default copyright reserves all rights. Block and identify, never assume public domain.
• Internal use is a state, not a pardon. Record internal-only copyleft components, because the verdict changes the day the product ships or opens to outside users.
• The FSF reads GPL linking, static or dynamic, as making a combined work. Plan on that reading, and flag genuinely separate programs (mere aggregation) as Review items with the architecture written down.
• Do not strip, shorten, or summarise away copyright notices or license texts in the notices file. Attribution duties apply to permissive licenses too, and missing attribution is a breach even when the code was free to use.
• A license check on direct dependencies only is an unfinished review. Transitive components ship, so transitive components get reviewed.
• Keep style plain in every report this skill produces. Short sentences, exact license names, no sales language.