오픈소스 철학의 실체: 대기업 무임승차를 보호하는 신념 체계

SSPL이 등장할 때마다 커뮤니티는 분노한다. "오픈소스 철학을 배신했다", "OSI 인증도 못 받은 라이선스", "진짜 오픈소스가 아니다". 그런데 이 분노가 실제로 보호하는 것은 무엇인가.

SSPL — Server Side Public License

MongoDB가 2018년 제정한 라이선스다.¹ 핵심 조항은 단 하나: 소프트웨어를 서비스로 제공하려면 해당 서비스를 구성하는 전체 스택(인프라, 관리 도구, 모니터링 시스템 포함)을 오픈소스로 공개해야 한다. AWS처럼 타인의 오픈소스를 그대로 클라우드 서비스로 팔면서 아무것도 돌려주지 않는 구조를 막으려는 의도로 설계되었다. OSI(Open Source Initiative)는 "지나치게 제한적"이라며 오픈소스로 인정하지 않는다.²

Redis 사태: 누가 훔쳤나

Redis는 수년간 BSD 라이선스로 공개되어 있었다. 전 세계 개발자들이 코드를 기여했고, 버그를 고쳤고, 문서를 작성했다. 그리고 AWS는 이것을 그대로 가져다 ElastiCache라는 이름으로 관리형 서비스로 팔았다.

AWS는 Redis에 공식 maintainer(Madelyn Olson)를 두고 TLS 지원, 페일오버 기능 등을 기여했다.³ 기여가 전혀 없던 건 아니다. 그런데 문제는 기여 대비 수익의 불균형이다. SSPL 전환 이전 기준으로 외부 비직원 기여자들이 커밋의 54%를 담당했다. 그럼에도 Redis Ltd에 돌아가는 수익은 없었다. Redis 트래픽의 상당 부분을 AWS가 흡수했고, 정작 Redis를 만든 개발자들은 서버 비용과 유지보수 비용으로 허덕였다.

오픈소스는 그때 무법지대의 지식 보따리였다. 누구나 가져갈 수 있고, 가져가도 아무런 의무가 없었다. AWS는 그 보따리를 통째로 들고 자신의 가게에서 팔았다. 기존 개발팀과 개발자에게는 아무런 가치도 돌아오지 않았다.

Redis Ltd(구 Redis Labs)가 라이선스를 변경한 것은 이 맥락이다.⁴ 변경된 라이선스는 RSALv2와 SSPLv1의 듀얼 라이선스다. SSPL의 핵심 조항은 단순하다: "클라우드 서비스로 제공하려면 전체 스택을 오픈소스로 공개하라." AWS는 이를 받아들이는 대신 2024년 3월 28일, AWS·Google·Oracle·Ericsson·Snap이 Linux Foundation 산하에 Valkey를 공동 출범시켰다.⁵ 유유히 빠져나간 것이다.

법의 허점, 설계된 약탈

오픈소스 라이선스는 클라우드 시대를 상정하지 않았다.

GPL이 만들어졌을 때의 "상업적 이용"은 소프트웨어를 수정하고 배포하는 행위였다. "배포 시 소스 공개"라는 조항은 이 시나리오를 전제한다. 그런데 AWS가 한 일은 소프트웨어를 배포한 것이 아니다. 서버에서 실행하고 API로 팔았다. 배포가 없으니 라이선스 조항이 발동하지 않는다. 완전히 합법적인 약탈이다.

Note

이 허점을 업계에서는 ASP 허점(ASP Loophole) 또는 SaaS 허점이라고 부른다. GPL, LGPL, BSD, MIT 모두 "배포(distribution)"를 트리거로 의무가 발동한다. 그런데 서버에서 소프트웨어를 실행하고 네트워크로 결과만 돌려주는 방식은 법적으로 배포가 아니다. 사용자에게 바이너리를 넘기지 않으므로 GPL 조항이 아예 발동하지 않는다. 2000년대 초 등장한 ASP(Application Service Provider) 모델에서 처음 문제가 됐고, 클라우드 시대에 규모가 폭발했다.

AGPL(GNU Affero GPL)이 이 허점을 막기 위해 나왔다. "네트워크로 서비스해도 소스를 공개하라"는 조항을 추가한 것이다. SSPL은 그 연장선으로, AGPL보다 요구 범위를 서비스 전체 스택으로 확장했다. 기술적 진화에 대응한 라이선스의 진화다.

"오픈소스 순수주의자"의 실체

SSPL이 발표될 때마다 Hacker News와 Reddit은 끓어오른다. "오픈소스 원칙 위반", "OSI가 인증 안 했다", "커뮤니티를 배신했다". 나 역시 Redis 라이선스 변경 소식을 맥락 없는 자극적인 타이틀로 처음 접했다. 왜 바꿨는지는 없었다. '라이선스 변경'이라는 결과만 있었고, AWS가 수년간 무엇을 가져갔는지는 없었다. 미디어는 그 논란을 소재로 수익을 창출했을 뿐, 구조를 설명하거나 반론을 제시하지 않았다. 방관자였다.

OSI(Open Source Initiative)의 재정 구조를 보면 더 명확해진다.⁶ OSI의 Platinum 스폰서에는 Google, Microsoft가 포함되어 있다. SSPL을 "오픈소스 아님"으로 거부한 기관의 운영 자금을 바로 SSPL로 제한받는 기업들이 대고 있는 것이다.

Note

OSI 인증은 법적 강제력이 없다. 누구든 어떤 라이선스도 만들 수 있다. OSI가 "이건 오픈소스가 아니다"라고 선언해도 해당 라이선스의 사용을 막을 수 없다. 그러나 OSI 인증은 사실상 업계 표준 마크로 기능한다. 기업 조달 정책, 공개 소프트웨어 목록, 개발자 커뮤니티의 판단 기준이 OSI 인증 여부를 기준으로 삼기 때문이다. OSI가 "아님"을 선언하는 순간 커뮤니티 전체가 그 라이선스를 배척하는 구조가 만들어진다.

메커니즘은 이렇다:

대기업이 직접 "SSPL 반대"를 외치면 → 욕먹는다
           ↓
OSI를 통해 "오픈소스 정의에 위반" 선언
           ↓
커뮤니티 개발자들이 신념처럼 따른다
           ↓
대기업은 뒤에서 기존 구조를 유지한다

"오픈소스 철학 수호"라는 명분으로 실질적으로 대기업의 무임승차권을 지키는 것이다. "오픈소스 배신", "커뮤니티 분열", "라이선스 전쟁" — 이런 제목은 조회수가 잘 나온다. Redis, HashiCorp 사태마다 미디어는 이 가십을 충실히 소비했다. 그 분노가 어디를 향해야 하는지 설명하지 않아도 됐다. 커뮤니티의 분노는 실제 권력 구조를 바꾸지 못하고 콘텐츠 소비로 소진됐다.

진짜 피해자가 착취 구조를 수호하는 역설

가장 씁쓸한 지점이 여기다. SSPL에 분노하는 사람들 중 상당수는 소규모 회사 소속 개발자거나 개인 개발자다.

실제로 SSPL이 그들에게 미치는 영향을 따져보면:

셀프호스팅 사용자 → 내부에서 돌리는 거라면 SSPL이어도 아무 제한 없음
소규모 서비스 개발자 → "클라우드 서비스로 제공"하지 않으면 역시 무관
대기업 내부 개발자 → 회사 법무팀이 "SSPL은 안 됨" 판정 → 지침에 따라 반대

마지막 케이스가 핵심이다. 개인 신념이 아니라 회사 지침에 따라 반대 의견을 커뮤니티에 전파하는 구조다. 그리고 그 회사가 바로 SSPL로 제한받는 AWS, Google, Microsoft다.

그럼에도 OSI가 "이건 오픈소스가 아니다"라고 선언하면, 개인 개발자들도 그 판단을 종교처럼 따른다. Hacker News에서 SSPL을 비판하는 댓글 중 상당수는 왜 반대하는지 논리적으로 설명하지 못한다. "OSI 인증 아니잖아요"가 전부다.

정작 진짜 피해자인 오픈소스 유지보수자들이 자신의 착취 구조를 지키는 역설이다.

반복되는 공식

HashiCorp(Terraform → BSL), Redis(→ RSALv2 + SSPLv1), MongoDB(→ SSPL), Elastic(→ SSPL + Elastic License v2, 이후 AGPLv3 추가). 라이선스 선택의 방향은 달랐다 — BSL은 "경쟁 서비스는 쓰지 마라"이고, SSPL은 "쓰려면 전체 스택을 공개하라"다. 그러나 비즈니스 패턴은 같다:

MIT/BSD로 커뮤니티 형성
       ↓
VC 투자 유치
       ↓
수익화 압박
       ↓
라이선스 변경
       ↓
커뮤니티 분노 → "배신자"
       ↓
대기업은 포크 or 다른 프로젝트로 이동

이것은 배신이 아니다. MIT/BSD가 클라우드 시대에 지속 가능한 비즈니스 모델이 될 수 없다는 반복된 증거다. 매번 같은 결말이 나오는데도 "이번엔 다를 거야"라고 믿는 것이 오히려 비논리적이다.

선순환이 착취 구조로 바뀐 세계

오픈소스가 처음 만들어졌을 때는 선순환이 있었다. 개발자가 코드를 공개하면 다른 개발자가 써서 편해지고, 그 결과물이 다시 커뮤니티로 돌아오는 구조. 그 구조 덕분에 수많은 라이브러리를 공짜로 쓰며 개발할 수 있었다. 분명한 빚이다.

그런데 지금은 다르다. 그 선순환의 수혜자가 개발자 커뮤니티가 아니라 클라우드 플랫폼이 되었다. AWS, Google Cloud, Azure가 오픈소스 생태계 전체를 흡수하고, 이익은 플랫폼이 독점한다. 개발자는 여전히 무상으로 기여하고, 플랫폼은 그것으로 수조를 번다.

오픈소스 철학이 틀린 게 아니다. 그 철학이 상정한 세계가 더 이상 존재하지 않는다. 클라우드가 없던 시대에 만들어진 개념을, 클라우드가 모든 것을 빨아들이는 시대에 그대로 적용하면 착취가 합법화된다. 그리고 그 합법성을 "오픈소스 정신"이라는 이름으로 지켜주는 것이 OSI이고, 커뮤니티이고, 오늘도 올라오는 가십성 콘텐츠다.

SSPL은 완벽한 답이 아닐 수 있다. 하지만 이 구조적 문제에 실질적으로 대응하는 시도다. 이것을 "철학 위반"으로 낙인찍고 거부하는 것은, 의도하든 아니든 착취를 보호하는 쪽에 서는 것이다. 그 진화를 "배신"이라 부르는 사람들이 누구의 이익을 대변하는지, 한 번은 솔직하게 따져볼 일이다.

MongoDB, SSPL v1 전문 (2018). OSI 공개 검토 스레드: License-review 메일링 리스트 ↩
OSI, SSPL 검토 결과 — "공개 소스 정의에 부합하지 않는다"고 결론 ↩
Redis 창시자 Salvatore Sanfilippo(antirez)는 2019년 블로그에서 클라우드 업체들이 기여보다 훨씬 많은 수익을 가져간다는 불만을 표명했다. SSPL 전환 이전 기준으로 외부 비직원 기여자들이 커밋의 54%를 담당했다는 데이터는 CHAOSS 데이터 과학 디렉터 Dawn Foster가 Monki Gras에서 발표한 내용이다(전체 코드 추가의 12%, 삭제의 15%에 해당). AWS maintainer가 있었음에도 수익 환원 구조는 전혀 없었다는 점이 핵심이다. 출처: devclass.com — 라이선스 변경 1년 후 분석, AWS Open Source Blog ↩
Redis Ltd., Redis 라이선스 변경 발표 (2024.03). 변경된 라이선스는 RSALv2(Redis Source Available License v2)와 SSPLv1의 듀얼 라이선스다. SSPL 단독이 아님에 유의. ↩
Linux Foundation, Valkey 프로젝트 공식 출범 (2024.03.28) — 출범 당시 AWS, Google Cloud, Oracle, Ericsson, Snap 5개 기업 참여. 이후 Alibaba Cloud, Huawei, Canonical 등으로 확대 ↩
OSI 스폰서 현황은 OSI 스폰서 페이지에서 확인 가능. 2024~2026년 기준 Platinum 스폰서는 Google, Microsoft. 이사진은 주로 오픈소스 재단 출신으로 구성되며, 빅테크는 스폰서 관계로 재정 지원을 한다. ↩