Hacker News Reader

Comment by lucasyvas | Hacker News Reader

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.

View on HN

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.

Yeah but thats not on demand support. They never say that you can demand a bugfix and they are obliged to provide it. Again, those bigfixes are provided as is. The author os talking about companies wanted to essentially raise tickets and get on demand support. Which no one in their right mind provides for free

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.

Reply on news.ycombinator.com