오픈소스 라이선스 2026 — BSL·SSPL·FSL, 그리고 클라우드에 맞선 8년의 반란기 심층 (2026)

프롤로그 — "AWS가 내 데이터베이스를 호스팅한다"
1장 · 퍼미시브 베이스라인 — 여전히 OSS의 90%는 MIT와 Apache 2.0이다
2장 · AWS 스트립 마이닝 문제 — 2010년대 후반의 발견
3장 · MongoDB와 SSPL의 탄생 (2018)
- 3.1 OSI의 반응 — "이건 오픈소스가 아니다"
- 3.2 MongoDB의 결말 — 시장에서 살아남았다
4장 · 반란의 타임라인 — 한눈에 보는 8년
5장 · Elastic 아크 — Apache 2.0 → SSPL → AGPL의 4년
6장 · Redis 아크 — 2024년의 데자뷔
7장 · HashiCorp와 OpenTofu — IaC 진영의 분열
8장 · Sentry와 FSL — "2년 뒤 Apache 2.0"
9장 · 기타 라이선스들 — CockroachDB, Confluent, FUTO
10장 · OSI 정의 싸움 — "오픈소스"는 누구의 단어인가
11장 · 라이선스 vs 권리 매트릭스 (2026)
12장 · 의미 — 누구에게 어떻게 영향을 주는가
13장 · 라이선스 결정 트리 (스타트업/메인테이너용)
14장 · 안티 패턴 — 이렇게 하면 안 된다
에필로그 — 8년 뒤, 우리는 무엇을 배웠는가
- 의사결정 체크리스트 — OSS 도입 시
- 다음 글 예고
참고 / References

프롤로그 — "AWS가 내 데이터베이스를 호스팅한다"

2018년 가을, MongoDB CTO Eliot Horowitz가 블로그에 한 문장을 올렸다.

"We have made the difficult decision to relicense MongoDB Server."

표면적인 이유는 한 줄이었지만, 그 뒤에는 8년이 흐를 긴 분쟁의 씨앗이 있었다. 클라우드 사업자가 오픈소스를 그대로 호스팅 서비스로 팔면서, 정작 그 소프트웨어를 만든 회사에는 아무것도 기여하지 않는 구조. MongoDB는 그것을 "strip-mining"이라 불렀다. 광산을 통째로 파내듯, AWS가 오픈소스를 통째로 팔아간다는 것이다.

이 진단이 옳았는지 틀렸는지를 떠나, MongoDB의 결정은 도화선이 되었다. SSPL(Server Side Public License). 이름은 "Public License"였지만 OSI는 결국 이것을 오픈소스로 인정하지 않았다. 그 뒤로 Elastic이, Redis가, Confluent가, CockroachDB가, MariaDB가, HashiCorp가, Sentry가 — 한 차례씩 비슷한 결정을 내렸다. 모두 "AWS에 대한 자기방어"를 명분으로 들었다.

2026년 현재 우리는 그 반란의 결말 가까이에 와 있다. Elastic은 2024년 8월에 AGPLv3를 옵션으로 추가하며 OSI 오픈소스로 돌아왔고, Redis는 2025년 5월에 같은 길을 따랐다. HashiCorp는 IBM에 인수되었고, 그 사이 OpenTofu는 CNCF 프로젝트로 자리 잡았다. Sentry는 FSL(Functional Source License)을 발명해 "2년 뒤 Apache 2.0으로 자동 전환"이라는 절충안을 내놓았다. FUTO는 "Source First"라는 새로운 이름을 만들었다.

이 글은 그 8년의 라이선스 전쟁을 — 무엇이 일어났고, 왜 일어났으며, 그리고 2026년 당신이 데이터베이스 한 줄을 고를 때 그 라이선스 한 글자가 왜 중요한지 — 한 호흡으로 풀어낸다. 옹호도 비난도 아니다. 결정에 필요한 도구를 주는 것이 목표다.

1장 · 퍼미시브 베이스라인 — 여전히 OSS의 90%는 MIT와 Apache 2.0이다

라이선스 전쟁을 이야기하기 전에 풍경부터 정리하자. 2026년 GitHub에 호스팅된 공개 저장소의 라이선스 분포는 이렇다 (Synopsys Black Duck OSS Audit 2026 통계 기준).

MIT — 약 45 ~ 50%
Apache 2.0 — 약 20 ~ 25%
BSD-3-Clause / BSD-2-Clause — 약 5%
GPL family (GPL/LGPL/AGPL) — 약 15%
MPL 2.0, EPL, ISC, 기타 OSI 인정 — 약 5%
Source-available (BSL, SSPL, FSL, ELv2, RSAL, Confluent CL, FUTO 등) — 합계 1% 미만

즉, 라이선스 반란의 모든 드라마는 시장의 1%에서 벌어지고 있다. 나머지 99%는 여전히 평온하게 MIT나 Apache 2.0이다. 이 사실을 기억하자. 우리가 다룰 BSL·SSPL·FSL은 시장 전체를 흔드는 것이 아니라, 단일 벤더 회사가 만드는 핵심 인프라 컴포넌트(데이터베이스, 검색 엔진, IaC 도구, 모니터링 SaaS의 OSS 컴포넌트)에서만 등장한다.

1.1 MIT — 21줄의 자유

MIT 라이선스의 본문은 영어로 약 170 단어다. 한 줄 요약하면 "공짜로 가져가서 무엇이든 해라. 다만 저작권 고지는 남겨두고, 책임은 우리에게 묻지 마라."

상업적 이용 OK
수정 OK
재배포 OK
사유 라이선스로 재패키징 OK
카피레프트 의무 없음

React, Rails, Express, Vue, Node.js 핵심, Prettier, Bun — 우리가 매일 쓰는 도구의 다수가 MIT다. MIT의 장점은 단순함이고, 단점도 단순함이다. AWS가 React를 가져다 자기 브랜드로 패키징해 팔아도 막을 방법이 없다. 다행히도(?) React는 그런 종류의 비즈니스가 아니다.

1.2 Apache 2.0 — MIT + 특허 보호

Apache 2.0은 MIT의 자유에 두 가지를 더한 라이선스다.

특허 라이선스 명시 — 기여자가 자신의 특허 권리도 함께 양도한다. 즉, 어떤 기여자가 자기 코드 위에 특허를 걸어 사용자를 공격할 수 없다.
트레이드마크 보호 제외 — 라이선스가 트레이드마크 사용 권리를 주지 않는다는 점을 명시한다.

Kubernetes, Kafka, Spark, TensorFlow, Terraform(BSL 이전), Cassandra — 클라우드 네이티브 시대의 거대 프로젝트들이 Apache 2.0를 택한 데는 이유가 있다. 특허 청구로부터의 안전판이 기업 채택을 가능하게 했다.

1.3 GPL 패밀리 — 카피레프트의 마지막 보루

GPL/LGPL/AGPL은 카피레프트(copyleft) 라이선스다. 즉, 이 코드를 가져다 수정해서 배포한다면, 너의 수정본도 같은 라이선스로 공개해야 한다. 일종의 "전염성"이다.

GPL v2 / v3 — 바이너리를 배포할 때 소스 공개 의무. Linux 커널이 GPLv2.
LGPL — 라이브러리 한정 GPL. 정적/동적 링킹의 차이로 카피레프트 범위가 달라진다.
AGPL — GPL의 SaaS 구멍을 막은 버전. 네트워크로 서비스를 제공하는 경우에도 소스 공개 의무. Bruce Perens가 만들었고, 2007년 OSI 승인.

AGPL의 마지막 조항이 결정적이다. 일반 GPL은 "바이너리를 배포할 때"만 소스 공개를 요구한다. 하지만 SaaS는 바이너리를 배포하지 않는다 — 그냥 호스팅해서 API로 제공할 뿐이다. AWS가 MongoDB를 AGPL로 받아 호스팅하면, 수정본 소스도 공개해야 한다. 이것이 MongoDB가 처음에 AGPL을 썼던 이유이고, 동시에 후에 SSPL로 옮긴 이유이기도 하다. AWS는 AGPL이어도 자체 구현(DocumentDB)을 만들어 우회할 수 있었기 때문이다.

2장 · AWS 스트립 마이닝 문제 — 2010년대 후반의 발견

2015년경부터 한 가지 패턴이 명확해졌다. 단일 벤더가 만든 오픈소스 인프라 컴포넌트는 클라우드 시대에 비즈니스 모델이 깨진다. 이유는 단순했다.

AWS/GCP/Azure는 어떤 OSS든 즉시 호스팅 서비스로 출시할 수 있다. 인프라, 마케팅, 영업 채널 모두 갖춰져 있다.
벤더는 자기 자체 클라우드를 운영할 수 있지만, AWS의 사용자 풀과 가격 경쟁력을 이길 수 없다. AWS는 동일 OSS를 더 싸게, 더 잘 통합되어, 더 신뢰성 있게 제공한다.
AWS는 코드 기여를 거의 하지 않는다. OSS 회사가 R&D 비용을 부담하고, AWS가 매출을 가져간다.

이 패턴이 가장 노골적으로 드러난 사건이 MongoDB → AWS DocumentDB (2019년 1월) 였다. MongoDB가 2018년 SSPL로 옮긴 직후, AWS는 "MongoDB 호환 API"를 표방하는 DocumentDB를 출시했다. MongoDB SSPL 코드를 직접 사용하지 않고 처음부터 새로 구현한 우회 전략이었다. MongoDB CTO Mark Porter는 후에 "DocumentDB는 MongoDB와 34%만 호환된다"고 공개적으로 말했지만, AWS는 그 34%만으로도 충분한 시장을 가져갔다.

비슷한 사건이 이어졌다.

Elasticsearch → AWS Open Distro for Elasticsearch (2019년 3월) — AWS는 Elastic의 X-Pack 유료 기능 일부에 해당하는 보안/알림/SQL을 오픈소스로 다시 만들어 뿌렸다. Elastic이 2021년 SSPL로 옮기자, AWS는 다시 포크해 OpenSearch를 만들었다.
Redis → AWS ElastiCache — AWS는 오랫동안 Redis OSS를 ElastiCache로 호스팅해 큰 매출을 만들었다. 2024년 Redis가 라이선스를 바꾸자 AWS는 Linux Foundation 후원의 Valkey 포크를 시작했다.

OSS 회사들의 좌절은 본질적으로 같은 문장이었다. "우리가 만든 것을 AWS가 팔고, 우리는 망해 가고 있다." 이 진단이 정확한지는 논쟁의 여지가 있다(Red Hat은 정확히 동일한 환경에서 340억 달러 매출을 만들었다). 그러나 그 정서가 라이선스 전쟁의 정치적 연료가 되었다.

3장 · MongoDB와 SSPL의 탄생 (2018)

2018년 10월 16일, MongoDB Inc는 Server Side Public License v1을 발표했다. 핵심은 AGPL을 한 발 더 밀고 나간 것이었다.

SSPL 핵심 조항 (의역):
"이 소프트웨어를 third party에 서비스로 제공한다면,
 그 서비스 전체의 소스 코드를 공개해야 한다.
 — 관리 도구, 모니터링, 백업, 로드 밸런서, 사용자 인증을 포함한 전부."

AGPL은 "수정된 OSS 자체의 소스"를 요구한다. SSPL은 **"OSS를 둘러싼 운영 인프라 전체의 소스"**를 요구한다. AWS의 입장에서 이는 사실상 사용 불가능하다 — DocumentDB를 제공하려면 AWS의 내부 운영 시스템까지 공개해야 한다는 뜻이기 때문이다.

3.1 OSI의 반응 — "이건 오픈소스가 아니다"

MongoDB는 SSPL을 OSI에 승인 신청했다. 2021년 1월, OSI는 명확히 거부했다.

"SSPL은 OSI 오픈소스 정의(OSD)의 6번 조항 — 'No Discrimination Against Fields of Endeavor' — 를 위반한다. 특정 사업 영역(클라우드 호스팅)을 차별하기 때문이다."

이 판정이 결정적이었다. SSPL은 그때부터 "source-available"이라 불리며, 오픈소스가 아닌 별도의 카테고리에 놓이게 되었다. 이는 단순한 단어 싸움이 아니다. 많은 기업의 컴플라이언스 정책이 "OSI 승인 오픈소스만 허용"이라는 규정을 갖고 있기 때문이다.

3.2 MongoDB의 결말 — 시장에서 살아남았다

논쟁은 격렬했지만, MongoDB의 비즈니스는 무너지지 않았다. 오히려 SSPL 전환 이후 MongoDB Atlas의 비중이 점점 커져, 2026년 현재 MongoDB 전체 매출의 70% 이상이 Atlas에서 나온다. 라이선스가 비즈니스를 직접 살린 것은 아니지만 — 적어도 죽이지도 않았다.

4장 · 반란의 타임라인 — 한눈에 보는 8년

2010 ────────────────────────────────────────────────────────────── 2026
       퍼미시브 황금기                                반란기와 정상화

2010    Redis 출시 (BSD 3-Clause)
2011    HashiCorp 창업, Terraform = MPL 2.0
2012    Elasticsearch 1.0 (Apache 2.0)
2018-10 MongoDB → SSPL  ← AWS DocumentDB 출시 직전
2019-01 AWS DocumentDB 출시
2019-03 AWS Open Distro for Elasticsearch
2021-01 Elastic → SSPL + ELv2   ← Apache 2.0 포기
2021-04 AWS → OpenSearch 포크
2021-01 OSI: SSPL은 오픈소스 아님 (공식 판정)
2023-08 HashiCorp → BSL 1.1     ← Terraform, Vault, Consul, Nomad
2023-09 OpenTofu (Terraform 포크) 발표, Linux Foundation 가입
2023-11 Sentry → FSL 발명, 2년 뒤 Apache 2.0 자동 전환
2024-01 OpenTofu 1.6 정식 출시
2024-03 Redis → SSPL + RSALv2   ← AWS ElastiCache 견제
2024-03 Linux Foundation → Valkey 포크 (Redis OSS의 후속)
2024-08 Elastic → AGPLv3 옵션 추가  ← OSI 오픈소스로 복귀
2025-02 IBM → HashiCorp 인수 완료
2025-04 OpenTofu, CNCF 인큐베이션 프로젝트로 승격
2025-05 Redis → AGPLv3 옵션 추가  ← OSI 오픈소스로 복귀
2025-11 Salvatore Sanfilippo, Redis 복귀 (developer evangelist)
2026-05 현재: 반란의 결말, 부분적 회귀

이 타임라인을 보면 공통 패턴이 보인다. (1) 단일 벤더 OSS가 (2) AWS의 호스팅 출시를 겪고 (3) 비-OSI 라이선스로 옮기고 (4) 커뮤니티 포크가 나오며 (5) 결국 일부는 OSI 라이선스로 회귀한다. 이 패턴을 우리는 **"라이선스 진자(license pendulum)"**라 부를 수 있다.

5장 · Elastic 아크 — Apache 2.0 → SSPL → AGPL의 4년

5.1 2021년 1월의 충격

Elastic CEO Shay Banon이 블로그에 글을 올렸을 때, 검색·로깅 업계는 한 차례 멈췄다. Elasticsearch와 Kibana가 Apache 2.0에서 SSPL + ELv2(Elastic License v2) 듀얼 라이선스로 옮긴다는 것이었다.

Banon의 명분은 익숙했다.

"We're forking ourselves so that nobody else needs to fork us."

AWS가 Open Distro for Elasticsearch라는 포크를 운영하는 상황에 대한 답이었다. 하지만 OSS 커뮤니티의 반응은 차가웠다. "10년간 Apache 2.0이라는 약속을 받고 기여한 사람들에 대한 배신"이라는 비판이 쏟아졌다.

5.2 AWS의 답 — OpenSearch 포크 (2021년 4월)

3개월 뒤 AWS는 마지막 Apache 2.0 버전(7.10.2)에서 포크한 OpenSearch를 발표했다. 2026년 현재 OpenSearch는 Linux Foundation 산하 프로젝트가 되었고, AWS 외에도 Aiven, Logz.io, Bonsai 등이 코어 기여자다. Elastic이 우려한 "검색 시장의 분할"이 실제로 일어났다.

5.3 2024년 8월 — AGPL로의 회귀

3년 반 뒤, Elastic은 다시 한 번 라이선스를 바꾼다. AGPLv3를 SSPL과 ELv2 옆에 추가한 트리플 라이선스로 전환. Banon은 블로그에 "We are now an Open Source Initiative-approved open source company again"이라고 적었다.

배경에는 두 가지 계산이 있었다.

상처 회복: Elastic이 입은 평판의 손실은 컸다. OSI 승인 라이선스 복귀는 그 일부라도 회복하기 위한 시도였다.
OpenSearch와의 격차 축소: OpenSearch가 커지자, Elastic은 다시 OSS 커뮤니티의 마인드셰어를 되찾을 필요가 있었다.

AGPL은 SSPL보다 약한 카피레프트지만 OSI 승인이다. AWS는 AGPL 코드를 그대로 호스팅 서비스로 팔 수 있다(소스를 공개한다면). 즉, Elastic은 AWS와의 경쟁 견제력을 일부 포기하고 OSI 배지를 다시 얻은 것이다. 비즈니스적 계산이지, 이타적 선택은 아니다.

6장 · Redis 아크 — 2024년의 데자뷔

6.1 2024년 3월의 충격

2024년 3월 20일, Redis Inc는 Redis 7.4부터 라이선스를 SSPL + RSALv2(Redis Source Available License v2) 듀얼로 바꾼다고 발표했다. 명분은 Elastic 때와 같았다 — "AWS, GCP, Azure가 Redis OSS를 그대로 호스팅 사업으로 만든다."

6.2 Valkey 포크 — 6일 만의 답

발표 6일 뒤, Linux Foundation은 Valkey라는 Redis 포크를 발표했다. AWS, Google Cloud, Oracle, Ericsson, Snap이 창립 멤버였다. 마지막 BSD 3-Clause 버전인 Redis 7.2.4에서 출발했다. 6개월 만에 Valkey 8.0이 나왔고, 2026년 현재 다수의 클라우드 사업자가 Redis 대신 Valkey를 호스팅한다.

특기할 점은 Redis 원작자 Salvatore Sanfilippo("antirez")의 입장이었다. 그는 2024년에는 Redis를 떠나 있었지만, 2024년 11월 Redis Inc에 developer evangelist로 복귀한다고 발표했다. 이 결정은 Redis의 라이선스 미래에 영향을 미쳤다.

6.3 2025년 5월 — AGPL 추가

Salvatore의 복귀 약 6개월 뒤, Redis는 Redis 8부터 AGPLv3를 세 번째 라이선스 옵션으로 추가했다. 이제 사용자는 RSALv2, SSPLv1, AGPLv3 셋 중 하나를 고를 수 있다. Elastic의 패턴을 거의 그대로 따랐다.

Redis 측 입장은 명확했다.

"We made a mistake. We are returning to OSI-approved open source — but on our terms, with AGPLv3."

커뮤니티 반응은 엇갈렸다. Percona의 Vadim Tkachenko는 "환영하지만 본질적으로 마케팅 무브"라 평가했다. Valkey는 이미 충분한 모멘텀을 얻었고, 많은 클라우드 사업자가 Redis로 돌아갈 동기를 잃은 상태였다. 라이선스를 되돌릴 수는 있지만, 신뢰는 되돌릴 수 없다.

7장 · HashiCorp와 OpenTofu — IaC 진영의 분열

7.1 2023년 8월의 BSL 전환

HashiCorp는 2023년 8월 10일, Terraform·Vault·Consul·Nomad·Boundary·Waypoint·Packer를 일제히 MPL 2.0에서 **BSL 1.1(Business Source License)**로 옮겼다. 마리아DB가 만든 BSL은 다음과 같은 구조다.

소스 공개: OK, 누구나 볼 수 있다.
사용 제한: 명시된 "Additional Use Grant"를 벗어난 경우 상업적 이용 불가. HashiCorp의 경우, "HashiCorp의 제품과 경쟁하는 상품/서비스를 제공"하는 것이 제한 대상.
4년 후 자동 전환: 4년이 지나면 자동으로 MPL 2.0 등 오픈소스 라이선스로 전환.

표면적으로는 "4년만 기다리면 다시 OSS"라는 점에서 SSPL보다 부드럽다. 하지만 핵심은 그 4년 동안 클라우드 사업자가 Terraform Cloud 같은 호스팅 서비스를 만들 수 없게 막는 것이었다.

7.2 OpenTofu — 한 달 만의 포크

발표 한 달 뒤인 2023년 9월, OpenTF Manifesto가 공개되었다. Gruntwork, Spacelift, env0, Scalr, Harness 등 Terraform 생태계 회사들이 모여 만든 선언문이었다. 핵심 요구는 단순했다.

HashiCorp가 Terraform을 다시 MPL 2.0으로 되돌릴 것.
그렇지 않으면 우리는 포크한다.
포크는 Linux Foundation 산하로 가져갈 것.

HashiCorp는 거절했다. 9월 20일 OpenTF Foundation이 결성되었고, 11월에는 OpenTofu라는 이름을 받았다(상표권 충돌 회피). 2024년 1월에 OpenTofu 1.6.0이 GA로 나왔다.

7.3 2026년 현재의 풍경

OpenTofu 1.9 (2026년 5월) — for_each 키 분리, 스테이트 암호화, 동적 프로바이더 등 Terraform에는 없는 기능을 먼저 출시.
CNCF 인큐베이션 — 2025년 4월 정식 채택. 다중 벤더 거버넌스 안정화.
IBM의 HashiCorp 인수 — 2025년 2월 완료. Terraform이 IBM 클라우드 도구 라인업의 한 축이 됨.

OpenTofu와 Terraform은 2026년 시점에서 코어가 다르다. Terraform 1.6 이후의 기능 일부를 OpenTofu가 따라가지 않고, 반대로 OpenTofu의 신기능을 Terraform이 도입하지 않는다. State 파일 포맷도 미묘하게 분기되었다. 사실상 두 개의 다른 도구가 된 것이다.

스타트업에게 결정 기준은 명확하다.

IBM/HashiCorp 엔터프라이즈 지원이 필요 → Terraform
베더 락인 없는 OSS만 고집 → OpenTofu
AWS/Azure/GCP 셋 다 자유롭게 → OpenTofu가 더 안전

8장 · Sentry와 FSL — "2년 뒤 Apache 2.0"

8.1 BSL에 대한 비판

BSL의 4년 전환 기간은 길었다. "4년 뒤 OSS"는 어떤 의미에서는 "지금은 OSS 아님"과 같았다. 또한 BSL의 "Additional Use Grant"는 텍스트가 길고 모호해서, 컴플라이언스 팀이 해석에 어려움을 겪었다.

8.2 FSL의 발명 (2023년 11월)

Sentry CEO David Cramer와 Heather Meeker(BSL의 원작자 변호사)가 협력해 **Functional Source License(FSL)**를 만들었다. 핵심은 BSL을 더 단순하고 짧게 다듬은 것이다.

FSL 핵심:
- "Permitted Purpose": 무엇이든 OK, 단 "Competing Use" 제외
- "Competing Use": 라이선서의 제품과 직접 경쟁하는 상품 제공
- 2년 뒤 자동 전환: Apache 2.0 또는 MIT 중 선택
- Sentry는 Apache 2.0 선택

BSL과 다른 점은 두 가지다.

전환 기간 단축: 4년 → 2년. 이것이 결정적이다. 2년이면 기술 사이클상 "거의 동시대"다.
언어 단순화: BSL의 "Additional Use Grant" 자리를 "Permitted Purpose / Competing Use" 두 단어로 줄였다.

8.3 Sentry의 결정 — 회귀

흥미롭게도 Sentry 자체는 2024년 말 FSL에서 다시 BUSL로 바꿨다(Sentry 자체 호스팅과 Codecov 호스팅 영역에서). 이유는 "Competing Use" 정의가 너무 좁다는 것이었다. 즉, FSL은 살아남았지만 발명자 자신은 다른 길로 갔다.

FSL을 이어받은 회사들은 있다.

Convex (실시간 데이터베이스)
Keygen (라이선스 관리)
상당수의 SaaS 컴포넌트 OSS화

FSL은 BSL의 "더 정직한" 버전으로 자리매김했다. "우리는 OSS 흉내를 내지 않는다, 2년 뒤에는 진짜 OSS가 된다." 이 약속이 더 신뢰성 있게 들린 것이다.

9장 · 기타 라이선스들 — CockroachDB, Confluent, FUTO

9.1 CockroachDB → BSL → 엔터프라이즈

CockroachDB Labs는 2019년에 BSL로 옮겼고, 2024년에는 **코어 부분을 완전히 사유 라이선스(CockroachDB Enterprise License)**로 만들었다. 즉, 더 이상 무료 셀프호스팅이 가능하지 않다. 가장 강경한 경로를 택한 케이스다.

스타트업이 CockroachDB를 도입할 때는 이 점을 알아야 한다. "OSS DB"라는 이미지로 시작했지만, 2026년 현재는 사실상 엔터프라이즈 라이선스가 필요한 상용 제품이다.

9.2 Confluent Kafka — Confluent Community License

Apache Kafka 자체는 Apache 2.0이다. 그러나 Confluent가 만든 부속 컴포넌트(KSQL, Schema Registry의 일부, Kafka Connect의 커넥터 다수)는 Confluent Community License(CCL) 라는 자체 라이선스다.

CCL의 핵심 제약: "Kafka SaaS를 제공하는 사업"에 사용 불가. AWS MSK(Managed Streaming for Kafka)는 Confluent의 부속 컴포넌트를 사용할 수 없다는 뜻이다. 결과적으로 AWS MSK는 KSQL이나 Schema Registry 같은 도구를 자체적으로 다시 만들어야 했다.

9.3 FUTO와 "Source First"

Eron Wolf가 만든 FUTO는 2024년 자체 FUTO License를 발표했다. 핵심 조항은 "비상업적 사용은 자유, 상업적 사용은 명시적 허가 필요"다. OSI 정의로는 명백히 비-오픈소스다.

흥미로운 것은 FUTO 측의 수사다. 그들은 "오픈소스" 대신 "Source First"라는 새 용어를 쓴다. OSI 정의에 도전하는 것이 아니라, **"OSS의 사회적 기능(투명성, 학습 가능성, 자유로운 수정)은 제공하지만 OSI 정의는 따르지 않는다"**고 명시적으로 분리한다.

OSI는 이 움직임을 곱게 보지 않는다. "open source"라는 단어의 정의 자체에 대한 도전이기 때문이다. 그러나 2026년 현재 "source-available", "fair-code", "source-first" 같은 새 카테고리가 사실상 정착되었다. OSS의 단일 정의는 깨지고 있다.

10장 · OSI 정의 싸움 — "오픈소스"는 누구의 단어인가

10.1 OSD — 10개의 조항

OSI(Open Source Initiative)는 1998년 설립되었고, Open Source Definition(OSD) 10개 조항을 유지한다. 핵심 몇 개를 짚어보자.

자유 재배포 (Free Redistribution) — 누구든 자유롭게 재배포 가능.
소스 코드 (Source Code) — 소스 코드 포함 또는 무료 접근 가능.
파생물 (Derived Works) — 수정과 파생물 허용.
저자 소스의 무결성 (Integrity of The Author's Source Code) — 패치 형태로 수정본 배포할 수 있어야.
개인/그룹 차별 금지 (No Discrimination Against Persons or Groups)
사용 분야 차별 금지 (No Discrimination Against Fields of Endeavor) — 이 조항이 SSPL을 막았다.
라이선스 배포 (Distribution of License)
제품 특정 금지 (License Must Not Be Specific to a Product)
다른 소프트웨어 제한 금지 (License Must Not Restrict Other Software)
기술 중립 (License Must Be Technology-Neutral)

10.2 6번 조항의 무게

6번 — "사용 분야 차별 금지". 이것이 핵심이다. SSPL, BSL, FSL, CCL, FUTO 모두 한 가지 공통점이 있다 — 클라우드 호스팅 사업이라는 특정 사업 영역에 제한을 둔다. 이는 6번 조항 위반이다.

OSI의 입장은 일관적이다. "라이선스가 누군가의 사용을 막는다면, 그것은 오픈소스가 아니다." 이것은 단지 단어의 문제가 아니다. GPL부터 MIT까지 모든 OSI 승인 라이선스가 6번을 따른다. 그것이 OSS 생태계의 신뢰 기반이다.

10.3 "Source-Available" 진영의 반박

벤더 측 반박도 명확하다.

"OSI 정의는 1998년에 만들어졌다. 그 시대의 적은 마이크로소프트의 사유 라이선스였다. 2026년의 적은 다르다 — AWS의 무한 자본 기반 클라우드 호스팅이다. 1998년의 정의로 2026년의 위협을 막을 수 없다."

이 논쟁은 해결되지 않았다. OSI는 "open source"라는 단어를 지키고, 벤더는 "source-available"이라는 새 단어를 받아들이는 — 일종의 정착이 일어났다. 그 너머에는 더 큰 질문이 있다: "오픈소스 회사가 비즈니스로 살아남을 수 있는가?" 이 질문에 대한 답은 아직 누구도 명확히 갖고 있지 않다.

11장 · 라이선스 vs 권리 매트릭스 (2026)

라이선스별로 사용자가 가지는 권리를 매트릭스로 비교하면 다음과 같다. Y는 허용, N은 금지, C는 조건부.

권리	MIT	Apache 2.0	GPL v3	AGPL v3	BSL 1.1	SSPL v1	FSL 1.1	ELv2	RSALv2	CCL
코드 열람	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
내부 수정·사용	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
사유 라이선스로 재배포	Y	Y	N	N	C	C	C	C	C	C
카피레프트 의무	N	N	Y	Y(net)	N	Y(strong)	N	N	N	N
특허 라이선스 명시	N	Y	Y	Y	N	Y	N	N	N	N
클라우드 호스팅 사업	Y	Y	Y	Y(공개시)	N(조건부)	C(전체공개)	N(2년간)	N	N	N
OSI 승인	Y	Y	Y	Y	N	N	N	N	N	N
시간 후 OSS 전환	-	-	-	-	4년 후	-	2년 후	-	-	-

이 매트릭스가 결정에 도움이 된다. OSI 배지가 필요하면 GPL 패밀리 또는 퍼미시브뿐이다. 클라우드 사업 견제력이 필요하면 SSPL/BSL/FSL/ELv2 중 하나다. 시간이 답이라면(언젠가 OSS로) FSL이 가장 빠르다(2년).

12장 · 의미 — 누구에게 어떻게 영향을 주는가

12.1 스타트업: OSS DB/컴포넌트를 고를 때

핵심 질문 — "이 라이선스의 변경 위험이 얼마나 큰가?"

스타트업이 데이터 인프라에 의존할 때, 라이선스 변경은 직격탄이다. 그래서 다음 순서로 평가해야 한다.

벤더 락인 위험 — 단일 회사가 통제하는 OSS인가, 다중 벤더 거버넌스(CNCF, Linux Foundation, Apache Foundation)인가?
퍼미시브 vs 카피레프트 — 우리 코드가 OSS 코드를 임베드하는가, 별도 프로세스로 분리하는가?
호스팅 가능성 — 우리 서비스가 사실상 "이 OSS의 호스팅 서비스"가 될 수 있는가?
장기 의존도 — 5년 뒤에도 이 컴포넌트가 필요한가?

12.2 클라우드 벤더: 호스팅 사업

AWS·GCP·Azure 입장에서 라이선스 풍경은 점점 복잡해진다. 2026년 현재의 대응 패턴:

포크 + 자체 운영: OpenSearch, Valkey. AWS가 직접 포크해 자체 호스팅.
별도 구현: DocumentDB. SSPL 코드를 쓰지 않고 호환 API만 제공.
수익 분배 계약: 일부 OSS 회사와 직접 수익 분배. Confluent ↔ AWS, MongoDB ↔ AWS의 일부 협업.
인수: HashiCorp → IBM, GitLab → 시도 등.

12.3 OSS 프로젝트: 지속 가능성

OSS 프로젝트의 메인테이너 입장에서 라이선스 결정은 곧 비즈니스 모델 결정이다. 2026년의 합의된 패턴이 있다면 이것이다.

순수 OSS 단일 벤더는 어렵다 — Red Hat 모델은 예외적 규모와 시기에만 통한다.
클라우드 사업자와의 정면 충돌은 자해다 — AWS와 직접 경쟁하는 호스팅 사업으로 이기기는 거의 불가능.
Open Core가 가장 현실적 — 핵심은 OSS, 부가 기능은 사유.
재단 이관이 신뢰를 만든다 — CNCF, Linux Foundation, Apache 산하로 가는 순간 라이선스 변경 위험이 사라진다.

13장 · 라이선스 결정 트리 (스타트업/메인테이너용)

새 OSS 프로젝트의 라이선스를 결정해야 한다면, 다음 순서로 묻는다.

[1] 이 프로젝트는 단일 회사가 주도하는가?
    ├─ Yes → [2]
    └─ No (재단/다중 벤더 기반) → Apache 2.0 권장. 끝.

[2] 5년 내 SaaS/호스팅 비즈니스로 만들 의도가 있는가?
    ├─ Yes → [3]
    └─ No (순수 OSS, 컨설팅/서포트 모델) → MIT 또는 Apache 2.0. 끝.

[3] 호스팅 비즈니스의 직접 경쟁자(AWS/GCP/Azure)가 위협인가?
    ├─ Yes → [4]
    └─ No (기업 내부 도구, B2B SaaS 중심) → Apache 2.0 + 상표권 강화. 끝.

[4] OSI 승인 배지가 컴플라이언스에 필수인가?
    ├─ Yes → AGPLv3. 끝. (Elastic·Redis가 선택한 경로)
    └─ No → [5]

[5] "언젠가 OSS로 돌려준다"는 약속을 명시적으로 하고 싶은가?
    ├─ Yes, 2년 → FSL 1.1
    ├─ Yes, 4년 → BSL 1.1
    └─ No, 영구 사유 → ELv2 또는 자체 라이선스 (Codeium 모델)

이 트리는 절대적이지 않다. 그러나 자신이 어느 노드에서 어떤 답을 했는지를 명시적으로 추적해두면, 미래에 라이선스를 바꾸어야 할 때 — 그 변경의 정당성을 외부에 설명할 수 있다. Elastic과 Redis가 라이선스를 바꾼 뒤 받은 비난의 상당 부분은 "왜 그렇게 결정했는지를 처음부터 말하지 않았기 때문"이었다.

14장 · 안티 패턴 — 이렇게 하면 안 된다

라이선스 결정에서 자주 보는 실수들을 정리한다.

14.1 "오픈소스"라는 단어를 잘못 쓰는 것

비-OSI 라이선스를 "open source"라 부르는 순간 OSI와 충돌하고, 컴플라이언스 팀이 도입을 막는다. 2026년 현재, 정확한 단어는 "source-available"이다. 이를 분명히 하라.

14.2 갑작스러운 라이선스 변경

Elastic과 Redis가 가장 비싼 대가를 치른 부분이다. 라이선스 변경은 최소 6개월 전부터 예고하고, 명분과 데이터를 함께 공개하라. "갑자기"는 거의 항상 신뢰를 깬다.

14.3 CLA(Contributor License Agreement) 없이 듀얼 라이선스 시작

14.4 "AWS가 위협"이라는 잘못된 명분

대부분의 OSS 프로젝트에 AWS는 위협이 아니다. AWS가 호스팅하기에 충분히 큰 OSS는 극소수다. 자기 프로젝트가 그 극소수에 속하지 않는다면, AWS 견제 명목의 BSL/SSPL은 자기 발등에 도끼다. 채택 속도만 떨어뜨린다.

14.5 4중 라이선스의 함정

Elastic은 현재 AGPLv3 + SSPLv1 + ELv2 세 가지를 동시에 제공한다. 이는 "사용자가 골라라"는 친절이지만 컴플라이언스 팀에는 악몽이다. 어떤 라이선스가 적용되는지 명시적으로 선택해야 하고, 그 선택이 부속 컴포넌트 전체에 일관적으로 적용되어야 한다.

에필로그 — 8년 뒤, 우리는 무엇을 배웠는가

2018년 MongoDB의 SSPL 발표부터 2025년 Redis의 AGPL 복귀까지 — 8년이었다. 그 사이 우리가 배운 것을 정리하면 짧다.

라이선스는 비즈니스 모델의 표현이지, 비즈니스 모델 자체가 아니다. 라이선스를 바꾼다고 매출이 늘지 않는다.
클라우드 사업자를 라이선스로 막을 수 있다는 발상은 부분적으로만 옳다. AWS는 우회 구현(DocumentDB), 포크(OpenSearch, Valkey)로 거의 항상 응답한다.
OSI 배지의 가치는 크다. 컴플라이언스, 채용, PR — 모든 측면에서 작용한다. 그래서 Elastic과 Redis가 결국 AGPL로 돌아온 것이다.
재단 이관이 신뢰의 최종 형태다. CNCF·Linux Foundation 산하의 프로젝트는 라이선스 변경 위험이 사실상 없다.
8년의 진자 운동 결과 — 시장은 정상화되고 있다. SSPL/BSL은 살아남았지만 극소수 영역에 한정되었고, 다수의 회사가 AGPL이나 Open Core로 회귀했다.

이 글을 읽는 당신이 2026년에 오픈소스 컴포넌트 하나를 고른다면, 마지막 체크리스트는 이렇다.

의사결정 체크리스트 — OSS 도입 시

이 OSS의 라이선스는 OSI 승인인가? (MIT, Apache 2.0, BSD, GPL, AGPL, MPL, EPL)
단일 회사가 통제하는가, 재단(CNCF/LF/ASF)이 통제하는가?
최근 5년 내 라이선스 변경이 있었는가? 변경 가능성은?
포크 버전이 존재하는가? 메인 트렁크 대비 채택률은? (OpenSearch, Valkey, OpenTofu 등)
우리 사용 패턴이 AGPL 카피레프트의 트리거를 발동하는가? (네트워크로 노출 + 사용자가 외부)
컴플라이언스 정책이 SSPL/BSL/FSL을 허용하는가?
5년 뒤에도 이 컴포넌트가 필요할 가능성이 있는가? 그렇다면 마이그레이션 경로는?

다음 글 예고

다음 글에서는 2026년 오픈소스 거버넌스의 거시 풍경 — 재단(CNCF, Linux Foundation, Apache, Eclipse)의 역할 변화, 정부 규제(EU CRA, US 행정명령)가 OSS에 미치는 영향, AI 모델 가중치는 오픈소스인가에 대한 답 없는 질문 — 을 다룬다. 라이선스가 한 줄의 글자라면, 거버넌스는 그 글자가 살아 움직이는 정치 구조다.