2 ms·
I wanted to say that the title is being a bit too slick in using “supplier” instead of “member of your supply chain”, but then I realized while that’s true, it’
by mananaysiempre 4y ago
I wanted to say that the title is being a bit too slick in using “supplier” instead of “member of your supply chain”, but then I realized while that’s true, it’s not really the point.
The point, as I read it, is that the your relationship's with an open-source maintainer as their downstream is very much unlike your relationship with any of your suppliers (or other suppliers, if you want to insist), because you haven’t negotiated a business relationship with them (and they may not necessarily even want one in the traditional sense). Thus it is, in fact, unhelpful to refer to them as “suppliers” in order to draw an analogy with your normal suppliers, because they can and will tell you to go take a hike if you treat them like one of those. And given the nature of open-source software and the amount of business leverage you have over them (none, if you go about it the way most commercial consumers of open-source code do), it’s not unreasonable of them to do so. (Distro maintainers, for example, need a very special set of social skills for handling ornery upstreams, even though they both receive more understanding for their demands, being volunteers themselves, and do actually have some leverage in the form of being the main form of getting your software in front of users.)
(This is the part where I disagree with the article: the important part is not that, legally, the usual license terms mean they can refuse to provide support; it’s that, socially, it’s not unreasonable of them to do so. Google and Facebook also have license terms like that, but people do argue it’s still bad of them.)
Perhaps looking into the analogy the term “software supply chain” is intended to evoke is more helpful. One possibility, which is what most engineering users of it (among others) intend, is, indeed, that your open-source dependencies are your liability the same way as your traditional supply chain is, and that’s true. Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false. Given that the liability and the entitlement are two equally important and mutually supporting sides of the standard supplier relationship, there is reason to dislike the an analogy that is only correct in half of its implications.
You’re free to disagree with any of this, to be clear, it’s just that you’ve said the article is only playing word games, while on my reading it does seem to have a point, as above.
- marcosdumay 4y ago> the your relationship's with an open-source maintainer as their downstream is very much unlike your relationship with any of your suppliers Hum... It's almost equal. For a start, you can demand anything that you have negotiated on, and can kick sand or try to pay outside if you want something else. That's the point he author wants to talk about, but I don't think he has a good grasp of supplier - consumer relations.
- mananaysiempre 4y agoHuh. OK, that’s fair. I guess a more precise phrasing would be: the relationship is indeed almost the same as far as the rules of engagement are concerned, but the default starting point is very different: with a conventional supplier you don’t (get to) start using their product in yours until after basic terms have been negotiated, almost necessarily including some kind of right to have the supplier fix their stuff if it’s broken in an obviously stupid way. Open-source things, though, individual devs can and do just pick off the floor. (Not necessarily good from a security standpoint, but hinder that process too much and work slows down to an extent most businesses won’t be able to afford, much like with installing outside software.) Which means that if you find some in your codebase and treat the author as you would any baseline supplier[1], just because there’s no way you wouldn’t negotiated the corresponding terms, you rightly get called an arsehole. This pattern of problematic behaviour predates the “software supply chain” meme, I think, but the fact that the meme seems to justify it in the minds of some people is a reason to dislike this analogy. Even if, as I said before, the other, liability half of it is entirely true. [1] https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquiry-response-required/ https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir..., https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644#c8 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644#c8, and I’m sure I’ve seen more of those