coredot.today
오픈소스 듀얼 라이센싱 전략: 무료의 역설과 생존의 기술
블로그로 돌아가기
오픈소스듀얼 라이센싱SSPLBSLFair Source소프트웨어 라이센스

오픈소스 듀얼 라이센싱 전략: 무료의 역설과 생존의 기술

MySQL에서 시작된 듀얼 라이센싱, MongoDB의 SSPL 충격, HashiCorp의 BSL 전환, 그리고 Elastic과 Redis의 U턴까지. 오픈소스 생태계의 8년간 라이센스 전쟁을 사례 중심으로 완전 해부한다. 2026년, 오픈소스의 지속가능성을 둘러싼 핵심 논쟁과 실무 전략.

코어닷투데이2026-04-0449

들어가며: XKCD가 그린 불편한 진실

2020년, XKCD 만화 #2347 "Dependency"는 IT 업계의 불편한 진실을 한 컷으로 포착했다. 거대한 디지털 인프라가 "네브래스카에 사는 어떤 사람이 2003년부터 감사도 없이 유지보수하는" 작은 프로젝트 위에 아슬아슬하게 서 있는 그림이다.

이 만화는 농담이 아니었다.

2024년 XZ Utils 백도어 사건은 이를 현실로 증명했다. Linux의 핵심 압축 라이브러리인 XZ의 유일한 메인테이너 Lasse Collin이 번아웃에 시달리던 틈을 타, 악의적인 공격자가 2년에 걸쳐 신뢰를 쌓은 뒤 백도어를 심었다. 전 세계 서버 인프라가 한 명의 지친 자원봉사자에게 의존하고 있었던 것이다.

2024년 Tidelift 보고서의 숫자는 더 충격적이다:

무급 메인테이너
60%
번아웃으로 이탈 (고려 포함)
60%
번아웃이 이탈 주원인
44%
GitHub Sponsors 참여 기업
0.0014%
4,200 / 3억 기업

3억 개 기업이 오픈소스를 사용하지만, 후원에 참여하는 기업은 4,200개에 불과하다. 이 구조적 모순 — 모두가 쓰지만 아무도 내지 않는 — 이것이 듀얼 라이센싱이 탄생한 배경이다.


제1장: 라이센스의 기초 — 이것만 알면 된다

오픈소스 라이센싱을 이해하려면, 먼저 세 가지 축을 알아야 한다.

1.1 허용적(Permissive) vs. 카피레프트(Copyleft)

구분허용적 (Permissive)카피레프트 (Copyleft)
핵심 원칙"자유롭게 써라""파생물도 공개해라"
대표 라이센스MIT, Apache 2.0, BSDGPL, LGPL, AGPL
상용 제품에 포함제한 없음소스 공개 의무
SaaS 제공제한 없음GPL: 가능 / AGPL: 소스 공개
채택 비율 (2026)~70%~30%

RedMonk의 Stephen O'Grady에 따르면, 업계는 2014~2017년 사이 카피레프트 다수에서 허용적 라이센스 다수로 전환점을 넘었다. 2026년 현재, 허용적 라이센스가 압도적 주류다.

1.2 "오픈소스"의 법적 정의

OSI(Open Source Initiative)가 인정하는 오픈소스의 핵심 조건:

  1. 자유로운 재배포 — 누구에게나
  2. 소스코드 접근 — 반드시 포함
  3. 파생물 허용 — 수정·배포 가능
  4. 차별 금지 — 특정 분야나 사용자를 배제하지 않음

4번이 핵심이다. "SaaS로 제공하면 안 된다"는 조건이 붙는 순간, 그것은 OSI 기준의 오픈소스가 아니다. 이것이 SSPL과 BSL이 "Source-Available(소스 공개형)"이라 불리는 이유다.

1.3 듀얼 라이센싱이란

하나의 소프트웨어를 두 가지 라이센스로 동시에 제공하는 전략이다:

동일한 소프트웨어
라이센스 A (오픈소스)
GPL, AGPL 등
무료 · 소스 공개 의무
라이센스 B (상용)
프로프라이어터리
유료 · 소스 공개 면제

원리는 단순하다: GPL 의무사항(소스 공개)을 지키기 싫다면, 돈을 내고 상용 라이센스를 사라. 이렇게 하면 오픈소스의 확산 효과와 상용 수익을 동시에 얻을 수 있다.


제2장: 듀얼 라이센싱의 기원

2.0 Sleepycat Software: 최초의 발명

듀얼 라이센싱의 진정한 기원은 1996년으로 거슬러 올라간다. Berkeley DB의 원저자 중 한 명인 Keith BosticSleepycat Software를 설립하면서, 하나의 소프트웨어를 자유 소프트웨어 라이센스와 상용 라이센스 두 가지로 동시에 제공하는 모델을 최초로 만들었다. Bostic은 FSF(자유 소프트웨어 재단)가 수용할 수 있는 라이센스를 직접 설계하는 데 상당한 시간을 투자했다.

원리는 단순했다: 자기 소프트웨어를 오픈소스로 공개하고 싶지 않은 기업은 Sleepycat에 비용을 지불하고 상용 라이센스를 구매하면 된다.

2.1 MySQL AB: 듀얼 라이센싱의 교과서

1995년 설립된 스웨덴의 MySQL AB는 Sleepycat의 모델을 가장 성공적으로 확장했다.

  • 커뮤니티 버전: GPL 라이센스. 누구나 무료로 사용, 수정, 배포 가능. 단, 파생물도 GPL로 공개해야 함
  • 상용 버전: 프로프라이어터리 라이센스. 자사 제품에 MySQL을 내장(embed)하면서 소스를 공개하고 싶지 않은 기업용

핵심 인사이트는 "GPL의 '전염성'을 지렛대로 활용한 것"이다. 기업이 MySQL을 자사 상용 제품에 포함하려면, GPL에 따라 전체 소스코드를 공개하거나, 상용 라이센스를 구매해야 했다. 대부분의 기업은 후자를 택했다.

MySQL의 성장 궤적은 이 모델의 위력을 증명한다:

2001
$6.5M
2003
$12M
2006
$50M
2007
$75M

CEO Marten Mickos는 MySQL을 "2세대 오픈소스 기업"이라 불렀다. 그의 핵심 통찰: 1,000명의 사용자 중 100명이 코드에 기여하고, 단 1명이 비용을 지불한다. 그리고 그 1명의 비용이 나머지 999명을 지탱한다.

Mikko Välimäki의 2003년 논문 "Dual Licensing in Open Source Software Industry"는 이 모델을 학술적으로 분석한 최초의 연구 중 하나다. 그는 MySQL AB, Sleepycat Software, Trolltech를 사례로 들며 듀얼 라이센싱이 오픈소스 기업의 가장 성공적인 비즈니스 모델이라고 결론 내렸다.

MySQL AB의 여정:

  • 2008년: Sun Microsystems가 약 10억 달러에 인수
  • 2010년: Oracle이 Sun을 인수하면서 MySQL도 함께 넘어감
  • EU 집행위원회가 Oracle의 MySQL 독점을 우려해 수개월간 인수를 지연
  • Oracle은 최소 2015년까지 듀얼 라이센싱 유지, MySQL 개발 자원 보장 등을 약속

공동 창업자 Michael "Monty" Widenius는 Oracle 인수에 반대하며 MySQL을 포크해 MariaDB를 만들었다. 이것은 이후 반복될 패턴 — 라이센스 변경 → 커뮤니티 포크 — 의 시작이었다.

"오픈소스는 비즈니스 모델이 아니다. 오픈소스는 배포 모델이자 소프트웨어 개발 모델이다." — Marten Mickos, MySQL AB CEO

2.2 Qt (Trolltech): 한 번의 위기가 만든 전환점

1991년, 노르웨이 Trolltech가 개발한 Qt는 처음에 독자적인 "Qt Free Edition License"로 배포되었다. 자유 소프트웨어 진영에서 문제가 터졌다.

1998년, KDE 데스크톱 환경이 Qt에 의존한다는 이유로 큰 논란이 벌어졌다. Qt가 진정한 자유 소프트웨어 라이센스를 사용하지 않았기 때문이다. 이 압력에 Trolltech는 Qt를 GPL + 상용 듀얼 라이센싱으로 전환했다.

이후 Qt는 Nokia에 인수(2008년), 다시 Digia에 넘어갔고, 현재까지 LGPL/GPL + 상용 라이센스 듀얼 라이센싱을 유지하고 있다. 30년 이상 지속된, 가장 오래된 듀얼 라이센싱 모델 중 하나다.


제3장: 클라우드의 역습 — "무임승차" 문제

3.1 문제의 핵심

2010년대 중반, 클라우드 시장이 폭발적으로 성장하면서 새로운 긴장이 생겼다:

문제
AWS, Azure, GCP 같은 클라우드 대기업이 오픈소스 프로젝트를 그대로 가져다 매니지드 서비스(SaaS)로 제공. 원저작자에게 코드 기여도, 수익 공유도 없음
🔍
배경
기존 허용적 라이센스(Apache 2.0, BSD)는 SaaS를 전혀 규제하지 않음. GPL조차 "네트워크를 통한 서비스 제공"을 배포로 보지 않아 소스 공개 의무가 발생하지 않음 (AGPL은 예외)
💥
결과
오픈소스 기업들이 수년간 개발한 소프트웨어를, 막대한 인프라와 영업력을 가진 클라우드 대기업이 더 잘 팔고 더 많이 벌어감. 원개발사는 R&D 비용만 쌓이고 수익은 빠져나감

3.2 대표 사례: MongoDB vs. AWS

MongoDB는 가장 극적인 사례다:

  1. MongoDB는 오픈소스(AGPL)로 시작해 NoSQL 시장을 개척
  2. MongoDB Atlas(자체 클라우드 서비스)를 출시해 수익화 시도
  3. AWS가 DocumentDB를 출시 — MongoDB 프로토콜과 호환되는 독자 서비스
  4. Azure Cosmos DB, Oracle도 MongoDB 호환 API 제공 시작
  5. MongoDB의 핵심 경쟁력인 "MongoDB 사용법을 아는 개발자 생태계"를 클라우드 대기업이 무임승차

MongoDB CEO Dev Ittycheria는 이를 "기생(parasitic)" 관계라고 표현했다. 개발 비용은 MongoDB가 지불하고, 수확은 클라우드 대기업이 가져간다.


제4장: 라이센스 전쟁의 연대기 (2018~2026)

2018년부터 시작된 대규모 라이센스 변경의 물결을 시간순으로 정리한다.

4.1 전체 타임라인

2018.10
MongoDB: AGPL → SSPL
클라우드 무임승차 방지를 위해 최초의 "반-클라우드" 라이센스 도입
2019.06
CockroachDB: Apache 2.0 → BSL 1.1
MariaDB가 만든 BSL을 데이터베이스 분야에서 최초 채택
2021.01
Elastic: Apache 2.0 → SSPL + ELv2
AWS OpenSearch 포크 → 오픈소스 진영 분열
2023.08
HashiCorp: MPL 2.0 → BSL 1.1
Terraform, Vault 등 전 제품군 전환 → OpenTofu 포크
2023.11
Sentry: BSL → FSL (Functional Source License)
Fair Source 운동의 시작. 2년 후 Apache 2.0으로 자동 전환
2024.03
Redis: BSD 3-Clause → SSPL + RSALv2
Linux Foundation이 Valkey 포크 발표 (AWS, Google, Oracle 지원)
2024.08
Elastic: SSPL → AGPL 추가 🔄
최초의 역전! 오픈소스로 복귀
2024.11
CockroachDB: BSL → 독자 라이센스
오픈소스 Core 폐지, 완전 상용 전환
2025
Redis: SSPL → AGPLv3 🔄
Redis 8.0에서 다시 오픈소스 라이센스로 복귀

4.2 반복되는 패턴

8년간의 사례에서 놀라울 정도로 동일한 패턴이 반복된다:

1단계
오픈소스로 시작 → 개발자 생태계 구축 → 시장 지배력 확보
2단계
클라우드 대기업이 해당 기술을 매니지드 서비스로 제공 → 원개발사 수익 위협
3단계
라이센스를 Source-Available로 전환 → "SaaS 경쟁 금지" 조항 추가
4단계
커뮤니티 반발 → 포크 생성 (OpenTofu, Valkey, OpenSearch 등)
5단계
Debian, Red Hat, Fedora 등 배포판에서 퇴출 → 생태계 분열

제5장: 핵심 라이센스 심층 분석

5.1 SSPL (Server Side Public License)

만든 곳: MongoDB (2018)

SSPL 핵심 조항 (Section 13)
SSPL 소프트웨어를 서비스로 제공하려면, 서비스를 구성하는 모든 소프트웨어의 소스코드를 공개해야 한다.

여기에는 관리 소프트웨어, UI, API, 자동화, 모니터링, 백업, 스토리지, 호스팅 소프트웨어가 모두 포함된다.

왜 논란인가?: AWS가 MongoDB를 서비스로 제공하려면, AWS 인프라 전체의 소스코드를 공개해야 한다는 뜻이다. 사실상 클라우드 대기업의 SaaS 제공을 금지하는 조항이다. OSI는 이를 "특정 사용 분야에 대한 차별"로 판단해 오픈소스로 인정하지 않는다.

5.2 BSL (Business Source License)

만든 곳: MariaDB (2013) — MySQL 포크의 창시자 Monty Widenius가 설계

BSL로 출시
소스 열람·수정 가능
상용 경쟁 서비스 금지
↓ 일정 기간 경과 (보통 4년)
자동으로 오픈소스 전환
GPL 호환 라이센스로 변경

핵심 메커니즘: "시간 잠금(time lock)" 방식이다. 일정 기간(보통 4년) 후에 자동으로 오픈소스 라이센스(GPL 호환)로 전환된다. 이것이 BSL의 가장 중요한 특징이며, 완전 프로프라이어터리와의 차별점이다.

채택 기업: HashiCorp(Terraform, Vault), CockroachDB(초기), MariaDB, Sentry(초기)

5.3 FSL (Functional Source License) / Fair Source

만든 곳: Sentry (2023)

BSL의 진화형으로, Fair Source 운동의 핵심 라이센스다:

  • 사용: 자유 (경쟁 서비스 제공만 제한)
  • 열람·수정: 자유
  • 시간 잠금: BSL의 4년보다 짧은 2년 후 Apache 2.0으로 전환
  • 목표: "유해한 무임승차(harmful free-riding) 없는 자유"

Sentry CEO Chad Whitacre는 Fair Source를 이렇게 정의했다:

소스코드를 읽고, 학습하고, 내부에서 실행하고, 수정하고, 개선안을 제안할 수 있다. 단 하나, 생산자를 경제적으로 잠식하는 무임승차만 금지한다.

5.4 라이센스 스펙트럼

라이센스OSI 인증SaaS 제공시간 잠금대표 사례
MIT / Apache 2.0자유없음React, Kubernetes
GPL v3자유 (소스 공개 불필요)없음Linux, WordPress
AGPL v3가능 (소스 공개 필수)없음MongoDB(초기), Grafana
SSPL사실상 불가없음MongoDB(현재)
BSL 1.1경쟁 서비스 금지4년HashiCorp, MariaDB
FSL경쟁 서비스 금지2년Sentry, Codecov
프로프라이어터리라이센스에 따름없음Oracle DB, SQL Server

제6장: 심층 사례 분석

6.1 MongoDB — SSPL의 원조, 그리고 그 대가

연대기:

  • 2009: AGPL v3로 오픈소스 출시
  • 2017.10: IPO (나스닥 상장, 시가총액 $1.5B)
  • 2018.10: AGPL → SSPL 전환 (IPO 12개월 후)
  • 2019: AWS가 DocumentDB 출시 (MongoDB 호환 API)
  • 2021.01: OSI가 SSPL을 오픈소스로 불인정
  • 이후: Debian, Red Hat, Fedora가 MongoDB 패키지 제거

교훈: SSPL은 클라우드 대기업의 무임승차를 효과적으로 차단했지만, 커뮤니티 생태계에서의 고립이라는 대가를 치렀다. 그러나 MongoDB Atlas(자체 클라우드)의 성장으로 비즈니스 자체는 크게 성공했다. 2026년 현재 MongoDB의 시가총액은 IPO 당시 대비 10배 이상 성장했다.

6.2 Elastic — 유일한 역전의 드라마

Elastic의 이야기는 이 전체 역사에서 가장 교훈적인 사례다.

1막 — 오픈소스의 성공:

  • Elasticsearch는 Apache 2.0으로 시작해 검색 엔진의 표준이 됨
  • 2018년 NYSE 상장

2막 — AWS의 도전:

  • AWS가 Amazon Elasticsearch Service를 출시
  • Elastic의 브랜드("Elasticsearch")를 AWS가 그대로 사용
  • Elastic의 핵심 수익원인 매니지드 서비스와 직접 경쟁

3막 — 라이센스 전환과 포크:

  • 2021년 1월: Apache 2.0 → SSPL + Elastic License
  • AWS가 즉시 OpenSearch를 포크 (Apache 2.0 유지)
  • OpenSearch는 빠르게 성장, 독자 생태계 구축

4막 — 반전, 오픈소스 복귀:

  • 2024년 8월: AGPLv3를 추가 라이센스 옵션으로 도입
  • Elasticsearch와 Kibana가 다시 공식 "오픈소스"가 됨

왜 돌아왔나? Elastic 창시자 Shay Banon은 이렇게 밝혔다:

"Elasticsearch와 Kibana를 다시 오픈소스라 부를 수 있게 되어 순수한 기쁨이다. 나는 25년간 오픈소스의 진정한 신봉자였다."

그러나 내부적 이유는 더 현실적이었다. SSPL 전환 후 3년이 지나면서, 라이센스 제한이 가져온 커뮤니티 이탈의 비용이 클라우드 보호의 이익보다 커진 것이다. OpenSearch는 포크 첫 해에 496명의 기여자1억 회 이상의 다운로드를 달성하며 독자 생태계로 자리잡았다.

그러나 개발자들의 반응은 냉담했다. Socket.dev의 조사에 따르면, OpenSearch로 이전한 개발자 대부분은 다시 돌아올 의사가 없다고 응답했다. 한번 잃은 신뢰는 라이센스 변경만으로 회복되지 않는다.

6.3 HashiCorp — BSL, IBM, 그리고 신규 고객 붕괴

2023년 8월, HashiCorp는 Terraform, Vault, Consul 등 모든 제품을 MPL 2.0 → BSL 1.1로 전환했다.

즉각적 결과:

  • 발표 5일 만에 OpenTF Manifesto 공개 — GitHub 스타 33,000개, 140개 기업, 700명 개인 서명
  • 발표 15일 만에 포크 발표 → 45일 만에 Linux Foundation이 OpenTofu로 수용
  • 신규 고객 성장률이 분기 대비 1.5%로 급락 — BSL 전환 직후 최저치
  • 2024년 1월: OpenTofu 첫 안정 버전 출시
  • 2024년 4월: IBM이 HashiCorp를 64억 달러(약 8.7조 원)에 인수 발표

IBM 인수는 라이센스 변경과 무관하게 전략적 판단이었을 수 있지만, 타이밍이 의미심장하다. BSL 전환으로 독립 성장이 어려워진 상황에서의 인수였기 때문이다. IBM 산하 Red Hat이 OpenTofu에 관여한다는 점에서, Terraform이 다시 오픈소스로 돌아올 가능성도 남아 있다.

6.4 Redis — 가장 극적인 U턴

Redis의 라이센스 여정은 가장 극적인 3막 구조를 보여준다:

왜 바꿨나? 숫자가 말해준다. Redis 내부 추산에 따르면, AWS는 Redis 기술로 연간 최대 10억 달러 이상의 매출을 올렸다. Redis 자체 수익의 10배 이상이다. 사용자의 1%만 유료 고객이 되는 "1% 전환 문제"에 시달리는 동안, 인프라 비용은 계속 올라갔다.

1막: 2009년부터 BSD 3-Clause로 15년간 순수 오픈소스 2막 (2024.03): BSD → SSPL + RSALv2. 며칠 만에 Linux Foundation이 Valkey 포크 발표, AWS·Google·Oracle 등이 지원. 대기업 83%가 Valkey 채택 또는 검토(Percona 조사) 3막 (2025): Redis 8.0에서 AGPLv3로 복귀. 이전 상용 전용이었던 기능들까지 오픈소스화

Redis 창시자 Salvatore Sanfilippo(antirez)는 복귀 후 이렇게 말했다:

"SSPL은 실질적으로 커뮤니티에 받아들여지지 못했다."

Redis의 사례는 "라이센스 전환의 비용"을 가장 명확하게 보여준다. 15년간 쌓은 BSD 생태계를 1년 만에 되돌려야 했고, 그 사이 Valkey라는 강력한 경쟁자를 스스로 만들어버렸다. 2025년 4분기 Valkey 채택률은 전년 대비 300% 성장했고, Valkey 8.0은 3배의 처리량 개선까지 달성했다.


제7장: 2026년의 새로운 전선 — AI와 "오픈소스"

7.1 Meta Llama: "오픈소스"의 재정의 시도

오픈소스 라이센싱 논쟁은 소프트웨어를 넘어 AI 모델로 확장되었다.

Meta는 Llama 시리즈를 "오픈소스"라고 마케팅했지만, 실제 라이센스에는:

  • 월간 활성 사용자 7억 명 이상의 서비스에서 사용하려면 Meta의 별도 허가 필요
  • Llama의 출력물을 다른 LLM 학습에 사용 금지
  • Llama 4부터는 EU 기반 개인·기업 사용 제한

2024년 10월, OSI는 "Open Source AI Definition"을 발표하며 이에 대응했다. 이 정의에 따르면 AI가 오픈소스로 인정받으려면 학습 데이터에 대한 충분한 정보가 공개되어야 하는데, Meta는 이를 충족하지 않는다.

자유 소프트웨어 재단(FSF)도 2025년 1월 Llama 3.1의 라이센스를 "비자유 소프트웨어 라이센스"로 분류했다.

그리고 2025년 12월, Meta는 전략을 완전히 전환해 프로프라이어터리 모델("Avocado")로 이동한다고 발표했다. "오픈소스"라는 이름으로 생태계를 구축한 뒤, 충분한 시장 지배력을 확보하자 문을 닫은 것이다. 이것이야말로 오픈소스 커뮤니티가 두려워하는 "오픈 워싱(open-washing)"의 전형이다.

7.2 AI 시대의 라이센싱 과제

2025년 arXiv 논문 "Open Source at a Crossroads: The Future of Licensing Driven by Monetization"은 AI가 가져온 새로운 라이센싱 과제를 분석했다:

  1. 학습 데이터의 라이센스: GPL 코드로 학습한 AI가 생성한 코드의 라이센스는?
  2. 모델 가중치의 법적 성격: 소스코드인가, 컴파일된 바이너리인가, 완전히 새로운 범주인가?
  3. "오픈 가중치(Open-Weights)"의 모호성: 가중치는 공개하되 학습 데이터와 방법론은 비공개 — 이것이 "오픈"인가?

이 논문은 오픈소스가 "기로(crossroads)"에 서 있다고 결론 내린다. 기존의 라이센스 프레임워크가 AI 시대의 현실을 담지 못하고 있다는 것이다.


제8장: WordPress 사태 — 오픈소스 거버넌스의 경고

2024년의 가장 충격적인 오픈소스 사건은 라이센스가 아닌 거버넌스에서 터졌다.

2024년 9월, WordPress 공동 창시자이자 Automattic CEO Matt Mullenweg는 WordCamp US에서 호스팅 기업 WP Engine을 "WordPress의 암"이라고 공격했다. WP Engine이 WordPress로 막대한 수익을 올리면서 프로젝트에 충분히 기여하지 않는다는 것이었다.

이후 벌어진 사태:

  1. Mullenweg가 WP Engine의 WordPress.org 접근을 차단 → 100만 이상의 사이트가 플러그인 업데이트 불가
  2. WP Engine이 Automattic과 Mullenweg를 권한 남용으로 소송
  3. Automattic 직원 159명(전체의 약 8%)이 퇴사 — 이 중 80%가 WordPress 관련 부서
  4. 2024년 12월 법원이 WP Engine의 WordPress.org 접근 복원을 명령

이 사건은 오픈소스의 또 다른 위험을 보여줬다. 코드는 자유롭지만, 인프라(WordPress.org)의 통제권은 한 기업/개인에게 집중될 수 있다. 라이센스만으로는 거버넌스 문제를 해결할 수 없다.


제9장: 듀얼 라이센싱의 경제학

9.1 수익 모델

듀얼 라이센싱으로 수익을 만드는 방법은 진화해왔다:

세대모델수익원대표 사례
1세대
(2000년대)
순수 듀얼 라이센싱GPL 면제를 위한 상용 라이센스 판매MySQL, Qt, Sleepycat
2세대
(2010년대)
오픈코어 (Open Core)핵심은 오픈소스, 엔터프라이즈 기능은 유료GitLab, Confluent, Elastic
3세대
(2018~)
소스 공개형 + 매니지드 서비스SaaS 경쟁 차단 + 자체 클라우드 서비스MongoDB Atlas, Redis Cloud
4세대
(2023~)
Fair Source (시간 잠금)일정 기간 경쟁 보호 후 완전 오픈소스화Sentry (FSL), MariaDB (BSL)

9.2 듀얼 라이센싱의 전제 조건

모든 프로젝트가 듀얼 라이센싱을 할 수 있는 것은 아니다. 핵심 전제 조건:

  1. 저작권의 단일 소유: 모든 코드의 저작권이 한 주체에게 있어야 함. 외부 기여자가 많으면 CLA(Contributor License Agreement)를 통해 저작권을 양도받아야 함
  2. 카피레프트 라이센스 사용: GPL 같은 "전염성" 라이센스가 있어야 상용 라이센스의 구매 동기가 생김
  3. 충분한 시장 지배력: 대체재가 있으면 고객이 유료 라이센스 대신 대체재를 선택

세 번째 조건이 가장 중요하다. 포크가 쉬운 소프트웨어는 듀얼 라이센싱이 어렵다. HashiCorp가 BSL로 전환하자마자 OpenTofu가 나온 것이 이를 증명한다.


제10장: 지속가능성을 위한 새로운 시도들

10.1 Open Source Pledge

2024년, Sentry가 주도해 Open Source Pledge를 시작했다:

  • 기업이 정규직 개발자 1인당 연간 $2,000 이상을 오픈소스 메인테이너에게 지급
  • Sentry 자체는 연 $750,000을 기부
  • 그러나 3억 기업 중 참여하는 곳은 극소수

10.2 Bruce Perens의 "Post-Open" 제안

OSI 공동 창립자 Bruce Perens는 2024년, 기존 오픈소스 라이센스가 "작동하지 않는다"고 선언하며 "Post-Open" 라이센싱을 제안했다:

  • 연 매출 500만 달러 이상인 기업이 Post-Open 소프트웨어를 사용하면, 매출의 1%를 501(c)(6) 비영리 단체에 지급
  • 개인과 비영리 단체는 무료
  • AI 학습 데이터 문제도 함께 다룸

아직 초기 단계이지만, "오픈소스의 아버지" 중 한 명이 기존 체계의 한계를 인정했다는 것 자체가 시사하는 바가 크다.

10.3 AGPL의 재부상

2024~2025년의 가장 주목할 트렌드는 AGPL(Affero GPL)의 재평가다:

  • AGPL은 OSI 인증 오픈소스이면서, 네트워크를 통한 서비스 제공 시에도 소스 공개를 의무화
  • SSPL처럼 SaaS를 완전 차단하지 않으면서, 클라우드 대기업에 "소스 공개"라는 부담을 줌
  • Elastic과 Redis가 모두 AGPL로 복귀한 것이 이를 증명
허용적 라이센스
(MIT, Apache 2.0)
보호 없음
AGPL v3
"균형점"
오픈소스 + SaaS 소스 공개
SSPL / BSL
비-오픈소스
SaaS 차단

AGPL은 오픈소스의 정의를 지키면서도 클라우드 무임승차에 대한 최소한의 방어선을 제공하는 "황금 균형점(golden middle)"으로 재평가받고 있다.

10.4 교훈: 무엇이 작동하고 무엇이 작동하지 않았나

전략작동한 점실패한 점
SSPL 전환클라우드 무임승차 차단, 자체 SaaS 보호커뮤니티 이탈, 배포판 퇴출, 포크 생성
BSL 전환시간 잠금으로 "결국 오픈소스" 약속신규 고객 급감, 기존 사용자 불신
오픈소스 복귀 (AGPL)정당성 회복, 배포판 재포함이미 떠난 커뮤니티는 돌아오지 않음
Fair Source (FSL)짧은 잠금(2년), 명확한 규칙아직 대규모 검증 부족
AGPL 처음부터오픈소스 유지 + SaaS 방어상용 내장(embed) 사용에 부담

제11장: 실무자를 위한 전략 가이드

11.1 오픈소스를 사용하는 기업이라면

체크리스트:

  1. 라이센스 감사(Audit)를 정기적으로: FOSSA, Snyk, Black Duck 같은 SCA(Software Composition Analysis) 도구 활용
  2. SSPL/BSL 의존성 파악: 해당 소프트웨어가 라이센스를 변경하면 대안이 있는가?
  3. 포크 생태계 모니터링: Valkey(Redis 대안), OpenTofu(Terraform 대안), OpenSearch(Elasticsearch 대안) 등
  4. CLA 요구 프로젝트 주의: 저작권을 단일 주체에 양도하는 CLA가 있으면, 라이센스 변경 리스크가 높음

11.2 오픈소스 프로젝트를 시작하려면

Step 1
목적 정의: 커뮤니티 확산이 목적이면 MIT/Apache 2.0. 상용화가 목적이면 AGPL 또는 듀얼 라이센싱 고려
Step 2
저작권 구조 설계: CLA를 처음부터 도입할지 결정. 나중에 라이센스를 바꾸려면 모든 기여자의 동의가 필요 (CLA 없는 경우)
Step 3
수익 모델 설계: 순수 듀얼 라이센싱? 오픈코어? 매니지드 서비스? Fair Source? 프로젝트 특성에 맞게 선택
Step 4
거버넌스 구조: 재단 이관(Apache, Linux Foundation)을 고려하면 커뮤니티 신뢰도가 높아지지만, 라이센스 변경 유연성은 낮아짐

11.3 2026년 추천 전략

상황추천 라이센스이유
순수 커뮤니티 프로젝트MIT 또는 Apache 2.0최대 확산, 기여 장벽 최소화
SaaS 보호가 필요한 스타트업AGPLv3오픈소스 유지 + SaaS 방어. Elastic/Redis가 검증
초기 수익화가 필수인 스타트업FSL (Fair Source)2년 잠금 후 Apache 2.0. 가장 현대적인 선택
엔터프라이즈 소프트웨어오픈코어 (Apache + 상용)핵심은 오픈소스, 관리·보안 기능 유료
AI 모델OSI Open Source AI 정의 준수학습 데이터 정보 공개 포함. "오픈 워싱" 방지

마치며: 오픈소스는 정신이지, 가격표가 아니다

8년간의 라이센스 전쟁이 남긴 교훈은 역설적으로 단순하다:

첫째, 한번 잃은 신뢰는 라이센스만으로 되돌릴 수 없다. Elastic이 AGPL로 돌아왔지만, OpenSearch로 떠난 개발자들은 돌아오지 않았다. Redis가 BSD로 돌아갈 수 없었기에 AGPL을 택했지만, Valkey는 이미 독립 생태계가 되었다.

둘째, 공정한 보상 없이는 지속가능성도 없다. 60%의 무급 메인테이너, 44%의 번아웃 이탈. "무료" 위에 세워진 디지털 경제는 기반이 흔들리고 있다. Open Source Pledge 같은 시도가 있지만, 아직 규모가 너무 작다.

셋째, AGPL이 현실적 균형점으로 부상하고 있다. 오픈소스의 정의를 지키면서도 SaaS 무임승차에 최소한의 방어선을 제공한다. 2024~2025년 Elastic과 Redis의 복귀가 이를 증명했다.

넷째, AI가 새로운 전선을 열었다. "오픈 가중치"는 "오픈소스"가 아니며, Meta의 Llama 사례는 거대 기업이 "오픈소스"라는 이름을 전략적으로 활용하다 버릴 수 있음을 보여줬다.

궁극적으로, 오픈소스의 미래는 코드의 자유개발자의 생존 사이의 균형을 찾는 데 달려 있다. Richard Stallman이 말한 "free as in freedom, not free as in beer" — 자유는 공짜가 아니다. 그 자유를 유지하기 위한 공정한 비용 분담 구조를 만드는 것이 2026년 오픈소스 생태계의 가장 시급한 과제다.


참고 자료

  • Välimäki, M. (2003). "Dual Licensing in Open Source Software Industry", Systèmes d'Information et Management, Vol. 8(1), pp. 63-75
  • Kula, R.G. & Treude, C. (2025). "Open Source at a Crossroads: The Future of Licensing Driven by Monetization", arXiv:2503.02817
  • O'Grady, S. (2026). "The State of Open Source Licensing in 2026", RedMonk
  • Tidelift (2024). "State of the Open Source Maintainer Report"
  • OSI (2024). "The Open Source AI Definition"