I built an open-source tool for dependency license compatibility review

I kept running into the same problem with open-source dependency reviews: most tools can produce an inventory, but the harder question is whether the dependency licenses are compatible with how the project is actually shipped, hosted, or distributed. So I built **licenseal**, an open-source CLI that scans dependency manifests, lockfiles, and public registry metadata, then flags license compatibility issues before they become procurement, diligence, customer review, or release blockers. https://preview.redd.it/iiz6tq0csn5h1.png?width=887&format=png&auto=webp&s=99454186abfd2397570fead2651bf76b989445f3 Source code: [https://github.com/shcherbak-ai/licenseal](https://github.com/shcherbak-ai/licenseal) Usage docs: [https://github.com/shcherbak-ai/licenseal/blob/main/USAGE.md](https://github.com/shcherbak-ai/licenseal/blob/main/USAGE.md) Implementation notes: * Scans transitive dependencies by default across 10 ecosystems (Python, JS/TS, Rust, Go, Java/JVM, .NET, PHP, Ruby, Elixir/Erlang, and R). * Does not install dependencies, run package managers, execute build scripts, or download package archives. * Uses structured manifest, lockfile, and registry metadata only. * Classifies dependency licenses against the project license, with strict CI exits for unreviewed warnings, violations, unknown licenses, and analysis gaps. * Produces Markdown and JSON reports that can be committed or attached to review workflows. * Supports a checked-in \`licenseal.review.toml\` file for documented review decisions. * **Includes a Claude Code review skill that walks through flagged findings, asks context-aware questions, records review rationale, and re-runs the scan.** One thing I tried to be careful about: the review file is an audit trail, not a blanket approval mechanism. A reviewed entry can document that registry metadata was wrong, or that a flagged dependency was reviewed in the context of how the project is distributed or hosted. But if the dependency is genuinely incompatible, the tool should keep that visible rather than silently turning it green. I’m curious how others handle this boundary in practice. When engineering teams surface open-source license findings, where do the final review decisions usually live: in the repo, a ticketing system, GRC tool, CLM, spreadsheet, legal memo, or somewhere else?