I’ve seen more and more visceral rejection of the notion of “software supply chain” by source contributors. They’re rightly calling out the hypocrisy of companies demanding they be complicit in the supply chain of a product, but not paid or compensated for their works on it.
There is no “software supply chain”, only products you didn’t pay for but still expect slave labor to support in perpetuity.
On the flip side, I’ve never known a project to reject work while being paid a livable wage to complete it. Funny, that.
reverendsteveii · 2h ago
your insistence that people doing what they want on their own time and then disposing of the product as they see fit is "slave labor" undermines your otherwise valid point.
stego-tech · 1h ago
Your deliberate misconstruing of my argument to support a point I wasn’t remotely making undermines your entire comment.
Expected or required labor that is not compensated is, well, slavery. Labor that is freely given without expectation of compensation or reward is volunteerism.
Trying to guilt open source projects into addressing security, regulatory, or feature concerns under some sort “digital supply chain” label without compensating them for their time or labor is a form of entitlement on the part of companies who could easily pay for the resources they consume or contribute the fixes themselves, but choose not to. Demanding said labor without compensation, with or without threat of consequences, is to demand the other party willfully submit to a form of enslavement or servitude.
I’m specifically talking about “digital supply chain” labels and logistics being applied to Open Source projects without their consent or compensation. You don’t get to magic up some excuse to not call the demand for free labor without compensation as anything other than what it actually is.
bee_rider · 1h ago
Expected labor that is not compensated is not slavery. It could is rude to expect people to do labor for us for free, but there’s no compulsion behind it.
Required labor that is not compensated flirts with slavery.
Part of the danger of a software supply chain law is that, as a law, it can compel behavior. So, it is runs the risk of bumping stuff from the “expected” to “required” bucket.
> Demanding said labor without compensation, with or without threat of consequences, is to demand the other party willfully submit to a form of enslavement or servitude.
A demand without a threat of consequences is just a request. It could be a very rude request. But that’s all it is.
Conflating rude requests with compelled actions cheapens the impact of the latter, and obscures what is wrong about the former.
reverendsteveii · 1h ago
when is labor required of FOSS? I always assumed that I was perfectly free to not write FOSS but I'd be interested to find out in what manner I can be compelled to do so. Keep in mind that asking, even asking forcefully or impolitely, is not compulsion. Compulsion is about what happens if the request is not fulfilled.
bee_rider · 3h ago
Is there much push anymore, behind the “open source software supply chain” concept? It seems like a very misguided and bad idea, but I actually wonder if the open source community actually managed to get that point through to policy makers? At least I haven’t heard anything about it lately (I’m not particularly listening, though).
zappb · 2h ago
The EU has been working on regulations related to this over the past couple of years. Various OSS foundations have been tracking this like Apache, Linux, and Eclipse Foundations.
detaro · 2h ago
Yes, and the regulations and guidelines coming out are looking good with regards to open-source, it seems they've gotten into the right places to be heard. (Basically they protect people just providing open-source from liability and force companies to have plans how they'll deal with their open dependencies)
Counter-argument to the author: If you publish a package you are a supplier full stop. If you don’t want to be considered a supplier, do not publish a built version of your software.
Allow someone else to build and publish it on your behalf (i.e. a separate distributor entity), then they become the supplier. They assume the risk - they can establish those business relationships.
This is how software distribution has worked in Linux forever. For example, it’s Debian’s or Red Hat’s problem to fix a bug in a library they ship and they can upstream it back to you if they want.
Do not publish your package, only provide the source. Publish it for only yourself privately if you wish to consume it. Promote it, provide build scripts… whatever. But don’t publish it.
bee_rider · 3h ago
That seems like a totally artificial distinction. If somebody releases a compiled version of their project along with the source code, just to save their friends time, they aren’t any more responsible for it that they were for the source code.
The responsibility is entirely a matter of licensing and contracts. Most free software doesn’t accept any responsibility in the license, and isn’t sold, so there’s no implied warranty or anything like that.
lucasyvas · 3h ago
It seems artificial at face value but the distribution model has existed for decades under the same conditions.
The argument is that we should split these two concerns explicitly to create a delineation of roles and responsibilities. We have a model for this but don’t adopt it elsewhere in the name of simplicity, but the outcome is more complex because you can’t point the finger at anyone.
It should work as you say, but it doesn’t and arguably never will. So I suggest we deliberately change everything to the distribution model to make it explicit. It then becomes clearer that the distributor is who you go to for support. If the author is the distributor, go to them. If it’s someone else, go to the entity that distributes it. If there is no distributor, it’s on you to build it and support it yourself.
It forces the build process onto the distributor which makes them best set up to deploy fixes, therefore it’s more clearly their responsibility. The shifting of where it builds actually goes a long way to solving this problem. If you are building and publishing it yourself, you are set up to fix the issue immediately which indicates you should fix it first and then upstream it.
bee_rider · 3h ago
What form does has this responsibility taken for decades? I use Ubuntu currently, if Canonical broke my computer I’d fully expect to have no recourse…
lucasyvas · 3h ago
If there’s a bug in SSH libraries that Canonical ships in Ubuntu, that is their distribution of that library even if they are not the primary authors. Canonical guarantees support for the software it ships, so they are obligated to fix it no matter what. Fixes are upstreamed to the primary author - the author never asked for their software to be included in that distribution so it’s not their problem to fix it for Ubuntu users.
This is a model that solves the problem the author is discussing.
bee_rider · 3h ago
Are we talking about, like, legal liability or just a feeling of social obligation?
I think with software supply chain, we’re talking about the former, and I don’t think Canonical has any legal liability toward me (who hasn’t paid them anything; although because I expect nothing I didn’t read the license in detail). In terms of feelings of social obligation it is much more complex, of course.
lucasyvas · 3h ago
Social obligations are inherently weak is the point I’m trying to make. Make it easy for active users of your software to distribute it and make it harder for free-loaders. The problem solves itself.
samrus · 3h ago
Where does Canonical say they guarantee support? They might for their paid program, but they dont for their free version. Which is the exact point the author made
lucasyvas · 3h ago
Ubuntu literally has LTS releases where they guarantee fixes for security issues and the like for absolutely no charge.
Aeolos · 2h ago
Almost all open-source software comes with a version of the following license terms:
"THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
To use the software you have to accept the license, which means you explicitly confirm that they are not your supplier. Pretty clear cut, no?
Edit: EULA-loving companies don't want to accept the license terms for the _free_ software they themselves are using - the hypocrisy is nothing short of staggering.
There is no “software supply chain”, only products you didn’t pay for but still expect slave labor to support in perpetuity.
On the flip side, I’ve never known a project to reject work while being paid a livable wage to complete it. Funny, that.
Expected or required labor that is not compensated is, well, slavery. Labor that is freely given without expectation of compensation or reward is volunteerism.
Trying to guilt open source projects into addressing security, regulatory, or feature concerns under some sort “digital supply chain” label without compensating them for their time or labor is a form of entitlement on the part of companies who could easily pay for the resources they consume or contribute the fixes themselves, but choose not to. Demanding said labor without compensation, with or without threat of consequences, is to demand the other party willfully submit to a form of enslavement or servitude.
I’m specifically talking about “digital supply chain” labels and logistics being applied to Open Source projects without their consent or compensation. You don’t get to magic up some excuse to not call the demand for free labor without compensation as anything other than what it actually is.
Required labor that is not compensated flirts with slavery.
Part of the danger of a software supply chain law is that, as a law, it can compel behavior. So, it is runs the risk of bumping stuff from the “expected” to “required” bucket.
> Demanding said labor without compensation, with or without threat of consequences, is to demand the other party willfully submit to a form of enslavement or servitude.
A demand without a threat of consequences is just a request. It could be a very rude request. But that’s all it is.
Conflating rude requests with compelled actions cheapens the impact of the latter, and obscures what is wrong about the former.
2022 (389 points, 240 comments) https://news.ycombinator.com/item?id=34201368
Allow someone else to build and publish it on your behalf (i.e. a separate distributor entity), then they become the supplier. They assume the risk - they can establish those business relationships.
This is how software distribution has worked in Linux forever. For example, it’s Debian’s or Red Hat’s problem to fix a bug in a library they ship and they can upstream it back to you if they want.
Do not publish your package, only provide the source. Publish it for only yourself privately if you wish to consume it. Promote it, provide build scripts… whatever. But don’t publish it.
The responsibility is entirely a matter of licensing and contracts. Most free software doesn’t accept any responsibility in the license, and isn’t sold, so there’s no implied warranty or anything like that.
The argument is that we should split these two concerns explicitly to create a delineation of roles and responsibilities. We have a model for this but don’t adopt it elsewhere in the name of simplicity, but the outcome is more complex because you can’t point the finger at anyone.
It should work as you say, but it doesn’t and arguably never will. So I suggest we deliberately change everything to the distribution model to make it explicit. It then becomes clearer that the distributor is who you go to for support. If the author is the distributor, go to them. If it’s someone else, go to the entity that distributes it. If there is no distributor, it’s on you to build it and support it yourself.
It forces the build process onto the distributor which makes them best set up to deploy fixes, therefore it’s more clearly their responsibility. The shifting of where it builds actually goes a long way to solving this problem. If you are building and publishing it yourself, you are set up to fix the issue immediately which indicates you should fix it first and then upstream it.
This is a model that solves the problem the author is discussing.
I think with software supply chain, we’re talking about the former, and I don’t think Canonical has any legal liability toward me (who hasn’t paid them anything; although because I expect nothing I didn’t read the license in detail). In terms of feelings of social obligation it is much more complex, of course.
"THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
To use the software you have to accept the license, which means you explicitly confirm that they are not your supplier. Pretty clear cut, no?
Edit: EULA-loving companies don't want to accept the license terms for the _free_ software they themselves are using - the hypocrisy is nothing short of staggering.