How licenses are grouped
Every package's declared license is matched against its SPDX identifier and placed in one of six categories, ordered by how much scrutiny it typically draws during technical due diligence. For dual-licensed packages (for example MIT OR GPL-3.0) the checker uses the least restrictive option, since you may choose which license to accept. For packages that combine licenses with AND, it uses the most restrictive.
- Restricted / not open source
- Source-available, non-commercial, or proprietary terms (SSPL, BUSL, Elastic, UNLICENSED). Usage rights may not transfer to a buyer.
- Network copyleft
- AGPL-style licenses can require releasing source code to users of a hosted service. The highest-scrutiny category for SaaS deals.
- Strong copyleft
- GPL-style licenses require derivative works to be released under the same license when distributed.
- Weak copyleft
- LGPL, MPL, and EPL obligations generally apply only to modifications of the licensed files or library itself.
- Unknown
- No license declared, or a custom license that needs manual review.
- Permissive
- MIT, BSD, Apache, ISC, and similar licenses require attribution but impose minimal restrictions.
Why license checks matter in M&A
Buyers ask sellers to disclose every third-party dependency and its license because copyleft and non-open-source licenses can restrict how the acquired software is distributed, sold, or offered as a service. Finding an AGPL or unlicensed package late in a deal can delay closing or change the terms. Running a license check before due diligence starts lets you replace or document problem packages on your own schedule. Read more in our guide to open source license compliance in M&A.
Frequently asked questions
- Which files does the license checker support?
- npm lock files (package-lock.json and npm-shrinkwrap.json) and Composer lock files (composer.lock). Lock files list every installed package, including transitive dependencies, along with the license each package declares. Manifests like package.json and composer.json only list direct dependencies and don't include licenses, so upload the lock file instead.
- Is my lock file stored?
- No. The file is parsed in memory to produce the report on this page and is then discarded. Nothing is saved to disk or linked to you, and you don't need an account.
- Why are some licenses marked as unknown?
- Some packages don't declare a license, use a custom license file (such as "SEE LICENSE IN LICENSE.md"), or come from an older lockfileVersion 1 package-lock.json that doesn't record licenses. Review these packages manually; an undeclared license means that by default no one else has permission to use the code.
- Which licenses are a problem in an acquisition?
- Buyers focus on network copyleft licenses like AGPL (which can require releasing source code for software offered as a service), strong copyleft licenses like GPL (which apply when software is distributed), and non-open-source licenses like SSPL, BUSL, and UNLICENSED packages. Permissive licenses such as MIT, BSD, and Apache-2.0 rarely raise concerns beyond attribution. Whether a specific use triggers an obligation depends on how the code is used and distributed, so have counsel review flagged packages.
- How is this different from a full DependencyDesk analysis?
- The checker reads one lock file at a time. DependencyDesk connects to your GitHub organization and analyzes every repository across JavaScript, PHP, Ruby, Python, and Go, adds security vulnerability scanning, and produces a CSV and HTML report you can hand to a buyer.