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 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.