That's an interesting license and the first I've seen of what I call open-source proprietary outside the dual-license model. I've been encouraging developments in this area given the problems of proprietary and OSS licenses in isolation. Additionally, people seem to have a false dichotomy where proprietary has to be closed/bad and OSS open/free/good. Wrote here, with security focus, that this wasn't the case:
https://www.schneier.com/blog/archives/2014/05/friday_squid_...
Elaborated briefly on my goal here with an old example:
https://news.ycombinator.com/item?id=10501615
Your license appears to meet many of those requirements. Curious about several things, though, that I figure you could give some straight, English answers to. ;)
How did you come to letting it depend on a user count rather than some other criteria? That's unusual and even reminds me of commercial licenses.
Does the license create a specific amount at that point or allow extortion where locked-in clients are hit with large amounts later?
Is the author able to terminate the project in a way where users are left with a dependency they no longer have access to?
I know you accept modifications under a CLA or something. Let's say, though, you didn't want to distribute some substantial changes. Basically, a fork is in order. How does that work? Do they just assign the whole fork to you where you can optionally offer it to others? Do they keep it onsite? Does it not happen at all? Prior discussions taught me forking is something that should have definitive answers in new OSS licenses.
The ability to make things disappear, get overpriced, or turn to shit arbitrarily are among the largest risks in proprietary OSS projects. So, interested in seeing your company's take on those.