> 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.
It's true that:
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.