오픈소스 라이선스 재편 — SSPL·BUSL과 '오픈'의 재정의, 개발자가 확인할 것

무슨 일이 벌어지고 있나

2010년대의 오픈소스 인프라는 하나의 암묵적 계약 위에 서 있었다. 회사는 데이터베이스나 검색엔진을 Apache 2.0 같은 관대한(permissive) 라이선스로 공개하고, 그 대가로 방대한 채택·기여·브랜드 신뢰를 얻는다. 수익은 유료 지원, 매니지드 클라우드, 엔터프라이즈 부가기능으로 회수한다. 이른바 open-core 모델이다.

문제는 이 계약의 한쪽에서 새로운 플레이어가 등장하면서 생겼다. AWS를 필두로 한 하이퍼스케일러가 오픈소스 프로젝트를 그대로 매니지드 서비스로 감싸 팔기 시작했다. Amazon Elasticsearch Service, Amazon ElastiCache for Redis 같은 상품이다. 원저작사 입장에서는 자기가 대부분을 개발한 소프트웨어의 클라우드 매출을, 코드 한 줄 기여하지 않은 거대 사업자가 규모의 경제로 가져가는 그림이 됐다.

회사들의 대응은 라이선스 교체였다. 관대한 라이선스로는 이 상황을 막을 수 없으니, '소스는 공개하되 우리와 경쟁하는 매니지드 서비스로는 못 쓴다'는 조건을 코드에 새겨 넣는 방식이다. 그렇게 등장한 것이 SSPL(Server Side Public License)과 BUSL(Business Source License), 그리고 Elastic License 2.0 같은 소스 공개형 상용 라이선스다.

OSI 정의: '오픈소스'는 원래 무엇을 뜻했나

'오픈소스'는 감성적 표현이 아니라 Open Source Initiative(OSI)가 관리하는 Open Source Definition(OSD)이라는 10개 조항의 문서를 가리킨다. 그중 이번 사태의 핵심은 세 가지다.

• 차별 금지(6조): 특정 사용 분야를 차별해선 안 된다. '상업적으로는 못 쓴다', '경쟁 SaaS로는 못 쓴다' 같은 조건은 이 조항 위반이다.
• 재배포의 자유(1·3조): 누구나 팔거나 무료로 배포할 수 있고, 수정본도 마찬가지여야 한다.
• 기술 중립성·구속 금지(10조): 특정 기술이나 인터페이스에 종속시켜선 안 된다.

이 잣대로 보면 SSPL·BUSL·Elastic License 2.0은 모두 오픈소스가 아니다. OSI는 SSPL을 명시적으로 심사한 뒤 승인을 거부했고, BUSL은 애초에 승인 신청 대상이 아니다. 그래서 이들을 부를 때 업계는 'source available' 또는 'fair-code' 같은 별도 표현을 쓴다. 회사들이 마케팅에서 여전히 '오픈'이라는 단어를 흘리는 것과, 실제 라이선스 텍스트가 부여하는 권리는 별개다.

세 가지 라이선스, 무엇이 어떻게 다른가

재라이선싱을 이해하려면 세 계열을 구분해야 한다. GPL을 확장한 copyleft 계열(SSPL), 시간이 지나면 오픈소스로 돌아오는 시한부 계열(BUSL), 그리고 단순 사용 제한형(Elastic License 2.0)이다.

SSPL의 독함은 13조에 있다. 소프트웨어를 서비스로 제공하려면, 그 서비스를 구동하는 데 필요한 관리·모니터링·백업 도구 등 전체 소프트웨어 스택의 소스를 SSPL로 공개하라고 요구한다. 현실적으로 어떤 클라우드 사업자도 자기 관제 시스템 전부를 공개할 수 없으니, 이는 사실상 'AWS는 이걸로 장사하지 말라'는 조항이다.

BUSL은 접근이 다르다. 코드는 처음부터 공개돼 있고 비프로덕션·소규모 용도는 대체로 허용하되, '원저작사와 경쟁하는 프로덕션 서비스'만 막는다. 그리고 Change Date(보통 배포 후 4년)가 지나면 각 버전이 지정된 오픈소스 라이선스(예: Apache 2.0, MPL 2.0)로 자동 전환된다. '지금은 우리가 먹고, 4년 뒤엔 커뮤니티에 돌려준다'는 절충안이다.

사례로 보는 재라이선싱 물결

Elastic (2021) — Elasticsearch·Kibana를 Apache 2.0에서 SSPL/Elastic License로 이중 라이선스 전환했다. 명분은 AWS의 Elasticsearch 서비스였다. AWS는 즉시 코드를 포크해 OpenSearch를 만들었고, 이후 이를 Linux Foundation 산하 OpenSearch Software Foundation으로 넘겼다. 흥미롭게도 Elastic은 2024년 AGPL 3.0을 추가해 '다시 오픈소스로 돌아왔다'고 선언했다 — 다만 SSPL/Elastic License도 함께 유지하는 삼중 라이선스다.

MongoDB (2018) — SSPL을 사실상 창시했다. Debian·Fedora 등 주요 리눅스 배포판은 SSPL을 오픈소스로 인정하지 않아 저장소에서 MongoDB를 제외했다. 데이터베이스 자체의 인기는 유지됐지만, '배포판 기본 패키지'라는 유통 경로는 잃었다.

HashiCorp (2023) — Terraform, Vault, Consul 등 거의 전 제품을 MPL 2.0에서 BUSL 1.1로 바꿨다. Terraform 커뮤니티는 곧바로 OpenTofu를 포크했고 Linux Foundation이 이를 받았다. 2024년 IBM이 HashiCorp를 인수하면서, 라이선스 전환이 결국 매각 가치 극대화의 포석이었다는 냉소적 해석도 나왔다.

Redis (2024) — RSALv2/SSPL 이중 라이선스로 전환하자, 원 개발자와 커뮤니티가 Valkey를 포크해 Linux Foundation으로 가져갔다. AWS·Google·Oracle이 곧바로 Valkey를 지지했다. 이 압박이 통했는지 Redis는 2025년 AGPL 3.0을 다시 채택해 오픈소스 지위를 부분 복원했다. 재라이선싱이 항상 회사에 유리하게만 끝나지 않는다는 대표 사례다.

개발자·기업이 실제로 확인할 것

라이선스 뉴스에 감정적으로 반응하기 전에, 실무에서는 다음을 기계적으로 점검하는 것이 낫다. 대부분의 조직에게 '내가 이 소프트웨어와 경쟁하는 매니지드 서비스를 파는가'는 아니오이므로, SSPL·BUSL 제약이 실제로 문제가 되는 경우는 생각보다 적다. 그러나 확인 없이 넘어가면 컴플라이언스 리스크가 된다.

• 버전 경계: 재라이선싱은 특정 버전부터 적용된다. Terraform 1.5.x까지는 MPL 2.0, 1.6.0부터 BUSL이다. 내가 쓰는 태그가 어느 쪽인지부터 확인한다.
• 사용 형태: 사내에서 자체 운영(self-host)하는 것과, 그걸 감싸 고객에게 SaaS로 파는 것은 완전히 다른 문제다. 후자만 SSPL·BUSL의 표적이다.
• Change Date: BUSL이라면 이 버전이 언제 오픈소스로 전환되는지 LICENSE에 박혀 있다. 장기 고정 의존성이라면 전환일을 기다리는 선택지도 있다.
• 재배포·번들: 내 제품에 이 바이너리를 포함해 배포하는가? 소스 공개형 라이선스는 재배포 시 조건이 까다로울 수 있다.

CI에서 의존성 라이선스를 자동 점검하면 '모르는 새 SSPL이 들어오는' 사고를 막을 수 있다.

# 파이썬 의존성 라이선스 스캔 (pip-licenses)
pip install pip-licenses
pip-licenses --format=csv --with-urls \
  --fail-on="SSPL;Business Source License;Elastic License 2.0"

# Node 프로젝트: 허용 목록 방식으로 차단
npx license-checker --production \
  --onlyAllow "MIT;Apache-2.0;BSD-3-Clause;ISC;MPL-2.0" \
  --excludePrivatePackages

SBOM(소프트웨어 자재 명세서)을 생성해 라이선스 필드를 자산으로 관리하면, 감사 시점에 '우리가 무엇을 어떤 조건으로 쓰는지'를 즉시 답할 수 있다.

# Syft로 컨테이너 이미지에서 SBOM 생성 후 라이선스만 추출
syft myapp:latest -o spdx-json > sbom.json
jq -r '.packages[] | [.name, (.licenseDeclared // "NOASSERTION")] | @tsv' \
  sbom.json | sort -u

# 결과에서 SSPL / BUSL / 'NOASSERTION'을 우선 검토 대상으로 분류

COSS 비즈니스 모델: 회사는 무엇을 팔아야 하나

이 모든 갈등의 뿌리는 상용 오픈소스(COSS, Commercial Open Source Software) 회사의 근본 딜레마다. 제품이 인기 있을수록 무료 사용자가 늘고, 그 인기를 클라우드 사업자가 수익화하기 쉬워진다. 즉 성공이 곧 수익화 난이도를 높인다.

대응 전략은 대략 네 갈래다. 첫째, open-core: 핵심은 오픈, 엔터프라이즈 기능(SSO, 감사로그, 클러스터링)은 상용. 둘째, 관대한 라이선스 유지 + 매니지드 우위: PostgreSQL·Kubernetes처럼 라이선스는 열어두고 운영 노하우·통합으로 승부. 셋째, copyleft(AGPL): 법적으로 SaaS 무임승차를 어렵게 만들되 OSI 오픈소스 지위는 지킴 — Grafana·MinIO가 택한 길. 넷째, 재라이선싱(SSPL/BUSL): 오픈소스 지위를 일부 포기하고 경쟁 자체를 차단.

넷째가 가장 강력해 보이지만 비용이 크다. 커뮤니티 신뢰, 배포판 채택, 외부 기여를 잃는다. 반대로 AGPL은 절충점으로 재평가받고 있다 — Redis·Elastic이 결국 AGPL로 회귀한 것이 이를 보여준다. 2026년 현재 업계의 정서는 'SSPL은 너무 나갔고, AGPL이 실용적 타협선'이라는 쪽으로 수렴하는 분위기다.

커뮤니티 신뢰라는 청구서

라이선스 전환의 진짜 비용은 법무가 아니라 신뢰다. 오픈소스 기여자는 '이 코드가 계속 자유로울 것'이라는 전제 아래 무보수로 시간을 쏟는다. 회사가 그 전제를 일방적으로 깨면, 기여자는 배신감을 느끼고 포크로 이동한다. OpenTofu·Valkey가 빠르게 자립할 수 있었던 건 이 이탈한 신뢰가 즉시 결집했기 때문이다.

더 깊은 구조적 문제는 CLA(기여자 라이선스 계약)다. 많은 COSS 회사는 외부 기여를 받을 때 저작권을 회사로 양도하거나 광범위한 재라이선싱 권한을 부여받는 CLA에 서명하게 한다. 바로 이 CLA가 나중에 회사가 라이선스를 일방 전환할 수 있는 법적 근거가 된다. 그래서 '이 프로젝트가 CLA를 요구하는가, 아니면 DCO(Developer Certificate of Origin)만 요구하는가'는 미래의 재라이선싱 가능성을 가늠하는 선행지표다.

재단(Linux Foundation, Apache, CNCF)이 포크의 안식처가 된 이유도 여기 있다. 단일 회사가 소유하지 않는 중립 거버넌스는 '두 번 다시 라이선스가 바뀌지 않는다'는 보증을 제공한다. 2026년의 인프라 채택 의사결정에서 '누가 이 프로젝트를 소유하는가'는 기능 목록만큼 중요한 항목이 됐다.

2026년 동향과 전망

몇 가지 흐름이 뚜렷하다. 첫째, AGPL의 부활. 재라이선싱의 극단(SSPL)을 겪은 회사들이 'OSI 오픈소스 지위는 지키되 SaaS 무임승차는 억제'하는 균형점으로 AGPL을 재발견하고 있다. 둘째, 재단 포크의 제도화. OpenSearch·Valkey·OpenTofu가 단순 대체재를 넘어 독자 로드맵과 기업 지원을 갖추면서, 원본보다 포크가 사실상 표준이 되는 역전 현상이 일부 영역에서 나타난다.

셋째, '페어소스(Fair Source)'의 제도화 시도. Sentry 등이 주도해 '일정 기간 후 오픈소스로 전환되는 소스 공개 라이선스'를 fair.io라는 이름 아래 하나의 카테고리로 정립하려 한다. 이는 SSPL식 은폐 대신 '우리는 오픈소스가 아니다, 대신 이런 조건이다'를 솔직히 표방하는 방향이다. 넷째, AI 시대의 새 변수. 코드가 LLM 학습 데이터로 흡수되는 상황에서, 일부 프로젝트는 '학습 이용'을 겨냥한 새로운 사용 조건을 실험하고 있다 — 오픈의 정의를 둘러싼 다음 전선이 될 가능성이 크다.

결론적으로 '오픈소스'라는 단어는 여전히 강력한 마케팅 자산이지만, 그 뒤의 라이선스 텍스트는 그 어느 때보다 다양해졌다. 실무자에게 필요한 태도는 냉소가 아니라 정밀함이다. 배지의 색깔이 아니라 LICENSE 파일의 조항을, 회사의 보도자료가 아니라 SPDX 식별자를 읽는 것. 그것이 재편의 시대에 자신을 지키는 유일한 방법이다.

자주 묻는 질문

GitHub에 소스가 공개돼 있으면 오픈소스 아닌가요?

아닙니다. '소스 공개(source available)'와 '오픈소스(open source)'는 다릅니다. 오픈소스는 OSI의 Open Source Definition 10개 조항을 충족하는 라이선스에만 붙는 이름이며, 사용 분야를 차별하지 않을 것을 요구합니다. SSPL·BUSL·Elastic License는 소스를 볼 수 있어도 '경쟁 서비스 금지' 같은 조건 때문에 오픈소스가 아닙니다.

우리 회사가 Terraform이나 Redis를 사내에서 쓰고 있는데 문제가 되나요?

대부분 문제가 되지 않습니다. BUSL·SSPL의 제약은 '해당 소프트웨어와 경쟁하는 매니지드 서비스를 외부에 판매하는 경우'를 겨냥합니다. 자체 인프라로 self-host해 내부 용도로 쓰는 것은 일반적으로 허용됩니다. 다만 버전 경계(재라이선싱 적용 버전)와 재배포 여부는 반드시 LICENSE 파일로 확인하세요.

SSPL과 BUSL 중 무엇이 더 제약이 강한가요?

실질적으로 SSPL이 더 강합니다. SSPL은 서비스로 제공 시 관제 스택 전체를 공개하라고 요구해 사실상 매니지드 제공을 봉쇄하며, 시한부 전환도 없습니다. BUSL은 경쟁 프로덕션 용도만 막고 Change Date(보통 4년) 이후 지정된 오픈소스 라이선스로 자동 전환된다는 점에서 상대적으로 완화적입니다.

OpenSearch, Valkey, OpenTofu 같은 포크로 갈아타도 안전한가요?

기술적 호환성과 거버넌스 측면에서 대체로 안전한 선택입니다. 이들은 Apache 2.0/MPL 2.0 같은 진짜 오픈소스 라이선스를 유지하고 Linux Foundation 같은 중립 재단이 후견하므로, 단일 회사에 의한 재라이선싱 위험이 없습니다. 다만 원본과 포크의 기능·API가 시간이 지나며 갈라지므로, 특정 신기능이나 상용 지원이 필요한지 먼저 확인하세요.

회사가 라이선스를 마음대로 바꿀 수 있는 근거는 무엇인가요?

대개 저작권 소유와 CLA(기여자 라이선스 계약)입니다. 코드 저작권을 회사가 보유하거나, 외부 기여자에게 재라이선싱 권한을 부여받는 CLA에 서명하게 하면, 회사는 향후 라이선스를 일방적으로 전환할 법적 권한을 갖습니다. 그래서 프로젝트가 CLA를 요구하는지, 아니면 DCO만 요구하는지가 재라이선싱 위험의 선행지표가 됩니다.

2026년 지금, 새 프로젝트에 인프라를 고를 때 무엇을 봐야 하나요?

세 가지입니다. (1) 라이선스가 OSI 승인 오픈소스인지 SPDX 식별자로 확인, (2) 소유 구조 — 단일 벤더인지 중립 재단인지, (3) CLA/거버넌스 정책. 기능만 보고 고르면 몇 년 뒤 재라이선싱에 발목 잡힐 수 있습니다. 재단이 후견하고 관대한 라이선스를 유지하는 프로젝트가 장기 안정성 측면에서 가장 방어적인 선택입니다.