오픈소스 라이선스 정책 변화 (개방형 → 폐쇄형)
1. 개요
가. 현상 정의
MongoDB·Elastic·HashiCorp·Redis 등 주요 오픈소스 프로젝트가, 상업적 이용·재배포가 자유로운 개방형 라이선스(MIT·BSD·Apache 2.0)에서 소스는 공개하되 서비스형 제공·경쟁적 이용을 제한하는 라이선스(SSPL·BSL·Elastic License)로 전환하는 최근의 흐름.
이 현상의 본질은 "소스 코드 공개"와 "자유로운 상업적 이용 허용"이라는, 그동안 한 몸처럼 여겨지던 두 가치가 분리되고 있다는 데 있다. 새 라이선스들은 소스는 계속 공개하되(Source Available), 이를 그대로 관리형 서비스로 팔아 원 개발사와 경쟁하는 행위만 제한한다. 이 때문에 OSI(Open Source Initiative)는 이들을 정통 오픈소스로 인정하지 않는다.
나. 라이선스 유형 비교
| 구분 | 개방형 | 폐쇄형(소스공개 제한) |
|---|---|---|
| 예시 | MIT, BSD, Apache 2.0 | SSPL, BSL, Elastic License |
| 특징 | 상업적 이용·수정·재배포 자유 | 소스는 공개, 서비스형(SaaS) 제공·경쟁 이용 제한 |
| OSI 승인 | 승인(오픈소스) | 미승인(Source Available) |
| 전환 사례 | — | Elasticsearch, MongoDB, Terraform, Redis |
두 유형의 근본 차이는 "타인이 이 소프트웨어로 나와 같은 사업을 하는 것을 막을 수 있는가"이다. 개방형은 이를 전혀 제한하지 않아 클라우드 사업자가 그대로 서비스화할 수 있는 반면, SSPL은 관리형 서비스로 제공하려면 서비스 스택 전체의 소스 공개를 요구해 사실상 상업적 재판매를 봉쇄한다.
2. 정책 변경 배경
flowchart LR
A[클라우드 사업자<br/>무임승차·SaaS화] --> B[원 개발사 수익 악화]
B --> C[지속가능성·투자회수 위기]
C --> D[라이선스 전환<br/>SSPL·BSL]
전환의 근본 원인은 클라우드 시대의 가치 배분 불균형이다. 개방형 라이선스가 만들어지던 시기에는 소프트웨어를 각자 설치·운영하는 것이 일반적이어서, 원 개발사와 이용자 사이에 직접적 수익 충돌이 적었다. 그러나 하이퍼스케일러가 오픈소스를 관리형 서비스(예: Amazon Elasticsearch Service)로 손쉽게 제공하면서, 개발은 원 회사가 하고 수익은 클라우드 사업자가 가져가는 구조가 생겼다. 개발사는 지속적 개발 재원을 확보하지 못하면 프로젝트 자체가 유지될 수 없으므로, 라이선스 전환은 생존을 위한 선택이 되었다.
| 배경 | 내용 | 왜 문제가 되었나 |
|---|---|---|
| 클라우드 무임승차 | 하이퍼스케일러가 OSS를 관리형 서비스로 제공해 수익 독식 | 개발 기여 없이 수익만 취득 |
| 수익화·지속가능성 | 개발 지속을 위한 재원 확보 필요 | 재원 없으면 프로젝트 유지 불가 |
| 경쟁 방어 | 동일 서비스로의 상업적 재판매 제한 | 원 개발사의 사업 모델 보호 |
3. 소프트웨어 산업에 미친 영향
라이선스 전환은 곧바로 커뮤니티의 반발과 포크(Fork) 를 촉발했다. 개방형으로 신뢰하고 채택했던 사용자·기업 입장에서는 갑작스러운 조건 변경이 배신으로 받아들여졌고, 중립 재단을 중심으로 마지막 개방형 버전에서 갈라져 나온 대체 프로젝트가 빠르게 형성됐다.
| 영향 | 내용 | 대표 사례 |
|---|---|---|
| 커뮤니티 반발·포크 | 마지막 개방형 버전에서 분기, 재단이 중립 유지 | OpenSearch(ES), Valkey(Redis), OpenTofu(Terraform) |
| 기업 이용 리스크 | 라이선스 조항 검토 부담, 벤더 종속·비용 증가 | SaaS 제공 기업의 재검토 |
| 오픈소스 신뢰성 논쟁 | '오픈소스' 정의(OSI)와 상업 모델의 충돌 | Source Available 논쟁 |
| 재단화·대체재 | 중립 재단 이관, 대체 프로젝트 활성화 | Linux Foundation 산하 이관 |
예컨대 Elasticsearch가 SSPL로 전환하자 AWS가 마지막 Apache 2.0 버전을 포크해 OpenSearch 를 만들었고, Redis의 라이선스 변경 직후에는 Linux Foundation 주도로 Valkey 가 출범했다. 이는 "개방형 생태계는 조건이 나빠지면 개방형 대체재로 이탈한다"는 오픈소스 특유의 자기교정 메커니즘을 보여준다.
4. 기업 대응 방안
도입 기업은 라이선스 변경이 아키텍처·조달·법무 리스크로 번지기 전에 선제적으로 관리해야 한다. 자신이 어떤 OSS를 어떤 조건으로 쓰는지조차 파악하지 못하면 대응 자체가 불가능하므로, 가시성 확보가 출발점이다.
| 대응 | 내용 | 목적 |
|---|---|---|
| 라이선스 인벤토리 | 사용 OSS·라이선스 조항 파악(SCA·SBOM) | 노출 범위 가시화 |
| 리스크 평가 | 변경 가능성·자사 SaaS 제공 해당 여부 검토 | 실제 영향 판별 |
| 대안 확보 | 포크·대체재·상용 계약 검토 | 종속·중단 위험 분산 |
여기서 SBOM(Software Bill of Materials) 이 왜 핵심인가 하면, 소프트웨어 구성요소의 목록과 라이선스를 표준 형식으로 관리하면 라이선스가 바뀌었을 때 영향받는 시스템을 즉시 식별해 대응할 수 있기 때문이다.
5. 고려사항 및 시사점
- 개방성과 지속가능성의 균형: 개발 재원 없는 순수 개방은 지속 불가능하고, 과도한 폐쇄는 커뮤니티 이탈을 부른다. 이 둘의 균형점을 찾는 것이 오픈소스 비즈니스의 핵심 과제로, 최근 "오픈 코어(핵심은 개방, 부가기능은 상용)"나 시간이 지나면 개방형으로 전환되는 BSL 같은 절충 모델이 확산되고 있다.
- 채택 기업의 전략적 판단: 특정 OSS에 깊이 종속되기 전에 라이선스 변경 리스크를 아키텍처·조달 결정에 미리 반영하고, 대체 가능성을 열어두는 것이 안전하다.
- 지속 모니터링: OSI 승인 여부, 포크 생태계의 활성도, 주요 프로젝트의 라이선스 동향을 상시 관찰해 전환 신호에 조기 대응한다.
- 시사점: 이 변화는 오픈소스가 이념에서 지속가능한 비즈니스 모델의 문제로 성숙해 가는 과정이며, 기업은 '공짜'가 아니라 '조건부 자산'으로 OSS를 관리해야 한다.
한 줄 요약: 클라우드 사업자의 무임승차로 인한 수익성 악화가 MongoDB·Elastic·Redis 등의 개방형→SSPL·BSL 폐쇄형 전환을 촉발했고, 이는 OpenSearch·Valkey 등 포크와 '오픈소스 정의' 논쟁을 낳았으며, 기업은 SBOM·리스크 평가·대체재 확보로 대응하고 개방성과 지속가능성의 균형을 관리해야 한다.