That software license is incredible
The author has absolutely no fucking clue what the code in this project does. It might just fucking work or not, there is no third option.
lmfao
GLWTSPL is my new favorite license lol
I mean, pretty sure legally that that’d be very bad for whoever makes contributions-
This is the exact reason why I’ve released this [license] with GLWT license and I have no intention to spend my time discussing or change the license. Try to figure out how you can use it on your project. Or don’t use it at all. I don’t care. Good luck.
—Ahmed Shamim, 2021The sentence “IN NO EVENT SHALL THE AUTHORS BE LIABLE” doesn’t fly where I live. You don’t get to choose wether or not you’re liable - the law decides who is liable. This thing is about as enforceable as those sovereign citizen license plates and would get the same reaction in a court room.
Plenty of other commonly used licenses have the same issue unfortunately and and the biggest nightmare (at least in my country) is laws against “misleading” or “deceptive” conduct. Telling someone you’re not liable for anything is blatantly misleading/deceptive.
Even if your software works perfectly, you are still breaking the law… a victimless crime that would normally fly under the radar or result in a “cut that shit out” order by the court… but it’ll really hurt your case if there is actually a victim (e.g. if your software has a bad security flaw that caused real damage).
That’s why organisations with big legal teams tend to choose licenses like Apache 2.0. Ones with language like “unless required by applicable law (such as deliberate and grossly negligent acts)”.
What country is that?
For anyone who is confused: This is exploiting an old soundness bug in the Rust compiler that is still present. The GitHub issue page has this comment from maintainers:
we already had a crate published on crates.io before which used this bug to transmute in safe code, see #25860 (comment).
this issue is a priority to fix for the types team and has been so for years now. there is a reason for why it is not yet fixed. fixing it relies on where-bounds on binders which are blocked on the next-generation trait solver. we are actively working on this and cannot fix the unsoundness before it’s done.
Giving off a lot of mixed signals with this one, lol 😅
It’s utilizing an obscure bug in the Rust compiler that unfortunately lets you circumvent the safety guarantees in order to produce undefined behavior - it’s mostly just a joke though, you will not run into the bug in normal code
Thanks for clarifying. Do you know what the bug is? I gathering it’s something to do with enums and boxing to enable a “safe” transmute, but couldn’t make sense of the code.
Scary compiler edge cases with value-type enums aren’t surprising though. Trying to implement that feature with memory safety and high performance sounds like a nightmare.
It’s essentially this issue https://github.com/rust-lang/rust/issues/25860
The code used to exploit the bug in this library is here: https://github.com/Speykious/cve-rs/blob/main/src/lifetime_expansion.rs
As far as I understand, the bug basically makes it so you can trick Rust into thinking any lifetime is actually 'static. From that, you can do all kinds of bad stuff.
My thoughts exactly!
Now, with cve-rs, you can corrupt your program’s memory without corrupting your program’s memory.
