Small developers and companies without layers of lawyers will read the licence, see that it says "do what the ---- you want", and use your code accordingly.
Big companies with layers of lawyers will read the licence, blanch in terror, and either refuse to use the software, or contact you for alternative terms.
Case in point: Google forbids use of the WTFPL. https://opensource.google.com/docs/thirdparty/licenses/#wtfp...
We go over it in new googler training (and our reasoning is on the Google open source policy site we publish: https://opensource.google.com/docs/thirdparty/licenses/#wtfp...)
You are welcome to not (but if you go and look, it's completely consistent with my viewpoints and history in OSS so ...).
I would love to live in a world where WTFPL is a good license, but we don't live in that world, and wanting it to be so will not change that.
I can also tell you stories of companies we've acquired who had bad experiences, FWIW.
So the "small companies" you think are being served, aren't.
You clearly didn't read the link i said which says our issue with WTFPL is with the lack of warranty disclaimer and with the rights grant (which is not likely to be valid in a number of countries).
You will find nothing, nor have i stated anything about the ability for google to use the code for "monetization" reasons. It doesn't even enter the equation
It is very hard to take your comment in good faith as a result.
Our policy pages are clear on why we ban licenses, even things like AGPL. You'll note they are not economic concerns (IE google won't be able to monetize), but compliance ones.
(Of course, you should view these in good faith, they were originally written for an internal audience)
I can definitively state I have never banned a license at Google due to Google's ability to "monetize" the code, or even indirect versions of that (IE that if it became popular, it would hurt google's ability to do that). All concerns are compliance ones.
Additionally, the pages i linked you to very clearly encourage people to contribute back as much as they can.
AGPL compliance wouldn't be that difficult if you remove making money from the equation. So indirectly your compliance concerns are based on economic concerns.
This is simply false (on both points), and you haven't given any reason it would be true past "i feel this way". Even with direct support from our build system, AGPL compliance is incredibly difficult relative to GPL and other licenses[1]
This argument also amounts to "I know more about your job than you do", which, if you do, awesome!, please feel free to do it :) I'm actually happy to go do something else.
But i don't see evidence that this is true.
[1] For starters, we have to distinguish between what things , what are user facing, what kinds of users have access to them (IE internal services accessible only to FTE googlers are different from those accessible to TVC for AGPL purposes) , etc. This is an incredibly difficult set of problems on the technical side.
That is always true, even for non-open source licenses.
You could take MIT code and comply not just by publishing a notice but by publishing all of it. I don't think that is a meaningful argument against the annoyance of having to collate and publish notices.
Imagine if you have a commercial license that requires you be able to allow them to look through your books to verify software licensing, that often has high cost. Your suggestion is basically "why not just make your books public" (IE more than the contract requires). I don't think that's a meaningful argument against the cost of compliance, because that's not about compliance with this license, but instead one that requires more.
The whole point of contracts/licenses is that they are a deal. What you are suggesting is a very different deal, and we'd deal with it a very different way.
Please do, to the extent their experiences relate to informal licenses.
The lack of a warranty disclaimer isn't an issue in practice; my readme just says "WTFPL, no warranty". The vague rights grant isn't something I've seen as an issue in analogous situations in case law.
More important, to me, is what WTFPL says about my code: I'm not precious about it, I give it to you, I trust you to go do amazing things with it. It is a very humble licence. It says life is too short to get precious about licence wankery. Plus there's the side-effect that small companies and artisan developers can use it, while behemoths like Google won't. These, in my view, are all to the good.
I don't expect you to share that view, but for these reasons, WTFPL is a "good licence" for me. OpenStreetMap thrived for years with a WTFPL-licensed editor (I wrote/maintained it). No-one died, no-one got sued, and OSM became one of only four worldwide geodatabases. The main reason the current editing software isn't WTFPL (I started it but handed over to more talented developers pretty quickly) is that Intel wanted to use it, went "WTF WTFPL", and asked the new maintainer to change it. He did, but tagged the next release idiot-intel-lawyers. I laughed.
(IANAL, though I have spent way too much time over the past 15 years studying licenses and their applicability across different jurisdictions, again principally in connection with OSM and with its - very successful - licence change.)
There have in fact been developers sued (and they lost!) over this very issue in analogous situations, so i'm not sure why you say this.
"my readme just says "WTFPL, no warranty". The vague rights grant isn't something I've seen as an issue in analogous situations in case law."
I'm not sure where you looked. Judges have varied wildly in what they have done in analogous situations.
We are nothing if not data driven. If we didn't have very good data that suggests it is an issue, we wouldn't care.