Just finished migrating our entire portfolio to FOSSA. The promise was clear: automate the OSS license compliance headache, finally retire our cobbled-together scripts and spreadsheets. The sales demo was predictably smooth. Reality, of course, bit us immediately when our custom license policies—the ones written in blood from past audit findings—collided with FOSSA's workflow.
The main issue wasn't detection; it was *policy enforcement*. Our internal policy has tiers, like "Review Required" for certain AGPL uses, and "Hard Block" for anything with a non-commercial clause. FOSSA's policy engine *seemed* to support this. Here's where the breakdown happened:
* **The "Review Required" action is basically a polite suggestion.** It flags things in the UI but does nothing to block merges in CI. Our developers, conditioned to green checks, sailed right through. We had three merges last week with components that required legal sign-off. The postmortem was... fun.
* **Custom conditions are brittle.** We tried to write a rule to flag any dependency with "SSPL" in its name. The policy syntax looks like this:
```yaml
policy:
- id: "SSPL_Alert"
license:
matches:
- "SSPL"
action: "review"
```
Turns out, this only catches SPDX license IDs. If a project's `package.json` or similar has a non-standard string like "Server Side Public License," it slips through unless FOSSA's internal classifiers catch it. Which they sometimes don't.
The migration exposed that we'd offloaded thinking to a tool. The dashboard looks comprehensive, but the gates aren't actually locked. We're now layering additional CI checks *outside* of FOSSA to enforce the hard stops, which feels like paying for a guard dog and then building a fence because it wags at intruders.
Has anyone else found the policy enforcement to be more of a reporting tool than a control point? What are you using to actually *block* the builds?
- Nina
- Nina
You've put your finger on the fundamental gap between policy modeling and policy execution. FOSSA, and tools like it, are excellent at the scanning and inventory phase, but the transition from a flagged finding to a concrete, automated gate is often poorly implemented.
The "polite suggestion" problem is a classic one. The workflow assumes a perfect, attentive human in the loop reviewing the FOSSA dashboard, which is disconnected from the actual merge velocity. For it to work, the policy action must inject a mandatory, non-bypassable status check into the pull request context. If it doesn't, it's just a report. We solved this by using FOSSA's API to write a small intermediary service that consumes the scan results and then uses the GitHub Checks API to create a blocking check. That way, "Review Required" literally becomes a pending status that blocks merge until a designated approver marks it approved.
Your brittle custom condition issue points to a lack of abstraction in their policy language. Relying on string matches in a dependency name is fragile because the naming isn't standardized. You'd be better off, if the tool allows it, writing a rule against the license family or category as FOSSA has normalized it, but I've found their normalization can be inconsistent too. Did you explore using their CLI to test the policy against a known problematic artifact before full rollout? That's usually where these syntax and logic gaps become apparent.
—BJ