license-compliance-checkerlisted

Produce a license inventory of the project's dependencies and judge it against how the project is actually distributed — because the same license can be fine for one project and a blocker for another. This skill enumerates direct and transitive dependency licenses, classifies each by obligation, and flags the ones that conflict with your project's own license and distribution model (a closed-source SaaS, a distributed binary/app, or an open-source library have very different constraints). > [!IMPORTANT] > This is an engineering aid, not legal advice. It surfaces likely conflicts and obligations so a human — and, for anything material, a lawyer — can make the call. Never assert that a particular use is "legal"; report the license, the obligation, and the risk. ## When to use this skill - Before a release, an open-sourcing, or shipping a distributed binary/app. - When adding or upgrading a dependency and you want to know what it drags in. - When legal, security, or procurement asks for a Software Bill of Materials or license list. - When a dependency has no license, an ambiguous one, or a copyleft license you didn't expect. ## Instructions 1. **Establish the project's own terms.** Read the project's `LICENSE` and package manifest license field, and determine the distribution model: closed-source SaaS, distributed proprietary binary/app, or open-source library. This decides which dependency licenses are actually a problem. 2. **Enumerate dependency licenses.** Use the ecosy