How are measured nested dependencies or indirect usage


I have doubts on how does Tidelift considers the case where a client makes indirect usage of a “lifted” library.

Let’s say that a client has a project P, which directly depends on libraries L1, L2 & L3, and let’s also say that L1 & L2 depend on L4, and L3 & L4 depend on L5…

L1   L2    L3
└─┬──┘     │
  L4       │

Are only L1, L2 & L3 eligible to be rewarded? (for this specific project), and in case L4 & L5 are eligible too, how is their score computed?

My intuition tells me that it would be fair to make them eligible too, with a score inversely proportional to a growing function of the distance from the project to them, and proportional to a growing function of the number of intermediate dependencies that depend on them.

Something like (just as a vague idea):

score(lib) = value_from_static_analysis_and_other_factors(lib) * sum([W(pkg)/(1 + pow(dist(P, pkg), k)) for pkg in dependents(lib) ])


  • one of those pkg instances could be P as well, so dist(P, pkg) would be 0
  • dependents(lib) is computed, of course, only in the scope of the given project P
  • W(pkg) is between 0 and 1, and is a growing function of score(pkg), but of course it could be the constant 1. W ( P ) would be 1 by convention.
  • k >= 1.

Best regards


Thank you for asking this, I’ve been wondering the same myself! Look forward to hearing how this works!


Short answer is that we don’t currently consider direct vs. transitive (or distance through the dep graph) in which packages we pay; the rationale is that we’re asking for the same work from maintainers regardless, and we’re paying for work done. So L4 and L5 are paid just the same as L1-L3.

Long answer, the subscriber concern is that all the OSS that ships as part of their app is security-clean, licensing-clean, and going to be maintained into the future; it doesn’t really matter how said OSS happens to be factored into packages. Think about a package that starts out as one big package and decides to break up into lots of little ones (which has happened for sure), usually there’s then some kind of root package or meta-package that pulls in many of the new more granular packages.

That said, there are some ways in which a direct dep is different for subscribers. They’re more likely to think about which version they’re using and update it manually, for example. So this could be a factor to put in the mix eventually.


Thanks for the great question @castarco!

We’ve incorporated your question and @havocp’s answer into our docs at

1 Like