Open source software (OSS) has become the foundation of modern software development, powering everything from operating systems to embedded devices. But using open source requires organizations to follow certain conditions that are set out in open source software licenses. Licenses dictate the terms under which an open source component can be used, modified, and/or distributed.
Of course, given the massive amount of open source in modern applications, manually tracking and complying with these licenses is often impractical. That’s why many teams rely on automated license compliance tools (like FOSSA) to identify and manage their open source obligations at scale.
The core of a license compliance tool is its ability to accurately detect the license(s) that govern the dependencies in the user’s application. However, not all license scanners work the same way. In this post, we’ll explore the two most common license detection methods found in modern license compliance management tools:
- A knowledge base look-up approach
- A source code download and analysis approach.
Editor’s Note: This blog is based on a recent episode of the FOSSA Video Podcast. We invite you to check out the podcast to see our full discussion on this topic.
Methods of License Detection
Generally speaking, every license compliance management tool is built around three primary workflows:
-
Build a complete dependency graph (including all direct and transitive dependencies) that represents the application.
-
Associate each dependency with its license(s).
-
Determine which obligations the user must meet based on those licenses (and, in some cases, assist in actually meeting those obligations, such as with automated license notice creation).
Our focus in this article is on the second step (associating dependencies with licenses) and the differences between a knowledge base lookup strategy and a direct code analysis strategy.
Knowledge Base Lookup
This approach relies on a curated database that maps known software packages (e.g., “Package X, Version Y”) to known licenses or spdx-ids (e.g., MIT, Apache 2.0). This knowledge base is typically populated purely by the metadata detected within the package distribution method, a registry (e.g npmjs, pypi, maven) or version control system (e.g GitHub, GitLab). The scanner compares your dependency list to this database and returns the corresponding license information.
Direct Code Analysis
In contrast, this approach involves downloading the actual software, whether that be source code or a package artifact, for each package and scanning it directly for license files or text fragments. The scanner looks not only at standard files (like LICENSE, COPYING, LICENSE.md, or LICENSE.txt), but also searches every file throughout the codebase for hidden license headers or embedded license text.
This approach also detects scenarios where the analyzed component includes vendored source code from a component under a different, potentially incompatible, license (which may require the analyzed component to also carry that different license).
Pros and Cons of the Knowledge Base Lookup Approach
The knowledge base approach prioritizes speed and simplicity. Because it doesn’t require fetching or analyzing source code, results are typically generated much faster, making it attractive for organizations that need lightweight compliance visibility.
Advantages
-
Good for internal or low-risk projects: Ideal for prototypes, internal tools, or development environments where compliance risk is limited.
-
Potentially more budget-friendly: Smaller and other budget-conscious organizations may find their preferred tools (both free options and paid security tools with lightweight license compliance add-ons) utilize this approach.
Drawbacks
The reality of open source license compliance is that entities which distribute software are responsible for complying with all applicable licenses, not just the declared licenses. For example, if an open source package claims (in its LICENSE.txt file) to be under the MIT License — but that package includes a chunk of code from a GPL-licensed component — the end-user is responsible for complying with the original GPL (due to the to viral nature of copyleft licenses).
The primary concern with license scanners that rely on a knowledge base lookup strategy is that they won’t be able to navigate these nuances, which can result in:
-
Copyleft license risk exposure: Copyleft licenses may be embedded in the code but not represented in registry metadata. Organizations that distribute applications with copyleft-licensed components are at risk of having to open source their applications.
-
Incomplete attribution notices: License scanners that don’t detect all applicable licenses put the end-user at risk of producing inaccurate NOTICE files.
In other words, this approach can be good enough for low-stakes projects, but it won’t hold up under the scrutiny of a compliance audit.
Pros and Cons of the Direct Code Analysis Approach
The direct code analysis method offers completeness and confidence. By examining the actual files, it detects every license, even those not declared by the package maintainer. The biggest potential drawback is that it’s not uncommon to see these comprehensive tools report multiple licenses for specific open source components; this has historically required some level of manual effort to triage.
(Editor’s Note: FOSSA will be announcing a new feature specifically built to assist in this scenario in the coming weeks. Stay tuned!)
Advantages
-
Comprehensive coverage and traceability: Detects every license present in the code, not just what’s declared. Confirm license findings down to specific files or snippets.
-
Protect against hidden copyleft risk: Ensures you’re not unknowingly including GPL or AGPL components in distributed products.
Drawbacks
-
Higher friction: Downloading and scanning every package takes more time and compute.
-
Alert volume and triage effort: License text found in README files or examples can trigger unnecessary alerts. Teams need processes (or automation) for reviewing, confirming, and dismissing false positives.
Ultimately, despite the friction, organizations with mature OSS license compliance programs tend to prefer the direct code analysis approach. It provides legal defensibility, precise audits, and peace of mind that your compliance posture reflects the full reality of your codebase.
FOSSA’s License Scanner Recommendation
FOSSA was founded over a decade ago as a license compliance automation platform, and we’re proud that many organizations rely on our platform to understand and reduce OSS-related IP risks. And, as you might have gathered, our platform primarily uses the direct code analysis approach, since it tends to be a better fit for the mature compliance programs we serve.
At the same time, there are scenarios when the license is included only in the registry metadata, which is why we also leverage the knowledge base approach as a fallback/where necessary.
This combination allows our customers to:
- Maintain audit-grade evidence for every license detection
- Identify hidden or undeclared obligations early in the development cycle
- Confidently distribute products without worrying about embedded copyleft risk
For smaller internal or experimental projects, a knowledge base-only approach can still make sense, especially when speed outweighs legal exposure. But for distributed, commercial, or regulated software, the extra fidelity of full source analysis is well worth the tradeoff.
For more information on FOSSA’s license compliance automation solution, please visit our website or get in touch with our team.