What is released under MIT (or BSD) will stay under that license forever, so it cannot "be closed anytime". The owner can change the license, but that will affect only future developments.

Permissive licenses sometimes allow sublicensing, which allows changing of the license, and does not require source code be made available when changes made.

IOW, this is de-facto closed source distribution.

What happens when a company decides to add their own secret sauce and release that version only, or what happens tons of slightly incompatible, closed source variants pop-up, what happens upstream decides to not release future versions' source code.

We have seen it all, and we'll see all of them again.

> Permissive licenses sometimes allow sublicensing, which allows changing of the license

No! Sublicensing simply means that there can be a chain of licensing, e.g. author —— Linux distribution —— end user. Not that the middleman can change the license.

(It's actually irrelevant in Germany, because consensus in our legal community seems to be that there is a direct licensing relationship between author and end user, even if they don't know each other and never interact)

> Permissive licenses sometimes allow sublicensing, which allows changing of the license, and does not require source code be made available when changes made.

If I own the code, I can redistribute that code under a non-GPL license any time I want to (or not release changes at all). The GPL license that I grant to you on my code only affects what YOU can do with it. Consider the common practice of dual-licensed GPL code (a very common strategy for FOSS libraries to extort license fees).

And yes, an MIT license permits sub-licensing. Which is a good thing. (So does GPL). Maybe that word doesn't mean what you think it means. Perhaps you meant re-licensing.

> What happens when a company decides to add their own secret sauce

Then you use the old code without the secret sauce.

> what happens tons of slightly incompatible, closed source variants pop-up,

The same thing that happens when tons of slightly incompatible GPL-licensed variants pop up.

> What happens when upstream decides not to release future version's source code.

GPL does't help with that either.

> We have seen it all

To be perfectly honest, coming to Linux world, I find the various creative strategies to extort license fees for GPL code to be extremely distasteful. Off the top of my head: Juce: three dozen dual-GPL- and GPL-incompatible (not-for commercial use without paid license) libraries and tools with no upfront documentation on which libraries and tools are distributed under which license. You have to download them one by one to find out which license they are distributed under. Ubuntu: withholds (currently) 21 security fixes unless you pay for a license! Reaper, which is GPL-licensed, but demands that you purchase a license when you run it; sources are available but are impossible to build. GPL libraries that require use of non-GPL services in the cloud. Seems much more like a dystopia to me.

All I want is for people to be able to use my code. For whatever. And I am grateful to those who have provide code that I use under equally generous terms. And not at all impressed by somebody who added four hundred lines of code to a huge MIT-licensed library, and licensed them under a GPL license. (It took me less time to rewrite from scratch than I spent trying to get a fix pulled into the GPL project).

Yes, obviously the license can change by the author. The same can be done with GPL software.

But what has once been licensed under a permissive license, will remain free forever.

Only the changes will be affected.

> that will affect only future developments.

There's a term for that: Embrace-Extend-Extinguish