What is open source license risk?

Open source license risk is the possibility that an open source library, once integrated into a software product, imposes legal obligations through its license that the organization did not anticipate, up to forcing it to publicly release proprietary code it intended to keep closed. Open source licenses split into two families with opposite effects: permissive licenses (MIT, Apache 2.0) allow the code to be incorporated into a closed commercial product with no particular obligation beyond crediting the original author; copyleft licenses (GPL, and its weaker variant LGPL) require that, if the resulting software is distributed, it be released under the same license as the open source component it contains. For a strong GPL this means, in practice, having to publish the source code of the entire derivative work, including the parts written in-house: the effect the industry calls contamination, or license "virality." This is not disputed legal opinion: it is the central clause the GPL was written around, and courts have enforced it.

How the risk enters unchosen

Almost no organization deliberately integrates a GPL library into a commercial product knowing what that entails: the risk almost always enters indirectly, through a transitive dependency. A developer imports a permissive library to solve a specific problem; that library, in turn, depends on a smaller component under a copyleft license, perhaps two or three levels deep in the dependency graph, invisible to whoever wrote the original line of code. Nobody finds out until it matters: the software works, ships, and gets sold to customers for years. The problem resurfaces when someone goes looking for a specific reason, typically a legal audit ahead of an acquisition, a request from an investor during a funding round, or a public flag raised by a competitor or a free software activist who simply read the distributed binary.

An enterprise example

An Italian small business builds, over the years, a proprietary software module that becomes the differentiating core of its product, sold to dozens of enterprise customers under a closed license model. The company enters talks for a strategic acquisition, and the acquirer, as a routine part of technical due diligence, has the entire codebase scanned with an automated license-scanning tool. The tool finds a GPL library, imported years earlier by a junior developer as a transitive dependency of a logging package, never removed. The consequence is not theoretical: the acquirer demands a price cut, the urgent replacement of the component before closing, or walks away. None of these outcomes would have been necessary had the problem surfaced a year earlier, through routine review instead of under the pressure of a deal in progress.

Why it matters for decision makers

For whoever runs a technical organization, open source license risk is not managed by banning open source, which would be both impossible and counterproductive: it is managed by knowing which licenses are in use before someone else finds out first. An up to date SBOM, generated at every build, already lists the declared license of every component and turns this check into something automatic instead of an emergency project. Italy's Linee guida su acquisizione e riuso di software per le pubbliche amministrazioni from AgID and developers Italia dedicate an entire attachment to classifying open source licenses for exactly this reason: choosing a license, or auditing the ones already in use, is a governance decision, not a technical detail left to whoever writes the code. The worst possible time to discover a copyleft contamination is while a funding round or a company sale is already in progress.

This entry is informational and does not constitute legal advice: evaluating a specific open source license and its contractual implications requires a lawyer specialized in intellectual property.