정보마당

Home > 정보마당 > 공개SW 활용 가이드 > 공개SW 가이드/보고서

공개SW 가이드/보고서

[기획기사] 오픈소스 기업의 비즈니스와 라이선스 정책 변경

support 게시글 작성 시각 2023-08-29 12:08:29 게시글 조회수 1753

오픈소스 기업의 비즈니스와 라이선스 정책 변경

- 이지현 IT 전문기자(j.lee.reporter@gmail.com) -

전통적으로 오픈소스 기업은 기업용 서비스 즉 기술지원 및 유지보수를 통해 수익 창출을 모색했다. 하지만 시대가 변하고 경쟁사가 많아지면서 오픈소스 기업의 생존 전략이 달라지고 있다. 오픈소스 운영 정책을 변경하며 수익 창출 권한을 제한하는 것이다. 가령 라이선스를 변경하여 소스 코드 복사(포크)가 어렵게 만들거나 클라우드 업체에서 관리형 서비스를 제공하지 못하게 막는 식이다. 물론 이런 정책에 대해 오픈소스 업계 내에서도 입장은 제각각이다. ‘허용성이 낮은 라이선스를 확산시키고 고객 선택권을 박탈하고 있다’라는 평가도 있고 ‘수익 창출을 위해 어쩔 수 없는 선택으로 보인다’라는 의견까지 다양하다. 최근 몇 년 사이 오픈소스 기업 사이에 화제가 되고 있는 정책에 대해서 살펴보자.

RHEL 무료 배포판을 둘러싼 치열한 공방

레드햇의 마이크 맥그라스(Mike McGrath) 부사장은 2023년 6월 한 공지글을 올렸다. ‘센트OS 스트림 발전을 확대하며(Furthering the evolution of CentOS Stream)’라고 시작하는 이 글¹⁾의 요지는 향후 RHEL의 관련된 공개적인 소스 코드는 센트OS 스트림 저장소에서만 공유된다는 것이었다.

해당 공지를 이해하기 위해서는 센트OS(센트OS 리눅스라고도 부름), 센트OS 스트림과 RHEL의 관계를 알고 있어야 한다. 일단 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux) 줄여서 RHEL은 유료 소프트웨어이며 기업용 인프라에 쓰이는 리눅스 배포판이다. RHEL은 기본적으로 GPL 라이선스를 따르는 오픈소스 프로젝트다. 따라서 그동안 관련 소스 코드가 모두 공개됐다. 맞춤형 기능과 보안을 강화하고 유지보수 서비스를 받으려는 기업이 RHEL의 주요 고객이었다.

센트OS는 오픈소스 기술인 RHEL를 복사해 만든 리눅스 배포판이다. 레드햇의 공식 지원을 받을 수 없다는 것을 제외하고 RHEL과 완벽 호환되는 기술이었다. 무엇보다 무료로 쓸 수 있다는 게 장점이었었다. 기술적 완성도도 높은 덕에 작은 기업뿐만 아니라 도요타, 버라이즌, 디즈니도 센트OS를 사용한 것으로 알려져 있다.²⁾ 원래 센트OS 개발 자체는 특정 기업이 아니라 커뮤니티 중심으로 기술 개발이 이뤄졌다. 하지만 2014년부터 레드햇은 직접 센트OS에 재정적으로 후원하고 센트OS의 관리 이사회 일원으로 들어가며 센트OS를 사실상 인수하게 됐다.

그렇게 레드햇은 한동안 유료인 RHEL과 무료 RHEL인 센트OS를 동시에 운영하고 있었다. 하지만 IBM이 레드햇을 인수한 이후 상황은 급변했다. 2019년 레드햇이 센트OS 지원을 중단하겠다고 발표한 것이다. 그리고 이때 제시된 것이 센트OS 스트림이다.

센트OS 스트림도 리눅스 배포판이다. 배포 순서를 보면 센트OS와의 차이를 명확히 알 수 있다. 센트OS 스트림은 커뮤니티 버전의 리눅스(정확히 페도라)를 기반으로 개선된 후 배포된다. 이후 각종 테스트를 거치고 피드백을 반영해 RHEL이 출시된다. 이런 구조 때문에 센트OS 스트림에서 없는 기능 및 지원이 RHEL에 나올 수 있다. 그래서 업계는 센트OS 스트림이 RHEL과 완벽하게 호환되지 않는다고 여긴다. RHEL 배포 이전에 나오는 운영체제이기에 기술적으로 센트OS 스트림을 RHEL의 ‘업스트림(Upstream)’ 프로젝트라고 부른다. 반대로 센트OS는 RHEL이 먼저 나온 다음에 배포된다. RHEL 코드가 나온 뒤 이를 복사해서 센트OS를 만드니 RHEL과 완전히 호환될 수 있었다. 그래서 센트OS는 RHEL의 ‘다운스트림(Downstream)’ 프로젝트라고 부른다.

[그림 1] 센트OS 스트림 구조 (출처:레드햇 공식 홈페이지³⁾)

센트OS 지원 중단 결정이 이뤄지자 오픈소스 커뮤니티에서는 매우 부정적인 반응이 나왔다. 말 그대로 ‘무료’ RHEL이 없어졌으니 이에 대한 대비책을 마련해야 했다. 그리하여 레드햇을 대신해 RHEL의 무료 복제판을 만드는 프로젝트가 추가로 생겨났다. 알마리눅스(AlmaLinux)나 로키리눅스(Rocky Linux)가 대표적인 센트OS의 대안 기술이다. 이런 대안 센트OS를 중심으로 별도의 기업용 유지보수 서비스도 나오고 있다.

레드햇은 센트OS 지원을 중단하고 센트OS 스트림을 만든 이유에 더 빠르게 RHEL의 가치를 전하고 협업을 증진하기 위해서라고 밝혔다.⁴⁾ 오히려 레드햇의 기술 방향을 센트OS 스트림으로 미리 공유하면서 일종의 ‘프리뷰 버전’으로서 고객이 RHEL의 방향성을 알고 대비할 수 있어 좋다는 의견도 밝혔다. ⁵⁾ 하지만 IT 매체 지디넷은 익명의 전·현직 임원 인터뷰를 통해 레드햇이 센트OS로 몰리는 고객을 유료 RHEL 고객으로 전환하기 위한 전략으로 센트OS를 없앴다는 입장을 전했다.⁶⁾

그럼 다시 처음 언급했던 올해 6월 발표로 돌아가 보자. 레드햇의 이번 발표에서는 RHEL 관련된 공개적인 코드는 센트OS 스트림 저장소에만 공개하겠다고 설명했다. 이 문장은 RHEL 코드는 이제 외부에 공개하지 않고 RHEL의 사전 공개 버전인 센트OS 스트림 코드만 오픈소스로 개방하겠다는 뜻이다. 이런 전략하에 REHL의 호환 배포판을 만드는 기업은 악영향을 받을 수밖에 없다. RHEL 유료 고객에게 RHEL 코드를 개방하긴 하지만 이용 계약 조항에 따로 RHEL 외부 배포를 금지하는 조항을 넣을 가능성이 크다. ⁷⁾ RHEL의 호환 배포판을 만드는 알마리눅스, 로키리룩스 등은 RHEL 코드 접근 접근에 제약이 생기면서 기술적인 부담을 얻을 것이며 개발에 드는 비용 및 시간도 늘어날 수 있다. 결과적으로 RHEL 관련된 유지보수 비즈니스에서 레드햇이 우위를 점할 수 있다.

오픈소스 진영은 레드햇의 이번 결정이 기업용 오픈소스 기술에 대해 고객의 권리를 빼앗는 것이라는 의견을 냈다. ⁸⁾ 물론 그런 입장 대부분은 센트OS를 만들었거나 RHEL 배포판을 두고 경쟁하는 곳에서 나오고 있다. 기업용 리눅스 제품을 제공하는 오라클, 수세, CIQ는 직접 RHEL 호환 기술을 공동으로 개발하기 위해 오픈ELA⁹⁾ 라는 단체를 출범시키기도 했다. 수세는 RHEL 호환 배포판을 만들기 위해 1천만 달러(약 132억 원)를 투자하겠다는 발표도 했다.¹⁰⁾

레드햇의 마이크 맥그라스 부사장은 이번 레드햇의 결정에는 문제가 없다는 입장을 밝혔다.¹¹⁾ GPL 라이선스를 위반한 것 아니냐는 비판에도 RHEL은 센트OS 스트림의 기술을 충분히 물려받기에 센트OS 스트림 코드 공개 자체로 GPL의 원칙을 지켰다고 대응했다.

마이크 맥그라스 부사장은 오픈소스 업계에서 RHEL의 다운스트림 코드를 다시 배포하며 성장하는 기업들의 방식이 옳은지 다시 한번 생각해봐야 한다고 설명했다. 기업용 오픈소스 시장이 성장하기 위해서도 단순히 오픈소스 기술을 복사하는 행위는 없어져야 한다는 것이다. 맥그라스 부사장은 ‘가치를 추가하거나 어떤 방식으로든 코드를 변경하지 않고 단순히 코드를 복사해 구축하는(rebuild) 방식은 모든 오픈소스 기업에 실질적인 위협이 된다’라며 ‘그런 단순 복사 및 구축하는 방식이 만연한다면 오픈소스 기술은 단순히 취미용이나 해커용 활동으로만 한정돼서 활용될 것’이라고 밝혔다.

오픈소스 기업의 핵심 경쟁자 ‘클라우드 업체’, 견제책은 라이선스?

레드햇 이전에도 경쟁 기업의 입지를 좁히기 위해 오픈소스 정책을 바꾸는 사례는 이미 존재했다. 여기서 중심은 대형 클라우드 기업이었다. 대형 클라우드 기업이 오픈소스와 관련한 관리형 기술을 제공하면서 기업용 오픈소스 기업의 강력한 경쟁 업체로 부상하고 있어 오픈소스 기업은 이를 견제하기 위해 라이선스를 변경하고 있다.

가령 인프라 프로비저닝 및 관리 기술을 개발하면서 오픈소스 업계의 새로운 유니콘 스타트업으로 부상한 하시코프(HashiCorp)는 8월 10일 자사의 오픈소스 프로젝트의 라이선스를 모질라 퍼블릭 라이선스(Mozilla Public License v2.0, MPL 2.0)에서 비즈니스 소스 라이선스( Business Source License, BSL 또는 BUSL이라고도 함) v1.1로 변경하겠다고 밝혔다. ¹²⁾ 하시코프 API, SDK, 기타 라이브러리 대부분은 MPL 2.0으로 유지했다.

하시코프 공동설립자 겸 CTO 아르몬 다드가(Armon Dadgar)는 라이선스를 변경한 이유에 “하시코프의 기술을 상업적 목적으로 활용하면서 실질적인 기여를 제공하지 않는 다른 공급업체 때문”이라며 “그러한 타 공급업체의 행동은 오픈소스 정신에 부합하지 않는다”라고 밝혔다.

약 10년동안 오픈소스 기업을 운영한 하시코프는 무료로 사용할 수 있는 개방형 소프트웨어를 지속적으로 제공하기 위해서는 수익 목적의 오픈소스 모델(commercial open source models)이 진화해야 하며 그 결과 BSL를 채택했다고 덧붙였다. BSL 1.1은 특정 조건 하에서 복사, 수정, 재배포, 비상업적 사용, 상업적 사용을 허용하는 소스 사용 가능 라이선스다.

다만 하시코프의 라이선스를 가이드라인을 살펴보면 사실상 하시코프의 오픈소스 기술은 앞으로 상업적으로 사용하기 어려워 보인다. 먼저 하시코프는 BSL를 적용하는 동시에 소스 코드의 광범위한 사용을 허용하는 사용 허가 항목을 추가했다. 여기서는 새로운 라이선스가 적용되면서 앞으로 하시코프의 오픈소스 기술을 이용하고자 하는 개발자와 기업은 하시코프의 ‘경쟁 제품’을 제공하는 경우를 제외하고 모든 비상업적 및 상업적 용도로 코드를 계속 복사, 수정, 재배포할 수 있다고 명시했다.

하시코프의 라이선스 FAQ 페이지 ¹³⁾에는 좀 더 구체적인 방향성을 공유했다. 하시코프가 표현하는 '경쟁 제품'이란 유료 지원 계약을 포함하여 제3자에게 판매되는 제품이며 하시코프 상용 제품의 기능과 상당히 겹치는 제품이라고 정의하고 있다. 테라폼을 호스팅하거나 임베딩하는 것이 경쟁 제품에 포함된다. 그 외 하시코프 솔루션을 통합해 유료 서비스를 만들 경우 별도의 논의를 해야 한다고 밝히기도 했다. 다시 말해 하시코프의 오픈소스 기술을 활용해 솔루션 및 서비스를 판매하는 경우 웬만하면 하시코프의 경쟁 제품이 될 것이다. 즉 많은 기업이 하시코프의 기술을 상업적으로 이용할 때 하시코프의 허락을 맡는 과정을 거쳐야 한다.

하시코프는 BSL 라이선스를 적용하기 전에 오픈소스 라이선스 전문가 및 기타 업계 이해관계자들과 상의하여 업계 관행에 부합하려고 노력했다고 밝혔지만, 하시코프 결정에 반발하는 개발자도 존재했다. 그 결과 나온 것인 오픈TF(OpenTF)¹⁴⁾라는 프로젝트다.

오픈TF는 하시코프의 라이선스 변경을 요구하는 프로젝트다. 이들이 하시코프의 결정에 반대하는 이유는 일단 하시코프가 제시한 ‘경쟁 제품을 제공하는 경우’라는 기준이 매우 모호하며 하시코프의 성장이 이를 사용해왔던 오픈소스 개발자 및 기업의 영향이 크다고 보고 있기 때문이다. 특히 하시코프의 대표 제품인 IaC(Infrastructure as code) 도구 ‘테라폼(Terraform)’이 성장하기까지 외부 벤더들의 역할도 크다고 지적했다.

오픈TF는 공식 입장문을 통해 “테라폼은 하시코프의 참여만으로 지금의 위치에 도달한 것이 아니며 공급업체를 포함한 전체 커뮤니티가 큰 역할을 했다”라며 “테라폼이 오픈소스가 아니었다면 기여는 결코 일어나지 않았을 것이다. 상업적 라이선스로 전환하여 기여자들이 앞으로 자신의 저작물을 사용할 수 없도록 하는 것은 매우 안 좋은 방식이다”라고 설명했다.

오픈TF는 테라폼 라이선스를 다시 MLP이나 아파치 라이선스 2.0으로 변경하는 것을 요구하고 있다. 또한, 상황이 여의치 않으면 향후 아예 프로젝트를 복사(포크)해 별도로 기술 개발을 이루겠다는 계획을 밝혔다.

물론 이런 오픈TF의 노력이 빛을 볼지는 아직 미지수다. 이미 기업용 오픈소스 기술을 운영하는 상당수의 기업이 비슷한 라이선스 변경 정책을 시행하고 있기 때문이다. 가령 아마존웹서비스(AWS)는 오픈소스 프로젝트인 엘라스틱서치의 코드를 가져와 상용 매니지드(관리형) 서비스 ‘AWS 엘라스틱 서비스’를 만들어 제공한 바 있다. 엘라스틱서치 운영사 엘라스틱은 AWS가 자사 오픈소스 프로젝트에 대한 기여 없이 기술을 사용하며 고객을 확보하고 있다는 점을 비난하며 라이선스를 아예 바꾸는 전략을 시행했다. 이전에 엘라스틱의 주요 제품에는 아파치 2.0 라이선스가 적용됐으나 2021년부터 엘라스틱 라이선스(Elastic License) 또는 SSPL(Server Side Public License)로 라이선스가 적용됐다. ¹⁵⁾이후 AWS는 엘라스틱의 결정에 반발하고 엘라스틱서치 코드를 복제한 후 AWS이 직접 오픈소스 프로젝트 ‘오픈서치(OpenSearch)’을 운영하고 있다.

엘라스틱은 “라이선스 변경을 통해 커뮤니티와 고객은 엘라스틱서치(Elasticsearch)와 키바나(Kibana) 소스 코드를 사용, 수정, 재배포 및 공동 작업할 수 있는 무료 개방형 액세스를 확보할 수 있다”라며 “또한 클라우드 서비스 제공자가 서비스 관리 계층의 소스 코드와 수정 사항을 공유하지 않고 제품을 서비스로 제공하지 못하도록 제한하면서 엘라스틱이 무료 개방형으로 배포하는 제품 개발에 대한 지속적인 투자를 보호하겠다”라고 설명했다. 사용자의 경우 엘라스틱이나 SSPL 둘 중에 원하는 것을 선택해야 했는데 이런 라이선스 정책으로 클라우드 업체가 엘라스틱 기술을 이용할 경우 엘라스틱과 협의를 거치도록 만들었다.

엘라스틱에서 도입한 SSPL 라이선스는 몽고DB가 2018년 처음 만든 라이선스다. 몽고DB도 당시 AWS와 같은 주요 클라우드 업체가 몽고DB를 통해 수익을 창출하는 것을 보고 이를 제지하기 위해 SSPL를 고안해 적용했다. SSPL에선 서비스 코드를 실행하는데 필요한 모든 것에 대한 소스를 공개해야 한다는 요구 사항이 있다. 해당 조항으로 클라우드 업체는 몽고DB 기반 서비스를 제공할 경우, 원치 않아도 모든 관련 소스 코드를 무조건 공개해야 했다. 덕분에 외부에서 몽고DB로 서비스를 만들고 수익 창출하는 것에 제약을 가할 수 있었다. 현재 레디스랩스(Redis Labs), 컨플루언트(Confluent) 등도 SSPL를 적용하고 있다.

참고로 앞서 언급한 BSL은 SSPL보다 유연한 라이선스로 알려져 있다. ¹⁶⁾BSL은 마이SQL 공동설립자 마이클 몬티 와이드디어스와 데이비드 액스마크가 만든 모델이다. BSL은 프리미엄(Freemium) 모델처럼 기본 서비스와 제품은 무료로 제공하고, 고급 기능과 특수 기능은 유료로 제공하는 비즈니스 모델이다.

BSL이 적용된 소프트웨어는 테스트 환경에서는 무료로 사용할 수 있지만, 외부에 판매될 때 실행할 수 있는 서버 및 CPU 등의 수를 제한할 수 있다. 정해진 횟수를 초과하여 사용하면 라이선스 비용이 발생한다. 또한, BSL 라이선스에는 만료 날짜가 있어서 특정 날짜 이후에는 GPL 등 사전에 정한 라이선스로 변경된다. 마이SQL 설립자들은 이런 라이선스 모델로 오픈소스 프로젝트 관리에 필요한 수익을 마련할 수 있을 것으로 보았다.¹⁷⁾실제로 최근 카우치베이스(Couchbase), 코크로치 랩스(Cockroach Labs), 센트리(Sentry) 등이 BSL를 채택했다.

카우치베이스는 ‘BSL이 오픈소스 제공과 독점 소프트웨어 제공 환경을 마련하는 적절한 절충안이라고 생각한다’라며 ‘BSL로 지속 가능한 성장을 위해 방어 가능한 경제 모델을 유지하며 확장된 커뮤니티가 당사 소프트웨어의 운영, 지원, 통합 및 사용에 익숙해질 수 있는 적절한 시간을 확보할 수 있다’라고 설명했다.¹⁸⁾

최근엔 이런 비슷한 정책이 생성형 AI 시장에서도 볼 수 있다. 바로 메타가 오픈소스 형식으로 만든 대형언어모델(LLM) ‘라마2(Llama 2)’의 사용료를 받는 방안을 고민하고 있다. 아직 확정된 것은 아니지만 일반 사용자에게는 라마2를 무료로 제공하고 클라우드 사업자에 한해 비용을 받겠다는 전략이 검토되고 있다.

마크 저커버그 메타 CEO가 올해 7월 분기 실적을 발표하면서 ‘마이크로소프트(MS), 아마존, 구글 같은 기업이 라마2 서비스를 재판매할 예정이라면 수익의 일부를 받아야 한다고 생각한다’면서 ‘단기적으로는 큰 수익이 될 것으로 생각하지 않지만, 장기적으로는 큰 수익이 될 수 있기를 바란다’라고 밝혔다. ¹⁹⁾

※ 참고문헌

번호	제목	작성자	조회수	작성
공지	[2024년] 오픈소스SW 라이선스 가이드 개정판 발간 file	support	5019	2024-01-03
공지	[2024년] 기업 오픈소스SW 거버넌스 가이드 개정판 발간 file	support	4087	2024-01-03
공지	[2024년] 공공 오픈소스SW 거버넌스 가이드 개정판 발간 file	support	4087	2024-01-03
공지	공개 소프트웨어 연구개발(R&D) 실무 가이드라인 배포 file	support	16514	2022-07-28
공지	공개소프트웨어 연구개발 수행 가이드라인 file	OSS	16276	2018-04-26
471	[10월 월간브리핑]금융분야 디지털 혁신에 따른 오픈소스 활용 및 관리의 중요성	support	1218	2023-10-30
470	[기획기사] 국내 금융 기업 오픈소스의 핵심은 ‘거버넌스 관리’	support	984	2023-10-30
469	[기고] 금융과 오픈소스 그리고 카카오뱅크의 오픈소스 활용 및 보안 관리	support	1663	2023-10-30
468	[9월 월간브리핑]오픈소스 기술, 자율주행·지능형 물류로봇 시장 혁신 견인	support	1287	2023-09-25
467	[기획기사] 물류 로봇 시장 속 오픈소스	support	1054	2023-09-24
466	[기고] 미래 자동차와 자율주행 오픈소스 소프트웨어	support	2465	2023-09-24
465	[8월 월간브리핑]기업은 왜 오픈소스 라이선스 정책을 변경하는가?	support	1523	2023-08-29
464	[기획기사] 오픈소스 기업의 비즈니스와 라이선스 정책 변경	support	1753	2023-08-29
463	[기고] 기업이 오픈소스를 활용하여 소프트웨어를 개발할 때 어떤 라이선스를 선택하는 것이 유리할까	support	1721	2023-08-29
462	[7월 월간브리핑]NIPA, 적극적인 오픈소스SW 개발 문화 확산 및 개발자 레벨업 지원	support	1149	2023-07-25