Redis adopts dual source-available licensing

Original Article ↗ Hacker News Discussion ↗

Redis Inc. is relicensing the popular in‑memory database from the permissive BSD license to a dual “source-available” model (SSPL and RSAL), effectively ending its status as open source and restricting others from offering Redis as a paid hosted service without separate terms. Commenters see the move as a response to cloud providers monetizing Redis while contributing relatively little back, but warn it will push Linux distributions to drop official packages and likely accelerate community forks and protocol‑compatible alternatives. The debate broadens into whether permissive licensing is viable for foundational server software in the cloud era, and whether non‑OSI licenses like SSPL are a reasonable way to fund development or a harmful erosion of software freedom.

What Redis Changed

  • Core Redis moved from 3-clause BSD to dual licensing:
    • SSPLv1 for source (copyleft, non-OSI-approved).
    • RSALv2 for “source-available” use, restricting “competitive offerings” (e.g., Redis-as-a-service).
  • Blog and FAQ emphasize:
    • Self-hosted / internal use remains free.
    • Managed service providers must either comply with SSPL (open their entire service stack) or sign commercial deals.

Impact on Users and Distributions

  • Most commenters think:
    • Typical app developers using Redis as a dependency are legally unaffected.
    • SaaS/DBaaS products offering Redis-like services face significant legal/operational risk.
  • Many expect:
    • Linux distros (Debian, Fedora, etc.) to drop or move Redis to non-free repos, as with MongoDB.
    • Users will increasingly install via vendor images/containers or switch to forks/alternatives.
  • Some worry about long‑term security updates for the last BSD-licensed releases and their backports.

Trust, Governance, and Contributor Reactions

  • Several see this as a “bait-and-switch”:
    • Earlier public assurances that core would stay BSD and “community-led” governance are contrasted with sudden relicensing and removal of the governance page.
    • New mandatory CLA lets Redis relicense future contributions; some contributors say they’ll stop contributing.
  • Others argue:
    • BSD explicitly allowed this; contributors should have understood the risk.
    • The project was always heavily shaped by the company that bought the trademark.

Forks and Alternatives

  • Multiple forks and alternatives are discussed:
    • Frozen BSD fork at the pre-change commit.
    • A work-in-progress community fork (“redict”) on Codeberg.
    • Drop-in or protocol-compatible options: KeyDB (MIT/BSL history), Dragonfly (BSL), Microsoft Garnet (MIT), Memcached, various Redis‑protocol backends (e.g., kvrocks).
  • Many expect a strong fork (backed by cloud vendors and ex-core devs) to become the de facto “open Redis”, citing MariaDB, OpenSearch, and OpenTofu precedents; others note not all forks succeed.

Cloud Providers and Fairness

  • One camp:
    • Sees SSPL/RSAL as justified defense against “mega-corp cloud leeches” reselling Redis with little or no financial support.
    • Argues sustainable OSS businesses need to capture some of the hosting revenue.
  • Another camp:
    • Counters that big clouds do contribute code and engineers, and operate within the freedoms BSD granted.
    • Argues the real failure is venture-backed “sell support/hosting” models, not OSS itself.

Licensing Philosophy and OSI Debate

  • Broad agreement that Redis is no longer open source under the OSI definition; it’s “source available”.
  • Disputes:
    • Some call SSPL “more truly copyleft” and in line with free‑software goals (forcing entire services open).
    • Others say SSPL imposes impossible obligations (e.g., all “hosting software”) and is a de facto field‑of‑use restriction.
  • Thread highlights confusion between:
    • “Permissive” vs “copyleft”.
    • “Open source” vs “source-available”.
    • “Free as in beer” vs “free as in freedom”.

Sustainability of FOSS Businesses

  • Recurrent themes:
    • Open core and hosted services have often failed under cloud competition; license tightening (Redis, HashiCorp, Elastic, MongoDB) is seen as a “rights ratchet”.
    • Foundations are not a panacea but are cited (Postgres, Kubernetes, Linux) as more stable long‑term stewards than VC‑backed companies.
  • Suggested alternatives:
    • Use AGPL from day one.
    • Put core under a neutral foundation; monetize proprietary extensions or SaaS layers.
    • Normalize direct funding and in‑house contributors from major users.
  • Views diverge on the future:
    • Some predict a retreat from FOSS back to proprietary/shareware.
    • Others think the episode will encourage earlier forks and more careful license choices rather than end large-scale open source.