The issue with "time limit" licenses is that it effectively centralizes contributions.
As an independent developer, I won't want to write patches for a project that will have already advanced internally. Sure I can make a change, but instead of collaborative development at trunk, I have to fork the year-old codebase to make my change available to users. Or hope that the company behind the project picks it up and it becomes open source after the long waiting period.
As the company behind a "time limit" licensed codebase, this means I won't get much from the community in terms of code contributions. Patches that do get contributed are going to result in merge conflicts. Sure you can privately collaborate with selected other entities, and in that case you've reinvented the Android development model wherein the owner company (Google) privately shares code with phone vendors and releases it to the rest of the world at a later point.
In short, this model may work for companies that want the branding aspect of open source while saying no to code contributions or even community governance models. The recent KDE Free Qt brouhaha also shows that this can easily imply delayed security fixes for the open version as well as increased risks of hostile forks. I don't see this as a particularly popular model going forward, although I imagine it covers some use cases well.
> As the company behind a "time limit" licensed codebase, this means I won't get much from the community in terms of code contributions.
Which 'in my experience' is the situation for the __majority__ of commercially driven open source projects. Most commercial OSS projects receive few contributions, most often around the edges. In these cases it may well be rational to protect yourself from large competitors (e.g. cloud vendors) taking your code vs losing some small contributions.
It's true that:
> In short, this model may work for companies that want the branding aspect of open source while saying no to code contributions or even community governance models
Often it's not 'bad faith' that's driving these sorts of trade-offs in licenses. Rather, it's the harsh realities of trying to get open source business to work.
It probably won't be a "popular model" because there's lots of reasons for creating FOSS - from individual drivers to strategic - so by volume of projects etc. But, for someone trying to create an OSS business "time delayed" licenses are not bad.
As an independent developer, I won't want to write patches for a project that will have already advanced internally. Sure I can make a change, but instead of collaborative development at trunk, I have to fork the year-old codebase to make my change available to users. Or hope that the company behind the project picks it up and it becomes open source after the long waiting period.
As the company behind a "time limit" licensed codebase, this means I won't get much from the community in terms of code contributions. Patches that do get contributed are going to result in merge conflicts. Sure you can privately collaborate with selected other entities, and in that case you've reinvented the Android development model wherein the owner company (Google) privately shares code with phone vendors and releases it to the rest of the world at a later point.
In short, this model may work for companies that want the branding aspect of open source while saying no to code contributions or even community governance models. The recent KDE Free Qt brouhaha also shows that this can easily imply delayed security fixes for the open version as well as increased risks of hostile forks. I don't see this as a particularly popular model going forward, although I imagine it covers some use cases well.