>You know what's a waste of time? Telling people something you already told them in your license.
Uh, the whole point of the comment was that license doesn't say how serious the project is.
It's not about boilerplate disclaimers...
> It's very useful advice. If you can't discern whether something FOSS will be useful to your business or not then don't base your business on FOSS code. Simple.
"don't use code in production that disclaims liability" is useless. All code disclaims liability. The "if you can't discern if it's useful" doesn't convert such a pointless phrase into good advice.
It's like saying "if you can't determine which foods are healthy, don't eat food that comes in amounts". If someone can determine, the advice doesn't apply, and if they can't determine... you just told them to starve? That advice helps nobody.
Food, that analogy doesn't apply because nobody is dying here.
And it is about boilerplate disclaimers. That's my entire point. "Add a boilerplate disclaimer reiterating what your license says if you really really mean it" is what your argument boils down to. How do you make it not boilerplate? Require then to write a 200 page report in their own words? If the license disclaimer means nothing, no number of disclaimers will mean anything more. If the advice helps nobody so will an additional disclaimer.
> Food, that analogy doesn't apply because nobody is dying here.
A typical business is going to die if it can't get software.
> And it is about boilerplate disclaimers. That's my entire point. "Add a boilerplate disclaimer reiterating what your license says if you really really mean it" is what your argument boils down to.
No, please read what people are saying.
The request is for a basic description of how serious the project is. Whether it's a super slapdash proof of concept, or a basic implementation with half the features stubbed out, or a mostly complete but unstable project that, or something battle-tested and heavily documented and maintained full-time, or other places in between or outside those lines. Whether they even want bug reports; whether they even want patch submissions.
All of those very different projects could have the exact same license. The exact same disclaimers.
The request is for information that does not belong in a license, and is not put into a license. Nobody is asking for a restatement or rewrite of the license.
A business that would die without software will write it's own software. A business that would die without getting that software for free is not a viable business.
I can see putting some message of intent as a developer, but people change their minds. Lots of the problems we see today that we are discussing involve people who started out with an intent to maintain full time but then for burnt out or otherwise lost interest. A message of intent like you say does nothing for a business already dependent on their work. This scenario is the more common problem with these dependency chains and what I thought we were discussing, most slapdash proof of concept projects say so in a README. If you can't discern whether you can depend on something, then you need to be prepared to take over the project or live without it.
> A business that would die without software will write it's own software. A business that would die without getting that software for free is not a viable business.
A business will not write its own OS, and commercial OSes have the same disclaimers. You didn't say "if you have a hard time discerning, don't use FOSS code that disclaims liability". You said "if you have a hard time discerning, don't use code that disclaims liability". (slightly paraphrased)
> I can see putting some message of intent as a developer, but people change their minds.
And then you can update the message. All the more reason not to tie it to license files.
> most slapdash proof of concept projects say so in a README
Sometimes. Less often can you tell the difference between a mildly serious project and a very serious project at a glance.
> A message of intent like you say does nothing for a business already dependent on their work.
> If you can't discern whether you can depend on something, then you need to be prepared to take over the project or live without it.
Anything could change, but knowing the intent gives you a much better starting position. And it's better to put it somewhere it can be seen in under a minute rather than after a chunk of time in investigation, especially because there might be a whole pile of dependencies to examine.
Uh, the whole point of the comment was that license doesn't say how serious the project is.
It's not about boilerplate disclaimers...
> It's very useful advice. If you can't discern whether something FOSS will be useful to your business or not then don't base your business on FOSS code. Simple.
"don't use code in production that disclaims liability" is useless. All code disclaims liability. The "if you can't discern if it's useful" doesn't convert such a pointless phrase into good advice.
It's like saying "if you can't determine which foods are healthy, don't eat food that comes in amounts". If someone can determine, the advice doesn't apply, and if they can't determine... you just told them to starve? That advice helps nobody.