Free Software, Real Liability: Is Your Company's Open Source Stack a Legal Time Bomb?

Let's be honest: most companies didn't sit down one day and consciously decide to build a sprawling web of open-source dependencies. It happened gradually — a developer pulled in a convenient library here, a DevOps engineer spun up a free tool there, and before anyone noticed, the organization was running on hundreds of packages with licenses nobody had ever read. That's the quiet reality behind a lot of enterprise tech stacks, and it's a problem that doesn't announce itself until things go sideways.

We're talking about licensing conflicts that can expose you to copyright claims, abandoned projects that quietly become security liabilities, and undisclosed transitive dependencies — the dependencies of your dependencies — that nobody on your team even knows exist. The good news? There are practical ways to get ahead of this. The better news? A lot of the tools that help you do it are, fittingly, free.

The Part Where Companies Usually Get Burned

Licensing is where most organizations stumble first. Open-source licenses aren't all created equal. The MIT and Apache 2.0 licenses are famously permissive — use the code, modify it, ship it, just keep the attribution. But GPL licenses operate differently. If you incorporate GPL-licensed code into your commercial product, you may be legally required to release your own source code under the same terms. That's a deal-breaker for a lot of businesses, and it's not a hypothetical risk. Companies have been sued over exactly this.

Then there's the abandoned project problem. A library that was actively maintained in 2019 might have had its last commit in 2021 and its last security patch never. If that library has a known vulnerability — and tools like the National Vulnerability Database track these publicly — you're running exposed code that nobody is fixing. The original maintainer moved on. Nobody picked it up. And your app is still calling that library every time a user logs in.

Transitive dependencies are arguably the sneakiest issue. Your team chose Library A. Library A depends on Library B. Library B depends on Library C, which has a GPL license and a critical CVE filed against it last month. Your team has never heard of Library C. This is not a rare scenario. It's basically the default state of modern software development.

What an Actual Audit Looks Like

Auditing your open-source stack doesn't have to be a six-month engagement with a consulting firm. Here's a practical framework you can start working through right now.

Step 1: Generate a Software Bill of Materials (SBOM) An SBOM is essentially an ingredients list for your software — every package, library, and dependency, along with version numbers and license information. Tools like Syft (open source, free) can generate SBOMs from container images, filesystems, and package manifests. The US federal government has actually started requiring SBOMs for software sold to government agencies, which tells you how seriously this is being taken at a policy level.

Step 2: Scan for License Conflicts Once you have your SBOM, you need to cross-reference it against your business model. FOSSA offers a free tier that can scan your dependencies and flag licensing conflicts automatically. FOSSology is a fully open-source alternative that runs on your own infrastructure if you'd rather not send dependency data to a third party. Both tools can highlight where GPL, LGPL, AGPL, or other copyleft licenses might conflict with your distribution model.

Step 3: Check for Known Vulnerabilities Grype pairs naturally with Syft — it takes your SBOM and scans it against vulnerability databases including the NVD and GitHub Advisory Database. OWASP Dependency-Check is another solid free option, particularly popular in Java and .NET environments. These tools won't just tell you something is vulnerable; they'll give you CVE identifiers so you can research severity and patch status.

Step 4: Assess Project Health Vulnerabilities are one thing, but a library that's technically unpatched because the maintainer disappeared is a different kind of risk. OpenSSF Scorecard evaluates open-source projects on criteria like branch protection, code review practices, and dependency update frequency. It's a fast way to gut-check whether a project you're relying on is actually being maintained.

Step 5: Set Up Continuous Monitoring A one-time audit is better than nothing, but it's not enough. Dependencies change. New CVEs get filed. Projects get abandoned. Tools like Dependabot (built into GitHub, free for public and private repos) can automatically open pull requests when your dependencies have updates or known vulnerabilities. Renovate is a more configurable open-source alternative that works across more platforms.

The Organizational Side of This

Tools only get you so far. The audit process also surfaces a cultural issue: most engineering teams don't have a formal policy around which licenses are acceptable, who approves new dependencies, or how abandoned projects get flagged and replaced. Fixing that doesn't require expensive software — it requires a written policy and someone responsible for enforcing it.

A lot of companies find it helpful to maintain an approved license list (MIT, Apache 2.0, BSD variants are common approvals) and a review-required list (GPL, AGPL, anything with unusual clauses). Any dependency that falls outside the approved list goes through a quick review before it gets merged. It sounds bureaucratic, but it takes maybe fifteen minutes per review and saves significant headaches later.

Don't Wait for the Letter

Legal notices about open-source licensing violations don't usually come with a lot of warning. Neither do security incidents traced back to an unpatched transitive dependency. The companies that get caught flat-footed are almost always the ones that assumed "we use free software" was the end of the story rather than the beginning of a responsibility.

The irony here is real: the tools you need to manage your free software stack responsibly are themselves mostly free. There's no excuse to skip this. Run the scan, generate the SBOM, check the licenses, and set up the monitoring. Your legal team will thank you. Your security team will thank you. And if you ever end up in a room explaining your software supply chain to an enterprise customer or a federal auditor, you'll thank yourself.

Freeware is powerful. It's also a commitment. Treat it like one.