I agree that the naming of the non-open-source licenses is confusing, e.g. "commons clause" is not a great name. However, I wonder if there is in fact a fundam

I agree that the naming of the non-open-source licenses is confusing, e.g. "commons clause" is not a great name. However, I wonder if there is in fact a fundamental difference between some kinds of reuse and others (thinking aloud here). If I want to use Debian to power my corporate desktops, that's one thing. Or if I want run Debian on cloud machines that provide a Redis service. But if I actually expose the Redis API and protocol through a service to customers, and charge them for it, can that be considered another form of reuse that requires licensing? This is in contrast to running Redis as a backend for say a for-profit Twitter clone. Using Debian, the analogy would be providing a remote-desktop-as-a-service using Debian, as opposed to merely using Debian in a cloud service. ----- Although, I may have missed it -- why not make Redis AGPL? That would prevent proprietary forks, as I understand it. But they want something even stronger than that? They don't want just a level playing field, but an advantage? I suppose I can understand that when you are faced with big cloud providers with tons of locked-in customers. I'm surprised that Cantrill isn't more sympathetic to the business model problems and the lock-in effects of big cloud providers. He seems to take a pretty hard line that the "community" comes first. But what if there's no real community? Is there a community around CockroachDB? It seems to be mainly for for-profit companies to run cloud services. ----- In other words I think there could be another name for software where you have rights to view, modify, and distribute the source, but not to directly sell it as a service. He is saying that nobody is ever going to license this software -- they will just reimplement it or use something else. But I think that is besides the point, which is that there are customers who WOULD pay for a hosted version of Redis or CockroachDB. I guess where this falls down is that it only works for projects in which there have been essentially no external contributors. Although a few people may have contributed the lion's share of the code, it's not clear that you should reserve rights for author A's company but not author B's company, even author B only contributed 10 lines of code. It is hard to draw that line.