My blog post bemoans coupling terms for license change to terms for the initial license, effective on release. BUSL does both license change and an initial, "non-production" license, all in one form. This new FSL does license change and a PolyForm Shield-esque "don't use to compete with us" license, all in one form. The more choices the forms make and bundle together as a package, the more likely we are to see yet another announcement of a new form with some other predictable, but as yet unbranded, combination.

It's not about minimizing blanks to fill out. It's about maximizing what terms licensors can share and reuse, and what "brands" for those terms they can promote and popularize.

It's pretty clear what the questions are for scheduled relicensing: "what new terms?" and "when?" And it's a relatively small legal job to write terms that just schedule a new license to kick in, with blanks for the answers.

I don't see why we'd want to "hard-code" those values, given how much licensors' choices have varied. The original users of scheduled relicensing, and most recently Hashi, chose copyleft licenses, not MIT or Apache 2. Of the recent crop of companies announcing scheduled relicensing, I think Sentry's the first I've seen that chose two years.

There is also a lot of variation in what terms developers want to apply from initial release, but a lot of it has been independent reinvention on recurring themes. If we popularize a named form just for scheduling relicensing, projects can put those terms in `FUTURE-LICENSE` or somesuch and whatever license terms they want for day one in `LICENSE`. Then we can focus on developing a recognizable set of restricted-license choices that serve most developers in these situations, for maximum reuse. The "menu" of PolyForm licenses https://polyformproject.org/licenses/ has already put a few into the field. Some are proving more popular than others.