라이선스 하나 바뀌었을 뿐(?)인데...

개발문화 오픈소스 카피라이트 카피레프트

지난 3월, 레디스(Redis)가 IT 커뮤니티를 뜨겁게 달궜습니다!
레디스는 빠른 성능을 비롯한 여러 장점으로 널리 알려진 데이터베이스 시스템이에요. 
2023년 개발자 커뮤니티 스택오버플로(Stack Overflow) 설문에 따르면 전문 개발자의 23%가 레디스를 쓴다고 응답했을 정도죠.

이런 레디스가 뜨거운 감자로 떠오른 건 바로 라이선스를 변경한다는 발표 때문인데요. 한 기술의 정책 변화가 거대한 IT 생태계의 이목을 이렇게나 집중시킨 이유는 뭘까요?

돌아온 67번째 인프메이션에서는 이번 발표로 오픈 소스 진영에서 벌어진 여러 논쟁과 복잡한 문제들에 대해 살펴봅니다.

들어가기 전에 : 레디스(Redis)? ✅

레디스는 MySQL, PostgreSQL 등 관계형 데이터베이스 시스템(RDBMS)과는 구분되는 NoSQL 방식의 데이터 저장소예요. 각각의 데이터를 이름표 붙이듯 특정한 키(Key)로 구분하고, 키에 맞는 값(Value)을 저장하는 구조가 특징이죠.

문자로 구성된(String: 문자열) 데이터 외에도 다양한 형태의 데이터를 지원하며, 모든 데이터를 메모리에 저장하고 조회하는 인-메모리(In-Memory) 방식의 고성능 데이터베이스예요. 때문에 검색 시간 지연이 적고 간단한 알고리즘으로 빠르게 데이터에 접근할 수 있는 장점이 있어요. 많은 DBMS에서 디스크에 데이터를 저장하고, 그 데이터를 다시 정렬해서 읽어오는 과정을 거치는데 반해 Redis는 메모리 자체에 데이터를 저장하므로 별도 디스크에 접근할 필요가 없기 때문이죠.

이러한 장점 때문에 레디스는 특히 캐싱, 세션 관리 작업 등에 적합하다고 알려져 있습니다. 2009년 탄생한 이후 수많은 온라인 기반 실시간 애플리케이션이 이용해 온 프로젝트였던 만큼, 이번 라이선스 변경에 개발자들의 이목이 쏠리고 있죠.

파격 선언! 새로운 라이선스 채택

_{지난 2024년 3월 20일 레디스에서 게시한 글.}

2024년 3월 20일, 레디스가 이번에 배포하는 7.4 버전부터 RSAL(Redis Source Available Lisence)과 SSPL(Server Side Public License)라는 듀얼 라이선스를 채택하였다고 발표했어요. CEO 로원 트롤로프(Rowan Trollope)의 글에 따르면,

• 그동안 쓰던 BSD 라이선스를 향후 버전에 더이상 적용하지 않으며 
• 커뮤니티 에디션을 통해 개발자, 고객 및 파트너가 계속해서 레디스의 소스 코드를 무료로 이용할 수 있고 
• 동시에 레디스가 책임지는 모든 레디스 클라이언트 라이브러리는 오픈 소스 라이선스를 유지한다고 합니다.

그런데 레디스의 이번 발표는 큰 파문을 불러 일으켰어요. 언뜻 크게 변하는 게 없는 듯 보이지만, 그전까지 채택하던 BSD 라이선스와 SSPL 라이선스가 다른 지점이 분명하기 때문입니다.

BSD 라이선스를 떠나는 이유

_{오픈 소스 기술 검토는 서비스 개발 및 상용화에 있어 중요한 부분이죠. (함께 읽으면 좋은 글 : 카카오 기술 블로그 “오픈소스 라이선스 변화의 흐름”)}

먼저 오픈 소스(Open Source)라고 하면 사용자가 프로그램의 소스 코드에 제약 없이 접근, 수정, 배포할 수 있도록 허가하는 걸 의미합니다. 즉 오픈 소스 소프트웨어는 저작권(Copyright)이 없는 소프트웨어가 아니라 소스 코드에 누구나 접근할 수 있게 하고, 그에 따른 2차적 저작물을 만들거나 수정 및 재배포를 할 수 있게 함으로써 소프트웨어를 개발하거나 배포하는 사람들에게 이용할 자유를 열어둔 소프트웨어를 말해요.

이 오픈 소스 라이선스에는 여러 종류가 있는데요. 레디스가 이전까지 채택하던 BSD(Berkeley Software Distribution License) 라이선스 역시 널리 알려진 오픈 소스 라이선스 중 하나예요. 최소한의 저작권자 표기 규정만 준수하면 개인적으로도, 상업적으로도 개작 및 배포 제한을 받지 않기 때문입니다.

다만 BSD 라이선스는 오픈 소스 라이선스지만 카피레프트^* 라이선스는 아니에요. BSD 라이선스는 소스 코드 공개를 의무로 두지 않고, 개작한 부분에 BSD를 적용할 필요가 없다(Permissive Lisence)는 특징이 있어요. BSD 라이선스를 따르는 소프트웨어를 수정하거나 확장하더라도 변경한 사항을 코드로 공개할 의무가 없죠. 더욱이 BSD 라이선스 소프트웨어를 이용해 상용 소프트웨어를 개발할 때도 소스 코드를 숨길 수 있습니다. 민감한 비즈니스 모델이나 기술을 보호하고자 하는 기업이라면 특히 유리하게 쓰이는 조항이에요.

레디스가 그동안 유지해오던 BSD 라이선스를 바꾼 이유도 여기에 있어요. 이번에 레디스가 RSAL 2와 함께 채택한 SSPL(Server Side Public License)은 2018년 NoSQL 데이터베이스로 잘 알려진 MongoDB(몽고DB)에서 처음 도입한 라이선스입니다. 상용 클라우드 서비스 제공업체가 호스팅^*한 MongoDB 서비스를 이용할 때 해당 서비스의 소스 코드를 공개하도록 요구하는데요. MongoDB가 AWS(아마존 웹 서비스)를 겨냥해 클라우드 제공 업체가 오픈 소스 소프트웨어를 개발하지 않았음에도 오픈 소스 소프트웨어를 서비스해 상업적인 이윤을 얻으면서 소프트웨어를 개발한 커뮤니티에는 기여하지 않는다는 점을 지적하면서 등장했어요.

MongoDB가 최초로 적용한 SSPL 라이선스에 따르면, 클라우드 제공 업체는 MongoDB와 연동되어 실행되는 관리 소프트웨어를 비롯한 모든 유관 소스 코드를 공개해야 해요. 때문에 실질적으로 SSPL을 적용한 최신 MongoDB를 AWS가 쓸 수 없게 견제한 셈이죠. SSPL은 라이선스가 다른 프로그램에까지 영향을 미친다며 비판을 받았고, 오픈 소스 재단(Open Source Initiative, OSI)은 SSPL을 오픈 소스 라이선스로 인정하지 않고 있어요.

_{컴퓨터로 영상을 인식하고 처리하는 ‘컴퓨터 비전’ 기술을 구현하는 대표적인 라이브러리, OpenCV 역시 4.4.0 버전까지 BSD 라이선스로 배포되었어요. (현재는 아파치 라이선스를 따름)}

레디스 역시 발표를 통해 이번 결정이 비슷한 맥락에서 이루어졌다는 점을 인정하고 있습니다. 레디스는 여전히 오픈 소스를 지지하지만, 이번 라이선스 전환으로 더이상 오픈 소스 재단의 정의에 따른 오픈 소스가 아니라는 점을 공개적으로 인정했어요. 한편으로는 커뮤니티 주도 모델을 유지하며 BSD 라이선스를 유지하려고 노력했음에도 레디스를 호스팅하는 다양한 환경에 맞춰 동시에 제공하는 데 기술적인 제약이 있다고 느꼈으며, 브랜드 및 IP를 보호할 목적으로 라이선스를 전환하게 되었다고 밝히고 있어요.

여기에 레디스에서 SSPL과 함께 채택한 RSAL은 소프트웨어 사용, 복사, 배포, 제공 및 파생에 대한 권리를 인정하지만, 사용자가 소프트웨어를 상업화하거나 다른 사람에게 관리형 서비스로 제공할 수 없다는 내용을 명시했어요. 즉 기존의 클라우드 서비스 제공 업체들이 더 이상 앞으로 출시되는 최신 레디스 소스 코드를 무료로 이용하지 못한다는 뜻이죠.

그런데, 뭐가 문젤까?

_{2021년, 일래스틱은 일래스틱서치 및 키바나의 라이선스를 아파치 라이선스에서 SSPL 또는 Elastic License의 듀얼 라이선스로 전환한다고 공지했어요.}

레디스는 자신들이 아닌 (아마존이나 마이크로소프트 같은) 대형 클라우드 서비스 제공 업체들이 레디스를 이용해 더 큰 이윤을 얻는 상황을 고려해 라이선스를 전환했다고 밝히고 있는데요. 다만 이번 결정으로 개발자 커뮤니티에 퍼진 충격은 적지 않아 보여요.

레디스는 소스 코드를 허용 범위 안에서 사용할 수 있으며 기존의 클라우드 서비스 제공 업체에 해당하는 제한이라고 설명하지만 많은 개발자들이 이러한 라이선스 전환이 야기할 수 있는 법적인 문제나 비용, 기술적 제한 발생 가능성을 우려하고 있어요. 오픈 소스 생태계를 중심으로 많은 비판이 가해지는 이유입니다. 클라우드 제공 업체를 선택할 수 있는 권한이 축소되거나 호스팅 가격이 상승할 수도 있겠죠. 레디스가 오픈 소스 프로젝트였기 때문에 지금처럼 널리 쓰이고 성공할 수 있었다는 의견도 많고요.

반면 ‘재주는 곰이 넘고 돈은 왕서방이 버는’, 대형 기업이 중간에서 큰 이윤을 챙기는 상황을 고려해야 한다는 시각도 존재합니다. AWS를 저지하기 위해 SSPL을 만든 MongoDB처럼 논쟁적인 유사 사례가 지속적으로 발생하고 있고요.

일명 ELK 스택^*으로 잘 알려진 일래스틱(Elastic) 역시 AWS에 대항하기 위해 오픈 소스였던 일래스틱서치(ElasticSearch)를 SSPL 라이선스로 전환하자 AWS에서 일래스틱서치의 오픈 소스 버전을 포크^*하겠다며 벌어진 분쟁이 대표적이죠. 불과 1년 전인 2023년에는 코드형 인프라(Infrastructure as Code: IoC) 관리 툴 테라폼(Terraform)의 라이선스가 바뀌면서 포크 버전인 오픈토푸(OpenTofu)가 등장하기도 했어요. 

물론 레디스의 경우는 좀 더 복잡한 면이 있는데요. 2009년 처음 레디스를 개발하고 배포하는 데 기여한 사람들이 라이선스 전환을 결정하지 않았다는 비판의 목소리도 있기 때문입니다. 현재 레디스는 2020년에 구 Garantia 사에서 레디스의 지적재산권 및 상표권을 인수했고, 이번 결정 역시 프로젝트를 재라이선스할 수 있는 법적 권리를 가지게 되면서 진행되었기 때문에 오픈 소스 커뮤니티를 통해 이득을 얻으려는 행위로 보인다는 입장이죠.

_{‘레디스가 레디스를 만들지 않았다’는 비판의 목소리도 들려요. (함께 읽으면 좋은 글 : Momento 기술 블로그 "RIP Redis: How Garantia Data pulled off the biggest heist in open source history")}

수많은 논쟁 사이 레디스를 대체할 새로운 기술을 찾는 움직임이 시작되고, 오픈 소스 버전의 레디스 역시 프로젝트 포크를 면치(?) 못했습니다. 지난 2019년에 레디스를 포크하며 등장한 KeyDB 외에도 여러 포크 프로젝트가 등장했거든요. 오픈 소스 저장소 소스헛(SourceHut)의 창립자 드루 드볼트(Drew DeVault)는 레디스를 포크한 레딕트(Redict)를, 오픈 소스 진영에서 큰 영향력을 미치는 리눅스 재단(Linux Foundation)에서는 발키(Valkey)를 공개했죠. 같은 시기 마이크로소프트는 레디스 호환 오픈 소스 프로젝트인 가넷(Garnet)을 출시했고요.

공유지의 비극? 자유에 대한 위협? 
생태계와 보상 사이의 줄다리기

_{지난 3월 29일 발견된 XZ Utils 백도어 사건은, 마이크로소프트에서 일하는 한 개발자(Andres Freund)가 평소보다 접속이 느려진 걸 보고 조사하면서 드러나게 되었어요. 많이 쓰이는 오픈 소스 프로젝트였던 만큼 위험한 상황이었지만, 아이러니하게도 그래서 빠르게 백도어를 발견할 수 있었다고 볼 수도 있죠.}

이번 레디스의 결정처럼, 이따금 벌어지는 오픈 소스 관련 사건은 오늘날 오픈 소스 생태계를 둘러싸고 있는 복잡한 문제를 비춥니다. 오픈 소스 커뮤니티 안에서의 상업적 사용, 그리고 기여자 권리 사이에서 균형을 잡고 가장 좋은 선택을 찾기가 무척 어렵기 때문이죠.

‘누구나 참여할 수 있다’는 오픈 소스의 정신에서 알 수 있듯, 기업이나 재단 규모가 아니라 개인의 기여로 움직이는 오픈 소스도 상당히 많습니다. 오늘날 널리 쓰이는 오픈 소스 프로젝트의 적지 않은 수가 개인이 만들기 시작하다 확장된 경우이기도 하고요.

불과 며칠 전인 2024년 3월 말, 리눅스에서 활발히 쓰이는 오픈 소스 데이터 압축 라이브러리 XZ Utils 버전 5.6.0 및 5.61에서 백도어(시스템에 불법적으로 접근할 의도로 인증 절차를 우회하거나 무효화하는 악성코드)가 발견되는 사태가 벌어졌는데요. 진 탄(Jin Tan)이라는 개발자가 XZ Utils 프로젝트에 2년 이상 커밋을 하는 등 유지보수에 기여하면서 프로젝트 운영진의 신뢰를 쌓은 다음 백도어를 심어 둔 것이죠. 만약 더 늦게 발견했더라면 수많은 시스템이 취약점에 그대로 노출되며 엄청난 피해를 가져왔을지도 모르는 상황이었습니다.

XZ Utils 사건에서 볼 수 있듯 오픈 소스 커뮤니티는 사람들의 선의나 대의에서 나오는 자발적인 기여에 기대 움직이기 때문에, 개발한 사람들이 충분한 보상을 취하지 못하고 비용 등의 문제로 운영을 유지할 수 없어 발생하는 어려움이 늘 존재해요. 프로젝트에 어떤 기술 스택을 오픈 소스라는 이유로 채택하기도 하지만, 반대로 오픈 소스여서 채택하지 않는다고 한다면 취약한 지원 및 유지 보수, 보안 문제 등을 우선으로 고려했기 때문이겠죠.

이런 상황에서 공공의 이익을 가장 균형있게 실현할 수 있는 방법은 무엇일까요? ‘바퀴를 다시 발명하지 말라’는 업계의 유명한 격언처럼, 오늘날 IT 생태계는 수많은 개발자들이 만든 프로젝트를 뿌리로 삼아 계속해서 새로운 서비스를 만들어가고 있어요. 한편으로는 오픈 소스라는 용어가 처음 등장한 지도 25년 넘게 지난 만큼, 달라진 상황에 맞는 논의가 필요하다는 목소리도 나오고 있죠. 기여에 걸맞은 보상이 필요한 현실, 그리고 기술 발전으로 가꾸는 생태계 사이에서 건강한 답을 낼 수 있도록 커뮤니티 전반의 고민이 모여야 하는 시점이 아닐까 싶습니다. 물론 쉽지 않은 문제지만요!

레디스의 이번 결정을 둘러싼 이야기, 여러분은 어떻게 생각하시나요? 
앞으로의 오픈 소스는 어떤 미래를 맞게 될까요? 
여러분의 의견을 댓글로 함께 들려주세요. 😊