Redis Labs adopts the Redis name under existing project governance
Redis Labs becomes Redis while stating that the core project's BSD license and governance remain unchanged. The shared name makes precise references to the company, project and released code more useful.
A company and an open-source project can share a name while remaining different subjects in a technical discussion. Redis Labs is becoming Redis, which makes that distinction more important in explanations of releases and operational dependencies. The announcement concerns the company's identity. Its accompanying statements about the project's license and governance define what the company says this change leaves in place.
The August 11 founders' announcement says the company is dropping Labs from its name. It explicitly states that the core project's BSD licensing and the governance model introduced the previous year remain unchanged. It also says future references will distinguish the company from the open-source project. Those are concrete commitments attached to the announcement, rather than evidence of a new database release.
I have used Redis since its early releases, so the software name already describes a long-established technical dependency for me. A shared company name does not tell me which binary an application runs or which commands it can use. Those questions still depend on the particular project release and the components selected for the deployment.
The governance transition predates the rename
The July 2020 core-team update describes the governance change following Salvatore Sanfilippo's decision to step back as the project's sole maintainer. Yossi Gottlieb and Oran Agra explain the intention to form a team of people already committed to the project. The update identifies Itamar Haber as a community lead and announces Madelyn Olson from AWS and Zhao Zhao from Alibaba Cloud as team members.
That history matters because the August rename does not originate the core-team model. The company is restating continuity with a model introduced earlier. Treating the two events as one would obscure the period during which the team has already been responsible for the project.
The company's accompanying press release describes the team's responsibility for the main Redis repository and coordination with related ecosystem projects. It also records company sponsorship beginning in 2015 and Sanfilippo stepping back from sole maintainership in June 2020. These details explain the relationship presented in the announcement without requiring the company and project to be interchangeable nouns.
Core-team membership and company identity answer different questions. One identifies people participating in project maintenance. The other identifies a commercial organization and its offerings. A reader assessing an engineering dependency needs the former information when considering how changes enter the main repository, even when the latter name appears in a contract.
Released code supplies a precise licensing reference
The COPYING file in Redis 6.2.5 supplies a contemporaneous reference for the core software's license. It permits redistribution in source and binary forms, including modified forms, subject to its stated conditions. Those conditions cover retaining notices and the disclaimer, and restricting use of contributor or project names for endorsement without permission.
The file also includes the warranty disclaimer. A company announcement and a released license file have different roles. The announcement states the intended effect of the rename. The file accompanies a particular version of the software and supplies the terms that version carries. Naming the release makes the reference more precise than relying on branding alone.
That distinction is also useful for dependency documentation. A system can identify the version it uses and link to the corresponding source and license. The shared brand does not require an engineer to collapse those references into one undifferentiated product description. The repository artifact gives the claim a definite subject.
I prefer that level of specificity because Redis is useful to me as software with known behavior. Governance explains who maintains the project, and the release identifies the code available to run. Both pieces of information remain meaningful after the company-name change.
A name does not specify command behavior
The existing 6.2.5 release notes illustrate the separate technical record. They describe a 32-bit BITFIELD security correction and changes to several command reply types. Those are versioned behaviors that a client or operator can encounter. The August naming announcement neither defines those behaviors nor substitutes for their release notes.
This gives the rename a practical documentation consequence. References to the company can use its new name while references to server behavior retain a version and project context. An incident explanation about a command response needs the latter. A statement about the organization providing an offering needs the former.
The founders' announcement states that project licensing and governance remain in place. The prior core-team update supplies the governance history, while the 6.2.5 artifacts supply a definite release and license reference. Together they let an engineer describe the August company-name change without assigning new command behavior or new release semantics to the announcement.