Skip to content
Published on

오픈소스 라이선스 대전환 2026 — BSL 물결: Elastic / Redis / HashiCorp / Sentry / Valkey / OpenTofu 심층 정리

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — 2026년, 우리는 어떻게 여기까지 왔는가

2026년 5월 현재, "이거 진짜 오픈소스 맞아요?"라는 질문이 기술팀 슬랙에서 일주일에 한 번씩 나온다. Elastic, Redis, HashiCorp, MongoDB, Sentry, Cockroach, Confluent, MariaDB, n8n — 우리가 매일 쓰는 도구의 상당수가 더 이상 OSI(Open Source Initiative)가 인정하는 라이선스로 배포되지 않는다.

지난 7년 동안 일어난 일을 한 문장으로 요약하면 이렇다. "클라우드 회사(특히 AWS)가 우리 코드로 매니지드 서비스를 팔아 우리보다 돈을 더 번다"라는 인식과, 거기에 맞선 OSS 회사들의 라이선스 변경. 그 결과 OSI 정의에 부합하지 않는 "source-available" 라이선스가 줄지어 등장했고, 그때마다 커뮤니티 포크가 태어났다.

이 글은 그 7년사를 정리한다. 누가 언제 무엇을 바꿨고, 왜 그랬으며, 어떤 포크가 살아남았는지, 그리고 2026년 현재 우리 회사가 어떤 결정을 해야 하는지를 본다. 12개 챕터, 약 65분 분량이다.

핵심 변화 세 가지를 먼저 짚는다.

  • BSL이 사실상 표준이 됐다. 2018년 MongoDB가 SSPL을 만들고, 2023년 HashiCorp가 Terraform/Vault/Consul을 BSL로 옮긴 뒤, 2024년 Redis·Sentry·Cockroach가 줄줄이 따라왔다. 신규 인프라 OSS의 절반 이상이 BSL 또는 그 변종으로 시작한다.
  • 포크가 반드시 일어난다. Elastic → OpenSearch(AWS, 2021), Terraform → OpenTofu(LF, 2023), Vault → OpenBao(LF, 2024), Redis → Valkey(LF, 2024). Linux Foundation이 사실상 "포크 인큐베이터" 역할을 한다.
  • OSI 정의가 흔들린다. "Source-available도 오픈소스로 봐달라"라는 압력과, "OSI 정의가 망가졌다"라는 비판이 동시에 나오고 있다. 2024–2025년 OSI는 AI 모델용 OSAID(Open Source AI Definition)를 만들며 한 번 더 논쟁의 중심에 섰다.

1장 · 2026년 오픈소스 라이선스 — 왜 다들 비-OSI로 가나

먼저 "비-OSI 라이선스"가 무엇인지부터 정의하자. OSI는 1998년에 만들어진 비영리 단체로, "오픈소스"라는 단어의 정의(Open Source Definition, OSD)를 관리한다. OSD는 10개 조항을 두는데, 그중 가장 자주 부딪치는 것은 6번(차별 금지: "특정 사업 분야에서의 사용을 제한하면 안 됨")이다.

BSL·SSPL·RSALv2·FSL·ELv2 — 이번 글에서 다룰 라이선스 대부분은 6번을 위반한다. 매니지드 서비스로 파는 것을 막거나, 일정 매출 이상 회사에는 다르게 적용되거나, 일정 시점 후에야 Apache로 바뀐다.

왜 회사들이 비-OSI로 가는가. 이유는 세 가지로 묶을 수 있다.

  1. AWS·구글·MS의 매니지드 서비스 경쟁. Amazon ES(2015), Amazon RDS, Amazon DocumentDB(MongoDB API 호환), Amazon MemoryDB(Redis 호환), Amazon EMR(Hadoop·Spark) — AWS가 OSS를 가져와 매니지드로 파는 패턴이 반복됐다. 회사가 만든 OSS의 트래픽을 AWS가 가져가고, 회사 매출은 정체한다.

  2. VC 압박. OSS 회사 대부분이 시리즈 B/C 단계에서 매출이 정체된다. 2020–2023년 ZIRP(zero interest rate policy)가 끝나며 VC가 "어떻게 monetize 할 거냐"라는 질문을 더 세게 했다. 라이선스 변경은 가장 직접적인 답이다.

  3. 모방의 가속. MongoDB가 2018년 SSPL로 가서 잘 됐다(주가는 떨어졌다가 결국 회복). Elastic이 2021년 SSPL/ELv2로 갔고, HashiCorp가 2023년 BSL로 갔다. "선례가 있고, 시장이 받아들였다"라는 메시지가 다음 회사의 결정을 쉽게 만든다.

비-OSI 라이선스의 종류.

라이선스만든 곳핵심 제약OSI 승인?
SSPL (Server Side Public License)MongoDB (2018)서비스로 제공 시 전체 SaaS 스택을 SSPL로 공개해야 함아니오
BSL (Business Source License)MariaDB (2013)4년(또는 정한 기간) 후 Apache 2.0으로 자동 전환, 그동안 production 사용 제한아니오
ELv2 (Elastic License v2)Elastic (2021)매니지드 서비스로 제공·우회 금지아니오
RSALv2 (Redis Source Available License v2)Redis (2024)매니지드 서비스 제공 금지아니오
FSL (Functional Source License)Sentry (2023)2년 후 Apache 2.0 또는 MIT로 전환, 그동안 경쟁 금지아니오
Sustainable Use Licensen8n (2022)내부 사용·임베드 가능, 호스팅 판매 금지아니오
AGPL v3FSF (2007)네트워크로 제공해도 소스 공개 의무예 (OSI 승인)

2024년 8월 Elastic이 AGPL로 돌아오면서 AGPL이 "BSL의 대안"으로 다시 조명받았다. AGPL은 OSI가 승인한 진짜 오픈소스이면서도 "AWS가 매니지드로 팔려면 자기 코드도 공개해야 한다"라는 효과가 있어서, 회사 입장에서는 SSPL보다 깔끔하다.

2장 · OSI 정의 vs "Source-Available" 논쟁

OSI 정의(OSD)는 10개 조항이다. 그중 BSL·SSPL이 위반한다고 OSI가 명시한 조항은 다음과 같다.

  • OSD #5 (개인·그룹 차별 금지): SSPL은 "당신이 SaaS 회사라면 다르게 적용"이라는 차별을 한다는 해석.
  • OSD #6 (사용 분야 차별 금지): BSL은 "production 사용 금지"라는 분야 제한을 둔다.
  • OSD #9 (다른 소프트웨어 차별 금지): SSPL이 "이 코드를 쓰면 함께 묶이는 모든 소프트웨어도 SSPL로 풀어야"라는 조항을 두어 차별을 일으킨다는 해석.

OSI는 2019년에 SSPL이 OSD에 부합하지 않는다고 공식 발표했다. MongoDB가 OSI에 SSPL 승인을 신청했다가 철회한 사건이다. 이후 BSL·ELv2·RSALv2·FSL도 같은 이유로 OSI 승인을 받지 못했다.

"Source-Available"이라는 용어. OSI 승인을 받지 못한 라이선스들은 자기를 "source-available"이라고 부른다. 코드는 공개되어 있지만(읽을 수 있고 포크할 수 있다), 일정 용도로는 쓸 수 없다는 뜻이다.

문제는 일반 개발자가 그 차이를 모른다는 것이다. GitHub 페이지에 "BSL" 또는 "FSL" 라벨이 붙어 있어도, "오픈소스니까 마음대로 써도 되겠지"라고 생각하고 production에 깐다. 1년 뒤 법무팀이 "이거 BSL인데 production 사용은 라이선스 위반이에요"라고 말하면 그 회사는 다음 두 가지 중 하나를 한다 — (a) 라이선스 구매, (b) 다른 OSS로 마이그레이션.

"오픈소스라는 단어를 뺏지 마라." 비-OSI 진영의 반론은 "OSI 정의가 1998년에 만들어졌고, 현실(클라우드 매니지드 서비스)을 반영하지 못한다"라는 것이다. HashiCorp의 Armon Dadgar, MongoDB의 Eliot Horowitz, Sentry의 David Cramer가 비슷한 주장을 했다. "우리가 만든 코드를 우리가 어떻게 라이선스할지 결정할 권리가 있다."

OSI의 입장. OSI는 "물론 회사는 자기 코드를 어떻게든 라이선스할 수 있다. 하지만 '오픈소스'라는 단어는 OSD에 부합하는 라이선스에만 써달라"라고 일관되게 말한다. 2025년 OSI 의장 Stefano Maffulli는 "BSL이 오픈소스라고 부르는 것은, 채식 햄버거가 소고기라고 부르는 것과 같다"라고 발언했다.

이 논쟁은 끝나지 않는다. 2026년 현재 OSI 정의는 그대로지만, "source-available을 무엇이라 부를 것인가"가 새로운 라벨 전쟁이 됐다. Fair Source, Sustainable Source, Functional Source 같은 신조어가 매년 하나씩 늘어난다.

3장 · Elastic 2021 (SSPL+ELv2) → OpenSearch (AWS) → Elastic AGPL 복귀 (2024.8)

Elastic의 라이선스 여정은 BSL 물결의 가장 상징적인 사례다. 2010년 Shay Banon이 Elasticsearch를 만들었을 때 라이선스는 Apache 2.0이었다. 2015년 AWS가 Amazon Elasticsearch Service를 출시했고, 그때부터 7년에 걸친 긴장이 시작됐다.

2018–2020년: 첫 번째 충돌. Elastic은 2018년에 "X-Pack(보안·모니터링)" 코드를 일부 공개했지만 라이선스는 Elastic License였다. AWS는 X-Pack을 클론한 Open Distro for Elasticsearch를 발표했다(2019). 양쪽 다 상대를 "fork hostile"이라고 비난했다.

2021년 1월: SSPL+ELv2 전환. Elastic은 Elasticsearch와 Kibana를 Apache 2.0에서 SSPL 또는 Elastic License v2 듀얼 라이선스로 옮긴다고 발표했다. 사용자는 둘 중 하나를 골라야 한다. 둘 다 OSI 승인이 아니다.

AWS의 반응은 즉각적이었다. OpenSearch 포크 발표(2021년 4월). Elastic 7.10(마지막 Apache 라이선스 버전)을 기반으로 OpenSearch를 만들었고, Apache 2.0 라이선스를 유지한다. 같은 해 Amazon ES는 Amazon OpenSearch Service로 이름을 바꿨다.

2021–2024년: 평행 우주. 두 프로젝트는 따로 진화했다. Elasticsearch는 Elastic의 상용 기능을 빠르게 통합했고, OpenSearch는 AWS·Logz.io·Aiven 등이 컨소시엄으로 발전시켰다. 기능적으로는 비슷하지만 API와 클라이언트가 미묘하게 갈렸다. 어느 쪽으로든 마이그레이션은 "코드 약간 + 운영 노하우 많이" 변경을 요구했다.

2024년 8월: Elastic의 AGPL 복귀. Shay Banon이 직접 블로그에 "We are back open source"라고 썼다. Elasticsearch와 Kibana에 AGPL v3 옵션을 추가해서 SSPL/ELv2/AGPL 트라이얼 라이선스가 됐다. AGPL은 OSI 승인이라 이제 다시 "진짜 오픈소스"라고 말할 수 있다.

왜 돌아왔는가. Banon의 설명은 두 가지였다. (1) "AWS와의 관계가 좋아졌다" — Amazon OpenSearch Service가 정착했고, AWS가 더 이상 Elastic을 위협으로 보지 않는다. (2) "오픈소스 커뮤니티의 신뢰를 되찾고 싶다" — SSPL이 너무 많은 비판을 받았다.

2026년 현재의 풍경. Elasticsearch와 OpenSearch는 둘 다 살아남았다. AWS는 OpenSearch를 2024년 Linux Foundation에 기증해 OpenSearch Software Foundation을 만들었다. OpenSearch는 더 이상 "AWS의 것"이 아니라 진짜 LF 프로젝트다. Elasticsearch는 자체 SaaS(Elastic Cloud)와 셀프호스팅 라이선스로 매출을 만든다. 두 진영 모두 "이겼다"라고 말할 만한 상태다.

교훈. Elastic 사례는 "라이선스 변경은 단방향이 아니다"라는 것을 보여준다. 비-OSI로 갔다가 OSI로 돌아온 첫 큰 프로젝트다. 다만 그 사이 3년 동안 OpenSearch라는 진짜 포크가 자리잡았고, 그 포크는 사라지지 않는다.

4장 · HashiCorp 2023 BSL → IBM 인수 (2024) → OpenTofu (Terraform) + OpenBao (Vault)

HashiCorp는 Terraform·Vault·Consul·Nomad·Packer·Vagrant·Boundary·Waypoint 등 인프라 OSS 라인업으로 유명하다. 2014년 창업 후 거의 모든 도구가 MPL 2.0(Mozilla Public License) 또는 비슷한 OSI 승인 라이선스였다.

2023년 8월: BSL 전환. HashiCorp는 모든 주요 제품(Terraform·Vault·Consul·Nomad·Packer·Boundary·Waypoint)을 MPL 2.0에서 BSL v1.1로 옮겼다. Change Date는 4년, Change License는 MPL 2.0. 그동안은 "경쟁 제품으로 활용 금지" 조항이 있다.

이유는 명확했다. Spacelift, env0, Scalr 같은 회사들이 Terraform Cloud(HashiCorp의 SaaS)와 직접 경쟁하는 SaaS를 만들었다. HashiCorp 입장에서는 "우리가 만든 도구로 우리와 경쟁하는 게 부당하다"는 것이었다.

OpenTofu 포크(2023년 9월). BSL 발표 한 달 뒤, Spacelift·env0·Harness·Gruntwork·Scalr 등 Terraform 생태계 회사들이 모여 Terraform 포크를 발표했다. 처음 이름은 OpenTF였지만 곧 OpenTofu로 바뀌었다. 2024년 1월 Linux Foundation 산하 프로젝트로 정식 출범했고, Apache 2.0 라이선스를 유지한다.

OpenTofu는 빠르게 성장했다. 2024년 1.6 GA, 2024년 5월 1.7(state encryption 기능 추가 — 본가 Terraform에는 없는 기능), 2026년 현재 v1.10대까지 왔다. 본가 Terraform과 거의 호환되지만, 점차 독자 기능이 늘어나고 있다.

2024년 4월: IBM의 HashiCorp 인수 발표. IBM이 64억 달러에 HashiCorp를 인수한다고 발표했다. 2024년 말 EU·UK 규제 승인을 거쳐 2025년 2월 인수가 종료됐다. HashiCorp는 이제 IBM Red Hat 아래의 한 사업부다.

인수 후 HashiCorp의 라이선스 정책은 일관성을 유지했다. BSL 그대로 가져가고, 일부 제품은 IBM의 다른 라인(Red Hat OpenShift 등)과 통합되는 식이다. 일부 회의론자는 "IBM이 들어왔으니 다시 오픈소스로 돌아갈 거다"라고 봤지만 2026년 현재까지 그런 움직임은 없다.

OpenBao 포크(2024년 4월). Vault 포크는 OpenTofu보다 조금 늦게 나왔다. IBM 발표와 비슷한 시점에 Linux Foundation이 OpenBao 프로젝트를 발표했다. Mozilla Public License 2.0(Vault의 원래 라이선스)을 유지하며, GitLab·1Password·SUSE 등이 참여한다.

OpenBao는 OpenTofu만큼 빠르게 크지는 않았다. Vault는 사용 패턴이 더 복잡하고("HCP Vault" 같은 매니지드 서비스가 정착해 있어), 포크의 즉시적 가치가 덜 명확하다. 그래도 2025년 v2.0 릴리스로 정식 GA 됐다.

2026년 풍경. Terraform과 OpenTofu는 평행 진화 중이다. 작은 팀과 OSS 친화 조직은 OpenTofu로, 엔터프라이즈와 IBM/Red Hat 생태계에 있는 조직은 Terraform/HCP로 간다. Vault와 OpenBao도 비슷한 분기가 진행 중이다. 회사가 "어느 쪽을 쓸까"를 결정할 때, 라이선스 외에 "팀에 IBM 컨트랙트가 있는가, 1Password를 쓰는가" 같은 컨텍스트가 영향을 준다.

5장 · Redis 2024 SSPL+RSALv2 → Valkey (Linux Foundation)

Redis는 2009년 Salvatore Sanfilippo가 만든 인메모리 데이터스토어다. 라이선스는 BSD 3-Clause로 시작했고, 2010년대 후반에 Redis Labs(현 Redis, Inc.)가 회사를 만들어 상용화했다. 핵심 Redis는 계속 BSD였지만, 모듈(RediSearch·RedisGraph·RedisJSON·RedisTimeSeries 등)은 2018년부터 Redis Source Available License(RSAL)로 옮겼다.

2024년 3월: 핵심 Redis도 SSPL/RSALv2로. Redis는 Redis 7.4부터 BSD를 떠나 SSPLv1과 Redis Source Available License v2(RSALv2)의 듀얼 라이선스로 옮긴다고 발표했다. 핵심 모티베이션은 동일했다 — AWS ElastiCache·Google Memorystore·Azure Cache for Redis가 Redis 위에서 매니지드 서비스를 팔지만 Redis Inc는 직접 매출을 못 가져간다.

Valkey 포크(2024년 3월, 같은 주). 라이선스 발표 일주일도 안 되어 AWS·Google·Oracle·Ericsson·Snap 등이 Linux Foundation 산하 Valkey 프로젝트를 발표했다. Redis 7.2.4(마지막 BSD 버전)를 기반으로 BSD 3-Clause를 유지한다. Madelyn Olson(원래 Redis 코어 메인테이너 중 한 명, AWS 소속) 등이 핵심 메인테이너로 이동했다.

Valkey는 빠르게 자리잡았다. 2024년 4월 v7.2.5 (Redis와 호환), 2024년 9월 v8.0(독자 기능 시작 — 멀티스레드 I/O 개선), 2025년 v8.1, 2026년 5월 현재 v9.x까지 왔다. AWS ElastiCache for Valkey가 정식 출시됐고(2024년 10월), Google Memorystore도 Valkey 옵션을 추가했다(2025년).

Redis Inc의 응답. Redis는 Redis 7.4·8.0을 빠르게 릴리스했고, Vector Search·JSON 같은 모듈 기능을 핵심에 통합하며 차별화했다. 또 자체 SaaS인 Redis Cloud의 가격 정책을 단순화했다. 2025년 Redis는 또 한 번의 라이선스 조정을 했다 — Redis 8.0부터 AGPL v3을 추가 옵션으로 더해서 트라이얼 라이선스가 됐다(SSPLv1 / RSALv2 / AGPLv3). Elastic이 갔던 길과 비슷하다.

2026년 풍경. Redis vs Valkey는 가장 활발한 포크 경쟁 중 하나다. Valkey는 "진짜 OSS, 클라우드 회사 친화"로, Redis는 "더 빠른 새 기능 + 엔터프라이즈"로 포지셔닝한다. 작은 팀들이 Valkey로 옮기는 속도가 빠르다 — 코드 호환성이 거의 100%여서 마이그레이션 비용이 낮기 때문이다.

기술적 차이가 생기기 시작. Valkey 8.0의 멀티스레드 I/O는 단일 노드 처리량을 2–3배 끌어올렸다. Redis 8.0도 비슷한 기능을 넣었지만 구현이 다르다. 2026년 현재 양쪽이 "같은 프로토콜, 다른 내부"로 분기하는 중이다. 1–2년 후에는 라이브러리/툴이 한쪽만 지원하는 상황이 늘어날 것이다.

6장 · MongoDB 2018 SSPL — BSL의 원조

이 모든 이야기의 시작점은 MongoDB다. MongoDB는 2009년 10gen(현 MongoDB Inc)이 만든 도큐먼트 DB로, 처음에는 AGPL v3 라이선스였다. 2010년대 중반 AWS가 Amazon DocumentDB를 발표하기 전부터, MongoDB는 매니지드 호스팅 업체들과의 긴장을 가지고 있었다.

2018년 10월: SSPL 발표. MongoDB는 AGPL v3을 떠나 Server Side Public License v1(SSPL)로 옮긴다고 발표했다. SSPL은 AGPL v3을 기반으로 하지만, "서비스로 제공할 경우 그 서비스 전체 스택(관리 도구, 백업 도구, 모니터링, 인터페이스 등)을 SSPL로 공개해야 한다"라는 조항을 추가했다.

이 조항은 사실상 "AWS는 MongoDB를 매니지드로 팔지 마라"라는 의미였다. AWS가 ECS·EC2·IAM 코드를 SSPL로 공개할 리가 없으니까.

OSI의 SSPL 거부(2019). MongoDB는 SSPL을 OSI에 승인 요청했다가 철회했다. OSI는 "SSPL이 OSD #5, #6, #9를 위반한다"라고 명시했다. 이후 SSPL은 "오픈소스가 아닌 source-available 라이선스"로 분류된다.

Amazon DocumentDB 출시(2019년 1월). SSPL 발표 3개월 뒤 AWS는 Amazon DocumentDB를 출시했다. MongoDB API 호환이지만 실제로는 다른 엔진(Aurora 기반)이다. MongoDB는 "Mongo 호환을 우회한 클론"이라고 비판했지만, 코드를 직접 사용하지 않으면 라이선스 위반이 아니다.

MongoDB의 비즈니스 영향. 흥미롭게도 MongoDB 주가는 SSPL 발표 직후 떨어졌다가 빠르게 회복했고, 2020–2021년에 폭등했다. MongoDB Atlas(매니지드 서비스)가 빠르게 컸기 때문이다. 2026년 현재 MongoDB Atlas는 MongoDB 매출의 70% 이상을 차지하고, 회사의 시가총액은 200억 달러대다.

MongoDB 사례의 의미. MongoDB는 두 가지를 증명했다. (1) 라이선스를 바꿔도 회사는 살 수 있다. SSPL이 죽음의 키스가 아니었다. (2) 하지만 커뮤니티의 신뢰는 잃는다. MongoDB가 "오픈소스 회사"라고 자칭하는 것을 많은 개발자가 더 이상 받아들이지 않는다. GitHub에서 MongoDB에 PR을 보내는 외부 기여자가 SSPL 이후 급감했다.

이후의 모든 BSL 결정 — Elastic, HashiCorp, Redis, Sentry — 은 MongoDB의 선례를 참고했다. "MongoDB가 했으니 우리도 할 수 있다"는 심리적 장벽 제거 효과가 컸다.

7장 · Sentry 2024 FSL (Functional Source License)

Sentry는 2008년 시작된 에러 트래킹 도구다. 오랫동안 BSL 3-Clause로 배포했고, 2019년 Business Source License로 한 번 옮긴 적이 있다. 2024년에는 자체 정의한 FSL(Functional Source License)을 발표하며 또 한 번 라이선스 논쟁의 중심에 섰다.

FSL의 정의. Functional Source License는 다음 두 가지 핵심 조항을 가진다.

  1. Non-compete 기간: 발표일부터 2년 동안 "Sentry의 경쟁 제품을 만들기 위해" 이 코드를 쓸 수 없다. "내부 사용", "임베드", "수정 후 자기 회사에서 사용"은 모두 OK.
  2. 자동 OSS 전환: 2년 후 코드는 자동으로 Apache 2.0(또는 MIT, 선택)으로 전환된다. 그래서 어떤 코드라도 "현재의 2년 전 버전"은 진짜 오픈소스다.

왜 FSL을 만들었는가. Sentry CEO David Cramer는 블로그에서 이렇게 썼다. "BSL은 너무 모호하고 SSPL은 너무 강하다. 우리가 원하는 것은 단순하다 — 경쟁자가 우리 코드로 우리와 경쟁하는 것을 막되, 2년 후에는 풀어주는 것이다."

FSL은 BSL과 비교해 두 가지가 다르다. (a) non-compete 기간이 더 짧다 — BSL은 4년, FSL은 2년. (b) production 사용은 처음부터 OK — BSL은 production 사용 자체를 제한하지만, FSL은 "경쟁 제품으로의 사용"만 막는다.

Fair Source 운동. Sentry는 FSL을 "Fair Source"라는 더 큰 운동의 일부로 포지셔닝했다. fair.io 사이트를 만들고, FSL을 채택한 회사 목록을 관리한다. 2025년 현재 30여 개 회사가 FSL을 채택했다 — PowerSync, GitButler, Keygen, Bytebase 등.

OSI의 입장. OSI는 FSL도 OSD에 부합하지 않는다고 봤다(역시 차별 금지 조항). 그래서 FSL은 "source-available 라이선스" 카테고리에 들어간다. 하지만 "2년 후 자동 OSS 전환"이라는 메커니즘 자체는 OSI도 긍정적으로 평가했다.

2026년 현재. Sentry는 FSL을 적극적으로 알리는 중이다. fair.io의 매뉴얼·템플릿 라이선스를 사용해 새 OSS 프로젝트가 처음부터 FSL로 시작하는 경우가 늘었다. 다만 큰 인프라 OSS(데이터베이스·메시지큐 등)는 여전히 BSL/SSPL을 선호한다 — FSL이 2년 후 자동 전환되는 것이 회사 입장에서는 부담스럽다.

평가. FSL은 "BSL의 부드러운 버전" 또는 "Apache로 가는 시간차 라이선스"로 볼 수 있다. 작은 OSS 회사에게는 합리적인 절충안이지만, 큰 인프라에서는 채택이 느리다.

8장 · Cockroach Labs 2024 변경

CockroachDB는 분산 SQL 데이터베이스로, 2015년 Cockroach Labs가 시작했다. 처음에는 Apache 2.0이었다가 2019년에 BSL 1.1로 옮겼다(Change Date 3년, Change License Apache 2.0). 핵심 코어는 BSL, 엔터프라이즈 기능은 별도 commercial 라이선스였다.

2024년 8월: CockroachDB Community License로 전환. Cockroach Labs는 CockroachDB v24.3부터 BSL을 떠나 자체 정의한 "CockroachDB Community License"(CCL)로 옮긴다고 발표했다. 핵심 변화는 두 가지다.

  1. 무료 사용 한도가 줄었다. "non-production"이거나 "annual revenue 1천만 달러 미만 회사"에서만 무료 사용 가능. 그 이상은 commercial 라이선스가 필요하다.
  2. 모든 기능이 한 라이선스 안에. 이전에는 "OSS 코어 + 엔터프라이즈"였는데, 이제는 한 패키지에 다 들어있고 라이선스가 사용 컨텍스트로 갈린다.

커뮤니티 반응. Cockroach Labs의 변경은 다른 BSL 사례보다 더 강한 반응을 일으켰다. "사실상 commercial 소프트웨어를 무료 체험판처럼 푸는 것"이라는 비판이 있었다. 작은 스타트업이 한도를 넘기는 순간 갑자기 비싼 라이선스를 사야 하는 구조이기 때문이다.

포크가 일어났는가. 흥미롭게도 CockroachDB 포크는 큰 규모로 일어나지 않았다. 이유는 두 가지다. (1) 분산 SQL은 운영 복잡도가 너무 높다. Redis·Terraform 포크는 운영팀이 직접 운영할 수 있지만, CockroachDB 같은 분산 시스템을 포크해서 유지하려면 핵심 엔지니어 10명 이상이 필요하다. (2) 대안이 이미 있다. YugabyteDB가 비슷한 분산 SQL을 Apache 2.0으로 제공하고 있어, 굳이 포크하지 않아도 마이그레이션 옵션이 있다.

2026년 현재. CockroachDB는 commercial 매출에 집중하며 큰 엔터프라이즈 고객으로 가고 있다. 작은 팀들은 Postgres + Citus, YugabyteDB, TiDB 같은 대안으로 이동하고 있다. Cockroach Labs는 라이선스 변경의 "포크 면역" 사례지만, 동시에 "커뮤니티 위축" 사례이기도 하다.

9장 · n8n Sustainable Use License — Fair Source 운동의 또 다른 갈래

n8n은 워크플로우 자동화 도구로, 2019년 독일에서 시작됐다. Zapier·Make의 셀프호스팅 대안으로 자리잡았다. 라이선스가 흥미로운 것은 처음부터 "non-OSI" 라이선스를 자체 정의해서 썼기 때문이다.

Sustainable Use License의 핵심. n8n의 라이선스는 다음을 허용한다.

  • 내부 사용: 회사 내부의 워크플로우 자동화 무료.
  • 임베드: n8n을 자기 제품 안에 내장해서 사용 — 단 "n8n을 호스팅 서비스로 재판매"는 금지.
  • 수정·기여: 코드 수정과 PR 환영.

금지하는 것은 단 하나 — "n8n을 매니지드 SaaS로 팔지 마라". n8n Inc가 직접 운영하는 n8n Cloud와 경쟁하지 말라는 것이다.

왜 SUL인가. n8n CEO Jan Oberhauser는 "MIT나 Apache로 가면 Zapier가 우리 코드를 가져다가 Zapier 안에 넣을 거다. AGPL로 가면 같은 일이 일어나도 코드 공개 의무가 있어 우리에게 약간의 보호가 되지만, 사용자 입장에서는 너무 강력하다. 그 중간이 필요했다"라고 설명했다.

Fair Source 운동의 일원. n8n은 Sentry의 fair.io 운동에 동참한다. SUL은 FSL과 다르지만 정신은 비슷하다 — "우리가 만든 도구를 우리가 어떻게 monetize 할지 통제할 수 있는 라이선스, 하지만 사용자에게는 최대한 자유를 줘라."

2026년 현재. n8n은 빠르게 성장 중이다. 2025년 시리즈 B 펀딩(약 7천만 달러, Highland Europe 등)을 받았고, AI 워크플로우 자동화 분야에서 Zapier·Make와 본격 경쟁 중이다. SUL 라이선스는 "오픈소스가 아닌" 것에 대한 불만이 일부 있지만, n8n의 셀프호스팅 사용자 베이스는 계속 증가하고 있다.

Fair Source의 다른 사례. PowerSync (DB sync), GitButler (Git GUI), Keygen (라이선스 관리), Bytebase (DB DevOps) — 모두 fair.io의 회원으로 SUL 또는 FSL을 채택했다. 작은 OSS 회사들이 처음부터 commercial-friendly source-available로 시작하는 경향이 강해지고 있다.

10장 · AWS "strip-mining" 내러티브 — 어디까지 진실인가

지난 8년의 BSL 물결을 설명하는 가장 흔한 단어는 "strip-mining"이다. "AWS가 OSS의 가치를 '광산처럼 파먹고' 자체 매니지드 서비스로 판다"라는 표현이다. MongoDB·Elastic·HashiCorp·Redis가 모두 이 내러티브를 명시적으로 또는 암시적으로 라이선스 변경 정당화에 사용했다.

얼마나 진실인가. 부분적으로 진실이지만, 단순화된 면도 있다.

진실인 부분:

  • AWS는 OSS를 가져와 매니지드로 파는 패턴을 반복했다. Amazon ES (2015) → MongoDB API 클론 DocumentDB (2019) → MemoryDB (Redis 호환, 2021).
  • AWS의 OSS 매니지드 서비스 매출은 수십억 달러대다. OSS를 만든 회사들의 매출과 직접 비교하면 차이가 크다.
  • AWS가 OSS 프로젝트에 코드 기여를 하는 비율은 (예전 기준으로) 매우 낮았다. "받기만 하고 주지 않는다"라는 비판이 있었다.

단순화된 부분:

  • AWS가 OSS 회사의 직접 매출을 빼앗았다는 단순한 모델은 부정확하다. AWS 매니지드 서비스는 OSS 인지도를 키우는 효과도 있다. Elasticsearch의 전 세계 사용자 베이스는 AWS Elasticsearch Service 덕에 폭발적으로 컸다.
  • 2020년 이후 AWS의 OSS 기여는 늘었다. Valkey·OpenSearch·OpenTelemetry·Karpenter·Bottlerocket·Firecracker 등이 모두 AWS가 만들거나 주도하는 OSS다.
  • "AWS가 우리 매출을 빼앗는다"라는 인식은 종종 "우리가 enterprise sales를 못해서 매출이 정체한다"의 대체 설명이기도 하다. AWS는 enterprise 고객을 매니지드로 가져가지만, 매니지드를 안 쓰는 회사는 OSS 회사의 enterprise 라이선스를 살 가능성이 더 높다.

클라우드 3사 비교.

클라우드OSS 매니지드 전략OSS 기여
AWS"OSS 가져다 매니지드로" — Elasticsearch, MongoDB API, Redis, PostgresOpenSearch·Valkey·Karpenter·Firecracker 주도. 2020년 이후 적극적.
Google Cloud"OSS 매니지드 + 주요 기여자" — BigQuery, Spanner, Anthos, KnativeTensorFlow·Kubernetes·gRPC·Istio·Go 주도. 가장 적극적.
Microsoft Azure"OSS 매니지드 + GitHub 보유" — Azure DB for PostgreSQL/MySQL, Azure Cache for RedisVSCode·TypeScript·.NET 오픈소스화. GitHub 자체 운영.

GCP의 OSS 기여가 가장 강하다는 평가가 일반적이고, AWS는 2020년 이후 빠르게 따라잡는 중이다. "AWS가 strip-mining만 한다"라는 단순한 그림은 2026년 기준으로는 더 이상 정확하지 않다.

그래도 남는 진실. 매니지드 서비스 매출의 대부분은 클라우드 3사가 가져간다. OSS를 만든 회사들은 "Open Core" 모델로 매출을 만들지만 한계가 있다. 그 격차가 BSL 물결의 근본 동력이다.

11장 · OSI 정의의 미래 — 어떻게 진화하나

OSI 정의(OSD)는 1998년 만들어진 이후 거의 변하지 않았다. 2026년 현재, 정의를 바꿔야 한다는 압력이 여러 방향에서 온다.

압력의 방향 1: source-available의 인정. "BSL·FSL 같은 라이선스도 어떤 형태로든 OSI가 인정해야 한다"라는 압력. 이유는 "현실(클라우드 매니지드 위협)에 적응해야 한다"는 것이다. 하지만 OSI는 일관되게 "오픈소스의 정의는 사용 자유를 제한하지 않는 것"이라고 답한다.

압력의 방향 2: OSAID (Open Source AI Definition). 2024년 OSI는 AI 모델에 대한 "Open Source AI Definition" v1.0을 발표했다. 코드뿐 아니라 학습 데이터·가중치·과정에 대한 공개 기준을 정의한다. Meta의 Llama는 가중치는 풀지만 학습 데이터를 안 풀어서 OSAID에 부합하지 않는다 — Meta가 "open weights"는 맞지만 "open source"는 아니라고 OSI가 명시했다.

이 결정은 큰 논쟁을 일으켰다. Meta는 "사실상 open이라고 봐도 된다"라는 입장, OSI는 "open source라는 단어를 함부로 쓰지 마라"라는 입장. 2026년 현재 OSAID v1.0이 정착했지만, "Meta의 Llama를 어떻게 부를까"는 여전히 불명확하다.

압력의 방향 3: 비-소프트웨어로의 확장. Creative Commons·Open Data 같은 다른 영역과의 협력. OSI가 소프트웨어 외 영역(데이터, 모델, 콘텐츠)으로 영향력을 넓히는 중이다.

OSI 자체의 변화. OSI는 2023–2025년 사이 리더십과 거버넌스가 크게 변했다. Stefano Maffulli가 의장으로 임명되고, 정책 결정을 더 투명하게 하기 위한 board 개편이 있었다. 자금원도 다양해졌다(GitHub·Bloomberg·Sloan Foundation 등의 후원).

OSI 정의가 망가졌다는 비판. 일부는 "OSI 정의가 클라우드 시대에 맞지 않는다"라고 본다. 하지만 OSI 정의가 바뀌면 그 정의가 더 약해지고, "오픈소스"라는 단어 자체가 모호해진다. 그래서 OSI는 정의를 지키는 쪽을 선택했고, 새 카테고리(예: OSAID for AI)를 만들어 시대 변화에 대응한다.

2026년의 균형. OSI 정의는 그대로 살아남았다. BSL·SSPL·FSL은 source-available 카테고리에 자리 잡았다. 두 진영은 평행 우주처럼 공존한다. 신규 OSS 프로젝트가 시작할 때 "MIT/Apache로 갈까, BSL/FSL로 갈까"를 선택하는 게 표준 흐름이 됐다.

12장 · 한국 / 일본 기업의 입장 — 카카오, 네이버, NTT, 楽天

한국·일본 기업의 BSL 물결에 대한 반응은 미국 기업과 다르다.

한국: 카카오의 fork-friendly 정책. 카카오는 OSS 사용에 대해 "사용 시 fork 가능한 라이선스 선호" 정책을 명시적으로 가지고 있다. 카카오 엔터프라이즈, 카카오뱅크, 카카오페이 모두 새 인프라 선택 시 "BSL/SSPL은 가급적 피하고, fork된 OSI 라이선스 버전이 있다면 그쪽 선호"라는 가이드라인이 있다.

실제로 카카오는 Redis 라이선스 변경 후 Valkey로 빠르게 검토를 옮겼고, 2025년부터 일부 서비스가 Valkey로 마이그레이션됐다. OpenTofu는 카카오 클라우드 내부 인프라 자동화에 사용되며, ElasticSearch는 OpenSearch와 병행 운영한다.

한국: 네이버 D2의 균형 잡힌 stance. 네이버는 D2(개발자 커뮤니티 브랜드)를 통해 OSS 활동을 한다. BSL 라이선스에 대한 입장은 "장기적으로는 OSI 라이선스를 선호하지만, 단기적으로는 비즈니스 필요에 따라 BSL도 사용 가능"이라는 실용적 stance다.

네이버 클라우드는 ElasticSearch 매니지드와 OpenSearch 매니지드를 둘 다 제공한다. 사용자가 선택하게 한다. Naver Pay·Naver Search 같은 내부 시스템은 사용 빈도가 가장 높은 도구를 라이선스 영향과 함께 정기 리뷰한다.

일본: NTT의 보수적 stance. NTT 그룹(NTT Communications, NTT Data 등)은 OSS 라이선스에 대해 매우 보수적이다. BSL/SSPL을 production에 쓰기 전에 법무 검토가 길게 들어가고, 가능하면 OSI 승인 라이선스 또는 commercial license를 명시적으로 산다.

NTT Data는 HashiCorp 인수 후에도 Terraform Enterprise를 정식 라이선스로 계속 쓴다. Elastic은 Elastic Cloud의 enterprise contract로 사용한다. 일본 대기업의 "법무 리스크 회피" 문화가 OSS 라이선스 선택에 강한 영향을 준다.

일본: 楽天(Rakuten)의 멀티클라우드 stance. Rakuten은 자체 클라우드(Rakuten Cloud)와 AWS를 병행 운영한다. OSS 라이선스에 대해서는 비교적 열린 stance — OSI 라이선스를 선호하지만 BSL도 비즈니스 필요에 따라 채택한다. Rakuten Mobile은 OpenStack·Kubernetes 등 OSI 라이선스 인프라를 깊게 쓴다.

한국·일본 공통 패턴. (1) 매니지드 서비스 선호도가 높다. 라이선스 복잡성을 회사가 안고 가기보다 클라우드 회사에 맡기는 경향. (2) 법무 검토 사이클이 길어서 라이선스 변경에 대한 반응이 미국보다 느리다. (3) 포크된 OSI 라이선스 버전(OpenSearch·Valkey·OpenTofu)에 대한 신뢰가 빠르게 올라가는 중이다.

13장 · 라이선스가 바뀐 OSS를 쓰고 있다면 — 마이그레이션 전략

여러분 회사가 Elasticsearch·Terraform·Redis·MongoDB를 쓰고 있고, 라이선스 변경 영향이 걱정된다면 무엇을 해야 하는가. 4단계 프레임을 제시한다.

1단계: 영향 평가. 다음 질문에 답한다.

  • 우리가 사용하는 버전이 OSI 라이선스인가, source-available인가? (예: Elasticsearch 7.10까지는 Apache, 7.11부터는 SSPL/ELv2)
  • 우리 사용 방식이 라이선스 위반 가능성이 있는가? (예: 우리가 만든 SaaS 안에 임베드해서 매출을 내는가?)
  • 우리가 매니지드 서비스를 쓰는가, 셀프호스팅인가? (매니지드는 라이선스 부담을 클라우드가 진다.)

2단계: 옵션 식별. 다음 옵션을 비교한다.

옵션비용마이그레이션 부담장기 리스크
유지 + commercial 라이선스 구매라이선스 비용낮음회사 종속
포크된 OSS로 마이그레이션 (OpenSearch·Valkey·OpenTofu)인프라 운영 비용중간포크 활성도에 의존
매니지드 서비스로 전환 (AWS·GCP·Azure)매니지드 비용중간클라우드 종속
완전 다른 OSS로 교체 (예: Redis → KeyDB/DragonflyDB)마이그레이션높음새 OSS의 안정성

3단계: 시범 적용. 회사에서 가장 영향이 적은 환경(staging, 비핵심 서비스)에 대안을 1–3개월 운영한다. 성능·운영성·팀 학습 곡선을 측정한다.

4단계: 단계적 롤아웃. 시범에서 통과한 옵션을 사용량 적은 서비스부터 옮긴다. 핵심 서비스는 마지막에 옮긴다. 마이그레이션은 데이터 이전 + 모니터링 + 백업 검증의 3단계로 한다.

구체적 마이그레이션 케이스.

  • Elasticsearch → OpenSearch. API 호환성이 90% 이상이다. 7.10 이하라면 거의 무중단 가능. 8.x로 가려면 마이그레이션 도구(OpenSearch Migration Assistant)를 쓴다.
  • Terraform → OpenTofu. 1.6 이하 .tf 파일은 거의 호환. provider/module 호환성 확인 필요. CI/CD에서 terraform 바이너리를 tofu로 교체하는 정도.
  • Redis → Valkey. v7.2.4까지는 100% 호환. v8.0 이후는 새 기능 사용 여부에 따라 다름. 클라이언트 라이브러리는 거의 모두 호환.
  • Vault → OpenBao. 데이터 마이그레이션 도구(Vault → OpenBao migrator)가 있지만 안정성이 OpenTofu만큼은 아직. 작은 secret 백엔드부터 시도.
  • HashiCorp Vault Enterprise → 1Password Secrets Automation 또는 AWS Secrets Manager. 라이선스 + 운영 부담을 한 번에 줄이는 방법.

잘 마이그레이션한 회사 사례. GitLab은 Vault에서 OpenBao로 일찍 옮긴 큰 사례 중 하나다. 1Password는 처음부터 OpenBao와 정식 파트너십을 맺어 통합을 강화했다. AWS·Google·Snap은 Valkey 발표부터 적극적으로 채택해 자체 인프라를 옮겼다.

14장 · 우리 회사가 라이선스를 바꿔야 한다면 — 의사결정 가이드

반대 시나리오 — 여러분 회사가 OSS를 만들고 있고 매출이 정체된다면? "라이선스를 바꿔야 할까"를 어떻게 결정하는가.

먼저 답할 5가지 질문.

  1. 우리 매출 정체의 원인이 정말 라이선스 때문인가? AWS가 진짜로 매출을 빼앗는가, 아니면 enterprise sales 인프라가 부족한가? 마케팅이 부족한가? 매출 정체의 진짜 원인을 진단하지 않으면 라이선스 변경이 약효가 없다.

  2. 포크가 일어날 가능성은? 우리 OSS의 운영 복잡도가 어느 정도인가? Redis·Terraform 정도는 쉽게 포크된다. CockroachDB·MongoDB 정도면 포크가 어렵다. Kafka·Elasticsearch는 중간.

  3. 커뮤니티 신뢰 손실을 감당할 수 있는가? 외부 PR이 급감할 가능성, GitHub 스타 증가 둔화, "오픈소스 회사" 브랜드 약화 — 이 비용을 회사 매출 증가가 상쇄할 수 있는가?

  4. 어떤 라이선스로 갈 것인가? BSL(4년 후 Apache), SSPL(엄격), FSL(2년 후 Apache), Sustainable Use License(자유 + non-compete) — 각각 다른 트레이드오프.

  5. 마이그레이션 경로를 어떻게 제공할 것인가? 기존 사용자가 새 라이선스를 거부할 경우 어떻게 할 것인가? 마지막 OSS 버전을 유지보수 모드로 둘 것인가, 아니면 완전히 끊을 것인가?

의사결정 매트릭스.

상황권장 라이선스
작은 OSS, 셀프호스팅 사용 많고 매니지드는 적음OSI 라이선스 유지 (MIT/Apache/AGPL)
중간 OSS, 클라우드 매니지드가 매출 위협AGPL 또는 FSL 시도
큰 OSS, 명확한 cloud-provider 위협BSL (HashiCorp 모델) 또는 SSPL (MongoDB 모델)
SaaS 본업 + 셀프호스팅도 일부 제공Sustainable Use License (n8n 모델)
AI/모델 영역OSAID 부합 라이선스 또는 자체 정의

커뮤니케이션이 중요하다. 라이선스 변경의 성공/실패는 변경 자체보다 커뮤니케이션에서 갈린다. Elastic의 SSPL 발표는 갑작스러웠고 외부 비판이 컸다. 반면 Redis는 사전에 커뮤니티에 영향 가능성을 알렸고 일부 모듈 라이선스를 미리 정리해뒀다(완벽하지는 않았지만 더 부드러웠다).

라이선스 변경 전에 다른 옵션도 시도하라. (a) Open Core 모델 강화 (엔터프라이즈 기능을 commercial로 분리), (b) 매니지드 서비스 자체 출시 (Elastic Cloud, MongoDB Atlas, Redis Cloud), (c) 클라우드 회사와 파트너십 (Snowflake와 dbt Labs의 관계 같은), (d) consortium 결성 (CNCF·LF 등). 라이선스 변경은 최후의 수단이어야 한다.

되돌릴 수 있는 결정인가. Elastic은 3년 만에 AGPL로 돌아왔다. Redis도 2025년 AGPL 추가 옵션으로 부분 복귀했다. 라이선스 변경은 영구적이지 않지만, 변경했다가 되돌리는 과정의 신뢰 손실은 영구적일 수 있다.

에필로그 — 2026년의 결론, 그리고 다음 7년

2026년 5월 현재, "오픈소스란 무엇인가"에 대한 답이 명확하지 않다. OSI 정의는 살아 있지만 일부 큰 OSS 회사들은 그 정의 밖에 있다. AWS·구글·MS는 OSS의 가장 큰 소비자이자 점점 가장 큰 기여자가 되어가고 있다. 한국·일본 기업들은 그 사이에서 실용적 균형을 잡고 있다.

지난 7년의 BSL 물결이 보여준 것은 세 가지다.

  1. 라이선스는 비즈니스 모델이다. 기술적 결정이라기보다 비즈니스 결정이다. 그래서 회사의 매출 구조가 바뀌면 라이선스도 바뀐다(Elastic의 AGPL 복귀처럼).

  2. 포크는 항상 일어난다. 운영 복잡도가 너무 높지 않은 OSS는 라이선스를 바꾸면 포크된다. Linux Foundation이 그 포크의 인큐베이터 역할을 하며, 클라우드 회사들이 자금과 인력을 댄다.

  3. 커뮤니티의 신뢰는 다시 사기 어렵다. SSPL/BSL로 갔다가 돌아온 회사도, 외부 기여자의 신뢰를 100% 되찾기는 어렵다. 그래서 라이선스 결정은 신중해야 한다.

다음 7년에 일어날 것. 추측 몇 가지.

  • AI 모델 라이선스가 주류 이슈가 된다. OSAID, Llama 라이선스, 모델 가중치 공개 — 우리가 "오픈소스 모델"이라고 부를 때 정확히 무엇을 말하는지가 더 중요해진다.
  • 클라우드 회사의 OSS 기여가 더 커진다. AWS·GCP·Azure가 자체 OSS(Karpenter·Knative·OpenTelemetry)에 더 투자하면서, "OSS 회사 vs 클라우드"의 단순한 대립 구도가 약해진다.
  • Source-available 카테고리가 성숙한다. FSL·SUL 같은 라이선스가 표준화되며, 신규 OSS 회사가 처음부터 source-available로 시작하는 비율이 늘어난다.
  • OSI 정의는 살아남는다. 하지만 새 카테고리(OSAID, Open Data 등)를 만들며 진화한다.

이 글이 여러분 회사가 다음 라이선스 결정을 할 때(쓰는 쪽이든 만드는 쪽이든) 작은 도움이 되길 바란다. 오픈소스의 다음 챕터는 여전히 우리 모두가 쓰고 있다.

참고 / References

Discuss on Twitter • View on GitHub