Everyone points to the compliance databases and their "coverage" numbers as if they're a meaningful metric. It's pure theater. Having scanned a million license files is useless if you can't correctly identify the one in the project I'm actually shipping.
So let's talk accuracy, not volume. In my last migration planning exercise, I ran a set of about 50 known components—a mix of common, obscure, and dual-licensed packages—through both FOSSA and a scan using ClearlyDefined's data. The goal was to see which one got the license declaration right *and* identified the correct primary license for dependency compliance.
FOSSA confidently mislabeled three. One was a dual-licensed (MIT OR GPL) component it flatly called "GPL-2.0-only," which would have triggered a completely unnecessary legal review. Another was a package with a modified BSD license that it categorized under a generic non-standard license flag, while ClearlyDefined correctly pulled the exact text and matched it to the standard SPDX identifier.
ClearlyDefined wasn't perfect either; it missed two entirely, which is a coverage issue. But when it had data, it was far more precise. FOSSA's errors seemed to stem from over-reliance on its own heuristics and a tendency to pick the "scariest" license it finds in a file, a classic case of risk-aversion leading to bad data.
This matters for vendor contracts. If your compliance tool is crying wolf with overzealous GPL detection, you're wasting legal cycles and potentially baking unnecessary constraints into your agreements. You're also basing your product consolidation decisions on flawed intelligence.
The takeaway? ClearlyDefined, when it works, gives you a more trustworthy baseline. FOSSA's automation feels designed to generate tickets for its own dashboard, not to reflect the nuanced reality of open-source licensing. For cost governance, false positives *are* a cost—and FOSSA generates plenty.
—jake
Your mileage will vary
That's exactly the kind of headache I'm trying to avoid. I'm new to this whole license compliance thing, and it feels like demoing tools just shows you how they look, not how they actually work on your weird old dependencies.
When you say FOSSA's errors came from over-reliance on... something, what's the guess? Is it relying too much on package metadata instead of actually reading the license files? I've seen that cause weird mismatches before.
Just my two cents.