We're evaluating FOSSA to formalize our open source compliance for acquisition targets. Our legal team wants a definitive "green light" report for due diligence, but our current process is ad-hoc and slow.
What does a "golden" policy look like in FOSSA for this specific use case? I'm thinking about:
- Setting license category rules (e.g., automatically flag any GPLv3)
- Configuring policy monikers to tag "Approved," "Review," "Blocked"
- Exporting a clean summary report for non-engineers
Is there a best practice for structuring this, especially the report output? We use Freshdesk for vendor tracking, so any integration tips there would be helpful too.
Your thinking is spot on for the core categories. We built ours with those exact three monikers: Approved (permissive), Review (weak copyleft), Blocked (strong copyleft). The trick for due diligence was adding a fourth: "Contaminated."
Here's why: if a vendor's project pulls in a GPLv3 library, that's blocked. But if their *own source* is under MIT and just uses that library, you might still want to flag it for deeper review, not outright fail the scan. We set a rule to tag anything with a transitive Blocked dependency as "Contaminated". It saved us from killing deals over a dev's mistaken `package.json` inclusion.
For reports, FOSSA's PDF export was too noisy for legal. We ended up using their API to pull a JSON policy summary and wrote a simple Python script to generate a one-page markdown table, grouped by the contaminated projects. Sent that directly into the Freshdesk ticket as a comment. Happy to share that script if you want.
terraform and chill
The "Contaminated" moniker is a lifesaver for M&A scans. We use it exactly as you described - stops a single dev mistake from derailing the whole process.
One extra step: we set an expiration on that tag, like 30 days. It forces the target's team to either replace the dependency or get a legal waiver before close. Without that, contaminated items just linger forever in the report.
Love the idea of piping the markdown into Freshdesk. Do you also auto-tag the ticket based on the highest severity moniker found?
Automate the boring stuff.
Expiration on the "Contaminated" tag is clever. It turns a static finding into a forcing function, which is the only way anything gets done before a deal closes.
But piping the markdown into Freshdesk and auto-tagging based on the highest severity moniker is where this falls apart for me. It's a false simplification. If you have one "Blocked" item and ninety-nine "Approved," the ticket gets tagged "Blocked." That single tag now drives the entire workflow, the SLA clock, and the executive summary, while the ninety-nine approved items might as well not exist. You've just recreated the "one mistake derails the process" problem at the ticketing level.
Either your Freshdesk workflow needs to ingest the structured data properly, or you're better off with a separate system for this. A single severity flag is for helpdesk tickets, not for a nuanced legal review.
Just my 2 cents
You're totally right about the danger of a single "Blocked" tag skewing the whole ticket. It creates the wrong pressure.
Maybe the answer is to split the outputs? One ticket for the "All Approved" summary report that gets the normal SLA, and a separate, high-priority ticket for any "Contaminated" or "Blocked" items that need action. That way the bulk of the work isn't mislabeled, but the critical issues still get flagged.
Does Freshdesk let you spawn child tickets from an API call?