Missing from the list: is its license and are all of its dependencies’ licenses compatible with my project’s?
Sure, but that concern probably comes last – after you’ve decided that you want somebody else’s code to solve some problem for you, but before you’ve decided from the eighty or ninety roughly-equivalent implementations of that functionality that a google search has surfaced.
If you’re doing system-as-a-service type work, then only the AGPL is a killer: everything else you can functionally ignore the terms of because you’re not distributing. (This is the reason for the popularity of SAAS: it lets corporations benefit from open source without contributing to it, even in the presence of viral licenses.) There aren’t all that many AGPL libraries.
I disagree that it comes last. The third and fourth questions in the list you linked are “What would I do if I do need to make changes to it?” and “Am I treating code in the dependency as not part of my software?”. I don’t think you can answer those without spending some thought on licensing. And while there are not that many AGPL libraries, it pays to look. As seen here, very recently.
In an SAAS context, maintenance schedule, project complexity, & interface stability are more likely to knock out the possibility of using a dependency than license with regard to those concerns.
Maintaining a fork (whether it’s internal or external) is tough when there’s very heavy development being done upstream, but it becomes necessary if you need to preserve an interface for a dependency that you don’t want to integrate deeply with or you need to add a feature or modify implementation detals for a dependency (ex., an otherwise-good library is doing an important task with an O(n^3) algorithm but you need to throw six terabytes of data at it so you replace it with an O(logn) algorithm).
It’s not that I don’t think one should look at licenses at all. In fact, when this gets done in my office, licenses are typically one of the first things we look at. It’s just that it’s easier to eliminate potential dependencies by identifying that they don’t actually have the features you need, or that those features don’t have anywhere near the performance you need. Once you’ve eliminated dependencies that couldn’t possibly work, of the remaining possibilities, the ones that are smallest (and therefore easiest to audit and maintain) tend to be permissively licensed anyhow.
That’s certainly fair. My orientation is usually more toward shipping software to be used in a customer environment than toward SAAS.
But in either case I like to look at licenses early as I’m considering the questions you linked because it’s a quick filter that can spare you spending time on things you need to consider at greater length.