No, Redis is not proprietary after Redis Labs introduced a tweak to its licensing strategy. Yes, some modules from Redis Labs will now be under a weird new license hack that says, in essence, “Clouds, you’re not allowed to make money from this code unless you pay us money.” And yes, this hack was completely unnecessary in terms of open source evolution.
You see, we already have ways to accomplish this. Not everyone likes strategies like Open Core, but they’re well-established, well-understood, and could have saved Redis Labs some headaches.
SEE: Software licensing policy (Tech Pro Research)
Money for nothing…
Let’s be clear: Redis Labs’ desire is rational and common to open source vendors. While Redis Labs didn’t touch the license for Redis Core (it remains under the highly permissive BSD), the company has slapped a “Commons Clause” onto otherwise open source software to make it…not open source. The rationale? Stop free riding, at least in part, as mentioned in the company’s explanation:
[T]oday’s cloud providers have repeatedly violated this [open source contribution] ethos by taking advantage of successful open source projects and repackaging them into competitive, proprietary service offerings. Cloud providers contribute very little (if anything) to those open source projects. Instead, they use their monopolistic nature to derive hundreds of millions dollars in revenues from them….
Redis is an example of this paradigm. Today, most cloud providers offer Redis as a managed service over their infrastructure and enjoy huge income from software that was not developed by them. Redis’ permissive BSD open source license allows them to do so legally, but this must be changed. Redis Labs is leading and financing the development of open source Redis and deserves to enjoy the fruits of these efforts. Consequently, we decided to add Commons Clause to certain components of open source Redis. Cloud providers will no longer be able to use these components as part of their Redis-as-a-Service offerings, but all other users will be unaffected by this change.
This all makes sense. While people can disagree over whether “free riding” in open source is good or bad, Redis Labs’ policy change is a rational response to the stripmining that cloud providers do. We can argue over whether it will work–I think the likelihood of an Amazon Web Services (AWS) or Microsoft Azure paying for the rights to build services based on these Common Cause/proprietary modules is less than zero, though arguably companies that might have preferred to buy those modules through a cloud will now be forced to buy them from Redis Labs–but what isn’t really in doubt is that the approach is clumsy and unnecessary. (Not evil, as some seem to suggest.)
Established paths
You see, we already have well-established open source licensing strategies for inhibiting free-riding from the cloud vendors (or others). The most well-worn path is through the AGPL, sometimes referred to as the “AWS GPL.” The AGPL closes the GPL’s famous “network exception.” Whereas it’s possible to run GPL code to provide a service over a network, the AGPL insists on code contributions back in this event.
Which, of course, is what Redis Labs is steering at with its Commons Clause, but in clunkier fashion.
Other companies like Cloudera, MongoDB, DataStax, and many others use an Open Core model, whereby they keep the core of their code open source but then license complementary modules or tooling under a proprietary license. Again, this is similar to what Redis Labs is doing, but rather than call an Open Core spade a spade, they do weird things like piggyback the Commons Clause on an otherwise BSD license, thereby making “any software under this new license…non-open source by definition.”
SEE: How to become a developer: A cheat sheet (TechRepublic)
Why not just license these bits under an openly proprietary license? Why bother with the licensing gymnastics? If the company hopes to encourage contributions (“Anyone can contribute to any of these projects (including those licensed with Commons Clause)”), it won’t work. It’s very rare for developers to contribute to proprietary projects. It happens, but it’s the exception, not the rule.
This storm will pass, though my former MongoDB colleague Jared Rosoff is probably correct in suggesting on Twitter that: “Even if the result of the change isn’t controversial, it’s hard to trust a platform that can change on a whim.”
Brian Leroux went further: “They should be focusing on integration and multi-cloud. This won’t solve anything other than alienating their base audience and top of funnel.”
Redis Labs, in an attempt to buy itself some revenue, may have cost itself some credibility. Or not.
As unnecessarily complicated as Redis Labs’ approach was, it’s doubtful that it will seriously injure the company’s prospects long-term. No, the real question is whether the company will benefit from the weird approach. In my experience, the answer is “no,” but maybe they’ll break new ground.
