Transitive Dependencies and Hidden License Risk

When a team adopts an open source library, it reviews that library. It rarely reviews the dependencies that library brings with it, or the dependencies of those dependencies. Yet in a modern application the indirect set dwarfs the direct one. A handful of chosen packages can resolve into hundreds of components, each with its own license, its own maintainers, and its own capacity to change terms. The exposure that matters is usually not the package on your list. It is the package three levels below it that no one ever looked at.

What transitive dependencies actually are

A direct dependency is something you declared. You named it in a manifest, a build file, or a package list because your code needs it. A transitive dependency is something that direct dependency needs in turn, and so on down the chain. The package manager resolves the whole chain automatically, which is convenient and also the root of the problem. The software that ends up in your build is far larger than the software you chose, and the difference is invisible unless you go looking.

This matters for license risk because a license attaches to every component, not only to the ones you picked. The convenience of automatic resolution means you inherit obligations you never read. A permissive library at the top of your tree can sit on top of a copyleft library further down, and the obligation flows up to the software you ship. The depth hides it, but the depth does not dilute it.

Why hidden license risk concentrates in the indirect set

Three forces push license risk into transitive dependencies. The first is volume. Indirect components outnumber direct ones many times over, so by simple count most licenses in your estate belong to packages you did not choose. The second is attention. A review at adoption, if it happens at all, looks at the named library and stops there. The deeper graph is treated as the package manager's business, not the reviewer's. The third is change over time. A component you adopted years ago can relicense, and the signal that it changed never reaches the team that depends on it through two intermediaries.

The relicensing wave of recent years shows how this plays out. As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1, which restricts competitive production use. Redis moved to a dual model with the Server Side Public License as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021, and MongoDB moved to the Server Side Public License in 2018. When any of these sits in your tree as an indirect dependency, the new terms still apply to you. Source available is not open source, and the Business Source License and the Server Side Public License are not approved by the Open Source Initiative. A transitive path to a relicensed component is still a path to the obligation.

How a transitive relicense reaches production

The reach is the same whether a component is direct or indirect. A relicensed library that your code calls through three intermediaries is still running in your systems, still governed by the new terms, and still part of what a vendor or an auditor can ask about. The Business Source License restricts how you may use the software in production. The Server Side Public License attaches obligations to anyone who offers the software as a service. Neither cares how many hops separate your manifest from the affected node. The obligation runs to the software that is actually deployed, and your deployment includes the full resolved tree.

This is why an inventory that lists only direct dependencies understates the exposure. It captures the part of the tree that was chosen and misses the part that carries the risk. The gap between what is listed and what is deployed is itself a finding, because it is the space where a relicensed component can sit unnoticed until the cheapest moment to act has already passed. The broader pattern is covered in the hidden open source exposure in production.

The blast radius runs in both directions

A transitive dependency creates exposure that runs upward, toward everything that relies on it. One relicensed component deep in the graph can sit beneath many libraries, which sit beneath many services, which sit beneath many products. Mapping that upward reach is what tells you the true scope, and it is almost always wider than the single node suggests. The method for tracing it is set out in how to map your open source blast radius, and the way that scope converts into a number is covered in quantifying open source license exposure.

The width of that reach is also what sets the cost to fix it. A relicensed component buried under one service is a contained change. The same component buried under forty is a program of work. Knowing which case you are in is the difference between a measured plan and a scramble, and it is covered in the cost to cure open source license risk.

How to map the full dependency graph

Finding hidden license risk is a resolution problem, not a reading problem. The method is to resolve the dependency graph to its real depth, including the indirect components no manifest names, reconcile that graph against what is actually deployed, and confirm the current license state of every node against primary sources, dated, because this area moves quickly. Where a component has relicensed, you trace what it touches upward and record the reach. The output is a dependency tree with a license verdict on every node, direct and transitive, ranked by exposure so the few that matter rise to the top. An open source license risk assessment produces exactly this map, and the discipline behind it sits on the open source license risk pillar. The same tree feeds your software bill of materials, which is why the two efforts belong together rather than apart.

We are independent and buyer side. We take no vendor fees and resell no software, so the map and the recommendation reflect your risk and nothing else, including when the honest finding is that a deeply nested component is fine and needs no action. This is commercial and licensing risk advisory, not legal advice. For interpretation of specific license terms and your compliance position, engage your own counsel.