Ask a license compliance vendor how it identifies licenses, what it does when signals disagree, how policies are enforced, what the output looks like for auditors, and where its judgment ends. The strongest answers are specific and admit limits. Vague answers about "AI-powered" detection should send you back to the demo.
This is a how-to-choose guide, so we do not rank vendors. Use the questions to compare any two.
Detection: how does it know the license?
1. Which signals does it read? Good: package metadata, SPDX identifiers, license file text, source headers and container layer metadata. Red flag: metadata only, which misses vendored code and mislabeled packages.
2. What happens when signals disagree? A package declares one license and its LICENSE file says another. A good tool raises a discrepancy for human review instead of picking silently. Ask to see one.
3. Does it use SPDX identifiers? The SPDX list gives each license a standard ID, so results map across tools and legal documents. If the vendor uses its own names only, exports become harder to reconcile.
4. How does it treat unknown or custom licenses? Look for an explicit unknown category that needs review, not a default pass.
Policy: can it enforce what your counsel decides?
5. Can you write allow, review and deny lists? Ask whether the policy can differ by product or delivery model, since the same license may be fine in a hosted service and a problem in distributed software.
6. Where does it enforce? Pull request, build, release and vendor intake are different gates. Ask which are supported today, not planned.
7. How are exceptions recorded? An exception should store who approved, when, for which component and why. That is the record an auditor reads.
Evidence: what do you hand to others?
8. What can it export? Look for SPDX and CycloneDX bills of materials with license fields, and a human-readable report for customers. Validate one export with an independent tool during the trial.
9. Can it scan vendor SBOMs? Third-party software is part of your exposure. Safeguard, for example, describes detecting and enforcing license policy across code, containers and vendor SBOMs. Whatever you evaluate, test it with a real vendor file.
Limits: where should you not trust it?
10. What is its error rate, and how was it measured? Ask for method, not a headline number. If a vendor quotes one, ask for the test set.
11. What does it not cover? Snippets copied without a notice, license changes between versions, and negotiated commercial terms are hard for any scanner. A good answer names them.
12. Who reviews the findings? The tool classifies, and your counsel decides. Be wary of a vendor that promises legal certainty.
OpenChain's ISO/IEC 5230 describes what a quality open source license compliance program contains, including processes and roles. Ask whether the vendor's workflow helps you meet it, without expecting the tool to do it for you.
How should you run the demo?
Bring your own repo, a container image, and one vendor SBOM. Plant a package whose metadata license disagrees with its license file. Ask the vendor to show the exception workflow from start to finish. Time each step.
What to do
- Get your counsel's allow, review and deny list before the first demo.
- Prepare one test repo, one image and one vendor SBOM.
- Score each vendor on the twelve questions, one to five.
- Ask for an export and validate it independently.
- Test the exception workflow with a named approver.
- Ask for references from a customer in your delivery model.
- Write down what the tool will not do, and who owns that gap.
Quick check
Which question matters most?
Question 2. How a tool handles disagreeing signals shows whether it supports real review or hides uncertainty.
Should the vendor give legal advice?
No. Tools classify licenses and enforce your policy. Legal interpretation belongs to your counsel.
Sources
Last reviewed: 18 October 2026.
