3 ms·

Do you demand that every screwmaker make aircraft-grade screws? Aircraft makers need screws and it would be very convenient to them to be able to go down to any

by Veserv 4y ago

Do you demand that every screwmaker make aircraft-grade screws? Aircraft makers need screws and it would be very convenient to them to be able to go down to any hardware store and just buy whatever screw they want since they are all up to spec. No need to evaluate their suppliers since everybody is required to make things up to their demanding standards. The problem with this is that not everybody needs expensive aircraft-grade screws. Most people only need hobbyist-grade screws, or construction-grade screws. The requirements depend on their usage and it is up to the consumer to correctly identify their requirements and use the appropriate product that is fit for purpose. The problem with software today is the rampant, careless usage of hobbyist-grade dependencies in critical software. It is the fault of the entities including dependencies that are explicitly hobbyist-grade or inadequate for purpose that poses a problem. It should not be the responsibility of makers of hobbyist-grade screws to produce aircraft-grade screws because the aircraft makers want to go to Home Depot and pick out whatever screw is the cheapest. The solution that matters today is holding the consumers of these endless software dependencies to task for the usage of substandard or even defective software components, whether open source or proprietary, like every other industry where you must use suppliers that are fit for purpose. To demand a change to the software that is explicitly marked as unfit for purpose is to solve the problem of a aircraft manufacturer using screws from Home Depot by making Home Depot required to only stock aircraft-grade screws while demanding they keep the prices the same.

staticassertion 4y ago
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

by Veserv 4y ago

staticassertion 4y ago

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