Redis module licensing changes the permitted product boundary

The difficult question in Redis Labs' module licensing change is which products may incorporate the software. The company wants applications to use its modules while restricting competing database offerings. Its new license expresses that distinction through a definition of database products, including products that expose certain APIs. That makes the architecture of a service relevant to the permission it receives.

The 21 February announcement replaces the company's Commons Clause approach for affected modules with the Redis Source Available License. Redis core remains separately licensed. A module's ability to run inside Redis does not mean its distribution terms match those of the server loading it. That distinction is necessary before discussing what this announcement changes for an application.

I have used Redis since its release, and its established semantics are part of its appeal to me. This announcement makes me more attentive to which component supplies a capability. The distinction between the core and an extension has consequences beyond command availability or deployment packaging.

The source tree records the change

RediSearch provides a concrete primary record. Its license change commit carries the date of the announcement. The license in that commit identifies itself as version 1, dated 21 February 2019. Reading that version avoids relying on a general licensing page that can change independently of the software under discussion.

The preceding Commons Clause license file describes Apache License 2.0 modified by an additional restriction. That restriction withholds the right to sell the software under its defined meaning of selling. The definition includes paid products or services whose value derives entirely or substantially from the software, and explicitly mentions hosting and consulting or support services.

The announcement identifies ambiguity about that restriction and confusion about the Apache name as reasons for replacing it. The new document uses its own license name and defines a set of excluded product categories. That is a change in how the boundary is expressed. It cannot be understood merely by observing that source code remains visible in a public repository.

For an engineer identifying dependencies, the commit establishes something testable without interpreting every possible application. A specific file at a specific revision has a specific license text. A dependency inventory that records only the repository name or the Redis protocol misses that level of detail. The module revision and its accompanying terms are part of the artifact being selected.

What version 1 actually grants

RSAL version 1 defines an application as an application developed by or for the recipient that is not a database product. Its grant permits modification, with modifications remaining under the license. Distribution and making the software available are permitted only as part of such an application, with a specified notice. Use also carries conditions tied to the application and third-party database products.

The definition of database product includes databases and caching engines. It also names stream-processing, search and indexing engines, along with machine-learning, deep-learning or artificial-intelligence serving engines. Beyond those functional categories, it includes products or services exposing the Redis API, the Redis Modules API or the licensed software's API.

That last group deserves attention because an API can be a product's external contract. A service can present a Redis-compatible interface while running code under a different commercial arrangement. Under this license's wording, the exposed interface is itself part of the definition. Calling a component a library or an internal module does not answer what interface the complete product exposes to its users.

The license also addresses sublicensing an embedded application, retention of notices and automatic termination following breach. Those clauses reinforce that the grant is conditional. The existence of permission to modify is not equivalent to permission to distribute any resulting product for any purpose. The categories and conditions have to be read together.

These are descriptions of the text attached to this revision. They do not decide how every borderline service should be classified. For architecture work, the useful immediate consequence is knowing what information the classification depends on. The product's purpose, the interfaces it exposes and the role of the licensed module all become relevant facts.

Redis core has a separate license

The Redis 5.0.3 COPYING file permits redistribution and use in source and binary forms, with or without modification, subject to its listed conditions. Those conditions concern retention of notices, reproduction of the terms in binary distributions and use of names for endorsement. It also contains the associated warranty and liability disclaimer.

That file is useful evidence because it belongs to a core release available before this announcement. The module change does not rewrite that artifact's license. An application using the server's built-in commands and an application loading an affected module therefore have different sets of component terms to consider, even if both connect through the same client library.

The February announcement explicitly preserves this separation. It describes the new terms as applying to certain modules running on top of open-source Redis. Treating the entire Redis installation as one undifferentiated license category would obscure the company's stated scope and the separate files in the source distributions.

I prefer to preserve that component distinction in technical descriptions. A claim that Redis has changed license is too imprecise for this event. The useful question is whether the installation includes a module distributed under the new terms, and which revision of that module it includes.

Deployment shape can affect product shape

The version 1 text connects permission to the application and the excluded product definitions. That creates a practical difference between software packaging and the product delivered to a customer. A module can be compiled separately, loaded by a server and used through an ordinary network connection. Those implementation boundaries do not by themselves establish the category of the resulting service.

For example, exposing a module's commands directly is an architectural fact different from using those commands behind an application-specific interface. The license's API clauses make that distinction relevant to reading its definition. This observation does not establish that hiding an API settles every other condition. The functional product categories remain in the same definition.

This is why a protocol compatibility claim cannot stand in for a licensing statement. Compatibility describes the commands and responses a client can exchange. Licensing describes the permissions attached to particular software. A client may be indifferent to which module implements a command while a distributor still needs to identify the module and its terms.

The distinction also applies to source availability. Being able to inspect the code helps an engineer understand implementation behavior. The permissions to use, change and redistribute that implementation remain those in its license. RSAL version 1 makes that separation explicit through its conditional grant and product restrictions.

The business aim and the implementation decision

Redis Labs frames the change as a response to cloud providers offering services based on software developed by others. The source license implements a broader set of named product restrictions rather than identifying a particular provider. An engineer evaluating the text therefore needs the actual definitions, even when the accompanying explanation emphasizes cloud economics.

That gap between motivation and mechanism is common in technical policy decisions. The motivation explains why a rule exists. The mechanism determines what information is needed to apply it. Here the mechanism asks about database-like products and exposed APIs, so the software bill of materials alone is incomplete without a description of the delivered product.

The change can also affect how a proposed extension is discussed within an architecture. Adding a module now introduces a component with terms different from the core release's BSD conditions. A build manifest can identify the selected revision, while an architecture description explains how customers access its functionality. Keeping both records makes the component decision reviewable when packaging or service interfaces change. That fact belongs alongside its command set and deployment requirements. It is part of deciding which implementation supplies the desired capability.

For this February change, the concrete record consists of a new license in the module tree and an unchanged BSD license in the existing core release. Keeping those records separate permits an accurate description of the system. The core server's terms do not automatically extend to a loaded module, and the module's restrictions do not replace the core server's own license file.