I dig it. And yeah, B has license costs, but those often go to a different cost center so they're invisible[1] . . and as we all know invisible things don't exist.

We'll agree to disagree that "lifetimes" are a real thing in software - I actually think this is a pretty fluid thing - but I'm going to extend your case here to illustrate how "lifetime" interacts with incomputable costs. We have the known license costs, as stated above, but then added to that we also have this unknown cost that represents "how much time my team needs to spend maintaining the vendor product". That cost is unquantifiable but it's going to go up the less tightly-defined the product is[2], and, as stated, there is an inverse relationship between "lifetime" and "tightly defined".

So you're in a situation where the lifetime is either very short, or the vendor costs are high. But you never know "how much my people will need to do at the very base level of vendor support" so the multiplier can take it way outside of the range of "acceptable" very, very rapidly, with just a small increase in scope/lifetime. You end up paying out more for the vendor support than you're making from the Product, thus operating the whole shebang at a loss.

I think this is much more of a problem when in a domain that's not commodified, or even worse, something that's extremely niche. I'm thinking of SGML and FOSI publishing systems, specifically, but it could go for anything way out on the fringes, like weirdo material-assembly-or-org-specific CAD functions. I'm going to go out on a limb here and say if your business depends on niche, you're really way, way, way better off in-housing that, then interfacing it with the commodified functions that can run off the vendor. There's no ceiling on how high the vendor costs can go with niche stuff.

[1] Please don't get me started on cost centers.

[2] For a given cost, Product grows in scope, less profitable for the vendor to staff for supporting it, support goes down.