What is transitive dependency

Definition

A transitive dependency is a piece of software your application depends on through another dependency rather than directly. When you add a library to your project, that library has its own dependencies, and those have theirs, and so on down the chain. The components you declared are your direct dependencies. Everything pulled in beneath them is transitive. If your code uses library A, and A in turn requires library B, then B is a transitive dependency of your project even though you never named it. In a typical application the transitive layer is far larger than the direct one, often by an order of magnitude, which means most of the open source you actually run is software you never consciously chose.

Why transitive dependencies carry hidden license risk

The license of a transitive dependency binds you just as a direct one does. A copyleft license such as the GNU AGPL, or a source available license such as the Business Source License, attaches its obligations regardless of how the component entered your tree. This is where most hidden license risk lives. A team reviews the licenses of the dozen libraries it declared and considers the question closed, while hundreds of transitive components sit beneath them unexamined. A restrictive license can ride in several layers down, carrying conditions no one reviewed, simply because a direct dependency depends on it. The transitive layer is precisely the part of the tree that intuition does not cover, which is what makes it dangerous.

How relicensing reaches you through the chain

Transitive dependencies are the path by which a relicensing event reaches a stack that never adopted the affected project directly. When a project changes its terms, every project that depends on it inherits the change, and the new license flows down the chain to everything beneath. A component that HashiCorp, Redis, or Elastic moved to source available terms can sit two or three layers down in your tree, reaching you through a direct dependency you trust, with no visible signal that anything changed. Source available is not open source, and these licenses are not approved by the Open Source Initiative, so the obligation that arrives indirectly is real. The license state of every node matters, not only the ones you picked, and the version actually resolved in your build is what governs, not the version you remember.

How to find what you depend on

Finding transitive dependencies requires resolving the full tree, not reading the manifest. Package files list what you declared. Only a complete resolution, the kind a real software bill of materials produces, reveals every layer and the license each node carries. That full map is the foundation of any serious license risk review, because a finding cannot be acted on if the component is invisible. Mapping it is the first task of an open source license risk assessment.

Related reading

For the tooling that resolves and inspects the full tree, see what is software composition analysis. For how the licenses of components beneath you can clash, read what is license compatibility. Both sit alongside the rest of our open source license risk glossary.