It's not okay to pretend your software is open source

You don't need to even choose a licence. That only comes in to play if you concern yourself with downstream users that care about licensing.

It really only becomes complicated when you want to release it and _also_ monetise it or restrict its use.

Licenses exist because of how this is ultimately at odds with how software actually works - it's basically legal DRM.

(I think licensing has valid uses in the current environment, but it's worth keeping in mind how absurd it is as a concept, it's basically a massive hack).

Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.

> Ultimately, people want to keep their code open, develop in the open, bring in contributors, make it easy to adopt and audit their code, etc.

The Commons Clause doesn't really change any of that from the base license. It says so explicitly - "Without limiting other conditions..."

> They also want to eat and have a home.

This is the very thing that the Commons Clause tries to prohibit: "the License does not grant to you, the right to Sell the Software."

In other words, it's a way for the maintainers of a project to say that they get to sell the software, but nobody else does.

Which, hey, I develop proprietary software for a living, I'm fine with doing that in the general case. What I don't like is trying to mix that kind of restriction into an open source license. Because then what you're saying is, you want other people to contribute code, and you want to be able to benefit financially from those contributions, but you expect it to be a one-way street. There's a basic principle of fairness at play there.

If you want to do that kind of thing, I'd say it's much preferable to go with something more like the oldschool "dual GPL/commercial licensing" approach. Or, if it fits your needs better, something like one of the non-OSI Microsoft Shared Source licenses.

In fact, I'd consider it a significant improvement over the concept of "open core" that has been becoming more and more popular, where the core 80% of a product is open source, but the last 20% isn't, making it so you need to either pay or build that last 20% yourself to use the software.

Contrast with an "open source, except you can't sell it", you'd be more likely to get the whole 100% of the software "open sourced" (as in all other aspects of open-source code, without the ability to sell it), people not using it for profit can benefit immensely, and those who are using it for profit can license it like anything else.

Ostracizing the latter because they don't adhere to strict definitions seems wrong, especially when pretty much all of the alternatives (aside from going full GPL/AGPL) means there is less code out there usable by people, and less users will have the ability to see the code they use.

There is no widely recognized equivalent of a CC-BY-NC license for software, partly because neither the FSF nor OSI will recognize such a license. Maybe someone needs to write one nonetheless. And stick it on their software clearly and unambiguously. They obviously think that OSI-approved licenses don't suit their needs. Then don't use them, period.

The author is right that "Apache 2.0 + Commons Clause" is potentially misleading. We've seen "GPLv2 + Classpath Exception" before, but that was to give additional permissions, not a restriction. Similarly, most examples of dual-licensing don't add restrictions to either license. Adding a restriction is something new. It's understandable that people find it disingenuous.

Just write a new license already and call it Redis Labs Open License (RLOL) or something like that.

I'm sure antirez would be rather unhappy if you forked Redis, deleted a bunch of features, and called it Redis Lite. At least have the courtesy of changing the name if you're going to use an incompatible license.