Hobby projects that prove useful have a tendency of starting to be used in production code, and then turning into CVEs down the road.
If there is a conscious intent of disregarding safety as you say, the Readme should have a prominent warning about that.
> Hobby projects that prove useful have a tendency of starting to be used in production code
Even if that is true, how is that the authors problem? The license clearly states that they're not responsible for damages. If you were developing such a serious project then you need the appropriate vetting process and/or support contracts for your dependencies.
I didn’t say it’s the author’s problem. It’s a problem with the code.
Why play all these semantic games? You're saying it's the author's problem. You want them to even edit their readme to include warnings for would be production/business users who don't want to pay for it.
GP is arguing about licences. Yes, formally there is no obligation, and I'm not saying the author has any such obligation.
In the present case, either the missing overflow check in the code is by mistake, and then it's warranted to point out the error, or, as I understood GGGP to be arguing, the author deliberately decided to neglect safety or correctness, and then in my opinion you can't reject the criticism as unwarranted if the project's presentation isn't explicit about that.
I'm not making anything the author's problem here. Rather, I'm defending my criticism of the code, and am giving arguments as to why it is generally good form to make it explicit if a project doesn't care about the code being safe and correct.
I understand your point and if I were the author I would want either a disclaimer or a fix. File an issue or make a pr. Filing an issue is quicker and more fruitful than dealing with folks here
It is useful to understand the limitations of such hobby programs to know what they are useful for.
[flagged]
Layer8 DID the thing though, skimmed through the code and thought about security issues.
[dead]
> If there is a conscious intent of disregarding safety as you say, the Readme should have a prominent warning about that.
What do you consider this clause in the LICENSE:
>> 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 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.
A standard clause you can find in every open source license? It doesn't say anything about how serious the project takes security
You write only Rust code don't you?
I wish ;) You're talking about how Rust code usually uses the MIT license and this is a part of the MIT license?
Every open source license has a very similar clause, include but not limited to BSD, GPL, CDDL, MPL and Apache.
then that is their problem, not the code author's. If you use a hobby project in production, that's on you
When such a library is used in production code, that's on the person who chose to use it in production, not on the original author of the library.
You are responsible for the code you ship, doesn't matter whether it's written by you, an LLM, or whether it's a third-party dependency.
While that is certainly true, we could also be nice and reduce the workload of someone reviewing their dependencies and write it down in the readme.
My personal take is: if the code is good enough, it should be trivial to switch to a better library at the point when needed.