일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Linux
- 정보처리기사 실기
- CloudWatch
- Spring
- Java
- IntelliJ
- kotlin spring
- 티스토리챌린지
- AWS EKS
- kotlin
- CKA 기출문제
- 정보처리기사 실기 기출문제
- 오블완
- Elasticsearch
- 기록으로 실력을 쌓자
- AI
- MySQL
- Kubernetes
- Pinpoint
- 코틀린 코루틴의 정석
- minikube
- aws
- 공부
- APM
- PETERICA
- CKA
- kotlin querydsl
- kotlin coroutine
- 정보처리기사실기 기출문제
- mysql 튜닝
- Today
- Total
피터의 개발이야기
[Redis] Redis 오픈소스 라이선스 변경 본문
ㅁ 들어가며
Redis의 오픈소스 라이선스가 변경되었다. v7.4 버젼 이후 적용되는 라이선스는 제 3자에게 서비스로 제공하지 못하는 문제점을 가지고 있다. 이러한 오픈소스 정책의 변경의 이유는 기업들이 오픈 소스를 이용하여 SaaS로 만들어 이익을 추구하지만 오픈소스 자체에 도움을 주지 않기 때문이다. 오픈소스 정책 변경을 이해하기 위해 Free Software, Open Source Software, Shared Source Software에 대해 간략히 정리하였다. 큰 맥락은 함께 공유하고 함께 성장하자는 오픈소스의 공동선에 맞추어, 오픈소스를 이용하여 이익을 추구하는 기업들도 기술을 공유하라는 것이다.
Redis 커뮤니티 에디션은 계속 무료로 사용 가능하다. 개발자들은 SaaS와 자체 Redis를 대체할 필요는 없다. 클라우드와 오픈소스의 경쟁적인 구조에서 SSPL과 RSAL과 같은 제한적 라이센스로 변경되었지, 완전 유료 라이센스가 된게 아니다.
update... 24.4.5
[Redis] Redis의 대체로 Redict을 선택해야 하는 이유
ㄴ Redict는 Redis®의 독립적인 저작권 보호 포크 버전이다. 2024.4.3에 Redict 커뮤니티는 Redis® OSS 7.2.4의 카피레프트 포크의 첫 번째 안정 버전인 Redict 7.3.0의 출시하였다. 이 글에서 Redict의 특징과 선택의 이유, Redict와 Redis의 주요 차이점에 대해서 정리하였다.
update... 24.4.9
Redis, 테라폼 등 오픈소스 소프트웨어의 라이선스 변경 논란
ㄴ 최근 레디스, 테라폼 등 오픈소스 소프트웨어가 기존 오픈소스 라이선스를 버리고 상용 라이선스로 전환하는 사건이 발생했다. 이는 개발자 커뮤니티와 사용자들에게 큰 분노를 불러일으켰다. 오픈소스에 관한 사건의 개요와 논란의 핵심을 정리해 보았다.
ㅁ Redis의 오픈소스 라이선스 변경
Redis의 7.4 버전부터는 라이선스 변경에 따라 RSALv2와 SSPL의 듀얼 라이선스 정책으로 이용하실 수 있다. 24.3.21, git의 Change license from BSD-3 to dual RSALv2+SSPLv1 #13157에 Redis이 독점 라이선스로 변경되었다. Redis는 Redis v7.4부터 RSALv2( Redis Source Available License 버전 2 ) 또는 SSPLv1(Server Side Public License 버전 1) 을 사용하여 BSD 3-Clause 라이선스에서 Redis 핵심 소프트웨어에 대한 이중 라이선스 접근 방식으로 전환한다고 발표했다. Redis의 모든 향후 릴리스에 적용된다.
사람들의 반응은 부정적이다. K-JO가 커밋하면서 Live long and prosper 🖖 라는 메시지를 남겼는데, 번역하면 장수하라는 말인데... 오픈소스를 제약하면서 번영을 어떻게 하라는 말인지??? 사람들은 다스베이터의 밈을 남기며, 오픈 소스의 이상을 저버리고 이익 추구하는 움직임에 부정적인 의견을 남기고 있다.
ㅁ 라이선스 변경에 따른 제한 사항
Redis의 라이센스는 2022년 11월 15일에 Redis 모듈(RedisJSON, Redis Stack 등 포함)을 이중 라이선스로 출시하였다. 이제 무료로 제공되는 모든 소프트웨어에 대해 이중 라이선스로 전환하고 있다. 이 이중 라이센스 접근 방식을 통해 사용자는 RSALv2 또는 SSPLv1 라이센스 중에서 선택할 수 있다. RSALv2나 SSPL은 모두 OSI 승인 라이선스가 아니며 각각 제한 사항이 있다.
RSALv2는 "소프트웨어의 사용, 복사, 배포, 제공 및 파생 저작물 준비" 권한을 허용하지만 두 가지 제한 사항이 있다.
- 소프트웨어를 상용화하거나 타인에게 관리형 서비스로 제공하는 행위
- 라이선스, 저작권 또는 기타 고지 사항을 제거하거나 모호하게 표기
ㅇ Redis를 이용해 SaaS 서비스 판매불가
RSALv2는 SaaS 서비스 제공이 불가능하며(RSALv2 Limitations), SSPL(Server Side Public License)은 Redis 혹은 그 기능을 SaaS로 제공 시 Redis 뿐만 아니라 부수적으로 필요한 관리 소프트웨어, 사용자 인터페이스, API, 자동화 소프트웨어, 모니터링 소프트웨어, 백업 및 저장 소프트웨어 등 SaaS 사용자가 실행하는 모든 소프트웨어의 코드를 공개해야 한다.(SSPL 제13조)
SSPLv1에서는 제품을 서비스로 제공하는 경우 SSPL에 따라 관리 계층의 수정 사항과 소스 코드를 공개적으로 릴리스해야 한다.
ㅇ SSPL 제 13조 영어원문
13. Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
여기서 “Service Source Code”는 프로그램뿐만 아니라 이를 관리하는데 필요한 모든 소프트웨어를 말한다.
ㅇ Redis 자체 패키징 판매 & Redis 소스 수정 후 판매
RSALv2는 재배포가 불가능하며(RSALv2 Limitations), SSPL은 Redis와 연결되는 모든 소프트웨어의 코드를 판매한 대상에게 제공해야 한다. (SSPL 제5, 6조)
ㅁ 오픈소스 라이선스 흐름의 이유
오픈소스는 Free Software로 시작하여 Open Source Software, Shared Source Software의 흐름으로 변하고 있다.
기업들이 SaaS로 전환하고 클라우드 서비스들이 오픈소스를 사용하기만 하고 투자는 하지 않고 있다. 아마존 웹 서비스와 같은 거대 클라우드 업체가 몽고DB, 일래스틱서치(Elasticsearch)와 같은 오픈소스 프로젝트를 주도하는 업체를 힘으로 짓뭉갤 수 있는 상황에서, 이들 업체는 대형 클라우드 업체의 공격을 피하는 동시에 기업 고객을 상대로 수익을 창출하기 위한 활로를 모색해왔다. AWS나 다른 클라우드 업체가 이 코드를 가져가기만 하고 그에 상응하는 가치를 환원하지 않는 것은 잘못된 일이다. 그래서 SSPL이 등장하게 되었다. SSPL은 ”Redis를 서비스로 제공하려면 그 서비스에 들어가는 코드를 기여해야 한다”는 조건을 내건다. 지나친 조건일 수도 있지만 오픈소스의 철학을 위해서 강제적인 공유의미를 추가하였다.
Free Software는 1980년대 리처드 스톨만의 자유 소프트웨어 운동으로 만들어진 것으로, GNU 프로젝트가 여기에 해당한다.
Open Source Software는 2000년경 등장했다. 오픈소스 소프트웨어는 Free 소프트웨어와 달리 소스코드 공개 등의 의무를 완화해서 자유롭게 사용하고 저작권 고지만 하면 되는 MIT 등의 라이선스를 채택했다. 이로 인해 오픈소스가 다양한 회사에서 채택됐고, 오픈소스 비즈니스로 빠르게 성장할 수 있었다. 오픈소스 소프트웨어는 사용자에게 많은 자유를 주었지만, 오픈소스 프로젝트를 만들고 운영하는 오픈소스 커뮤니티에는 많은 이점을 제공하지 않았다.
Shared Source Software는 이러한 부분을 개선하기 위해 2020년경부터 등장하였다. Shared Source Software는 오픈소스 프로젝트의 지적재산권은 보호하면서, 사용자가 소스코드를 자유롭게 사용할 수 있도록 제공한다. 여기에, 지적 재산권 보호 방식으로 상용 서비스를 제한하는 조항을 추가하였다. 이러한 차이로 인해 Shared Source Software는 상용 서비스 금지와 같은 차별 조항으로 인해 오픈소스 라이선스로는 인정되지 않는다.
참조: 오픈소스 라이선스 변화의 흐름
ㅁ 마무리
Redis가 BSD에서 듀얼 라이선스로 변경한 이유는 크게 클라우드와 오픈소스의 경쟁적 구도에서 시작되었다. SSPL과 RSAL과 같은 사용 제한 라이센스들은 AWS와 같은 거대 클라우드 기업 독점적 구조에서 오픈소스 생태계를 지키려는 노력으로 볼 수 있다. Redis의 라이선스가 당장 유료화로 전환하지는 않는다. 그래서 사용중인 SaaS를 교체하거나, 내부에서 사용하는 Redis를 당장 교체할 필요는 없다.
Redis는 벤처 투자를 받은 회사이다. 회사의 입장에서 오픈소스를 벗어나 더 많은 수익을 창출하려는 노력은 당연하다. MongoDB의 사례를 보면, SSPL로 이동한 후 많은 기업들이 서비스 사용에 대해 지불하는 것을 선호하고 있다. Free Software, Open Source의 중요한 덕목은 좋은 소프트웨어를 공유하여 다 함께 성장하자는 공동선의 정신에 있다. Big Kind. 일부 기업들은 공동의 선을 이용하여 이익만 낸다면 공동선의 철학은 불공정하다. 그렇기 때문에 공동선을 보장하는 선에서의 라이선스 변경은 오픈소스를 성장하고 더 좋은 소스를 공유하는 하나의 수단임은 분명해 보인다.
Redis v7.4부터는 저작권에 문제가 될 소지가 있지만, 이전의 Redis 버젼의 사용에는 큰 문제가 없어보인다. 다만 업그레이드 시 다른 대체자가 필요할 것이다. 나는 자유가 더 좋다.
ㅁ 함께 보면 좋은 사이트
ㅇ 칼럼 | '시작은 오픈소스, 수익 내면 상용'··· 지긋지긋한 잔꾀
'DevOps > Redis&Redict' 카테고리의 다른 글
[Redict] Redict을 설치하는 3가지 방법 (0) | 2024.04.05 |
---|---|
[Redis] Redis의 대체로 Redict을 선택해야 하는 이유 (0) | 2024.04.02 |
[Redis] 쿠버네티스 환경에서 Redis 모니터링의 필요성 (1) | 2024.02.17 |
[Redis] Docker redis 비밀번호 설정 (0) | 2023.09.15 |
[Redis] Docker Redis 설치하기 (0) | 2023.08.03 |