Redis clarifies the license boundary between core and modules
Redis Labs confirms that core Redis remains BSD-licensed while its modules use Apache 2.0 with Commons Clause restrictions. The module license defines selling broadly enough to include certain hosted services.
The license of an extension can differ from the license of the server loading it. That distinction explains the August 22 clarification from Redis Labs. Core Redis retains its BSD license. Modules developed by the company have moved from AGPL to Apache 2.0 with an additional Commons Clause restriction. Describing the whole installation with the name Redis conceals a distinction that matters to its permitted commercial uses.
The company announcement identifies RediSearch and RedisGraph among the affected add-ons. It presents two motivations, preventing cloud providers from selling module-based managed services and accommodating enterprises unwilling to use AGPL software. Those are the company positions, not evidence that every enterprise or cloud provider has the same requirements.
I have used Redis since its initial release, and I value the freedom to keep familiar infrastructure useful in different deployments. The core license remains important to that judgment. An optional module now requires a separate assessment, because compatibility with Redis commands does not establish identical permissions for running a commercial service.
The clarification follows an existing module change
The RediSearch license commit is dated July 15. Its patch replaces the AGPL text with a short notice applying Apache 2.0 modified by Commons Clause. The August announcement therefore confirms and explains a change already visible in this module. It should not be read as establishing that every affected repository changed its license on August 22.
The license at that commit is a useful concrete source. It identifies Redis Labs as the licensor and incorporates the restriction into the grant. Reading the underlying Apache license alone would omit an operative condition in the module notice.
This is an important distinction for dependency records. A record that says only Apache 2.0 would fail to describe the combined terms. A record that says core Redis has acquired this restriction would describe the wrong component. The relevant unit is the particular artifact and version under examination.
A license file is also different from a general statement about a product family. The announcement explains the company policy and the repositories show how that policy reaches code. Those sources answer related questions, but neither makes it unnecessary to identify which component a deployment actually contains.
Commons Clause changes the commercial permission
The RediSearch notice first refers to Apache 2.0, then states that the grant does not include the right to sell the covered software. Its definition of selling includes providing a product or service to third parties for money or other consideration when its value derives entirely or substantially from the software functionality. Hosting fees and consulting or support fees appear explicitly within that definition.
This wording reaches beyond distributing a paid copy of a binary. A hosted offering can fall within the definition even when the customer never receives the executable. Renaming the module would not, by itself, change where the functionality supplying the service comes from. The restriction concerns the value provided by the product or service, not merely its packaging.
The words entirely or substantially also make the clause different from a blanket prohibition on using the module in a business. The text asks about the relationship between the offered product and the covered functionality. An application with other functionality and a service consisting substantially of the module are different cases under that wording. The notice does not provide a numerical threshold for substantiality.
That lack of a numerical test is relevant to engineering planning. A build system can record which license notice accompanies a module. It cannot determine from a filename whether a future commercial offering derives substantial value from that module. The latter question depends on the actual offering and the application of the written terms to it.
The notice also requires inclusion of the Commons Clause condition with license notices or attributions required by the underlying license. An inventory that preserves only a stock Apache text would consequently omit the condition that changes the commercial grant. Treating the module as ordinary Apache-licensed code loses the principal fact in this change.
Apache remains part of the combined terms
The Apache License 2.0 text, dated January 2004, supplies copyright and patent grants subject to its conditions. It also sets redistribution requirements. These include supplying the license, marking modified files, and retaining relevant notices. A distributed work that includes a NOTICE file has additional notice-preservation requirements described in section 4.
Those provisions continue to matter when a module adds Commons Clause. The additional condition restricts the permission identified in its own text. It does not turn the rest of the Apache document into an irrelevant label. Reviewing only the commercial restriction would therefore be incomplete for a party distributing the module or a modified version.
The practical result is a combined license whose permissions differ from unmodified Apache 2.0. The familiar base document may help readers understand the remaining terms, but familiarity does not eliminate the added condition. Calling the change a move to a more permissive license without explaining which activity is restricted would be misleading.
Redis Labs describes allowing applications and commercial products built on the modules while reserving direct commercialization of the modules themselves. The published restriction defines the operative scope more carefully than that short summary can. Its explicit coverage of some services is particularly important for anyone interpreting selling as only a transfer of software copies.
Core Redis has a different grant
The COPYING file shipped with Redis 4.0.11 permits redistribution in source and binary form, with or without modification, subject to its listed conditions. Source redistribution must retain the copyright notice, conditions, and disclaimer. Binary redistribution must reproduce them in the accompanying documentation or other materials.
A third condition prohibits using the Redis name or contributor names to endorse derived products without specific permission. The file also disclaims warranties and limits liability. It contains no Commons Clause definition of selling and no corresponding exclusion of that right from the grant.
That difference explains why a module announcement does not automatically change the license of the core server. The server artifact carries its own terms. Loading an extension with different terms creates a deployment containing components whose permissions have to be understood separately.
The contemporary module loader makes that technical separation visible. It loads a dynamic library and resolves its RedisModule_OnLoad entry point. After successful initialization, the server registers the module. Nothing about sharing a process mechanically replaces either component license with the other component license. The loader also refuses to unload a module that exports its own data types. Removing such an extension can therefore involve stored-data compatibility as well as the decision about licensing.
MODULE LIST
The command implementation returns information about loaded modules. It can help identify that an installation includes extensions, though it does not evaluate their license terms. Establishing the applicable notice still requires the module artifact and its corresponding source or distribution material. A server version string alone cannot describe every extension loaded into the process.
AGPL and a sale restriction address different behavior
The removed AGPL text remains visible in the RediSearch license patch. Its section 13 requires a modified version supporting remote network interaction to offer corresponding source to users interacting with it remotely. That is a source-sharing requirement attached to the covered modified program. It does not define a general exclusion of the right to operate a paid service.
The new restriction instead withholds a permission for the defined category of selling. These mechanisms target different behavior. Replacing one with the other changes the relationship between source availability and commercial operation, even if a user can still read the implementation in a public repository.
I prefer to keep those questions explicit when choosing infrastructure. Being able to inspect code is useful, and permission to build a commercial offering around it is another property. The module terms need to be evaluated for the intended use without assuming that the unchanged core license answers both questions.
For an installation using only core Redis, the BSD COPYING file remains the relevant core grant. An installation adding an affected module brings in the combined Apache and Commons Clause terms for that component. The August clarification makes that distinction public, while the pinned source notices provide the documents needed to examine a particular version.