Redis Stack adds a license choice while Redis core remains BSD

Redis Stack's combined distribution does not give all of its components the same license. The November licensing announcement makes that boundary explicit. Stack and the Redis modules move to a choice of RSALv2 or SSPLv1 for source, while the Redis open source core remains under its three-clause BSD license.

The November 15 announcement identifies two motivations. Redis says users have found the earlier RSAL text difficult to interpret, and that it has not standardized on a widely used source-available license. Its response is a revised RSAL and an alternative license with different obligations. The change concerns the terms on which the modules and Stack are made available, not a new command or storage format.

I value the Redis data structures and their established ecosystem. Licensing belongs in the description of a dependency because it determines what kind of distribution or service a developer can build around that dependency. A shared protocol and convenient package do not erase differences between the components being used.

The core server is outside this change

The announcement explicitly states that Redis core remains BSD-licensed. The Redis 7.0.5 COPYING file provides the corresponding license text. It permits source and binary redistribution with or without modification, subject to retaining the required notices and disclaimer and observing its endorsement condition.

That text is distinct from a module license. An application using core commands has a different dependency description from one using RedisJSON or RediSearch. Calling both deployments Redis is convenient in conversation, but insufficient when identifying the code and permissions included in a product.

The technical boundary is visible in the Stack startup script from its launch. It starts Redis with separate shared libraries loaded as modules. Packaging makes those components available together, while their identities remain separate. The licensing announcement follows that distinction by naming the core as unaffected.

The announcement also says Redis Enterprise Software and Redis Enterprise Cloud customers are unaffected. That is another scope statement. It prevents the new source choices from being read as a change to every commercial arrangement associated with the Redis name.

Source and default binaries have different stated terms

Beginning November 15, Redis says default binary distributions of Stack and its modules use RSALv2. Users of the source can choose either RSALv2 or SSPLv1. The term dual licensing therefore needs to retain the distinction between obtaining source and using the default supplied binary.

A choice of source license is not a statement that both licenses simultaneously apply to every action. The announcement presents them as alternatives. Its explanation compares RSALv2's restrictions with SSPL's copyleft obligations so that users can identify the relevant terms for their chosen route.

This also makes artifact identity relevant. A product inventory needs to know whether it uses Redis core, a default Stack binary, or a module built from source under one of the offered terms. The name of the application package alone may not preserve that information.

The article describes the new licensing as applying at specified module version boundaries. It identifies RediSearch 2.6, RedisJSON 2.4, RedisGraph 2.10, RedisTimeSeries 1.8, RedisBloom 2.4, and RedisGears 2.0 in the newer group. It also says fixes for previously released versions remain under RSALv1. This is a versioned transition, rather than a claim that every historical module release has been placed under the new terms.

RSALv2 addresses commercialization and notices

Redis describes RSALv2 as allowing use and modification while restricting commercialization or providing the software to others as a managed service. It also prohibits removing or obscuring licensing and other notices. Those restrictions distinguish it from the core's BSD terms even though source is available.

The announcement supplies examples to explain its intent. A SaaS application powered by Stack on its backend is described as permitted. A database service allowing developers to deploy Stack instances is described as prohibited under that license. The distinction concerns the service supplied to others, not merely whether a business earns revenue from software that uses Redis.

Those examples should remain attached to their source. They are Redis's explanation of its license model, not a universal classification of every possible hosted architecture. The underlying point is that using a component inside an application and offering that component's functionality as a service can be treated differently by the stated terms.

The earlier RSAL file included in the launch repository shows the previous structure. It defines a category of database products and an application outside that category, then conditions grants on those definitions. The November announcement says its revised wording aims to make the permissions and limitations easier to understand.

SSPL's service obligation extends beyond server modifications

The alternative is SSPL version 1, the existing license identified by the announcement. Its section 13 addresses making the program's functionality available to third parties as a service. It requires service source code to be available through a free network download under the license when that condition applies.

The definition of service source includes more than modifications to the database program. It names the programs used to make the service available, including management and automation software, with the aim of allowing another user to run an instance using the released source. That breadth is central to understanding why SSPL is not simply an alternative way to publish a small patch to a module.

The license also describes conveying source and object-code forms in other sections. Source distribution has notice and licensing conditions. Object-code distribution has corresponding-source requirements. The hosted-service provision adds a separate situation that needs to be understood alongside those distribution provisions.

Redis explicitly says neither RSALv2 nor SSPL is OSI-approved. Source availability and open source approval are different claims, and the announcement does not equate them. Describing the new options accurately requires keeping that terminology precise.

Module requirements identify the relevant dependency

An application that uses JSON document commands depends on a module implementing them. Search queries depend on the search module. A client abstraction may hide the command spelling, but it does not remove the server component that supplies the behavior. That is why the licensing boundary has a direct relationship to technical dependency analysis.

The same architecture can contain core commands and module commands. There is no need to classify the entire application by a single database adjective to describe that. Its dependency record can name the components and versions that supply the operations it actually uses.

I prefer that explicit description because it also improves reproducibility. The component list that explains a license decision helps explain why one server can execute the application's commands and another cannot. Packaging is useful, but the underlying module requirements remain part of the system's design.

The old RSAL defines its software as components designed to work with Redis and defines Redis separately as the open source project. This is another concrete indication that the module terms were never simply the core server license. Its application definition excludes the defined database-product category, and its grant refers back to those definitions. Reading a permission sentence without its defined terms would lose that structure.

The core BSD file uses a different form. It permits redistribution subject to a short list of notice and endorsement conditions and includes a warranty disclaimer. It does not use the older RSAL distinction between an application and a database product. These are differences in the published texts, independent of whether the components communicate through one protocol or arrive in one download. The November announcement retains that separation while changing the module options it describes.

The announcement changes available terms

This is a licensing milestone for the module ecosystem and the Stack distribution. It does not announce a corresponding change to Redis core's BSD license. Its practical distinctions concern which component is used, whether the artifact is source or a default binary, and which version falls within the announced transition.

The two offered source licenses express different approaches to services built around the software. RSALv2 imposes commercialization restrictions described by Redis's examples. SSPL supplies a service-source obligation with a wider definition than the server code alone. Keeping those terms attached to the actual module dependency gives an engineer a precise account of what changed on November 15.