3 ms·

I'm quite sure that screws are indeed something that, if made in a shoddy way, would have legal repercussions for those producing them. That's the norm - it's s

I'm quite sure that screws are indeed something that, if made in a shoddy way, would have legal repercussions for those producing them. That's the norm - it's software that's weird for not having that. I would actually expect screws are even rated for specific work. Also, people sell screws, so the analogy really makes no sense. I'm not suggesting that software developers be required to do anything if they're just writing code, and I'm not suggesting that they do things to some sort of extreme, as you seem to be implying, if they do distribute their code for use. > explicitly hobbyist-grade or inadequate for purpose that poses a problem Well, no, they're not explicitly hobbyist-grade. That would be fine if someone were just publishing code and saying "don't use this", but they are publishing code for distribution to package repositories. They don't have to do that, they could just leave it as open source code that isn't distributed, and note that it's not production quality explicitly as you suggest. Perhaps a more appropriate analogy would be if you were making dinner. You go to the farmer's market and someone with a booth their says "I'm giving away some free fruit, here you go". You would hope that someone who set up a stand at the market would be giving you fruit that's edible. If you went home and ate it, and then you got sick because it didn't meet food quality standards, you would not be the one liable, the vendor would be. "But the vendor gave it away for free!" Yes, but other than software the person giving you something is in fact liable for its quality. Anyway, analogies suck, I'm sure this misses plenty of important bits. Rather than argue about analogies, let's clarify the actual argument. 1. No one forces anyone to publish their code for distribution purposes 2. When you publish code with the intent for others to use it there should be an obligation to provide basic quality standards to avoid that code doing others harm

lstodd 4y ago
no.
Veserv 4y ago
Package repositories were never intended nor designed for anything other than hobbyist grade software. The have never offered any guarantees on the quality of their contents and in fact the vast majority of their contents are freely accepted without review and explicitly disclaim any fitness such as via Clause 15 of the GPLv3[1]: "THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION." If the quality of a package is not positively asserted, then it must be assumed to be hobbyist-grade regardless of how others wrongly treat it, how convenient it would be to assume it is not, or even if the quality is high but no explicit positive guarantee has been made to that effect. It is ultimately the responsibility of the users of a package to verify it is fit for purpose which demands either a positive, legally binding guarantee from the package creator or a assessment of the package itself (which would be easy if the quality is high, but no explicit guarantee was provided). To use a package while expecting guarantees on its function when it explicitly disclaims any guarantees is to use the package wrongly no matter how many others may do so and it is a problem with the user of the package, not the creator of the package who accurately advertised the quality of their package. It is the recognition of this fact and the usage of components that have actual guarantees about fitness for purpose that distinguish civil engineering from software development, not the quality of the underlying components; the quality of the underlying components follows naturally once liability is accepted and guarantees are required. [1]: https://www.gnu.org/licenses/gpl-3.0.en.html https://www.gnu.org/licenses/gpl-3.0.en.html

lstodd 4y ago

no.

Veserv 4y ago

Package repositories were never intended nor designed for anything other than hobbyist grade software. The have never offered any guarantees on the quality of their contents and in fact the vast majority of their contents are freely accepted without review and explicitly disclaim any fitness such as via Clause 15 of the GPLv3[1]: "THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION." If the quality of a package is not positively asserted, then it must be assumed to be hobbyist-grade regardless of how others wrongly treat it, how convenient it would be to assume it is not, or even if the quality is high but no explicit positive guarantee has been made to that effect. It is ultimately the responsibility of the users of a package to verify it is fit for purpose which demands either a positive, legally binding guarantee from the package creator or a assessment of the package itself (which would be easy if the quality is high, but no explicit guarantee was provided). To use a package while expecting guarantees on its function when it explicitly disclaims any guarantees is to use the package wrongly no matter how many others may do so and it is a problem with the user of the package, not the creator of the package who accurately advertised the quality of their package. It is the recognition of this fact and the usage of components that have actual guarantees about fitness for purpose that distinguish civil engineering from software development, not the quality of the underlying components; the quality of the underlying components follows naturally once liability is accepted and guarantees are required. [1]: https://www.gnu.org/licenses/gpl-3.0.en.html https://www.gnu.org/licenses/gpl-3.0.en.html