소스 공개 라이선스와 오픈소스의 차이

최근 몇 년간 Redis, Elasticsearch, Terraform 등 전 세계 수많은 엔지니어링 조직의 기반이 되어 온 핵심 소프트웨어들이 잇따라 기존 오픈소스 라이선스(BSD, Apache 2.0, MPL 2.0)를 버리고 소스 공개(Source-Available) 라이선스로 전환했습니다.

많은 개발자가 소스 코드가 GitHub에 공개되어 있으면 여전히 오픈소스라고 오해하지만, 오픈소스 이니셔티브(OSI)의 정의와 법적 권리 측면에서 소스 공개와 오픈소스는 완전히 다른 범주입니다. 본 가이드에서는 두 진영의 법적 기준과 핵심 조항, 그리고 실무 엔지니어링 환경에 미치는 영향을 데이터와 함께 정리합니다.

1. 오픈소스의 법적 기준: OSI 10대 정의(OSD)

오픈소스(Open Source)는 단순한 관용구가 아니라 오픈소스 이니셔티브(OSI, Open Source Initiative)가 관리하는 법적 인증 기준(OSD, Open Source Definition)입니다. OSI가 승인한 라이선스(MIT, Apache 2.0, BSD-3-Clause, GPL 등)는 반드시 다음 핵심 조항을 충족해야 합니다:

• 제5항 개인 및 집단 차별 금지: 특정 개인이나 특정 기업 집단의 사용을 제한할 수 없습니다.
• 제6항 분야별 차별 금지 (No Discrimination Against Fields of Endeavor): 상업적 연구, 서비스 제공, 군사 등 특정 분야에서의 소프트웨어 실행이나 상업적 이용을 배제하거나 제한할 수 없습니다.

즉, OSI 승인 오픈소스 라이선스는 누구나, 어떤 목적으로든, 심지어 경쟁 관계에 있는 기업이라도 소프트웨어를 자유롭게 실행하고 서비스를 제공할 수 있도록 보장합니다.

2. 소스 공개(Source-Available) 라이선스란 무엇인가?

소스 공개(Source-Available) 소프트웨어는 소스 코드를 누구나 열람하고 직접 빌드할 수 있으며, 버그 리포트나 수정도 가능합니다. 그러나 특정 상업적 이용(주로 경쟁 관계의 관리형 클라우드 서비스 제공)을 명시적으로 금지하거나 라이선스 비용을 강제합니다.

이러한 제한 조항은 OSI 10대 정의 중 제6항(분야별 차별 금지)을 위반하므로, OSI는 이들 라이선스를 공식 오픈소스로 인정하지 않습니다.

3. 대표적인 소스 공개 라이선스 유형과 핵심 제약 조항

Relicensed에서 추적 중인 주요 프로젝트들이 도입한 대표 라이선스는 다음과 같습니다:

1) SSPL-1.0 (Server Side Public License)

MongoDB가 처음 고안하고 Redis와 Elasticsearch가 채택했던 라이선스입니다. 전통적인 AGPL-3.0을 기반으로 하지만, 제13항(Offering the Program as a Service)이 추가되었습니다.

이 조항은 해당 소프트웨어를 대외에 서비스(SaaS/DBaaS) 형태로 제공할 경우, 소프트웨어 자체뿐 아니라 호스팅·백업·모니터링·스케줄링 등 전체 서비스 인프라를 구동하는 관리 소프트웨어 소스 코드 일체를 SSPL로 전면 공개하도록 강제합니다. 클라우드 벤더 입장에서는 독자적인 클라우드 운영 시스템 소스를 공개할 수 없으므로 사실상 상용 서비스 제공이 원천 차단됩니다.

2) BUSL-1.1 (Business Source License)

HashiCorp(Terraform, Vault, Consul), CockroachDB, Sentry 등이 채택한 대표적인 조건부 제한 라이선스입니다.

• 용도 제한: 프로젝트마다 별도의 ‘추가 사용 허가(Additional Use Grant)’ 조항을 두어 제품과 직접 경쟁하는 상용 서비스를 금지합니다.
• Change Date (자동 전환 조항): 발행 후 최대 4년이 경과하면 GPL-2.0, Apache-2.0, MPL-2.0 등 진정한 오픈소스 라이선스로 소스 코드가 자동 전환되는 시한부 메커니즘을 내장하고 있습니다.

3) RSALv2 (Redis Source Available License v2) & Elastic License 2.0

Redis Ltd.와 Elastic이 자사 소프트웨어를 보호하기 위해 만든 라이선스로, 소프트웨어를 관리형 서비스 형태로 판매하거나 제품의 핵심 가치로 우회 제공하는 행위를 간결한 조항으로 직접 금지합니다.

4. 실제 라이선스 전환 데이터 비교

Relicensed 데이터베이스에 기록된 대표적인 라이선스 전환 이력과 영향도 라벨입니다:

5. 기업 사용자가 반드시 점검해야 할 핵심 기준

소스 공개 라이선스로 바뀐 소프트웨어를 도입할 때는 반드시 자사의 사용 형태를 분류해야 합니다:

1. 사내 내부 인프라(Internal Self-hosting): 일반적인 웹 서비스의 백엔드 캐시나 데이터베이스로 내부에서 구동하는 경우 대부분 허용됩니다.
2. 클라우드 서비스 상품화(Managed Hosting / DBaaS): 해당 소프트웨어를 고객에게 인스턴스 형태로 임대하거나 경쟁 서비스를 제공하는 경우 즉각적인 라이선스 침해(저작권 분쟁)가 발생합니다.
3. 온프레미스 솔루션 패키징(Embedding): 고객사 환경에 납품하는 소프트웨어 패키지 내부에 번들링할 경우 라이선스별 세부 재배포 허용 조건을 반드시 검토해야 합니다.

자사가 현재 사용 중인 버전이 라이선스 전환 경계 이전인지 이후인지 확인하려면 Relicensed 라이선스 점검기를 통해 즉시 점검할 수 있습니다.