Launching today
licenseal
Catch incompatible dependency licenses before release
53 followers
Catch incompatible dependency licenses before release
53 followers
A free, open-source CLI that checks every dependency license, transitive ones included, against your project's license, in 10 ecosystems. It reads lockfiles and registry metadata, installs nothing, and gives CI a verdict, not a list.
Free
Launch Team / Built With
CloudflareStill paying to deploy your apps? Try Cloudflare Workers for free
Promoted
Hi Product Hunt! I'm Sergii, and I build licenseal.
A dependency's license binds the product that ships it, whether anyone on the team chose that dependency or not, and most of a dependency tree is transitive: chosen by nobody. A conflict usually surfaces late, in a customer's procurement review, an investor's due diligence or the week of a release, when swapping the package out costs the most.
licenseal moves that check to every pull request. In your project's directory, run:
It reads your manifests and lockfiles, follows the whole dependency tree, looks up each package's license in public registry metadata and judges it against the license you ship under. You get a verdict for each dependency (compatible, warning, violation or unknown) and an exit code CI can gate on: a verdict, not a list.
What it does
Ten ecosystems in one tool: Python, JavaScript / TypeScript, Rust, Go, Java / JVM, .NET, PHP, Ruby, Elixir / Erlang and R.
Transitive by default. A flagged package is listed under the direct dependency that brought it in, so you know what to remove.
No dependency installs. It builds nothing and downloads no package. The registries see a package's name and version, nothing else, and it can reach fourteen registry hosts and no others.
Strict by default. A license it can't read from structured metadata is unknown, and something it couldn't read, such as a manifest without an up-to-date lockfile, fails the check instead of passing quietly.
A Claude Code skill. Run /licenseal-review and it walks you through each flagged dependency, asks how you distribute, host or modify your product, and records each decision with its reason in licenseal.review.toml. Real incompatibilities stay flagged.
In a benchmark of 50 widely used open-source repositories across the ten ecosystems, licenseal flagged 485 license-compatibility issues at default settings: 405 warnings and 80 outright violations.
What it isn't: legal advice, an SBOM generator or a vulnerability scanner. It tells you where a person needs to look, and keeps that person's decisions in the repository.
It's free and open source (Apache-2.0). It runs on Python 3.11 or later, through uv or pipx; the project you check can be in any of the ten ecosystems.
I'd love your feedback. Where has a license surprised you late? And which lockfile or ecosystem should it read next?
GitHub: https://github.com/shcherbak-ai/licenseal
Docs: https://licenseal.shcherbak.ai
Is Swift Package Manager on your list for a next ecosystem? Most of my Swift dependencies come in transitively through Package.resolved, and the strict-by-default unknown verdict is the part I would want to understand first — how would you handle a package whose license is only stated in its repo, rather than in structured registry metadata?
@jcbuilds Thanks, JC! Swift is on my list, and you've hit the reason why Swift is the hard one. Swift has no central public registry, so most packages come straight from git, with no registry metadata behind them. Today licenseal reports any git dependency as UNKNOWN, and a Swift package would start out the same way.
This is by design. licenseal only accepts a license that the maintainer declared in a structured field. Reading LICENSE files would mean matching text, which is easy to spoof and misses edited licenses, or fetching every dependency's code, which is slow and touches far more than a license checker should.
When the license is only in the repo, UNKNOWN is where your review starts. You check the license once and record it in licenseal.review.toml with your reason (the bundled Claude Code skill walks you through it), and from then on CI passes. The entry is tied to that version or commit, so an upgrade comes back for review.