Why would I invest, or encourage clients to invest, in a technology that has a support monopoly?

This is a good question. Most proprietary software companies allow other companies to charge for support of the software. This seems like they're a service provider too, and want to stifle competition. Like if Google made it illegal to charge for services in setting up a private kubernetes install for a company.

To be clear, this license does not (and, according to the post, never will) apply to regular Redis deployments, so from that angle at least you're clear. Currently it only applies to certain Redis modules, which need to be deployed separately anyway.

I'm also a bit unclear on whether this would prevent you from selling consulting services for products licensed under this clause that the paying customer deployed themselves or were deployed by someone other than you.

Full disclosure: Am a Redis Labs employee, although not here in any official capacity.

Appreciate the clarification. The entire paragraph "Redis is an example" should to be deleted from this post to remove confusion.

> Consequently, we decided to add Commons Clause to certain components of open source Redis

Are these components distributed with open source redis core that I can download & compile from @antirez/redis? This whole bit is confusing an doesn't answer what components are covered and in what distributions e.g. source vs. packaged.

If there's anything we should have learned from the React licensing fiasco, it's that the open source community doesn't screw around when it comes to the critical software systems we've adopted on the good faith of the licenses they included.

No, nothing you obtain from the antirez/redis repo will come with this restriction clause, and you are free to continue using it under the terms of the vanilla BSD license.

The new clause is mainly used for some of the add-on Redis modules developed by Redis Labs (https://github.com/RedisLabsModules), all of which you would need to pull in manually and intentionally.

I totally get the confusion. The good news is that, at least as far as I can see, you should never find yourself accidentally pulling in something without meaning to that brings along this restriction clause.

That’s okay, but I think there’s two parts you might be missing. 1/ the Commons Clause doesnt apply to retroactive versions and in this case is not applied to Redis core. 2/ The Commons Clause isn’t meant for everyone. In the world of open source, sometimes projects can stay open, and sometimes they can’t. For projects that can’t, sometimes it’s because people do bad things that are disguised as Services but in reality add little value other than resell.

Thanks. That clarifies that I should 1/ immediately stop deploying new projects using redis, but 2/ I've probably got breathing space to still charge consulting fees for existing projects while I work out which of your competitors to migrate to.

> It's embarrassing that I'm being told that the time & energy I've invested in deploying this software (redis in particular) will now be rewarded with the inability to commoditize that experience through consulting. No thanks.

Can you explain the thought process with regards to why it's okay for you to receive compensation for your efforts, but not the OSS developer who invested significantly more time (nine years, in the case of Redis) in creating the product?

What will you do as a technology practitioner if more projects move to this model to provide some semblance of financial support for their devs? Write your own RDBMS? Your own in-memory caches? I won't discount these paths as impossible, but it increases your costs and time to market significantly.

Standing on the shoulder of giants is both efficient and convenient when building your product/stack by bolting together existing tooling (what products aren't using Redis/Memcached, MySQL/MariaDB/Postgresql, ElasticSearch, etc), but it should have a cost; those shoulders aren't free, and it's not reasonable that those enjoying easy revenue (AWS, for example) by providing managed services with these tools don't have to share that revenue. You can't freeload forever.

> Can you explain the thought process with regards to why it's okay for you to receive compensation for your efforts, but not the OSS developer who invested significantly more time (nine years, in the case of Redis) in creating the product?

The consultant isn't selling the product; they're selling a complement to the product: knowledge of how to use the product effectively in the client's circumstances. But complementary goods don't substitute for each other. Paying a consultant for Redis expertise doesn't buy you the functionality of Redis itself.

So if Redislabs deserves to be the only Redis consultancy in existence, the argument has to be that not only do they deserve the exclusive right to profit from the sale of their intellectual property, they also deserve an exclusive right to profit from other people's expertise with their product. But why should anyone accept that?

They might be within their legal rights to impose such a condition in a license (IANAL), but there's not a strong ethical justification for the position.

I agree that their approach to restricting consulting is...unconventional, but I support their legal right to do so. Their code, their rules.

This attitude is how you get silliness like the idea that I can be prevented from reverse engineering software by an impersonal EULA. It's blanket permission to erode the rights of people who are in practice forced to comply with toxic aspects of an ecosystem. "You have the right to create your own operating system" is not a take that would be supported by any serious analysis seeking fairness for both parties.

> This attitude is how you get silliness like the idea that I can be prevented from reverse engineering software by an impersonal EULA. It's blanket permission to erode the rights of people who are in practice forced to comply with toxic aspects of an ecosystem.

Your issue is not with my attitude, it is with copyright law and property rights. Someone's right to license their software any way they see fit is not "toxic". You take issue to an erosion of rights that do not exist, and your participation in an ecosystem is voluntary. At it's core, you are demanding the ability to govern your use of property that is not yours.

EDIT: I don't believe the law to be unjust as to how it relates to copyright, code ownership, and licensing. We've reached an impasse.

Laws reflect attitudes, supporting unjust laws with your opinion sustains them. So yes, my issue is with your attitude.

EDIT: Since you've edited your comment to elaborate I'll respond in kind:

If by default I have the legal right to reverse engineer your software, and you can strip this from me with a 'contract' that amounts to a checkbox with text that nobody reads and therefore has no marginal cost to add enforceable boilerplate to, that is a basic perversion of the intent of contract law. Contract laws start from the premise that a contract should protect both parties. One sided contracts are in general antithetical to the goals of contract law:

https://www.legalmatch.com/law-library/article/what-is-an-un...

A boilerplate click through disclaimer should not be able to prevent me from taking actions that the vendor finds inconvenient but are otherwise legal and nonviolent.

EDIT 2: To clarify, the portion cited as an "edit" above:

"EDIT: I don't believe the law to be unjust as to how it relates to copyright, code ownership, and licensing. We've reached an impasse. "

Was not the full extent of editing of the parent comment, which had significant text added between me replying and its present state.

Not even dark-ages Microsoft tried to prevent users exchanging knowledge about their products for money ("consulting", or frankly, "employment").

Such a suggestion is preposterous and should kill any company adopting it immediately.

At it's core, this is fundamentally about property rights. The owners of the Redis copyright are well within their right to license their property in any way they see fit. It's preposterous to you, but you're not the one who has spent the time creating Redis. It's preposterous to me that they wouldn't have the rights to govern their creation's use.

You could go build your own infrastructure software, of course, that is a valid path forward. But will it be of the same quality at the same (or similar) cost? Most likely not. Will someone provide an alternative to Redis out of disdain for this? Probably. But it will take years, if not longer, to reach feature, stability, and therefore market parity.

And in the interim, cloud providers will pay or have to front the costs to build their own. And that's what this is all about: internalizing the externality of providers getting a free ride.

>At it's core, this is fundamentally about property rights. The owners of the Redis copyright are well within their right to license their property in any way they see fit.

They absolutely are. And I'm free to say that their license is ridiculous and do my best to warn others about the potential pitfalls of their license.

>You could go build your own infrastructure software, of course, that is a valid path forward. But will it be of the same quality at the same (or similar) cost?

Maybe, maybe not. But it doesn't matter. If Redis continues down this path, then enough developers are going to stop using Redis that any free alternative, even though it might start off weaker, will quickly become the superior option. Look at MySQL vs. MariaDB. Or OpenOffice vs. LibreOffice. In both cases, Oracle (no coincidence that it's Oracle in both cases) took over a very popular, well established open source project and engaged in license shenanigans. In both cases, the community rebelled, forked the project, and the fork quickly superseded its parent.

>Will someone provide an alternative to Redis out of disdain for this? Probably. But it will take years, if not longer, to reach feature, stability, and therefore market parity.

Not true. You have to remember that the new license only applies to Redis going forward. I'm free to take my copy of the old Redis codebase, fork it into something, say, NuCache, and hack on that to try to keep up with and surpass Redis. That's exactly what happened with the OpenOffice/LibreOffice fork. That's exactly what happened with MySQL/MariaDB fork. And if redis continues with its ill-advised policy, that's what will happen here.

> Not true. You have to remember that the new license only applies to Redis going forward.

At the risk of repeating myself all over this thread, I feel the need to emphasize that the new license does _not_ apply to Redis proper, which, in the words of the post, "is, and always will remain, an open source BSD license."

Full disclosure: Am a Redis Labs employee, although not here in any official capacity.

Sure. The same argument applies to the "enterprise modules", which until today everybody assumed would always remain under an open source BSD license.

Your boss has bait-and-switched once now. That's enough for everybody who cares to start risk managing future similar behaviour.

I'm very curious to see if this stands in court, since "consulting" can be considered similar to repairing and there are laws in many countries that restrict a manufacturer's right to limit repairs and who performs them.

> Not true. You have to remember that the new license only applies to Redis going forward. I'm free to take my copy of the old Redis codebase, fork it into something, say, NuCache, and hack on that to try to keep up with and surpass Redis.

True! But that means today's Redis is in maintenance mode, with all new commercially-relevant features covered under the new license.

True, but that assumes that Redis is the only one capable of coming up with commercially relevant features. If the community fork of Redis gets commercially relevant features, then Redis will have to do work to re-implement them.

Moreover, that assumes that said commercially relevant features are compelling enough for people to upgrade from the unencumbered version of redis that they have to the encumbered version.

This seems like a superior alternative than allowing cloud providers the ability to generate revenue with your product that you receive no portion of. If you're already substantially "losing", there is no harm in doubling down. RedisLabs has nothing to lose by doing this other than people moving to another solution that someone else will need to expend resources and time to develop.

Monetization shouldn't be a four letter word. People need to pay their rent and eat.

I've made some contributions to Django over the years. Some code, a decent amount of documentation, and I like to think I've been useful in bureaucratic roles (I was the release manager for a while, I sit on the security team and technical board, I serve on the board of its sponsoring nonprofit, etc.). Along the way, I've picked up pretty extensive knowledge of Django, inside and out. And I've certainly made money as a result of that!

But I can't imagine sitting down one day thinking "you know, nobody else should be allowed to do what I did". It's a big world with a lot of potential clients and employers out there. There's room for anyone who wants to get good with Django to put that knowledge to use to make a living, and I don't see any justification for trying to stop them.

If this were the standard sort of "we trademarked the name, and you can't use it as the name of your product" that a lot of larger open-source projects do (including Django, FWIW), I'd be more sympathetic. But trying to forbid people offering consulting or hosted "I set it it up for you" type services? That's a massive grab of other people's knowledge and labor, and I can't support it even a little tiny bit.

Redis Lab neither created, popularized, or own the copyright to redis. Antirez and the open source community that embraced it are responsible for it becoming a household name it is in the IT community.

And now that the open source community has done all the hard work of making libraries available in every language, fighting to get it adopted within our organizations, recommending it to our friends & peers, writing blog posts & tutorials, evangelizing it to our clients, and creating so much demand that AWS & GC both offer it, suddenly this company with ZERO responsibility for its success now wants to try and profit from an ecosystem it had no hand it creating.

I'm more than happy to pay for good commercial software that helps me run my business and have happily spent many tens of millions over the years doing so. But I'm not going to tolerate this bait-and-switch bullshit from a company that's trying to pretend it invented redis just because it employs antirez.

The license doesn't just talk about the software - it tries to restrict the sale of knowledge about it (in the form of consulting) too.

That makes it the most overreaching of any software license I have ever encountered, including those from Oracle.

> At it's core, this is fundamentally about property rights

Imaginary property has nothing to do with property rights. Those are about real property.

Man, you are a smart guy. I know this, your posts are generally awesome. How in the hell do you think it's okay for them to try to ban consulting about a product? That isn't "property rights", that's just...fuckery.

I made several comments without fully understanding the situation. I regret making those comments, but I don't regret my comments from being permanent now. When I'm wrong, I'm wrong.

I know someone who have had their life ruined by having their projects monetized out from beneath them by others; there is emotion behind those comments that shouldn't have been there. It happens to the best of us. I apologize for disappointing, and understand if I've lost your respect.

Nah, dude, everybody's mistaken sometimes. I shoot off half-cocked all the time. I just wanted to make sure we were all on the same page. =)

Redis core is almost exclusively written by Salvatore. Redis Labs itself was just a consultancy that monetized this work and eventually hired him on full-time many years later.

So if this license had existed from the beginning, Redis Labs wouldn't exist. See the problem?

I don't understand this entire argument. Someone developed open source, free to use software, then didn't understand why people should expect to use it without paying for it. It's totally fine to make proprietary software, just call it that. If you expected to get paid, sell it, fine. And make it clear that it is not free. That's what is happening here, good. But wrapping it in a rhetoric of protecting open source code doesn't make sense. Maybe the common perception of what open source code is wrong in the general public. I'm definitely not a lawyer, I do respect licenses, but I guess I thought open source meant free to use, when maybe it can be interpreted, "free to see, maybe pay to use". With a free trial version for students and hobbyists.