You don't really need a new kind of license for that; you can just AGPL now, and release MIT later (assuming you're assigned the copyright for all the code).
That doesn't guarantee downstream users that later they'll in fact have the code as MIT licensed. The author can change their minds, or just thinks it isn't worth the hassle. (Or some big corp buys them and they won't care.)
Isn't that always the case if the author is the sole copyright holder (or all copyright holders agree)? (Meaning that regardless of the license the copyright holder can always choose to not distribute new versions under that license anymore.)
But that's completely different than having a released version that we know will be available as MIT in X months.
It might mean you can start developing something based on the code and when it becomes MIT you can launch it and keep your additions to yourself. (Let's say in case of a server side thing.)
Is it difficult legally to draft a meta-license that says "This work is licensed under X upon release; Y months after release it will be licensed under the terms of Z"?
Presumably you'd have to also specify what it means to do a non-release pull from their git repository -- when does that particular git commit switch to Z -- but that can't be too hard. Just make the clock not start ticking until a release is made, and if you want a safety valve for the case that someone wants to fork, or if the company folds and doesn't make any more releases, you can have a clause where it switches to Z after N*Y months or something, where N is chosen with an understanding of the usual release cadence.
I could understand how all this might be legally risky for another company to base their business on software licensed like this, but I kinda think that's ok. If we're talking about X=AGPL and Z=MIT, I imagine many non-corporate developers would be happy to use the software under the AGPL, while corporate types will -- as intended -- be more likely to use (for example) the developer's enterprise hosted version, or some other paid self-hosting agreement.
Hm, they could simply put the exact date into the LICENSE file upon release and be done with it.
So by default the code in trunk/master/main has AGPL license in the LICENSE file.
Then when they do a tagged release they just specify 2021-09-08 or something.
Also they can probably refer to the git commit date as release date for the code. (After all it's reasonable to specify a canonical place and method for source code access by the author in the license itself. That is, unless you got the code via this and this site then the code is unlicensed.)
Usually successful (widely used) code has simple licenses. Sure, in the future it's possible there will be complex licensed successful things. But currently big corps just don't really touch complex stuff, they spend rather large amounts on preventing these kinds of risks, even if that means buying an inferior software or reimplementing it. (But then there's also the risk of patent infringement.)
The advantage of AGPL now is that you can get your code into distributions / services that require your code to be under an OSD-compatible license (like Debian, Fedora, Travis CI, etc.) or a source-available one (GitHub, etc.), but it dissuades the AWSes of the world from setting up a competitor, and it may also dissuade certain corporate users from using your OSS release instead of your enterprise one.
