Should I give attribution for transitive dev-dependencies?

Question

I'm working on a library/cli-tool for bundling dependency licenses into a single file. Currently, I'm trying to collect licenses of: direct dependencies, transitive-dependencies and direct dev-dependencies.

In other words, I'm trying to collect licenses of packages, that are installed in node_modules. Transitive dev-dependencies are not installed by the package manager, because of the very nature of dev-dependencies.

I'm worried, whether or not code portions of those transitive dependencies somehow can be included in installed packages.

For example: Project "A" depends on Package "B". Package "B" has Transpiler "C" as a dev-dependency. Code generated by Transpiler "C" in Package "B" includes not only simple transpilation result, but also some polyfill for a function, that is not available in older browsers, from Transpiler "C". But, because Transpiler "C" is a transitive dev-dependency, it is not installed in node_modules of Project "A", so without manually installing it, Transpiler "C"-s license cannot be properly obtained, can it? Even if we could, we will have to look for Transpiler "C"-s dependencies/dev-dependencies too, etc, etc.

In this hypothetic case, we have only one transitive dev-dependency, but, in real-world scenarios, there could be hundreds. There could be several versions of the same package defined as a transitive dev-dependency in different packages. By manually installing transitive dev-dependencies for collecting license information, these transitive dev-dependencies could have their own dev dependencies, which will be needed to be installed too. This process will have to be repeated until all transitive dev-dependencies of all transitive dev-dependencies are installed.

Question is: Should I care for collecting license information about transitive dev-dependencies? And if I should, to which point?

I already care for regular transitive-dependencies, but I'm worried for transitive dev-dependencies.

Answer 1

This is a really tricky scenario, which is why automated license compliance tools can only go so far. Your analysis seems generally correct.

In practice, I would expect that the license of B doesn't just cover B's original source code, but also B's transpiled code (at least if B is distributed in transpiled form). This would neatly sidestep the issue of transitive dev dependencies. However, this points to a more general problem: license metadata might not be accurate, another reason why automated tools only go so far.

If you are designing a general-purpose tool, it might be useful to add an option that also triggers analysis of dev dependencies and transitive dev dependencies, by fetching metadata for tools mentioned in the package metadata (no need to actually install them). By default, I would not expect dev dependencies to have any direct effect on the licensing status (although, as you correctly explain, especially polyfills could violate this expectation).