Dependencies can be lumped into two general categories: direct dependencies and transitive dependencies. Direct dependencies are the libraries your code directly calls and otherwise utilizes. Transitive dependencies are the libraries or other software that the direct dependencies utilize. Transitive dependencies are, essentially, dependencies of dependencies.
For example, Android is licensed under the permissive Apache license, version 2.0. However, buried in Android, among other dependencies, is a modified version of the GPL-licensed Linux kernel. Someone digging into the Apache stack could see some Linux elements and may wonder why the copyleft effect of the GPL doesn’t extend to Android as a whole.
As with so many things in law, and especially in the arena of open source license interpretation, the answer is, “it depends.” First, it should be said that as a user of software, you have an obligation to adhere to the applicable license, regardless of what the software is or what channel or means you accessed it through. You are technically legally responsible for complying with the obligations of all the licenses applicable to all the dependencies included with the code you obtained. There is no “umbrella coverage” provided by the fact that a product may be licensed under a permissive license. It’s expected that any user identifies all the applicable licenses and abides by the obligations. So the top-level license typically does not provide you with protections or a shield from the licenses applicable to other included components.
However, producing a complete Bill of Materials for every open source package that you intend to repurpose, and conducting a complete analysis of the obligations of all the licenses applicable to all the elements contained therein can be daunting—and at times impractical. Accordingly, a risk-based, triage- style approach is often used to consider the effort in light of the risk.