Redis adopts dual source-available licensing

Original Article ↗ Hacker News Discussion ↗

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.