I am not a supplier (2022)
softwaremaxims.com
softwaremaxims.com
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.
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.
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.
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.
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.
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.
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.