개요편집이의 제기
서버 사이드 퍼블릭 라이선스(Server Side Public License, SSPL)는 2018년 10월 16일 MongoDB Inc.가 발표한 소프트웨어 라이선스다[1]. GNU 아페로 일반 공중 사용 허가서 버전 3(AGPL v3)을 기반으로 하되, 네트워크를 통해 소프트웨어 기능을 제3자에게 서비스로 제공하는 경우 적용 범위를 대폭 확장한 '강한 카피레프트(strong copyleft)' 라이선스로 분류된다[2][3]. 오픈 소스 이니셔티브(OSI), 레드햇, 데비안 등 주요 오픈소스 커뮤니티 기구로부터 자유 소프트웨어 또는 오픈 소스 라이선스로 인정받지 못하고 있으며, '무늬만 오픈(fauxpen) 소스' 라이선스로 지칭되기도 한다[2][3].
역사·유래편집이의 제기
MongoDB의 라이선스 변경 배경
MongoDB Inc.는 자사 데이터베이스 제품인 MongoDB가 아마존 웹 서비스(AWS) 등 클라우드 서비스 제공업체에 의해 관리형 서비스로 제공되면서, 소스 코드 기여에 대한 보상 없이 상업적 이득을 취해간다는 문제 의식을 가졌다[2][3]. 기존 AGPL v3의 제13조가 네트워크를 통한 사용 시 소스 코드 제공을 요구하지만, 그 범위가 '라이선스된 저작물 자체'로 한정되어 있어 서비스 운영에 필요한 주변 소프트웨어 스택 전체에는 미치지 못한다고 판단했다[2][3]. 이에 MongoDB는 2018년 10월 16일 SSPL을 공개하고, 자사 제품의 라이선스를 AGPL v3에서 SSPL로 변경했다[1][2][3].
OSI 인증 시도와 철회
MongoDB는 2018년 SSPL을 오픈 소스 이니셔티브(OSI)에 제출하여 오픈 소스 라이선스 인증을 받으려 했으나[2][3], 2019년 제출을 자진 철회했다[2][3]. 브루스 페렌스(Bruce Perens)는 SSPL이 오픈 소스의 정의(Open Source Definition) 6조(분야에 따른 차별 금지)와 9조(다른 소프트웨어에 대한 라이선스 제한 금지)를 위반한다고 지적했다[3]. 2021년 1월, 일래스틱(Elastic NV)의 라이선스 변경에 즈음하여 OSI는 공식 성명을 통해 SSPL이 오픈 소스의 정의를 준수하지 않으며 특정 노력 분야를 차별한다고 비판하고, 이를 '무늬만 오픈(fauxpen) 소스' 라이선스로 규정했다[2][3].
작동 방식과 유형편집이의 제기
AGPL v3와의 구조적 관계
SSPL의 장(chapter) 구조는 GPL 전문(preamble)과 적용 지침(application instructions)이 라이선스 텍스트에서 제거된 점을 제외하면 AGPL v3와 동일하다[2][3]. 핵심적인 차이는 제13조에 있다. AGPL v3 제13조는 '네트워크를 통해 전달되는 경우 라이선스된 저작물의 소스 코드를 제공해야 한다'고 규정하는 반면, SSPL 제13조는 '서비스로 제공하는 경우 서비스 전체의 소스 코드를 SSPL 하에 공개해야 한다'고 규정한다[2][3].
수정된 제13조: '서비스 소스 코드' 개념
SSPL 제13조는 SSPL 라이선스 소프트웨어의 기능을 수정 여부와 관계없이 제3자에게 '서비스'로 제공하는 자에게 다음을 요구한다[2][3].
* 관리 소프트웨어(management software)
* 사용자 인터페이스(user interfaces)
* 애플리케이션 프로그램 인터페이스(API)
* 자동화 소프트웨어(automation software)
* 모니터링 소프트웨어(monitoring software)
* 백업 소프트웨어(backup software)
* 저장 소프트웨어(storage software)
* 호스팅 소프트웨어(hosting software)
* 그 밖에 사용자가 '서비스 소스 코드(Service Source Code)'를 사용하여 서비스 인스턴스를 직접 실행하는 데 필요한 모든 것
이러한 구성 요소 전체의 소스 코드를 SSPL 조건하에 공개해야 한다. MongoDB Inc.는 이 조항이 AGPL 제13조의 불분명한 범위를 명확히 하고, 라이선스 프로그램을 제3자 서비스로 제공하기 위한 조건을 명시적으로 규정한다고 밝혔다[2][3].
라이선스 버전
자료에 따르면 SSPLv1이 존재하며, 레디스(Redis) 사례에서 SSPLv1이 명시적으로 언급된다[2][3].
사례편집이의 제기
MongoDB (2018년 10월)
최초 적용 사례다. MongoDB 데이터베이스의 라이선스가 SSPL로 변경되었다[2][3]. 이에 따라 데비안(Debian), 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux), 페도라(Fedora) 등 주요 리눅스 배포판은 SSPL에 대한 우려를 이유로 공식 저장소에서 MongoDB를 제거했다[2][3]. 아마존 웹 서비스(AWS)는 SSPL 적용을 회피하기 위해 MongoDB API와 부분적으로 호환되지만 사유 소프트웨어인 '도큐먼트DB(DocumentDB)' 서비스를 출시했다[2][3].
Graylog (2020년 11월)
로그 관리 플랫폼 Graylog가 소스 공개(source-available) 릴리스인 4.0 버전의 라이선스를 SSPL로 변경한다고 발표했다[2][3].
일래스틱서치 및 키바나 (2021년 1월)
Elastic NV는 아파치 라이선스 2.0 하에 배포되던 일래스틱서치(Elasticsearch)와 키바나(Kibana)의 향후 버전을 SSPL과 자체 '일래스틱 라이선스(Elastic License)' 하의 다중 라이선스(dual-license)로 변경한다고 발표했다[2][3]. 이 결정은 생태계에 해를 끼칠 것이라는 비판을 받았으며, 아마존 웹 서비스(AWS)는 아파치 라이선스 2.0 버전 기반의 지속적인 개발을 위해 프로젝트를 포크(fork)할 계획을 밝혔다[2][3]. AWS 주도로 Logz.io, CrateDB, 레드햇, Aiven 등이 참여한 오픈 소스 포크 프로젝트를 통해 '오픈서치(OpenSearch)' 소프트웨어가 탄생했다[2][3].
레디스 (2024년 3월 ~ 2025년 5월)
레디스(Redis)는 2024년 3월 20일, 기존 3조항 BSD 허가서(BSD 3-Clause License)에서 벗어나 SSPLv1과 자체 '레디스 소스 가용 라이선스 v2(RSALv2)' 중 하나를 선택하는 다중 라이선스 체제로 전환했다[2][3]. 이 변경은 많은 사용자의 반발을 샀으며, 리눅스 재단(The Linux Foundation)은 레디스의 마지막 BSD 라이선스 버전을 기반으로 '발키(Valkey)'라는 포크 프로젝트를 출범시켰다[2][3]. 2025년 5월 1일, 레디스는 레디스 8을 오픈 소스인 AGPL v3 라이선스 하에 출시한다고 발표했으나, 일부 개발자는 이 변경이 소프트웨어를 모두에게 자유롭게 제공하기에는 충분하지 않다고 주장했다[2][3].
규제·논란·평가편집이의 제기
오픈 소스 정의 위반 논란
핵심 쟁점은 SSPL 제13조가 요구하는 '서비스 소스 코드'의 범위가 라이선스된 프로그램 자체를 넘어, 서비스 운영에 사용되는 관리 도구, 모니터링, 백업, 호스팅 인프라 등 제3자 소프트웨어 및 사유 소프트웨어까지 포괄한다는 점이다[2][3]. OSI, 레드햇, 데비안 등은 이 조항이 다음과 같은 이유로 오픈 소스의 정의를 위반한다고 주장한다[2][3].
* 제6조 위반 (분야에 따른 차별 금지): 클라우드 서비스 제공업체 등 특정 비즈니스 모델(서비스형 소프트웨어, SaaS)을 영위하는 사용자 집단에 대해 불리한 조건을 부과하여 차별한다.
* 제9조 위반 (다른 소프트웨어에 대한 라이선스 제한 금지): SSPL 라이선스 프로그램과 단순히 함께 사용되거나 상호작용하는 별개의 프로그램(관리 소프트웨어, 호스팅 스택 등)까지 SSPL 하에 공개하도록 강제함으로써, 별개 프로그램의 라이선스 선택권을 제한한다.
'바이러스성' 확산 우려 및 실질적 효과
비판론자들은 SSPL의 조항이 실질적으로 서비스 제공자가 자신의 전체 기술 스택을 오픈 소스화하지 않는 한 SSPL 소프트웨어를 서비스에 사용할 수 없게 만듦으로써, 상업적 서비스 환경에서의 사용을 사실상 차단한다고 본다[2][3]. 이는 오픈 소스 생태계의 협력적 개발 모델을 저해하고, 기업들이 오픈 소스 대신 사유 소프트웨어 대안(아마존 도큐먼트DB, 오픈서치, 발키 등)을 개발하거나 채택하도록 유도하는 결과를 낳았다[2][3].
'소스 공개(Source Available)' 라이선스로의 재분류
OSI 인증 실패와 주요 배포판의 배제 조치 이후, SSPL은 오픈 소스 라이선스가 아닌 '소스 공개(Source Available)' 또는 '공정 소스(Fair Source)' 계열 라이선스로 분류되는 것이 일반적이다[2][3]. 소스 코드는 공개되나, 사용·수정·재배포의 자유에 중대한 제약이 따른다는 점에서 자유 소프트웨어 재단(FSF)과 OSI의 정의상 '자유/오픈 소스' 요건을 충족하지 못한다는 평가다[2][3].
이 문서는 GGWiki AI가 공개 자료(아래 출처)를 조사해 새로 쓴 초안입니다. 틀린 내용은 편집하거나 이의 제기로 알려 주세요.
