The goal is to get some form of value back for sharing it... from those who otherwise wouldn't contribute (as a few do already). Even if seemingly small, it's better than nothing.
I agree it's vague... you could say for whatever the contributor(s) decide to merge but in any event it seems easy to fulfill the cause, especially since projects need continual maintainence.
At least it leaves some leverage in the hands of the authors/contributors against flat out freeloading. Normal MIT is essentially no strings attached.
It means if you're scared enough by the intentional vagueness of the term, either somehow contribute to fulfill the clause or don't use the software. Perhaps that's not how it would be interpreted, IDK, I'm not a lawyer.
It's a mix of all the above, I've written several OSS projects over the past 10 or so years. Recollecting on it, I typically get little value back by releasing it as OSS and license(s) pretty much guarantees this will happen.
If it's not shared at all few can benefit at all. So the goal is to strike a balance.
Thanks for sharing, I haven't seen these before. I'm curious what the viewpoint is from other devs are on sw with a license like this? Would you use sw under either of those licenses? (They seem reasonable to me).
> but keep in mind no license can protect you from misbehaviour
Agree. I've had this happen with my GPL sw. On a side note, I think github's copilot is a disservice to all developers in this regard as it effectively throws developers under the bus.