Redis, 이중 소스 사용 가능 라이선스 채택

 (redis.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Redis는 Redis 7.4부터 BSD 3-Clause 배포를 중단하고, 앞으로 Redis를 RSALv2 또는 SSPLv1로 제공해 라이선스 경계를 크게 바꿈
  • 소스 코드는 Redis Community Edition으로 계속 무료 제공되지만, 새 라이선스는 OSI 정의의 오픈소스에는 해당하지 않음
  • Redis는 Core와 Stack을 통합해 검색, JSON, 벡터, 확률적 데이터 구조, 시계열 데이터 모델을 하나의 무료 패키지로 묶을 계획임
  • 내부·개인 사용, 클라이언트 라이브러리, 통합 파트너, 기존 Redis Enterprise 고객은 영향을 받지 않지만, 경쟁적 관리형 서비스는 새 Redis 소스 코드를 무료로 쓸 수 없음
  • Redis 8부터 Redis Stack 기능이 Redis 자체에 포함될 예정이며, 이후 별도 Redis Stack 빌드의 수명 종료가 진행됨

Redis 라이선스 변경 범위

  • Redis는 앞으로 나오는 모든 Redis 버전을 소스 사용 가능 라이선스로 배포함
  • Redis 7.4부터 Redis Core 소프트웨어는 Redis Source Available License v2 또는 Server Side Public License v1 중 하나로 사용할 수 있음
  • 더 이상 BSD 3-Clause 라이선스로 배포되지 않음
  • Redis 소스 코드는 Redis GitHub 저장소를 통해 Redis Community Edition으로 계속 무료 제공됨
  • RSALv2와 SSPLv1은 모두 OSI 승인 라이선스가 아니며, 각각 사용 제한이 있음

Redis Stack 통합과 제품 구성 변화

  • 향후 소스 사용 가능 릴리스는 Redis Core와 Redis Stack을 통합함
  • 통합 대상은 검색, JSON, 벡터, 확률적 데이터 구조, 시계열 데이터 모델임
  • 하나의 무료 다운로드 패키지로 제공되며, Redis는 다음 용도로 사용할 수 있음
    • 고성능 키/값 저장소
    • 문서 저장소
    • 쿼리 엔진
    • 생성형 AI 애플리케이션을 위한 저지연 벡터 데이터베이스
  • Redis 8부터 기존 Redis Stack에서 RSALv2 또는 SSPLv1로 제공되던 새 데이터 타입과 처리 엔진이 기본 제공 항목에 포함될 계획임
  • Redis 8 제공 이후에는 별도 Redis Stack 빌드가 필요 없어져 Redis Stack 수명 종료가 진행됨

변경 배경과 Redis의 입장

  • Redis는 Redis Stack 배포판의 고급 Redis 모듈에 이미 이중 라이선스를 적용해 왔고, Redis 6 이후 redis.io 다운로드의 50% 이상이 Redis Stack에서 나왔다고 밝힘
  • 여러 배포판을 동시에 유지하는 구조가 Redis의 향후 개발 추진과 충돌한다고 봄
    • 오픈소스 배포판
    • 소스 사용 가능 배포판
    • 온프레미스와 클라우드 플랫폼에 최적화된 상용 소프트웨어
  • Redis는 주요 클라우드 서비스 제공자가 Redis의 투자와 오픈소스 커뮤니티를 상품화한다고 봄
  • 이번 변경은 기능이 풍부한 무료 소프트웨어와 엔터프라이즈 제품에 계속 투자하기 위해 상용 사용을 관리하려는 조치임
  • 이 변경으로 Redis는 더 이상 OSI 정의상 오픈소스가 아님

사용자와 파트너에게 미치는 영향

  • Redis의 기존 오픈소스 버전이나 새 이중 라이선스 릴리스를 내부·개인 용도로 쓰는 최종 사용자는 영향을 받지 않음
  • Redis와 연동되는 클라이언트 라이브러리나 기타 통합을 만든 파트너에게도 변경이 없음
  • Redis가 책임지는 모든 Redis 클라이언트 라이브러리는 오픈소스 라이선스를 유지함
  • 기존 Redis Enterprise 고객은 별도로 협상된 라이선스 조건으로 기술을 제공받기 때문에 영향이 없음
  • Redis Community Edition이나 Enterprise를 비경쟁적 형태로 활용하는 통합 및 관리형 서비스 파트너는 Redis와의 파트너십을 통해 계속 솔루션을 구축·운영·제공할 수 있음
  • Partner Program은 향후 Redis 기술, 기능, 릴리스에 대한 독점 접근을 제공함

클라우드 서비스와 경쟁 제품 제한

  • 새 라이선스 아래에서 Redis 호스팅 서비스를 제공하는 클라우드 서비스 제공자는 Redis 소스 코드를 무료로 사용할 수 없음
  • 예를 들어 클라우드 서비스 제공자는 Redis 코드 유지관리자인 Redis와 라이선스 조건에 합의한 뒤에만 Redis 7.4를 제공할 수 있음
  • Redis의 “경쟁적 제공”은 Redis 코드베이스에서 파생되고 Redis 상용 제품의 기능과 크게 겹치며, 제3자에게 판매되는 제품을 뜻함
    • 유료 지원 계약을 통한 판매도 포함됨
    • Redis Enterprise Software 또는 Redis Cloud와 경쟁적으로 판매되는 솔루션 안에 Redis를 호스팅하거나 내장하는 경우가 예시임
  • Redis를 활용하더라도 Redis 자체와 구체적으로 경쟁하지 않는 솔루션에는 영향이 없음
  • 특정 사용 사례 문의는 redis_licensing@redis.com으로 안내됨

RSALv2와 SSPLv1의 조건

  • RSALv2는 비카피레프트 성격의 허용적 라이선스로, 소프트웨어 사용, 복사, 배포, 제공, 파생 저작물 준비 권리를 허용함
  • RSALv2의 주요 제한은 두 가지임
    • 소프트웨어를 상업화하거나 관리형 서비스로 다른 사람에게 제공할 수 없음
    • 라이선스, 저작권, 기타 고지를 제거하거나 가릴 수 없음
  • SSPLv1은 AGPL을 기반으로 하며, 서비스로 제공하는 경우 서비스 전체의 소스 코드를 SSPL로 공개해야 함
    • 관리 소프트웨어, 사용자 인터페이스, API, 자동화 소프트웨어, 모니터링, 백업, 스토리지, 호스팅 소프트웨어가 포함됨
    • MongoDB가 이 라이선스의 발행자임
  • SSPL로 라이선스된 소프트웨어를 수정한 버전은 다른 라이선스로 재배포할 수 없음
  • 이중 라이선스에서 RSALv2를 선택하면, 제3자에게 서비스로 기능을 제공하지 않는 등 RSALv2 제한을 지키는 범위에서 수정과 재배포가 가능함

기존 BSD 버전과 보안 패치

  • 라이선스 변경은 소급 적용되지 않음
  • 변경 전의 모든 소스 코드와 릴리스는 BSD 3-Clause 라이선스 아래에 남음
  • 사용자는 해당 라이선스 조건을 지키는 한 기존 BSD 버전을 무기한 계속 사용할 수 있음
  • Redis는 Redis Community Edition이 제공될 때까지 현행 보안 정책에 따라 해당 릴리스의 보안 업데이트와 중요한 결함 수정을 계속 제공할 계획임
  • 기존 BSD 3-Clause 버전에 대한 중요 보안 패치 백포트는 Redis Community Edition 9.0 출시 전까지 제공되며, 이후 패치는 새 이중 라이선스로 제공됨

이름, 기여, 코드 혼합 조건

  • Redis 7.2 및 이전 릴리스는 계속 Redis OSS로 불림
  • Redis 7.4부터 공개적이고 무료로 제공되는 버전은 Redis Community Edition으로 불림
  • 제품명에는 더 이상 “Redis” 또는 “for Redis”를 사용할 수 없지만, 제품 설명에서 Redis 호환 또는 legacy-Redis 기반이라고 명시할 수 있음
  • 커뮤니티 기여는 계속 받을 수 있으나, 기여 검토를 위해 Contributor License Agreement 동의가 필요함
  • RSALv2 또는 SSPLv1 코드와 다른 라이선스의 코드는 각 구성 요소가 자체 라이선스를 유지하고 GPL 같은 강한 카피레프트 코드와 섞지 않는 조건에서 함께 사용할 수 있음
  • 조직 내부에서 Redis를 서비스로 호스팅하는 것은 허용되며, 조직에는 계열사와 자회사가 포함됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이건 Hashicorp가 밀리고 매각처를 찾는 것처럼 Redis Labs도 망가뜨릴 가능성이 크고, Redis Labs를 베끼려는 쪽을 막지도 못할 것 같음
    진짜 피해를 보는 건 법적 골치 없이 Redis 캐시를 쓰고 싶은 작은 스타트업들임. AWS는 Redis를 포크할 수 있고, 오히려 그 포크를 허용적 라이선스로 내놓으면 Redis Labs 쪽이 라이선스 측면에서 더 나쁜 선택지가 될 수 있음
    어려운 선택이긴 하지만, 코드를 독점으로 유지하든지 아니면 Apache 또는 MIT를 고수하는 편이 낫다고 봄. 중간에 라이선스를 바꾸는 건 정말 별로고 역효과가 날 운명처럼 보임
    오픈소스는 사용자가 소프트웨어를 소유할 수 있게 하는 것임. 돈을 벌려고 법적 꼼수로 이를 우회하려 하면 대기업 팀이 아니라 사용자들이 다침. Redis는 늘 허용적 오픈소스 프로젝트였고, 바로 그 점 때문에 성공했음. 그 조건을 바꾸면 앞으로의 계산식도 바뀌고, 관련된 모두에게 나쁜 결과를 예고함

    • 이 일은 장기적으로 기업이 오픈소스 사용자 요구의 좋은 관리자가 될 수 있다는 생각을 거의 끝장내는 것 같음
      PostgreSQL처럼 재단이 소유한 소프트웨어와 기업이 소유한 오픈소스의 차이를 더 분명히 봐야 함. “주주 가치 극대화”에 초점을 맞추면 사용자 자유를 지키는 목표는 결국 뒤로 밀릴 수밖에 없음
      Redis 커뮤니티 입장에서는 Antirez가 고용 관계와 프로젝트 소유권을 분리해 비영리 쪽에 맡기는 편이 훨씬 나았을 것임. Apache Redis 같은 형태가 커뮤니티에 더 좋고, Redis Labs도 그 주변에서 독점 확장과 클라우드 사업을 만들 수 있었을 것임
    • 시간이 지나며 이 관점에 동의하게 됐고, 이렇게 정리하게 됨: 목표가 이익이라면 핵심 제품을 오픈소스로 공개하지 말라는 것
      회사가 핵심 소프트웨어를 허용적 라이선스로 공개하면, 더 큰 경쟁자가 와서 그 소프트웨어를 재배포하는 솔루션을 팔아버리는 일을 계속 봐왔음
      회사의 중심 목표가 이익이라면 이는 존립 위협임. 반대로 회사의 목표가 비영리 관리자로서 소프트웨어가 계속 존재하게 하는 것이라면 이는 대성공임
      핵심 제품이 아닌 보조 소프트웨어, 예를 들어 직접 팔아 돈을 버는 대상은 아니지만 개발 중 만든 유용한 도구에는 이 논리가 적용되지 않음
    • 오픈소스에는 “너희가 구현하고, 우리가 판다, 고마워” 문제가 있음
      이번 라이선스 변경은 바로 그 문제, 즉 클라우드 초대형 기업이 무임승차하지 못하게 하려는 것임
      나에게는 더 나은 AGPL처럼 들림. 철학적 뉘앙스나 OSI 승인 목록에는 관심 없고, 결국 AGPL보다 훨씬 덜 제한적임. 소스 코드가 있고, 로컬에서 돌릴 수 있고, 내 프로젝트와 상업 프로젝트, 직장, 베어메탈, VM, Docker, k8s, Azure에서 같은 방식으로 쓸 수 있음
      Microsoft가 이미 받고 있는 프리미엄의 일부를 나눠야 한다는 사실은 나와 무관함. 오히려 지속 가능한 사업 모델을 찾아낸 점은 박수칠 만함
    • “오픈소스는 사용자의 소프트웨어 소유권”이라는 말은 틀림
      OSS 개발자는 저작권을 보유함. 퍼블릭 도메인을 제외하면 라이선스와 조건을 바꿀 수 있는 건 저자뿐임. 사용자는 소프트웨어와 코드로 여러 일을 할 수 있는 라이선스를 받는 것이지, 소유권을 얻는 게 아님
    • “돈을 벌려고 법적 꼼수로 우회한다”는 건 엔시티피케이션을 떠올리게 함
      전적으로 동의하고, Cory Doctorow의 논지에 또 하나의 사례가 추가된 느낌임

  • 지금쯤 이미 포크가 진행 중일 것 같음. 회사가 자기 개발자 커뮤니티와 스스로 단절하는 모습을 보는 건 좀 슬픔
    왜 그러는지는 이해하지만 장기적으로 통한다고 보지는 않음
    대부분의 Redis 사용자는 뒤에 있는 회사에 단 한 푼도 낸 적이 없고, 나도 마찬가지임. 돈을 벌기 위해 이렇게 하는 건 이해하지만 내 행동은 바뀌지 않을 것임. 그냥 포크를 쓸 것임. 다른 대다수 Redis 사용자, 외부 기여자, Redis를 상업적으로 제공하던 모든 클라우드 사업자도 그럴 것이고, 시간이 지나면 현재 Redis 직원 중 꽤 많은 수도 그쪽으로 갈 수 있음
    상업 사용자와 클라우드 사업자가 많기 때문에 이들이 조직화되는 데 오래 걸리지 않을 것 같음. 이미 돈 내는 사용자가 많으니 사실상 그럴 수밖에 없음
    Terraform, Elasticsearch, Red Hat 등에서도 이미 비슷한 선례가 있음. 목표 사용자와 잠재 고객 상당수가 오픈소스 포크에 의존하게 만드는 건 사업 전략으로 잘못된 방향처럼 보임
    Oracle이 Sun의 오픈소스 프로젝트들, 예컨대 mysql, hudson, openoffice 등을 가져갔을 때도 대부분의 통제권을 빠르게 잃었음. Oracle의 폐쇄형 제품을 쓰라고 설득하려던 시도는 별 성과가 없었음. Java조차 결국 어느 정도 물러섰고, 요즘 중심은 openjdk임. 몇몇 은행을 제외하면 Oracle JDK를 쓰는 사람은 거의 없음. 그럴 필요가 없고, Oracle도 오래전에 장점이 있다는 척을 멈췄음. 모든 개발은 OpenJDK에서 일어나고, 인증 빌드를 제공하는 회사도 여럿임
    개인적으로 Elasticsearch와 Opensearch 컨설팅을 하는데, 최근 고객 대부분은 Opensearch를 기본값으로 삼음. 그냥 그렇게 흘러감. 모두 무료이자 오픈소스인 선택지를 고름
    결론은 하나뿐임. 현재 Redis 사용자 대다수가 쓰게 될 Redis 포크가 만들어질 것임

    • Microsoft가 3일 전에 거의 드롭인 대체품을 내놨음[1]. 대부분의 Redis 클라이언트와 동작한다고 주장함. 적어도 Azure 사용자에게는 꽤 큰 변화를 만들 것 같음
      [1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
    • 장기 전략은 Broadcom식 관점으로 보면 통할 수도 있음. 많은 사용자를 잡는 게 아니라, 제품을 중심으로 자기 시스템을 구축한 아주 비싼 소수 고객을 노리는 방식임
      기업 입장에서는 완전히 이전하지 않기 위해, 또는 단기적으로 마이그레이션하는 동안 가격 인상을 감수할 수 있음
      단기 이탈을 막으려면 제공자가 “시간을 사서” 가격을 낮게 유지하다가 프로젝트가 포크와 충분히 달라져 이전이 훨씬 어려워진 뒤 가격을 올릴 수도 있음
      어느 쪽이든 장기적으로는 다양한 규모의 많은 회사를 계속 지원하기보다 소수 기업에서 큰돈을 벌 수 있음. 마음에 들지는 않지만 작동할 수는 있어 보임
    • 이미 진행 중인 포크가 있음: https://codeberg.org/redict/redict
    • 장기적으로는 FOSS가 업계의 한때 유행으로 여겨지고 다시는 반복되지 않을 수도 있음. 업계가 무료 등급이나 소스 코드에서 전체 기능을 제공하지 않는 체험판과 데모판으로 돌아가는 방향에 안착할 수 있음
    • 냉소적으로 보면 Oracle은 이미 훨씬 비싼 대안이 있었기 때문에 MySQL을 수익 중심으로 만들 필요가 없었음
      MySQL 커뮤니티를 쪼개고, 사용과 외부 개발을 위축시키며, 전체 프로젝트 속도를 늦추는 것만으로도 좋은 투자수익률을 얻었을 수 있음

  • 이런 프로젝트들의 큰 동력은 계속 호스팅 수익이고, 그래서 라이선스 변경이 벌어짐
    흐름을 보면 프로젝트를 소유한 회사에 맞는 오픈소스는 라이브러리뿐인 것 같음. 프로그램, 예를 들어 데이터베이스 같은 서버 소프트웨어라면 소스 공개형이 되거나 재단 아래 있어야 함. 어렵고 답이 뭔지는 모르겠음
    복잡한 프로그램에도 허용적 오픈소스 라이선스가 다시 돌아오게 하는 모델을 보고 싶지만, 아직 실행 가능한 방법은 안 보임. 상표권 집행과 오픈소스 코드, 그리고 라이선스된 빌드만 제공하는 방식일 수도 있음
    어쨌든 앞으로도 인기 오픈소스 소프트웨어의 부상과 몰락, 또는 라이선스 변경은 계속 보게 될 것임. 개발자와 회사가 처음에 오픈소스로 시작할 이점이 너무 크고, 나중에 바꾸려는 압박도 너무 큼
    최소한 Redis가 세상에 준 가치는 가져간 가치보다 훨씬 컸다고 인정하고 싶음. 정말 압도적인 차이임
    포크가 얼마나 빨리 나오고 성공할지, 그리고 5년 뒤 Redis라는 회사의 매출 성장 곡선이 어떨지 흥미로울 것임

    • 결국 거대한 클라우드 제공자들이 Redis 같은 회사의 점심을 빼앗아 먹는 구조 아닌가 싶음
      라이선스는 잘 모르지만, 기반 기술을 만든 중소 규모 회사들이 과점적 클라우드 거인에게 상품화되고 높은 가격으로 재판매되는 상황에는 크게 공감함. 오히려 이렇게 오래 걸린 게 놀라움
      기업과 오픈소스가 모두 건강한 생태계를 원한다고 할 때, 라이선스 변경 말고 어떤 대안이 있을지 궁금함
    • 재단이 이 문제의 마법 같은 해법이라고 보지는 않음
      단일 회사가 재단 바깥으로 사실상 “포크”해서 빠져나가기로 한 사례가 많고, 커뮤니티는 결국 같은 결과를 맞게 됨
    • “복잡한 프로그램을 위한 허용적 오픈소스 라이선스”라면 AGPL3 같은 것인가?
      https://spdx.org/licenses/AGPL-3.0-or-later.html
    • 개발자들도 다른 전문직과 다르지 않다는 점을 인정하면 도움이 될 것임. 자기 일에는 보수를 기대하면서 작업 도구를 만든 사람에게는 한 푼도 내고 싶지 않은 태도는 지속될 수 없음
      작업 도구를 만드는 사람들도 청구서를 내야 함
      어떤 의미에서는 FOSS의 꿈이 실패한 데 개발자 자신에게도 책임이 있음
      천천히 퍼블릭 도메인과 셰어웨어 시절로 돌아가고 있음
    • “오픈소스 코드에 라이선스된 빌드만 제공”하는 건 오픈소스가 아님

  • 사람들은 오픈소스로 돈 버는 모델은 지원 서비스라고 늘 말했음. 예를 들어 어떤 회사가 Postgres를 쓰면 온프레미스 구성에서 전문가가 도와주고 장애를 꺼주는 식임
    하지만 “클라우드” 시대에는 회사들이 그냥 Amazon, Microsoft, Google 등이 제공하는 관리형 서비스를 쓰고, 프로젝트 유지보수자와 주변 사람들의 재정적 기회는 사실상 사라짐. 누구도 OSS에서 죽어라 일해 놓고 AWS가 아무것도 돌려주지 않은 채 수백만 달러를 벌어가는 걸 보고 싶어 하지 않음

    • 공개: Amazon에서 일하지만 Redis 관련 클라우드 서비스에 직접 관여하지는 않음. 오픈소스 프로그램 사무소와는 가까이 있고, 오픈소스 프로젝트에서 협업하는 데 필요한 힘든 일을 하는 사람들을 매우 중요하게 생각함
      Madelyn Olson은 AWS에 고용된 상태에서 수년간 힘든 일을 해 다른 Redis 핵심 개발자들의 신뢰를 얻고 핵심 유지보수자가 됐음. 그녀와 다른 AWS 개발자들은 Redis 핵심 엔진에 많이 기여했음. 그들 역시 Redis 커뮤니티를 위해 열심히 일했다고 말할 수 있음
      관련 기여는 여기에서 더 읽을 수 있음: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...

  • 더 많은 오픈소스 프로젝트가 SSPL을 채택하거나, Llama 2처럼 무료 사용 가능한 회사 규모에 제한을 두는 방식을 실험해야 함. 예를 들어 오픈소스이지만 수십억 달러 규모의 클라우드 초대형 기업에는 해당하지 않는 식임
    개인 개발자가 기여할 때 AWS의 무임승차를 가능하게 하려고 한 건 아니었음
    프로젝트들이 더 제한적인 라이선스로 몰려가는 가장 큰 이유는 AWS임. AWS가 해야 했던 옳은 일은 원 저자나 회사의 작업을 존중하고, 원 개발자가 지원하는 제품에 힘을 실어주는 것이었음. 대신 AWS는 OSS 제품이 성공하는 걸 보면 경쟁 제품을 만듦. 더 촘촘한 통합과 마케팅 힘 때문에 제3자 벤더는 승산이 없음
    게다가 Amazon과 AWS는 오픈소스의 큰, 어쩌면 가장 큰 수혜자이면서도 거의 돌려주지 않음. Google, Microsoft, 심지어 Oracle도 Amazon보다 오픈소스에 더 많이 기여함

    • SSPL과 AGPL은 괜찮지만, 내 권리를 다른 사람에게 넘기게 만드는 CLA가 없다면 그렇다는 조건이 붙음
      CLA가 있는 프로젝트에는 기여한 적이 없고, 고용주가 돈을 주지 않는 한 앞으로도 그럴 생각이 없음
    • 예전에 AI가 코드를 쓰지 못하게 하는 FOSS 라이선스를 주장해 본 적이 있음. 제한을 부과하므로 FOSS가 아니라는 부정적 반응을 많이 받았음. SSPL도 마찬가지임
      하지만 장기적인 FOSS 생존 가능성을 위해서는 FOSS 개발자를 사실상 착취하는 거대 기업들로부터 우리 자신을 보호하기 위한 제한이 필요할 수 있음
    • AWS가 많은 OSS 프로젝트가 인기 있어진 큰 이유 중 하나라는 점도 잊으면 안 됨
      Redis, Mongo, ES, HashiCorp 제품군, 빅데이터 생태계 전체가 AWS의 제공을 통해 더 널리 알려졌음. AWS나 다른 대형 클라우드 제공자가 밀어주지 않아 아직도 사람들이 모르는, 수년간 개발된 잘 알려지지 않은 데이터베이스도 많음
      또한 자유로운 라이선스 덕분에 사용과 인기가 늘어나면서 많은 프로젝트가 버그 보고, PR, 패치 같은 기여를 받음. SSPL, BSL 계열 라이선스가 붙은 것에는 별로 기여하고 싶지 않음. 나중에 자유롭게 쓸 수 없는 것에 시간을 낭비하고 싶지 않기 때문임
    • Redis가 커진 건 정확히 무료이자 개방형이었기 때문이라는 점을 잊고 있음
      Redis가 Llama 2와 비슷한 제한을 달고 나왔다면 시작부터 망했을 것임. 주요 소비자는 기업이고, Llama 2가 인기를 얻은 주된 이유는 개인이 개인 용도로 쓸 수 있는 고품질 LLM을 초기에 제공했기 때문임
      RESP와 호환되는 키-값 저장소는 특별히 대단한 것이 아님. Microsoft도 방금 MIT 라이선스로 자체 구현인 garnet을 내놨음. Redis의 가치는 언제나 무료이자 오픈소스라는 점과 그것을 지탱한 커뮤니티였음. 이제 Redis를 쓸 가장 큰 이유를 버린 셈임
    • AWS가 어떤 경우에는 원 개발자 쪽을 지원하기도 함. 관리형 Grafana와 Prometheus는 Grafana Labs와 협력함
      하지만 내가 아는 건 사실상 그 사례뿐이고, MongoDB, Redis, Memcached, MySQL, PgSQL 등 거의 모든 다른 경우는 그렇지 않음

  • Redis Inc.가 https://github.com/redis/redis/ 프로젝트를 3조항 BSD 라이선스에서 OSI 승인을 받지 않은 두 라이선스의 이중 라이선스로 옮기고 있음
    이전에는 “Redis core license는 3-Clause-BSD로 라이선스되어 있으며 앞으로도 항상 그럴 것”이라고 말한 적이 있음. (https://redis.com/blog/redis-labs-modules-license-changes/)

    • 오픈소스 프로젝트를 개발한 것도 아니고 채택한 회사들을 MBA CEO들이 장악한 결과임

  • 지원 종료가 걱정된다면, Redis 7.4가 새 라이선스 아래 첫 릴리스가 되고 7.2가 예전 라이선스의 마지막 릴리스가 됨
    Redis는 특정 시점에 추가 릴리스 2개를 지원함: latest major.(minor-1), (major-1).(last-minor)
    대략적으로는 8.0이 나오면 6.2 지원이 끝나고, 7.6 또는 8.0이 나오면 7.2 지원이 끝난다는 뜻임
    과거 릴리스를 보면 8.0은 2025년 3~5월쯤 나올 것으로 예상함. 따라서 3BSD 라이선스 아래 Redis에 의존한다면 그에 맞춰 계획해야 함
    Ubuntu는 redis를 universe 저장소에 패키징하므로 보안 업그레이드는 Ubuntu Pro 고객에게만 제공됨. 따라서 Ubuntu 20.04는 Ubuntu Pro의 ESM 사용자를 제외하면 2024년 4월에 redis 업그레이드가 멈춤
    Debian 11/12는 Redis 6.0/7.0을 따라가므로 7.2의 패치를 백포트할 책임이 있음. 7.2가 보안 업데이트를 받지 않고 7.4 브랜치로만 제공되면 이게 어떻게 될지는 확실하지 않음
    직접 사용 방식이 새 라이선스와 맞더라도 간접적으로 영향을 받을 수 있음. 배포판이 다음 릴리스에서 공식 저장소에서 redis를 제외할 가능성이 높기 때문에, 다음 배포판 업그레이드 주기에서 이를 고려해야 함
    (https://endoflife.date/redis를 유지보수하고 있으니, 지원 종료와 지원에 어떤 영향이 있는지 명확히 아는 사람이 있으면 PR을 병합할 수 있음)

  • 새 라이선스인 SSPL은 적어도 사용 분야 제한 때문에 오픈소스가 아닐 가능성이 큼: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...

    • SSPL은 확실히 오픈소스가 아니며, 6번 조항을 위반함
      https://opensource.org/definition-annotated#6
      오픈소스, 그리고 어떤 면에서는 자유 소프트웨어의 핵심이 바로 이 점임. 카피레프트 라이선스에는 제한이 있지만, 그 제한을 따르면 그 소프트웨어로 원하는 것을 만들 수 있음. SSPL, FSL, BUSL 라이선스는 특정 상업적 방식의 경쟁을 아예 막음
      대부분의 사업 모델이 카피레프트를 따르고 싶어 하지 않는다고 해서 그것이 오픈소스가 아닌 것은 아님. 단지 그 사업 모델에 맞지 않을 뿐임
    • “아마도”가 아니라, 그냥 명백한 비자유 라이선스임
    • 이런 것들을 위한 새 용어가 필요하다고 봄
      SSPL, BSL, FSL 같은 새 라이선스가 점점 인기를 얻고 있고, 그럴 만한 이유도 있음. 20년 전에는 AWS가 FOSS를 전 세계에 재판매하는 상황이 없었으니 조건이 지금과 크게 달랐음
      제한 때문에 “오픈소스”는 아니지만, 그다음으로 가까운 용어인 “소스 공개형”도 현실을 잘 반영하지 못함. 소스 코드는 기술적으로 어딘가에 있을 뿐이라는 뜻에 가깝기 때문임
      ElasticSearch, Sentry 등은 여전히 공개적으로 개발되고, 프로젝트와 무관한 사람도 PR을 보낼 수 있으며, 프로젝트 뒤 회사와 공개적으로 경쟁하려는 게 아니라면 누구나 원하는 일을 할 수 있음

  • 동시에 Microsoft가 Garnet을 공개함: https://github.com/microsoft/garnet
    타이밍이 좋음

    • Garnet 관련 HN 토론에서 누군가는 절대 MS와 엮이지 않겠다고 했음
      그 논리는 MS가 미끼를 던졌다가 필요할 때 라이선스를 바꿀 것이고, 그래서 항상 오픈소스 라이선스를 유지할 Redis가 더 낫다는 것이었음. 대단한 예측이었음
    • Microsoft와 Azure는 이 변경에 완전히 동의하는 듯함: https://azure.microsoft.com/en-us/blog/redis-license-update-...
    • 이게 연구용 제품인지, 운영 환경용인지 궁금함
    • 왜 이렇게 중요한 소프트웨어를 C#이나 Java처럼 전체 런타임과 VM 설치가 필요한 언어로 작성하는지 모르겠음

  • Redis와 Hashicorp의 기술 창업자들이 각자 회사가 FOSS에서 멀어져 큰 폭풍을 맞기 전에 물러난 셈임. 일정이 틀리지 않았다면 그렇다는 얘기임
    그들이 이 일을 미리 알고 반대했는지, 알고 있었지만 평판 타격을 피하고 싶었는지 궁금함. 이 움직임에 동의하든 아니든 평판 손상은 있음. 아니면 그들이 떠났기 때문에 변경을 밀어붙일 수 있었던 걸까
    전적으로 추측이지만 Hashi에서 봤던 일이 Redis에서도 반복되는 것 같아 눈에 띔

    • 그들이 떠나기 전에는 막을 만큼 영향력이 있었던 것일 수도 있음
      Hashi와의 유사성은 나도 놓치지 않았음
    • 더 그럴듯한 건 그냥 프로젝트나 회사를 꽤 오래 운영했고, 새롭고 더 흥미로운 일로 옮기고 싶었기 때문일 수 있음. 또는 그냥 현금화하고 싶었을 수도 있음
답변달기