Thanks for this. Worthwhile read.
There are a bunch of misunderstandings of common license terms. Especially of the longer forms. Especially especially the FSF forms, like AGPLv3 and LGPL. It’s not cool to be misrepresenting those licenses’ requirements. But it can’t be any surprise to see this happening, given how hard they are to read, much less interpret, in the first place.
The idea of license revocation has come up a few times, including on GPL contributions to the Linux kernel, never with much to show for it. There are common licenses that go out of their way to say they can’t be revoked. The Blue Oak Model License is especially clear on this point.
But old academic-permissive terms like MIT and BSD don’t say anything about revocation, so the question becomes one of background law. Which you won’t find spelled out in the license terms.
My general sense of fellow specialists I’ve spoken to is that lawyers generally suspect MIT and BSD grants for code released to the wild, as in published online, probably can’t be practically revoked, at least overall. But the edge case is just the one mentioned here, where the putative copyright holder specifically notifies a particular would-be-licensee that their license is revoked.
Speaking for myself now, my advise for clients is usually to steer well around this uncertainty:
Don’t rely on being able to revoke MIT or BSD license grants for code you’ve released in the past.
Don’t rely on being able to keep using under MIT or BSD code if the copyright holder finds you and specifically tells you they’ve terminated their grant.
If you want to change your license terms for code you’ve already released, fork the project, or at the very least draw a clear line at a particular version of the old project, and make very clear that your new terms apply to all new work from that point forward. This doesn’t change your terms for code you’ve already released. But it’s not on you to make it easy for others to separate your new work from your old.