Redis Goes From Open-Source to Fauxpen and the Forks Have Already Started

Redis is only the last in a line of companies that have lately dropped open-source licenses in favor of proprietary open-source lookalike licenses. In this case, a fork has already happened that just might end up being real competition for Redis.

Last Thursday, after Redis announced that it had changed the license covering its software from the open-source 3-Clause BSD License to the Redis Source Available License and the Server Side Public License, both source-available proprietary licenses, Redis CEO Rowan Trollope said something very curious to TechCrunch. He said that the license change was “protecting our investment that we make in open-source.”

To me, this sounds like a big case of trying to eat your cake and have it too.

“I agree. If you invest in open-source and you want to maintain that investment, then you should hold true to it still being open-ource,” Jim Jagielski said when I ran the quote by him for a comment. These days Jagielski is head of open-source at Saleforce. He’s also a co-founder of the Apache Software Foundation, where over a 28-year period he’s been everything from president and EVP to director and chairperson.

“It’s like saying I want to protect my investment in gold by converting it all to silver,” he added. “You no longer have any investment in gold at that point; your investment is in silver.”

For the uninitiated, both the RSAL and the SSPL belong to a classification of license that some open-source pundits call “fauxpen,” which are licenses that have some open-source qualities without fully complying with the established Open-Source Definition — which is required for a license to be approved as a bonafide open-source license by the Open Source Initiative, the recognized authority on what does or does not constitute open-source.

For the last decade or so these fauxpen licenses been something of a thorn in the side of the open-source community, as more than a couple of previously open-source companies — mostly database firms such as MongoDB, CockroachDB, and others — have relicensed their software under these open-source lookalikes. Generally, they’re being sold to the public as being so close to legitimate open-source that it doesn’t matter, and that the only thing that’s keeping them from being officially recognized open-source licenses is the Open Source Initiative’s nitpicking around the Open-Source Definition.

Almost always, this relicensing is motivated by the increasing importance of software as a service by companies such as Redis that don’t want to see others profit by the use of “their software” as an online service without compensation. When you listen to the C-suite suits behind the changes justify their actions, it often seems as if they are confusing software licenses with business models. That, or else they are upset because the licenses they have been using just don’t fit their business models.

“I think that some of these companies do one of two things,” Jagielski said in our email back-and-forth. He said they either, “Don’t truly understand open-source and, therefore, went into an open-source-related business strategy without really understanding the true details, or [they] want to blow smoke and pretend that their new license is ‘real’ open-source ‘in spirit’ and is more open-source than any OSI approved license.”

“One is incompetence and the other is untruthfulness,” he added. “Neither is good.”

The Trouble With Redis’s Licenses

The two licenses that now cover Redis’s software are offered as a users’ choice. That is, users of the software can choose the license that is most appropriate to them. The primary differences in the licenses are in the area that Redis is seeking to address by the license change — that is, keeping cloud vendors from being able to throw Redis’s software online and let people access it for a metered fee.

The RSAL addresses the issue directly — by outlawing using the software as the basis of a SaaS product:

“You may not make the functionality of the Software or a Modified version available to third parties as a service or distribute the Software or a Modified version in a manner that makes the functionality of the Software available to third parties.

“Making the functionality of the Software or Modified version available to third parties includes, without limitation, enabling third parties to interact with the functionality of the Software or Modified version in distributed form or remotely through a computer network, offering a product or service, the value of which entirely or primarily derives from the value of the Software or Modified version, or offering a product or service that accomplishes for users the primary purpose of the Software or Modified version.

“You may not alter, remove, or obscure any licensing, copyright, or other notices of the Licensor in the Software. Any use of the Licensor’s Trademarks is subject to applicable law.”

The primary problem with this license from an open-source perspective is that a main tennet of open-source is that once you have in your possession a legally obtained copy of any software, that software should now be yours to do with as you please. You can install it on any computer you own, you can modify the software in any way you desire (although, with some licenses you might be required to share those modifications upstream), and you can use it for any purpose. In other words, an open-source license can’t require that this software only be used on, say, Dell computers, or that you can’t make any changes to the software without prior approval, or that you can’t use the software in a business or to support military actions. It’s you software, use it as you will.

The other license choice offered by Redis, the SSPLv1, was introduced by MongoDB in 2018 after Amazon Web Services began offering SaaS access to a database that was compatible with Mongo’s products, and is loosely based-on the GNU Affero General Public License version 3, which was specifically designed to deal with the SaaS issue. However, it goes a step further than the AGPL v3 by requiring that anyone who offers the functionality of the covered software to third-parties as a service must release all of the source code being used to run the SaaS offering.

MongoDB initially submitted SSPLv1 to OSI for approval, but eventually withdrew the submission after it became apparent that it wasn’t going to be approved. OSI’s reviewers saw two main problems with the license, starting with it having separate terms depending on whether the software was being run standalone or as part of a SaaS service. There were also concerns that requiring SaaS operators to release the source code of support software being used to host the software might fall outside the purview of a software license, especially considering that the software could be from a third party vendor.

SourceHut Says, “Fork You, Redis”

Within a day or so after Redis announced the license change the inevitable happened. Redis’s still fresh on the open-source vine software was forked, given the new name “Redict,” and released under the Lesser GNU General Public license v3.0-only. The person behind the fork is Drew Devault, the founder and CEO of the open-source GitHub alternative SourceHut, who introduced the fork in a post on the new project’s website:

“Like many of you, I was disappointed when I learned that Redis was changing to a non-free licensing model. This is a betrayal of the free software community, but perhaps not an entirely surprising one. Forks are likely to start appearing in the coming days, and today, I would like to offer Redict to you as a possible future home for your needs, and present its trade-offs as compared to the other forks you’re likely to be choosing from soon.”

Devault said that the project’s immediate efforts will be on “changing the name in a backwards-compatible manner and establishing a technical foundation for an independent future.” That future includes, “a continuation of development for a free software distribution of Redis OSS compatible software, with minimally disruptive changes for the time being.”

He also said that although care will be taken to maintain backwards compatibility, “No effort will be made to remain compatible with future versions of Redis SAL.”

The “Failure” of Open-Source

Since this mini exodus from open to fauxpen began, one of the things we’ve heard as an excuse explanation is that open-source has “failed the business community,” generally while pointing to the Open-Source Definition disallowing restrictions on how covered software can be used.

Jagielski said that he thinks the real issue is the business community’s preference for “permissive” licenses such as BSD and Apache — which allow covered software to be included in proprietary projects — and its disdain for “copyleft” licenses like the GPL and AGPL, which do not.

“I think that open-source has succeeded because of the criteria of the Open-Source Definition, not despite it,” he said. “In almost all cases I see their ‘problem’ would be solved by moving to the AGPL license, which is FSF- and OSI-approved, but they don’t. Why? Because of the negative connotation of copyleft licenses. So instead of choosing the ‘right’ open-source license for their use case, because of the FUD around copyleft they abandon open-source totally.

“Maybe, more than anything, this addresses a PR problem associated with copyleft. It is strange that copyleft is seen as more ‘dangerous’ and less palatable than non-open-source. Weird.”

Weird indeed.