Free license compliance tools are good at one job: finding licenses and copyright notices in code and dependencies and writing the result to a report. They are weaker at the rest, which is policy, approvals, ongoing monitoring and audit history. Free is enough for a small, stable codebase. It is rarely enough once releases are weekly.
What do free tools actually do well?
Open source scanners such as ScanCode Toolkit and FOSSology detect licenses and copyright text, and both can run on your own infrastructure. ScanCode runs as a command line tool or a library. FOSSology adds a database and web interface, can generate an SPDX file in one click, and rescans only changed files after a new version.
That covers the discovery step well. If your question is "what licenses are in this tarball," a free scanner answers it, and you can keep the result as evidence.
Where do they stop?
Discovery is not compliance. Four gaps show up in practice.
Policy. A scanner tells you a package is under a copyleft license. It does not know that your company allows weak copyleft in internal tools but not in a shipped binary. Someone has to write that rule and apply it to every build.
Workflow. Findings need an owner, an exception path and a record of who approved what. A report in a folder is not that.
Monitoring. Licenses change between releases, and new dependencies arrive every week. A scan you ran in March says little about a build in October unless it runs on every change.
Transitive depth. Many teams only look at direct dependencies. The questions that hurt are about the third layer down.
What should you check before choosing free?
Ask these in order. If you distribute nothing, your dependency set is small and no outside party asks for reports, free tools will probably serve you.
- Do you distribute software to customers, or ship it inside a product? Hosted only, internal only and distributed carry different obligations.
- Is the dependency set small and slow to change?
- Does anyone outside engineering, such as legal or a customer's procurement team, ask for license reports?
- Do you need SPDX license expressions to be parsed so that "MIT OR Apache-2.0" is treated as a choice rather than two licenses?
- Do you need approvals and an audit trail?
A realistic split
A common pattern is to run a free scanner for deep file level analysis on the releases that matter, and use a platform for continuous checks on every pull request. Whatever you choose, keep the SBOM as the source of truth, since SPDX and CycloneDX both carry license data.
If you want a quick look without installing anything, the free in-browser scan at gold.safeguard.sh/scan checks up to 100 dependencies. It is a way to see what your tree looks like, not a legal review. Our license compliance checks parse SPDX expressions and group licenses by permissive, weak, strong and network copyleft, and they work alongside the SBOM.
What to do
- List where your software is distributed and note which products ship to customers.
- Write a one page license policy: allowed, needs review, banned.
- Run a free scanner on your most important release and keep the output.
- Generate an SBOM in a standard format and store it with each release.
- Decide who approves exceptions and where that is recorded.
- Move the check into CI once the manual run is routine.
- Revisit the choice when you add a customer that asks for license reports.
Quick check
Is a free scanner legally sufficient?
No tool makes a legal decision for you. A scanner finds and reports licenses. Interpreting obligations for your use case is a job for your legal counsel.
Do I need SPDX output?
It helps. SPDX is a common format that customers and tools can read, so a report in that form saves rework later.
When does free stop being enough?
When you need enforced policy on every build, an approval trail, or reports on demand for customers, a manual scan no longer keeps up.
Sources
Last reviewed: 18 October 2026.
