Guide: Filtering out 'BSD-3-Clause' noise from the critical issues list.

Another day, another team paralyzed by a FOSSA report with 200+ "critical" issues, 190 of which are BSD-3-Clause. I've seen this movie. The legal team gets a PDF, their eyes glaze over, and suddenly your engineering roadmap is hijacked by license compliance theater for packages where the only obligation is to preserve a copyright notice. The tool is doing its job, but the signal-to-noise ratio is atrocious.

The core problem is that FOSSA, by default, often elevates license detection to a "critical" policy violation, especially in strict compliance profiles. BSD-3-Clause is about as benign as it gets, but it gets flagged because it's a *license* and you haven't explicitly whitelisted it. Instead of whitelisting it globally and potentially missing a real issue, you need to filter it from your critical issues list. This requires moving from a reactive to a configured policy model.

Here's how to stop the madness, using FOSSA's policy engine. You'll be working in your `.fossa.yml` policy configuration. The goal is to create a rule that downgrades or ignores BSD-3-Clause violations from the critical list, while keeping real problems (like GPL violations) elevated.

First, ensure you have a `policy` section in your `.fossa.yml` at the root of your repo. If not, create it. The key is to define a custom policy rule that targets the specific license.

```yaml
# .fossa.yml
version: 3
policy:
public:
- type: license
license: BSD-3-Clause
action: flag
severity: low
```

But that's just the start. This simple rule might only change the severity. To truly remove it from the "critical" waterfall in your issues list, you need to ensure your project's dependency scan uses this policy. More importantly, you likely need to adjust your organization's **compliance profile** in the FOSSA web UI. That's where the default "critical" thresholds are often set.

The real power move is to craft a rule that acknowledges the license but doesn't treat it as an action-blocker:

```yaml
policy:
public:
- type: license
license: BSD-3-Clause
action: flag
message: "Benign license. Review copyright notice requirement."
severity: low
- type: license
license: GPL-3.0-only
action: block
severity: critical
```

The crucial step everyone misses: after updating your `.fossa.yml`, you must trigger a new FOSSA build. The policy is evaluated on **analysis**, not on existing results. Push the change, let FOSSA re-run, and watch the tsunami of red issues recede to a manageable puddle of actual concerns.

If your organization is wedded to a central compliance profile that can't be changed, you're in for a political slog. Argue that engineering time spent "reviewing" hundreds of false positives creates real risk by drowning out the handful of actual problematic licenses. Sometimes the most elegant infrastructure architecture is a simple configuration change that stops wasting expensive human cycles.