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.
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.
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.
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.
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.
Even now, the CRA is very vague -- any commercial activity tenuously related to a piece of software you share can force you to do work for the EU. Of at least try, if you don't tell the EU to shove it. And that commercial activity doesn't even need to be in the EU.
I feel there must be a middle ground here. It's similar to free food. Giving food to anyone does not entitle them to more food in the future. They are not entitled to complain free food is not up to their standards or demand changes.
But they are entitled to not being poisoned. Basic sanitation is still required. You should remove free food from the public once it's rotting.
Food going bad is a universal problem of food, we should optimize our handling of food (and write all our laws) under the assumption that it is always in the process of going bad.
Code doesn’t just turn dangerous on its own. Good code is good code, it can be turned bad by conscious effort on the part of somebody, but that’s an active decision that somebody makes and is responsible for.
Also, all food is for eating. Code has different uses. Most is not hardened against security threats, because it is only designed to be run locally by the user, and it is total fine in that use-case. Designing code that is appropriate to be exposed unprotected to the internet is unbelievably difficult, so most code won’t be up to the task. We shouldn’t lose useful code just because it can be used out-of-scope dangerously.
The risks with food are also generally higher, because almost everyone is able to ingest it. And potentially get very sick or die. So, bad food is a big risk. Bad code is not such a big risk because anyone who knows what to do with it has already passed some skill hurdles as far as understanding it goes. And it is rare to get sick or die from code.
Most code should be left up, maybe with a note that says it is unmaintained, if it is unmaintained.
I really love Rob Mensching's framing in Open Source Maintenance Fee[1]. "The _software_ is free. The _project_ (issue tracker, forums, release management, package repository, etc.) is not."
It doesn't solve the supplier problem, but it is a very clever way to square the "free software, but I'd like to cover my expenses" circle.
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).
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.
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.
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.
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.
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.
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.
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.
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
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.
At least Node.js and Rust distribute dependencies as source. NPM and Cargo automate adding and compiling dependencies.
But, to be quite blunt: I've put a few hobby packages up on Cargo and NPM just to see if other people like them. If you think I'm going to assume liability if someone hits a bug, then you're in for a rude awakening.
The source code is available for free for anyone who wants to use or modify it. If it doesn't meet someone's needs, they can fix it themselves or contact me and we can work out a mutually beneficial arrangement.
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.
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.
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.
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.
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.
The EU certainly proposed something not far off. And it took the python foundation threatening to block all users from the EU to partially shelve it.
The compulsion: jump through EU paperwork hoops, perform security work, and fix bugs on demand or face ruinous fines.
https://pyfound.blogspot.com/2023/04/the-eus-proposed-cra-la...
Even now, the CRA is very vague -- any commercial activity tenuously related to a piece of software you share can force you to do work for the EU. Of at least try, if you don't tell the EU to shove it. And that commercial activity doesn't even need to be in the EU.
I feel there must be a middle ground here. It's similar to free food. Giving food to anyone does not entitle them to more food in the future. They are not entitled to complain free food is not up to their standards or demand changes.
But they are entitled to not being poisoned. Basic sanitation is still required. You should remove free food from the public once it's rotting.
Food is not really that similar to software.
Food going bad is a universal problem of food, we should optimize our handling of food (and write all our laws) under the assumption that it is always in the process of going bad.
Code doesn’t just turn dangerous on its own. Good code is good code, it can be turned bad by conscious effort on the part of somebody, but that’s an active decision that somebody makes and is responsible for.
Also, all food is for eating. Code has different uses. Most is not hardened against security threats, because it is only designed to be run locally by the user, and it is total fine in that use-case. Designing code that is appropriate to be exposed unprotected to the internet is unbelievably difficult, so most code won’t be up to the task. We shouldn’t lose useful code just because it can be used out-of-scope dangerously.
The risks with food are also generally higher, because almost everyone is able to ingest it. And potentially get very sick or die. So, bad food is a big risk. Bad code is not such a big risk because anyone who knows what to do with it has already passed some skill hurdles as far as understanding it goes. And it is rare to get sick or die from code.
Most code should be left up, maybe with a note that says it is unmaintained, if it is unmaintained.
I really love Rob Mensching's framing in Open Source Maintenance Fee[1]. "The _software_ is free. The _project_ (issue tracker, forums, release management, package repository, etc.) is not."
It doesn't solve the supplier problem, but it is a very clever way to square the "free software, but I'd like to cover my expenses" circle.
[1]: https://opensourcemaintenancefee.org/
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).
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.
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)
Discussion in 2024 (121 points, 37 comments) https://news.ycombinator.com/item?id=39904234
2022 (389 points, 240 comments) https://news.ycombinator.com/item?id=34201368
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.
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.
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.
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…
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.
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.
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.
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
Ubuntu literally has LTS releases where they guarantee fixes for security issues and the like for absolutely no charge.
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.
At least Node.js and Rust distribute dependencies as source. NPM and Cargo automate adding and compiling dependencies.
But, to be quite blunt: I've put a few hobby packages up on Cargo and NPM just to see if other people like them. If you think I'm going to assume liability if someone hits a bug, then you're in for a rude awakening.
The source code is available for free for anyone who wants to use or modify it. If it doesn't meet someone's needs, they can fix it themselves or contact me and we can work out a mutually beneficial arrangement.