Open Source Dependency Obligations for Commercial Products

I've spent enough time untangling license headaches on client codebases to tell you this upfront: the license category attached to a dependency decides what you owe, and getting that category wrong is how a routine build turns into a legal bill. Black Duck's 2026 OSSRA report puts a number on the scale of the issue: 97% of commercial software contains open source components, and 70% of the average scanned codebase traces back to open source origins. The real question worth asking is whether you actually know what each dependency is asking of you.

The numbers keep climbing, too. A typical application now carries 911 open source components, and average codebase size has quadrupled over five years to more than 84,000 files. If your MVP came together through AI coding tools, a no-code platform, or a rotating bench of freelancers, there's a decent chance nobody on your team has ever sat down and inventoried what's actually in your stack. That gap reflects how fast building software has gotten, relative to how slowly license awareness has caught up.

What license category a dependency falls into determines what you owe

Every open source license lands in one of a handful of buckets, and each bucket runs on its own compliance logic.

Permissive licenses ask for the least: mostly attribution, in exchange for near-total freedom to do what you want with the code. Copyleft licenses work on reciprocity, use the code a certain way and you owe the community source access back, triggered by distribution or, under AGPL, by network access alone. Weak copyleft sits in the middle, narrowing that share-alike obligation down to the files you actually modified instead of your whole codebase.

Then there's a fourth bucket that trips people up constantly: source-available or "fair-code" licenses like BSL and SSPL. The source sits right there, readable, inspectable. But these aren't OSI-approved open source licenses, and commercial use, hosting the software as a service especially, can be restricted in ways that catch teams flat-footed.

So what actually matters here? The category tells you the shape of the obligation. The specific license fills in the details, and what happens if you get it wrong. Most compliance problems start with one mixed-up assumption: that "open source" means "free to use however I want."

Permissive licenses: what attribution actually requires

MIT, Apache 2.0, and BSD are the licenses most engineers assume come with no strings. Mostly fair. You can fold them into a proprietary product without asking anyone's permission. The catch is attribution: preserve the copyright notices, include the license text somewhere in your product or documentation.

Apache 2.0 does one thing MIT and BSD don't. It includes an explicit patent grant, which shields you from patent claims by contributors down the road. That matters more than people assume when you're picking infrastructure-level dependencies that touch a lot of your product's surface area.

Where teams actually slip up is boring and mechanical. Someone minifies a JavaScript bundle and strips the license headers along with it. Or nobody includes a NOTICE file because nobody knew one was required in the first place. Technically, that's a violation, even on a license this permissive. It rarely blows up on its own; but surface it during an app store review or an acquisition's due diligence process, and a missing attribution line becomes a flagged item on somebody's spreadsheet.

Worth remembering: these licenses form the backbone of the ecosystem. MIT and Apache 2.0 are among the most commonly encountered licenses in commercial codebases today.

Copyleft licenses: when distribution triggers source disclosure

GPL v2 and v3 run on a simple trade. Distribute software that incorporates GPL code, and you owe the full corresponding source, under the same license, to whoever you handed it to.

GPL v2 doesn't forgive mistakes. Violate it, and your rights terminate automatically and permanently. GPL v3 softened that with a 60-day cure window, which matters enormously if you discover the problem after you've already shipped. That window is the difference between a fixable oversight and a legal cliff.

Here's the part that quietly saves a lot of SaaS companies without them even realizing it: the copyleft obligation triggers on distribution, not use. Run GPL-licensed code entirely server-side, never ship a binary to a user, and you're generally clear under GPL v2 or v3. AGPL was written specifically to close that loophole; it treats network access as distribution, so any product letting users interact with AGPL code over a network, even without ever handing them a file, owes source code back.

This distinction matters directly if you're building API-first products, B2B SaaS, or anything self-hosted on a tool that later relicensed to AGPL, which is exactly what's happened with Redis and Elastic in recent years. And the cost of getting this wrong isn't hypothetical. In February 2024, Orange S.A. was ordered to pay hundreds of thousands of euros over a GPL violation. Sit with that number for a second.

Weak copyleft licenses: the boundary between modified files and the whole product

LGPL lets you link the library into proprietary code freely. The share-alike obligation only kicks in if you modify the LGPL library itself, not the larger application wrapped around it. MPL 2.0 works on similar logic but at the file level: change an original MPL-licensed file, and you owe disclosure on that file, even while it sits comfortably next to proprietary code in the same repository.

Where does this actually go wrong? Teams treat LGPL and MPL components like they're MIT licensed, because the surface-level freedom feels similar enough. Nobody's tracking whether the library itself got modified somewhere along the way, and that's exactly the wrong place to stop paying attention. The modification is the trigger.

There's a build-system wrinkle worth flagging too. Whether you statically or dynamically link an LGPL library can change your compliance picture entirely. That's a question your build engineers need looped in on, not just something a license reviewer signs off on alone.

No dramatic lawsuit needed to make this section's point, either. Just get the boundary line straight in your head: modifying the library activates the obligation, using the library on its own generally doesn't.

Source-available and fair-code licenses: the category that looks open but isn't

BSL and SSPL read like open source at a glance. The source sits there for anyone to inspect. But neither is OSI-certified, and both carry real restrictions on commercial use, particularly around cloud hosting or offering the software as a managed service.

BSL comes with a built-in expiration date: the license converts to an OSI-approved open source license no later than four years after initial public release. Until that date lands, though, the commercial restrictions apply in full. Four years sounds like a long runway, until you're the one building on top of it.

This category is also shifting under people's feet in real time. HashiCorp moved Terraform from MPL 2.0 to BSL in August 2023. Redis relicensed from BSD to SSPL and RSALv2 in March 2024, citing commercial sustainability directly. Elastic added AGPLv3 as a third licensing option in August 2024. Three companies, three separate moves, all inside about a year.

What should you take from that pattern? If your product builds on or wraps a database, an infrastructure tool, or a developer platform, the license category of that upstream dependency isn't something you check once at adoption and forget about. It's a line item you revisit, because the company maintaining it might change the deal on you without much warning.

Transitive dependencies: the obligations you didn't knowingly accept

Here's a number that should reframe how you think about your dependency tree: 64% of open source components found in codebases are transitive, according to the 2025 OSSRA report. Most of what's running in your product was never a decision anyone made directly. It came along for the ride.

Install one package, and you might be installing dozens more without ever realizing it. Electron alone pulls in 87 additional packages, each carrying its own license terms, independent of whatever you agreed to when you added Electron itself. And 56% of codebases contain license conflicts, most of them caused by exactly this: incompatible transitive dependencies stacking up in layers nobody ever reviewed.

The example everyone in this industry knows by heart is Log4j. The vulnerable version most commonly entered codebases as a transitive dependency, three or four layers removed from any deliberate choice anyone made. As of the 2025 OSSRA dataset, 11 codebases still contained vulnerable versions of it, years after the vulnerability went public.

Ignorance doesn't work as a defense here. A GPL or AGPL component sitting three layers deep in your dependency graph carries the exact same obligations as one you added on purpose. And a conflict between, say, Apache 2.0 and GPLv2 code buried somewhere in that graph can create an incompatibility that no amount of after-the-fact documentation is going to fix.

How AI-generated code creates a new category of unlabeled dependency risk

More than half of organizations now use AI coding tools, and adoption has spread widely across teams regardless of internal guidance. People use them anyway. Often quietly.

To understand why this is genuinely tricky, look at how AI-generated code actually enters your codebase. It can reflect patterns pulled straight from restrictively licensed training data, without carrying any attribution or provenance information along with it. A package installed through npm or pip shows up in a manifest file, gets tracked in a dependency graph, gets caught by an SCA scan. Code generated by an AI assistant skips all of that. No manifest entry, no license file, nothing for your scanning tools to catch. It just appears in your codebase, indistinguishable from anything your own team wrote by hand.

Only a minority of organizations conduct a real review of AI-generated code for IP, license, security, and quality risk, per the 2026 OSSRA data. That gap is going to widen before it narrows.

If you built your MVP leaning on AI tools and you're now heading toward a production rebuild, that rebuild is the moment to treat every AI-generated chunk of code as unverified. The concern is that you genuinely don't know its provenance yet, and that not-knowing is the risk itself.

Where obligations shift as a product moves from MVP to production

Most copyleft obligations wait for one specific trigger: distribution. Internal use, even at real scale inside your own company, generally doesn't set them off. AGPL is the outlier here, since network access alone counts as distribution under its terms.

Distribution covers more ground than people assume. Shipping a customer-downloadable app counts. So does offering a hosted or managed version of an open source tool. Certain OEM or white-label arrangements count too, even when no code technically leaves your servers in the traditional sense.

This is where the SaaS gray zone gets real. Run your product entirely server-side, and GPL copyleft obligations mostly stay dormant. Add a downloadable client, though. Ship an SDK. Offer an on-premise deployment option. The moment you do any of that, the obligation you thought you'd sidestepped switches on.

A lot of teams don't find out they have a problem until an acquisition forces the issue into the open. In one documented case, a $120 million acquisition surfaced undisclosed LGPL dependencies buried deep in core libraries, which triggered source-disclosure obligations nobody on the selling side had accounted for. That's an expensive way to learn a lesson a proper audit would have caught for a fraction of the cost.

Legal counsel is consistent on this point: handle license obligations during development, not after the fact. Educating contractors and outside developers early costs a lot less than untangling the mess at scale later. If you're rebuilding an AI-assisted or freelancer-built MVP onto real production infrastructure, that rebuild is the cheapest point in the entire lifecycle to get the dependency record straight.

Building a compliance process that doesn't depend on manual review

Manual license review doesn't scale past a handful of dependencies, let alone 911 of them. Software Composition Analysis tools, Black Duck, Snyk, FOSSA, Mend, scan your codebase and its full dependency graph, identify the license attached to every component including transitive ones, and flag conflicts before they turn into actual problems. This is baseline practice for any codebase heading toward production now.

A Software Bill of Materials, or SBOM, sits alongside that as the machine-readable inventory: every component, every license, formatted in SPDX or CycloneDX. Enterprise buyers ask for these as a matter of course now, and regulators are starting to require them outright.

The EU Cyber Resilience Act mandates SBOM maintenance for software sold in the EU market, with a compliance deadline that is approaching faster than most teams assume. That sounds distant, but any product you're building right now needs to satisfy those requirements by the time it actually launches, which puts the deadline closer than the calendar suggests. Non-compliance carries real financial weight too: fines run up to €15 million or 2.5% of global turnover.

The fix that actually holds up runs continuously. Wire the scan into your CI/CD pipeline so every build catches new dependencies, transitive ones included, before they ever reach production. Pair that with an SBOM management tool that ingests your bill-of-materials data, cross-references components against known vulnerabilities, and enforces the license policy rules you configure yourself.ately, security and license compliance, into a single workflow.

They're the same problem more often than people think, too. In the 2025 OSSRA report, 81% of risk-assessed codebases contained high- or critical-risk vulnerabilities. The unlabeled component quietly creating a legal obligation is frequently the exact same component carrying an unpatched CVE. If you're working with an engineering partner on a rebuild, SCA tooling and SBOM generation belong on the production-readiness checklist from day one, not bolted on afterward as a separate audit somebody remembers to schedule six months too late.