라이선스 전쟁 — SSPL, BSL, Elastic License

오픈소스는 무료인데, 왜 라이선스 전쟁이 일어났을까

오픈소스에 대해 이야기할 때 가장 먼저 등장하는 단어는 보통 “무료”다. 많은 개발자들은 GitHub에서 코드를 내려받고, 라이선스 파일을 확인하고, 별다른 비용 없이 프로젝트에 사용한다. 이러한 경험이 반복되면서 자연스럽게 하나의 인식이 형성된다. 오픈소스는 누구나 사용할 수 있고, 비용을 지불하지 않아도 되는 소프트웨어라는 인식이다. 실제로 많은 오픈소스 프로젝트는 이런 방식으로 확산되었다. 개발자들은 코드를 공유하고, 서로의 프로젝트를 개선하고, 새로운 기술을 빠르게 발전시키는 협업 구조를 만들어 왔다. 이러한 문화는 소프트웨어 산업 전체에 큰 영향을 주었고, 오늘날 인터넷 인프라의 상당 부분이 오픈소스 위에서 돌아가고 있다.

하지만 이 구조를 조금만 더 깊이 들여다보면 하나의 질문이 자연스럽게 떠오른다. 이렇게 많은 사람들이 사용하고 있는 소프트웨어는 누가 만들고 있는 것일까. 그리고 그 개발 비용은 누가 감당하고 있을까. 실제로 복잡한 데이터베이스나 검색 엔진, 분산 시스템 같은 인프라 소프트웨어는 수많은 개발자들의 장기간 작업을 통해 만들어진다. 버그를 수정하고, 새로운 기능을 추가하고, 보안 문제를 해결하고, 성능을 개선하는 일은 결코 작은 일이 아니다. 이러한 작업을 지속적으로 수행하려면 안정적인 개발 조직과 상당한 자원이 필요하다. 결국 오픈소스 프로젝트도 현실적인 경제 구조 안에서 유지되어야 한다는 사실을 피할 수 없다.

이 지점에서 오픈소스 기업들은 하나의 복잡한 문제와 마주하게 된다. 코드는 공개되어 있고 누구나 사용할 수 있지만, 그 코드를 기반으로 만들어지는 경제적 가치가 항상 프로젝트를 만든 기업에게 돌아오는 것은 아니다. 특히 인프라 소프트웨어 분야에서는 이 문제가 더 크게 나타난다. 어떤 기업이 수년 동안 투자하여 만든 데이터베이스나 검색 엔진이 있다고 가정해 보자. 그 소프트웨어는 오픈소스 라이선스에 따라 공개되고, 전 세계의 개발자들이 이를 사용하기 시작한다. 하지만 시간이 지나면 다른 회사가 그 소프트웨어를 기반으로 새로운 서비스를 만들 수 있다. 그리고 그 서비스가 원래 프로젝트보다 더 많은 수익을 만들어낼 수도 있다.

이러한 상황이 반복되면서 오픈소스 기업들 사이에서는 하나의 공통된 질문이 등장하기 시작했다. 오픈소스 프로젝트를 유지하면서도 기업으로서 지속 가능한 비즈니스 모델을 만들 수 있을까. 그리고 만약 어떤 기업이 오픈소스를 기반으로 거대한 서비스 사업을 시작한다면, 그 가치의 일부는 원래 프로젝트를 만든 조직으로 돌아와야 하는 것 아닐까. 이 질문은 단순히 기술적 논쟁이 아니라, 소프트웨어 산업의 구조와 관련된 문제다. 그리고 이 문제를 둘러싸고 등장한 것이 바로 라이선스 전쟁이다.

라이선스 전쟁이라는 표현은 다소 과장된 것처럼 들릴 수도 있다. 그러나 실제로 지난 몇 년 동안 오픈소스 세계에서는 매우 중요한 변화가 일어났다. 여러 기업들이 기존의 오픈소스 라이선스를 변경하거나 새로운 라이선스를 만들기 시작했고, 그 과정에서 커뮤니티와 기업 사이의 논쟁이 크게 확산되었다. MongoDB, Elastic, MariaDB 같은 프로젝트들이 서로 다른 방식으로 라이선스 전략을 바꾸었고, 일부 경우에는 대형 클라우드 기업과 공개적인 갈등이 발생하기도 했다. 이러한 변화는 단순히 몇 개의 프로젝트에서 일어난 사건이 아니라, 오픈소스 생태계 전체의 방향을 다시 생각하게 만드는 계기가 되었다.

결국 이 논쟁의 중심에는 하나의 질문이 있다. 오픈소스는 어디까지 자유로워야 하는가. 그리고 그 자유는 누구를 위한 것인가. 개발자 개인, 기업 사용자, 클라우드 플랫폼, 그리고 프로젝트를 만든 조직 사이의 이해관계는 항상 완전히 일치하지 않는다. 오픈소스는 오랫동안 이러한 이해관계를 균형 있게 유지하면서 성장해 왔다. 하지만 최근 몇 년 동안 그 균형이 조금씩 흔들리기 시작했다. 그리고 그 균형이 무너지기 시작한 결정적인 계기는 바로 클라우드 시대의 등장이었다.

오픈소스 라이선스의 기본 구조 — GPL과 Apache의 철학

라이선스 전쟁을 이해하기 위해서는 먼저 오픈소스 라이선스가 어떤 철학 위에서 만들어졌는지 살펴볼 필요가 있다. 대부분의 오픈소스 프로젝트는 단순히 코드를 공개하는 것이 아니라, 특정한 라이선스를 통해 사용 조건을 정의한다. 이 라이선스는 코드가 어떻게 사용될 수 있는지, 수정된 코드가 어떻게 배포되어야 하는지, 그리고 어떤 의무가 발생하는지를 규정한다. 겉보기에는 단순한 법적 문서처럼 보이지만, 실제로는 오픈소스 생태계의 규칙을 형성하는 매우 중요한 요소다.

오픈소스 라이선스는 크게 두 가지 철학으로 나뉜다. 하나는 Copyleft 계열이고, 다른 하나는 Permissive License 계열이다. Copyleft 라이선스의 대표적인 예는 GPL이다. GPL은 자유 소프트웨어 운동에서 등장한 라이선스로, 코드를 자유롭게 사용할 수 있도록 허용하지만 하나의 중요한 조건을 둔다. 만약 누군가가 이 코드를 기반으로 새로운 소프트웨어를 만들고 배포한다면, 그 소프트웨어 역시 같은 라이선스로 공개해야 한다는 것이다. 이 조건은 소프트웨어가 폐쇄형 제품으로 변하는 것을 막고, 오픈소스 생태계 안에서 코드가 계속 공유되도록 만드는 역할을 한다.

반면 Permissive License는 훨씬 더 자유로운 접근 방식을 취한다. MIT, BSD, Apache 같은 라이선스는 코드를 사용하거나 수정하는 데 거의 제한을 두지 않는다. 심지어 상용 소프트웨어에 포함시키는 것도 허용된다. 단지 원 저작자에 대한 표시와 같은 최소한의 조건만 요구한다. 이러한 라이선스는 기업에게 매우 매력적인 선택이 된다. 기업은 오픈소스를 기반으로 제품을 만들거나 서비스를 제공할 수 있고, 반드시 그 코드를 다시 공개할 의무는 없다. 그래서 많은 인프라 프로젝트들이 Apache나 MIT 라이선스를 선택해 왔다.

이 두 철학은 오픈소스 역사 내내 서로 다른 장점을 가지고 공존해 왔다. Copyleft 라이선스는 커뮤니티 중심의 협력을 강화하는 역할을 했고, Permissive 라이선스는 기업 채택을 촉진하는 역할을 했다. 실제로 Linux 커널은 GPL을 사용하고 있지만, Kubernetes나 Apache Kafka 같은 프로젝트는 Apache License를 사용한다. 각각의 프로젝트는 자신이 속한 생태계와 목표에 맞는 라이선스를 선택해 온 것이다.

하지만 시간이 지나면서 Permissive 라이선스의 또 다른 특징이 점점 더 중요해지기 시작했다. 이 라이선스는 코드를 사용하는 방식에 거의 제한을 두지 않기 때문에, 매우 큰 규모의 상업적 서비스에도 사용될 수 있다. 과거에는 이 점이 큰 문제로 인식되지 않았다. 대부분의 기업은 소프트웨어를 설치형 제품으로 판매했기 때문이다. 하지만 클라우드 플랫폼이 등장하면서 상황이 달라졌다. Permissive 라이선스로 공개된 소프트웨어는 이제 대형 클라우드 서비스의 핵심 구성 요소로 사용될 수 있게 되었고, 그 과정에서 예상하지 못한 경제 구조가 만들어지기 시작했다.

즉, Permissive 라이선스가 기업 채택을 촉진하는 장점은 그대로 유지되었지만, 동시에 오픈소스 프로젝트를 만든 조직에게 불리한 결과를 만들 수도 있게 된 것이다. 이러한 변화는 처음에는 크게 주목받지 않았다. 하지만 시간이 지나면서 점점 더 많은 오픈소스 기업들이 같은 문제를 경험하기 시작했다. 그리고 이 문제는 결국 하나의 새로운 질문으로 이어지게 된다. 오픈소스 라이선스는 과연 클라우드 시대에도 여전히 공정한 구조를 만들고 있는가라는 질문이다.

클라우드가 등장하면서 깨진 오픈소스 경제 구조

소프트웨어 산업의 구조는 지난 20년 동안 매우 큰 변화를 겪었다. 과거에는 대부분의 소프트웨어가 설치형 제품으로 판매되었다. 기업은 소프트웨어 라이선스를 구매하고, 자신의 데이터센터에 서버를 설치하고, 그 위에서 프로그램을 실행했다. 이 모델에서는 소프트웨어를 만든 회사가 직접 제품을 판매하거나 지원 서비스를 제공하면서 수익을 얻을 수 있었다. 오픈소스 프로젝트 역시 이 구조 안에서 비교적 안정적인 비즈니스 모델을 만들 수 있었다. 예를 들어 Red Hat은 Linux를 기반으로 기업용 지원 서비스를 판매하는 방식으로 큰 성공을 거두었다.

하지만 클라우드 컴퓨팅이 등장하면서 이 구조는 크게 달라졌다. 이제 기업들은 소프트웨어를 직접 설치할 필요가 없어졌다. 대신 클라우드 플랫폼에서 제공하는 서비스를 사용할 수 있게 되었다. 데이터베이스, 메시지 큐, 검색 엔진, 로그 분석 시스템 같은 인프라 소프트웨어가 모두 Managed Service 형태로 제공되기 시작했다. 사용자는 서버를 관리할 필요도 없고, 소프트웨어를 직접 설치할 필요도 없다. 몇 번의 클릭만으로 서비스를 시작할 수 있다.

이 모델은 사용자에게 매우 편리했다. 하지만 동시에 오픈소스 프로젝트를 만든 기업에게는 새로운 문제를 만들기 시작했다. 클라우드 플랫폼은 오픈소스 소프트웨어를 기반으로 서비스를 만들 수 있었고, 그 서비스를 통해 상당한 수익을 얻을 수 있었다. 하지만 그 과정에서 원래 프로젝트를 만든 조직이 반드시 수익을 얻는 것은 아니었다. 어떤 경우에는 클라우드 서비스가 공식 제품보다 훨씬 더 많은 사용자와 수익을 확보하기도 했다.

이 상황은 오픈소스 기업에게 매우 복잡한 딜레마를 만들었다. 오픈소스 라이선스는 원래 누구나 자유롭게 코드를 사용할 수 있도록 설계되어 있었다. 하지만 그 자유가 특정 기업에게만 경제적 이익을 집중시키는 구조로 이어질 수 있다는 사실이 드러난 것이다. 특히 인프라 소프트웨어 분야에서는 이러한 문제가 더욱 뚜렷하게 나타났다. 데이터베이스나 검색 엔진 같은 소프트웨어는 클라우드 플랫폼에서 매우 중요한 역할을 하기 때문이다.

결국 오픈소스 기업들은 두 가지 선택지 사이에서 고민하게 되었다. 하나는 기존의 라이선스를 유지하면서 클라우드 플랫폼과 경쟁하는 것이다. 다른 하나는 라이선스를 변경하여 특정 사용 방식에 제한을 두는 것이다. 후자의 선택은 매우 논쟁적인 결정이었다. 왜냐하면 오픈소스의 핵심 가치 중 하나가 바로 사용의 자유이기 때문이다. 하지만 동시에 기업으로서 프로젝트를 유지하기 위해서는 새로운 경제 구조를 만들어야 한다는 현실적인 압박도 존재했다.

이러한 배경 속에서 등장한 것이 바로 새로운 유형의 라이선스다. SSPL, Elastic License, BSL 같은 라이선스들은 모두 클라우드 시대의 경제 구조 속에서 만들어졌다. 이 라이선스들은 기존 오픈소스 라이선스의 철학을 완전히 버리지는 않지만, 특정한 비즈니스 모델에 대해서는 제한을 두려고 한다. 그리고 바로 이 지점에서 오픈소스 커뮤니티와 기업 사이의 새로운 논쟁이 시작된다.

다음 섹션에서는 이러한 변화의 첫 번째 사례로 자주 언급되는 MongoDB와 SSPL 라이선스의 이야기를 살펴보려고 한다.

MongoDB와 SSPL — 클라우드 서비스를 막기 위한 첫 번째 실험

클라우드 시대의 오픈소스 라이선스 논쟁을 이야기할 때 가장 먼저 등장하는 사례 중 하나가 바로 MongoDB다. MongoDB는 2000년대 후반 등장한 NoSQL 데이터베이스로, 빠르게 성장하며 개발자 생태계에서 매우 중요한 위치를 차지하게 되었다. 유연한 스키마 구조와 높은 확장성 덕분에 많은 스타트업과 기업들이 MongoDB를 사용하기 시작했고, 오픈소스 프로젝트로서도 상당한 인기를 얻었다. MongoDB는 처음에 AGPL 기반의 오픈소스 데이터베이스로 공개되었고, 많은 개발자들이 이를 자유롭게 사용하며 커뮤니티가 성장했다. 이러한 흐름은 오픈소스 프로젝트가 성공하는 전형적인 패턴처럼 보였다.

하지만 상황은 클라우드 플랫폼이 등장하면서 조금씩 달라지기 시작했다. AWS를 비롯한 여러 클라우드 기업들이 MongoDB를 기반으로 한 Managed Database 서비스를 제공하기 시작한 것이다. 사용자 입장에서는 매우 편리한 서비스였다. 복잡한 데이터베이스 운영을 직접 관리할 필요 없이, 몇 번의 클릭만으로 데이터베이스 인프라를 사용할 수 있었기 때문이다. 하지만 MongoDB 회사의 입장에서 보면 이 구조는 조금 이상하게 보일 수밖에 없었다. 자신들이 개발하고 유지하고 있는 오픈소스 프로젝트를 기반으로 다른 기업이 거대한 서비스 사업을 만들고 있었기 때문이다.

이 문제를 해결하기 위해 MongoDB는 2018년에 중요한 결정을 내린다. 기존 AGPL 라이선스를 대신해 SSPL(Server Side Public License)이라는 새로운 라이선스를 도입한 것이다. SSPL은 GPL 계열 라이선스를 기반으로 만들어졌지만, 기존 오픈소스 라이선스에는 없던 매우 강력한 조건을 포함하고 있었다. 만약 이 소프트웨어를 기반으로 서비스 형태의 제품을 제공한다면, 그 서비스 전체를 구성하는 소프트웨어의 소스코드를 공개해야 한다는 조항이었다. 단순히 MongoDB의 수정된 코드만 공개하는 것이 아니라, 서비스 운영에 필요한 모든 시스템을 공개해야 한다는 의미였다.

이 조건은 사실상 대부분의 클라우드 플랫폼에게 받아들일 수 없는 것이었다. 클라우드 서비스의 내부 아키텍처는 기업의 핵심 자산이기 때문이다. 결국 SSPL은 명확한 메시지를 전달하는 역할을 하게 된다. MongoDB를 기반으로 서비스를 만들고 싶다면 MongoDB 회사와 협력하거나 상용 라이선스를 구매해야 한다는 것이다. 이 전략은 오픈소스 프로젝트를 보호하려는 기업의 시도로 볼 수 있지만, 동시에 매우 큰 논쟁을 불러일으켰다. Open Source Initiative(OSI)는 SSPL을 공식 오픈소스 라이선스로 인정하지 않았고, 일부 커뮤니티에서는 MongoDB가 오픈소스의 정신을 훼손했다고 비판하기도 했다.

그럼에도 불구하고 SSPL은 하나의 중요한 전환점을 만들었다. 오픈소스 기업이 클라우드 플랫폼과의 경쟁 속에서 라이선스를 전략적으로 변경할 수 있다는 사실을 보여준 첫 번째 사례였기 때문이다. 그리고 이 사건은 곧 더 큰 갈등의 서막이 된다. MongoDB의 선택은 단순한 개별 사건이 아니라, 이후 여러 오픈소스 기업들이 비슷한 고민을 하게 되는 계기를 만들었다. 그 가운데 가장 큰 논쟁을 불러온 사건이 바로 Elasticsearch를 둘러싼 라이선스 변경이었다.

Elastic License와 OpenSearch — 오픈소스 역사상 가장 큰 포크

MongoDB의 SSPL 사건이 오픈소스 라이선스 논쟁의 시작이었다면, Elasticsearch 사건은 그 갈등이 얼마나 크게 확산될 수 있는지를 보여 준 대표적인 사례였다. Elasticsearch는 로그 분석과 검색 인프라 분야에서 가장 널리 사용되는 오픈소스 프로젝트 중 하나였다. Logstash, Elasticsearch, Kibana로 구성된 이른바 ELK 스택은 수많은 기업의 데이터 인프라에서 핵심적인 역할을 하고 있었고, 오픈소스 생태계에서도 매우 중요한 위치를 차지하고 있었다. Elasticsearch는 Apache 2.0 라이선스로 공개되어 있었기 때문에 누구나 자유롭게 사용할 수 있었고, 이러한 자유로운 라이선스는 프로젝트의 확산에 큰 기여를 했다.

하지만 시간이 지나면서 Elastic 회사는 하나의 문제를 인식하게 된다. AWS가 Elasticsearch를 기반으로 Amazon Elasticsearch Service라는 Managed Service를 제공하고 있었고, 이 서비스가 상당한 규모로 성장하고 있었기 때문이다. Elastic 입장에서 보면 자신들이 개발한 프로젝트가 클라우드 플랫폼의 핵심 서비스가 되었지만, 그 과정에서 프로젝트 개발에 대한 기여나 경제적 보상이 충분하지 않다고 느낄 수 있었다. 특히 클라우드 플랫폼은 막대한 인프라와 고객 기반을 가지고 있기 때문에, 동일한 소프트웨어를 기반으로 하더라도 훨씬 더 큰 시장을 확보할 수 있었다.

결국 2021년 Elastic은 큰 결정을 내린다. Elasticsearch와 Kibana의 라이선스를 Apache 2.0에서 Elastic License와 SSPL의 이중 라이선스 구조로 변경한 것이다. 이 결정은 사실상 Elasticsearch가 더 이상 전통적인 의미의 오픈소스 프로젝트가 아니라는 것을 의미했다. Elastic License는 소스코드를 공개하지만 특정 사용 방식, 특히 서비스 제공 형태의 사용을 제한하는 라이선스였다. 즉, 클라우드 플랫폼이 Elasticsearch를 기반으로 직접 경쟁 서비스로 제공하는 것을 막으려는 의도가 명확하게 드러난 결정이었다.

AWS는 이 결정에 매우 빠르게 대응했다. Apache 2.0 라이선스가 적용되던 마지막 버전을 기반으로 OpenSearch라는 새로운 프로젝트를 시작한 것이다. 이것은 단순한 포크가 아니라, 대형 클라우드 기업이 직접 오픈소스 프로젝트의 대안을 만들기 시작한 사건이었다. OpenSearch는 이후 AWS뿐만 아니라 여러 기업들의 참여를 받으며 독립적인 프로젝트로 성장하게 된다. 이 사건은 오픈소스 역사에서 매우 중요한 의미를 가진다. 단순히 라이선스가 변경된 사건이 아니라, 오픈소스 기업과 클라우드 플랫폼 사이의 경제적 갈등이 공개적으로 드러난 사건이었기 때문이다.

Elasticsearch 사건은 오픈소스 생태계에 여러 가지 질문을 던졌다. 프로젝트를 만든 회사는 자신의 소프트웨어를 기반으로 한 경쟁 서비스에 대해 어떤 권리를 가질 수 있을까. 그리고 오픈소스 라이선스는 이러한 상황에서 어떤 역할을 해야 할까. Elastic의 결정은 일부 개발자에게는 현실적인 선택으로 보였지만, 다른 사람들에게는 오픈소스 철학에서 멀어지는 움직임으로 보이기도 했다. 그러나 한 가지 분명한 사실은, 이 사건 이후 오픈소스 라이선스가 단순한 기술적 선택이 아니라 기업 전략의 핵심 요소가 되었다는 점이었다.

BSL — 완전히 닫지도, 완전히 열지도 않는 새로운 전략

MongoDB와 Elastic의 사례는 모두 매우 강력한 방식으로 클라우드 플랫폼을 제한하려는 시도였다. 하지만 모든 오픈소스 기업이 동일한 전략을 선택한 것은 아니다. 일부 기업들은 보다 절충적인 접근 방식을 찾기 시작했다. 그 가운데 등장한 모델이 바로 Business Source License(BSL)이다. BSL은 기존 오픈소스 라이선스와 완전히 동일하지도 않고, 전통적인 상용 소프트웨어 라이선스와도 다른 독특한 구조를 가지고 있다. 이 라이선스의 핵심 아이디어는 일정 기간 동안은 제한된 라이선스로 소프트웨어를 제공하고, 시간이 지나면 자동으로 오픈소스로 전환하는 것이다.

이 모델은 매우 흥미로운 균형을 시도한다. 프로젝트를 만든 회사는 초기 몇 년 동안 경쟁 서비스가 등장하는 것을 어느 정도 제한할 수 있고, 그 기간 동안 비즈니스 모델을 안정적으로 구축할 수 있다. 동시에 시간이 지나면 해당 소프트웨어는 완전히 오픈소스가 되기 때문에, 장기적으로는 커뮤니티와 생태계에 기여하게 된다. MariaDB, CockroachDB, Sentry 같은 프로젝트들이 이 모델을 선택한 이유도 바로 여기에 있다. 완전히 닫힌 소프트웨어가 되는 것을 피하면서도, 초기 시장에서의 경쟁 구조를 조금 더 유리하게 만들 수 있기 때문이다.

BSL 모델은 오픈소스 철학과 기업 전략 사이에서 하나의 타협점처럼 보이기도 한다. 커뮤니티는 일정 시간이 지나면 코드를 자유롭게 사용할 수 있게 되고, 기업은 그 이전 기간 동안 프로젝트를 기반으로 한 서비스 사업을 성장시킬 수 있다. 물론 이 모델 역시 논쟁에서 완전히 자유로운 것은 아니다. 일부 개발자들은 BSL 역시 엄밀한 의미의 오픈소스가 아니라고 비판하기도 한다. 하지만 다른 관점에서 보면 BSL은 오픈소스와 상용 소프트웨어 사이의 새로운 실험이라고 볼 수도 있다.

이러한 새로운 라이선스 전략들은 모두 하나의 공통된 질문에서 출발한다. 오픈소스 프로젝트를 만들고 유지하는 조직은 어떻게 지속 가능한 경제 구조를 만들 수 있을까. 그리고 그 과정에서 오픈소스의 철학은 어디까지 유지될 수 있을까. MongoDB의 SSPL, Elastic의 라이선스 변경, 그리고 BSL 모델은 모두 같은 문제를 서로 다른 방식으로 해결하려는 시도다. 그리고 이러한 시도들은 오픈소스의 정의 자체를 다시 생각하게 만드는 논쟁으로 이어지게 된다.

오픈소스인가, Source Available인가 — 정의를 둘러싼 논쟁

MongoDB의 SSPL, Elastic의 라이선스 변경, 그리고 BSL과 같은 새로운 라이선스 모델들이 등장하면서 오픈소스 세계에서는 또 다른 논쟁이 시작되었다. 그것은 단순히 “어떤 라이선스가 더 좋은가”라는 기술적 문제를 넘어, 무엇을 오픈소스라고 부를 수 있는가라는 근본적인 질문이었다. 오픈소스라는 단어는 오랫동안 특정한 의미를 가지고 사용되어 왔다. 누구나 코드를 자유롭게 사용할 수 있고, 수정할 수 있으며, 재배포할 수 있다는 원칙이 그 핵심이었다. 이러한 원칙은 Open Source Initiative(OSI)가 제시한 오픈소스 정의를 통해 비교적 명확하게 정리되어 있다. 이 정의는 수십 년 동안 오픈소스 생태계의 기준점 역할을 해 왔다.

하지만 클라우드 시대 이후 등장한 새로운 라이선스들은 이 정의와 미묘하게 충돌하기 시작했다. SSPL이나 Elastic License 같은 라이선스는 소스코드를 공개하지만 특정한 사용 방식에 제한을 둔다. 특히 클라우드 서비스 형태로 소프트웨어를 제공하는 경우에는 강력한 조건을 요구하거나 아예 사용을 제한하기도 한다. 이러한 조항은 기업 입장에서는 현실적인 선택일 수 있지만, OSI의 기준에서는 문제가 될 수 있다. 오픈소스 라이선스는 특정 산업이나 특정 비즈니스 모델을 차별해서는 안 된다는 원칙이 있기 때문이다. 바로 이 지점에서 새로운 용어가 등장하게 된다. 그것이 바로 Source Available이라는 개념이다.

Source Available 소프트웨어는 이름 그대로 소스코드를 공개한다. 누구나 코드를 읽고, 학습하고, 수정할 수 있다. 하지만 모든 사용 방식이 허용되는 것은 아니다. 특히 경쟁 서비스 형태의 사용이나 특정 규모 이상의 상업적 사용에 제한을 두는 경우가 많다. 이러한 모델은 기업에게는 매력적인 선택이 될 수 있다. 소스코드를 공개함으로써 개발자 커뮤니티와 협력할 수 있으면서도, 핵심 비즈니스 모델을 보호할 수 있기 때문이다. 하지만 일부 오픈소스 커뮤니티에서는 이러한 접근 방식을 매우 비판적으로 바라본다. 왜냐하면 오픈소스라는 단어가 가지는 의미가 점점 희석될 수 있기 때문이다.

이 논쟁은 단순한 용어 문제로 끝나지 않는다. 오픈소스 프로젝트에 참여하는 개발자들에게 라이선스는 매우 중요한 의미를 가진다. 많은 개발자들이 오픈소스 프로젝트에 기여하는 이유는 코드가 특정 기업의 자산이 아니라, 공동의 자산으로 남기를 바라기 때문이다. 만약 어떤 프로젝트가 Source Available 라이선스로 전환된다면, 일부 개발자들은 그 프로젝트에 대한 기여를 중단할 수도 있다. 반대로 기업 입장에서는 프로젝트를 유지하기 위한 재정적 기반이 없다면 오픈소스 자체가 지속되기 어렵다고 주장하기도 한다. 결국 이 논쟁은 철학과 현실 사이의 균형을 어디에 둘 것인가라는 문제로 이어진다.

이러한 갈등은 오픈소스가 단순한 개발 문화가 아니라 거대한 산업 구조의 일부가 되었음을 보여준다. 과거에는 오픈소스 프로젝트가 커뮤니티 중심으로 성장하는 경우가 많았지만, 지금은 수많은 기업이 오픈소스를 기반으로 사업을 운영하고 있다. 이 상황에서 라이선스는 더 이상 기술적인 세부 사항이 아니라, 생태계 전체의 방향을 결정하는 중요한 요소가 된다. 그리고 바로 이 지점에서 다음 질문이 등장한다. 만약 오픈소스의 정의가 변화하고 있다면, 기업들은 앞으로 어떤 전략을 선택하게 될까.

라이선스는 이제 기술이 아니라 비즈니스 전략이다

오픈소스의 초기 역사에서 라이선스는 주로 법적 보호 장치로 이해되었다. 개발자가 코드를 공개하면서도 자신의 저작권을 유지할 수 있도록 하는 도구였고, 동시에 코드가 자유롭게 공유될 수 있도록 보장하는 장치였다. 하지만 현대의 소프트웨어 산업에서는 라이선스의 의미가 훨씬 더 복잡해졌다. 특히 인프라 소프트웨어와 클라우드 플랫폼이 결합하면서 라이선스는 단순한 법적 문서가 아니라 비즈니스 전략의 핵심 요소가 되었다. 어떤 라이선스를 선택하느냐에 따라 시장에서의 경쟁 구조가 달라질 수 있기 때문이다.

예를 들어 Permissive 라이선스를 선택하면 개발자 채택이 빠르게 이루어질 가능성이 높다. 기업은 자유롭게 코드를 사용하고 제품에 통합할 수 있기 때문에 생태계가 빠르게 성장한다. 하지만 동시에 경쟁 서비스가 등장할 가능성도 높아진다. 반대로 강력한 Copyleft 라이선스를 선택하면 코드의 자유로운 확산이 제한될 수 있지만, 프로젝트의 통제력을 유지하기는 쉬워진다. 그리고 최근 등장한 SSPL이나 BSL 같은 라이선스는 이 두 가지 전략 사이에서 새로운 균형을 찾으려는 시도로 볼 수 있다.

이러한 변화는 특히 오픈소스 기반 스타트업에서 두드러지게 나타난다. 많은 인프라 소프트웨어 기업들은 초기에는 오픈소스를 통해 개발자 커뮤니티를 확보하고, 이후 기업 고객을 대상으로 유료 기능이나 서비스 모델을 구축한다. 이 과정에서 라이선스는 단순히 코드 공개 여부를 결정하는 것이 아니라, 어떤 방식으로 수익을 창출할 수 있는지를 결정하는 요소가 된다. 예를 들어 클라우드 플랫폼이 동일한 소프트웨어를 기반으로 경쟁 서비스를 만들 수 있다면, 오픈소스 기업의 비즈니스 모델은 매우 어려워질 수 있다.

그래서 최근 몇 년 동안 라이선스 선택은 기술 전략만큼이나 중요한 경영 전략이 되었다. 기업들은 프로젝트의 확산 속도, 커뮤니티 참여, 경쟁 서비스 등장 가능성, 그리고 장기적인 수익 구조를 모두 고려하여 라이선스를 결정한다. 이 과정에서 기존 오픈소스 라이선스의 철학과 현실적인 비즈니스 요구 사이에서 많은 고민이 이루어진다. 어떤 기업은 여전히 완전히 개방된 라이선스를 선택하고, 어떤 기업은 Source Available 모델을 선택하며, 또 어떤 기업은 완전히 새로운 라이선스를 만들어 사용하기도 한다.

결국 현대의 오픈소스 기업에게 라이선스는 단순히 코드의 사용 조건을 정하는 문서가 아니다. 그것은 제품 전략, 시장 전략, 그리고 경쟁 전략이 모두 결합된 하나의 설계다. 그리고 이 설계는 소프트웨어 산업 전체의 경제 구조와도 깊이 연결되어 있다. 이러한 흐름을 이해하지 못하면, 최근 몇 년 동안 발생한 여러 라이선스 변경 사건들을 단순한 기업의 선택 정도로만 보게 될 수도 있다. 하지만 실제로는 훨씬 더 큰 산업 구조의 변화가 그 뒤에 존재한다.

클라우드 시대 이후의 오픈소스 — 새로운 균형을 찾는 과정

지금까지 살펴본 여러 사례들은 하나의 공통된 흐름을 보여 준다. 오픈소스는 더 이상 단순히 무료 소프트웨어를 의미하지 않는다. 그것은 거대한 개발자 생태계와 기업 전략, 그리고 클라우드 인프라가 얽혀 있는 복잡한 경제 구조의 일부가 되었다. MongoDB의 SSPL, Elastic의 라이선스 변경, 그리고 BSL과 같은 새로운 라이선스 모델은 모두 동일한 질문에서 출발했다. 오픈소스 프로젝트를 만드는 조직은 어떻게 지속 가능한 경제 구조를 만들 수 있을까 하는 질문이다. 그리고 이 질문은 단순히 몇몇 기업의 문제에 그치지 않는다. 오늘날 수많은 인프라 소프트웨어 프로젝트들이 동일한 고민을 하고 있기 때문이다.

클라우드 플랫폼이 등장하기 전까지 오픈소스와 기업의 관계는 비교적 단순했다. 기업은 오픈소스를 기반으로 제품을 만들거나 지원 서비스를 제공했고, 프로젝트는 커뮤니티와 기업의 협력을 통해 성장했다. 하지만 클라우드 서비스 모델이 확산되면서 이 구조는 크게 달라졌다. 이제 소프트웨어 자체가 아니라, 그 소프트웨어를 어떻게 서비스로 제공하느냐가 더 큰 경제적 가치를 만들 수 있게 되었기 때문이다. 이 변화는 오픈소스 프로젝트를 만든 기업에게 새로운 도전을 가져왔다. 코드의 자유로운 사용을 허용하면서도 프로젝트의 지속 가능성을 확보해야 하는 어려운 균형을 찾아야 했기 때문이다.

그 결과 등장한 것이 바로 최근 몇 년 동안 이어진 라이선스 변화들이다. SSPL은 클라우드 서비스 모델에 직접적인 제약을 두는 방식으로 문제를 해결하려 했고, Elastic License는 특정 사용 방식을 제한하는 방식으로 프로젝트의 경제 구조를 보호하려 했다. BSL은 일정 기간 이후 완전한 오픈소스로 전환하는 절충안을 제시했다. 이 세 가지 접근 방식은 서로 매우 다르지만, 공통적으로 하나의 현실을 반영하고 있다. 오픈소스 프로젝트가 성공할수록 그 위에서 만들어지는 경제적 가치 역시 커지며, 그 가치의 분배 방식이 새로운 논쟁을 만들어 낸다는 점이다.

이러한 논쟁은 때로는 오픈소스의 철학을 훼손하는 것처럼 보일 수도 있다. 실제로 일부 개발자들은 Source Available 모델이나 새로운 라이선스 전략을 비판하기도 한다. 하지만 동시에 오픈소스 프로젝트를 유지하기 위해서는 현실적인 경제 구조가 필요하다는 주장 역시 설득력을 가진다. 수십 명의 개발자가 수년 동안 프로젝트를 유지하고 발전시키려면 안정적인 재원이 필요하기 때문이다. 결국 이 논쟁은 철학과 현실 사이의 균형을 어디에 둘 것인가라는 질문으로 이어진다.

그리고 중요한 사실은 이 균형이 아직 완전히 정해지지 않았다는 점이다. 오픈소스 생태계는 여전히 변화하고 있으며, 새로운 라이선스 모델과 비즈니스 전략이 계속 등장하고 있다. 어떤 프로젝트는 완전히 개방된 라이선스를 유지하고 있고, 어떤 프로젝트는 Source Available 모델을 선택하고 있으며, 또 어떤 프로젝트는 커뮤니티 중심의 거버넌스를 통해 새로운 협력 구조를 만들고 있다. 이 모든 시도들은 하나의 공통된 목표를 향하고 있다. 바로 오픈소스를 지속 가능한 형태로 유지하는 것이다.

결국 라이선스 전쟁이라고 불리는 최근의 변화는 단순한 갈등의 역사라기보다는, 오픈소스가 새로운 산업 환경에 적응하는 과정이라고 볼 수도 있다. 소프트웨어 산업의 구조가 변하면, 그 위에서 작동하는 규칙 역시 변할 수밖에 없다. 오픈소스 역시 예외가 아니다. 수십 년 동안 이어져 온 협력의 문화와 새로운 경제 구조 사이에서, 오픈소스 생태계는 지금도 새로운 균형점을 찾아가고 있다. 그리고 그 과정 자체가 오픈소스가 여전히 살아 있는 생태계라는 사실을 보여 주는 가장 분명한 증거일지도 모른다.