So you seem to be making an argument in favour of applying the phrase “supply chain” to OSS just as you would apply it to proprietary dependencies you build upo

So you seem to be making an argument in favour of applying the phrase “supply chain” to OSS just as you would apply it to proprietary dependencies you build upon, because it’s a framing that helps your business (even if it harms the OSS ecosystem, which is a point of mine you didn’t argue against). But I don’t think it would help the business either, since it’s a false abstraction. A supplier is expected to be holding themselves to certain standards—including literally, by way of ISO 31000 and similar. Your suppliers’ compliance with, say, risk management practices is what your risk management practices build upon: this is why you have procedures for choosing your suppliers. Furthermore, there’s an important reason for transaction relationship and contracts in some form or shape to exist—of course, ultimately you are responsible to your customers; but if something really bad happens, it is quite handy to be able to legally demonstrate that (1) you have done your work picking a reliable partner (if they actually comply with certain standards, they at least must have managed to convince relevant auditors—and are probably liable to them for lying) and (2) there is a paper trail that codifies your relationship with that partner, who may not have upheld their part of the deal. (Naturally, your compliance with risk management standards, having relevant contracts signed with your suppliers, etc. plays an important role in downstream partners’ willingness to work with you as a supplier: it’s turtles all the way down.) With OSS, no one owes you anything and your business is the final supplier in the chain; and if there’s no chain in any meaningful sense, the phrase is actively misleading to business decision makers.