License compliance is invisible until it isn't
Most day-to-day development treats open-source licenses as a formality — a field in a package.json that nobody reads closely. That changes the moment a copyleft license, most commonly GPL or AGPL, is discovered somewhere in a dependency tree of a commercial, closed-source product, because these licenses can impose real obligations on derivative works, potentially including a requirement to release your own source code under the same terms.
Why "I didn't directly install it" isn't a defense
Modern dependency trees are deep — a package you directly installed can pull in dozens or hundreds of transitive dependencies, any one of which might carry a different license than the packages you explicitly chose. A GPL-licensed dependency three levels deep in your tree carries the same legal weight as one you installed directly, even though it's far easier to miss during a casual review.
Why context changes the actual risk
- Closed-source commercial product. This is where copyleft license discovery carries the most consequence — GPL/AGPL terms can conflict directly with keeping your own code proprietary, depending on how the dependency is used and linked.
- SaaS / internal service. The distribution model matters significantly here — some copyleft licenses (notably the AGPL specifically) extend obligations to software offered as a network service, not just software that's literally distributed, which is a common point of confusion.
- Open-source project. Copyleft dependencies are generally far less concerning here, though license compatibility between different copyleft licenses within the same project can still raise its own questions.
Why a quick check beats discovering this during due diligence
License compliance issues have a habit of surfacing at exactly the worst moment — during an acquisition's legal due diligence, an enterprise customer's procurement review, or a competitor's scrutiny of a public codebase — rather than being caught early when the fix (swapping a dependency, or getting a specific licensing exception) is far cheaper and easier.
Why this tool is explicitly a starting point, not a final answer
An educational reference-table check against common package names and patterns catches well-known cases quickly, but it isn't equivalent to a live, comprehensive license-scanning tool (like FOSSA, license-checker, or a similar dedicated service) that actually queries package registries and license databases directly — for anything beyond a fast sanity check, especially before a real legal event like a product launch or acquisition, a proper scanning tool and legal review are the appropriate next step.
Building this into a normal review habit
Checking new dependencies for license risk before adding them to a project is meaningfully cheaper than discovering a problem after a dependency is deeply embedded and difficult to swap out — treating this as a routine part of adding any new dependency, rather than an occasional audit, is what actually prevents the expensive, late-discovery version of this problem.
Frequently Asked Questions
GPL and AGPL licenses can impose obligations on derivative works, potentially including a requirement to release your own source code under the same license terms, depending on how the dependency is used and linked. This can directly conflict with keeping a commercial product's code proprietary.
No — a transitive dependency (one pulled in by a package you directly installed, rather than one you chose yourself) carries the same license obligations as a direct dependency. It's easier to miss during a casual review, but legally it carries the same weight.
Some copyleft licenses, notably the AGPL specifically, extend their obligations to software offered as a network service (like a SaaS product), not just software that's literally distributed to users as a download. This is a common point of confusion since many people assume copyleft only applies to distributed software.
No — it's an educational starting point using a reference table of common packages and name patterns, useful for a fast initial sanity check. A live, comprehensive license-scanning tool (like FOSSA or license-checker) that actually queries package registries directly is the appropriate tool before a real legal event like a launch or acquisition.
Yes — the Dependency License Compliance Checker parses a pasted package.json or dependency list, checks each package against a reference table of common copyleft-risk patterns, and adjusts its guidance based on whether you're shipping closed-source, SaaS, or open-source.