많은 회사들이 자체 개발하고 유지 관리 하는 오픈소스 소프트웨어를 기반으로 사업을 확장하고 있습니다. 그 과정에서 기존의 오픈소스 라이선스에서 상업적 사용에 제한을 두는 비FOSS(Non-Open Source) 라이선스로 변경하는 사례가 최근 수년 간 늘어나고 있습니다. 이와 관련한 주요 사례 중 하나로, 올해 큰 이슈가 되었던 것은 Terraform의 라이선스 변경입니다. 본 포스팅에서는 이에 대해 자세히 소개합니다.

오픈소스와 직접적으로 연결되어 있는 형용사 ‘free’는 일반적으로 ‘무료(gratis)’ 또는 ‘자유(libre), 제한 없음’ 두 가지 의미 중 하나로 사용되고 있습니다.2 업계에 잘 알려진 재밌는 일화가 있죠. Open Source Software의 개념이 처음 소개되었을 때엔(당시엔 ‘Free Software’라고 지칭), 공짜로 사용해도 되냐는 질문들이 쇄도했었다고 합니다(WIRED3).

Free Software Foundation의 Richard Stallman은 이에 대해 “Think free as in free speech, not free beer.”라고 Open Source software의 개념을 아주 유쾌하게 설명합니다.4

Richard Stallman

오픈소스의 딜레마라고도 알려진 사용과 기여의 불균형 현상 또한 일어났습니다. 오픈소스의 개념에 대한 크고 작은 혼란들이 중첩되어, 결국 Free Software는 Free and Open Source Software 혹은 Open Source Software라고 명칭을 변경하게 되고, ‘어떤 조건에서 어떻게 자유롭게 사용할 수 있는가’를 명확하게 하기 위해 오픈소스 라이선스들이 등장하게 됩니다.

10년 전, Cloud DB 개발사인 MariaDB의 CTO인 Michael Widenius는 2013년 ZDNet과의 인터뷰5에서, 오픈소스를 사용하면서도 개발 비용이나 프로젝트에 대한 금전적 지원을 하지 않는 것은 오픈소스의 취지를 악용하는 것이라고 말했습니다. 그가 말했던 ‘오픈소스의 취지’는 사용자의 행동에 대한 자유와 공동체에 대한 존중입니다. 이는, 자유롭게 사용하되, 소스코드의 발전을 위해 기여해야 한다는 것을 의미합니다. 하지만 자유롭게 ‘사용하기만’ 하는 사용자들로 인해 문제가 발생한다고 비난하고 있는 것입니다. 그는 MariaDB를 운영하면서, ‘결과물은 기대하지만, 인력과 비용 등의 기여는 하지 않는 이들’을 경험했습니다.

Michael “Monty” Widenius

당시 MariaDB와 같은 오픈소스 프로젝트는 1년에 100만 유로의 비용이 들었고, 그 중 절반은 커뮤니티를 관리하고, Review하고, Build하는 커뮤니티 운영 비용이었습니다. 사용자에게 기능(feature)에 대해 비용을 요구할 수는 있으나, 커뮤니티 운영에 대한 비용은 오롯이 개발사인 MariaDB의 몫이었습니다.

이러한 Open Source 프로젝트 운영을 위한 자금 조달 문제를 해결하기 위해, Widenius는 사용자 중 일부에게 비용을 지불하도록 강요하는 것을 골자로 하는 ‘Business Source License(BSL)’를 개발합니다. 그리고, 2016년 MariaDB는 BSL6 7v1.0을 발표하였습니다. BSL는 ‘Open Source 스타일의 상업적’ 라이선스로, MariaDB에서 제공하는 FAQ의 설명에 따르면, ‘Open Source software 본연의 혜택’과 ‘제품 혁신 및 유지 관리를 지속적으로 제공해야 하는 소프트웨어 개발자의 지속 가능성 요구’ 사이에서 서로에게 도움이 될 수 있는 균형(balance)을 위한 것이라고 말합니다.8

1BSL 또는 BUSL

2https://en.wikipedia.org/wiki/Gratis_versus_libre

3https://www.wired.com/2006/09/free-as-in-beer/

4“Free software” means software that respects users' freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software. Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.” We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do not mean the software is gratis.  What is Free Software? - GNU Project - Free Software Foundation

5"The more people are using it and, in these cases, abusing the whole idea of open source by not paying back either with development or money to help projects, it is actually destroying open source.”  Open source: Its true cost and where it's going awry by Monty Widenius | ZDNET

6https://fossa.com/blog/business-source-license-requirements-provisions-history/#:~:text=The%20Business%20Source%20License%20%28BSL%29%20is%20a%20middle,purposes%2C%20but%20there%20are%20limitations%20on%20commercial%20use.

7https://mariadb.com/bsl11/

8“to provide a mutually beneficial balance between the user benefits of true Open Source software that is free of cost and provides open access to all of the product code for modification, distribution, etc., and the sustainability needs of software developers to continue delivering product”  Adopting and Developing BSL Software | MariaDB

현재 Business Source License(BSL)는 MariaDB가 2016년 릴리스한 v1.0과, 2017년 Heather Meeker(IP 변호사이자 Open Source License 전문가)와 Bruce Perens(Open Source Initiative(OSI) 공동 창립자)의 의견을 바탕으로 만들어진 v1.1의 두 가지 버전이 있으며 현재 일반적으로 사용되는 BSL은 v1.1입니다.

v1.0, v1.1 두 버전 모두 특정 조건에서 복사, 수정, 2차 저작물 생성, 재배포, 비상업적 사용, 상업적 사용을 허용하는 기본 내용은 동일합니다. 그러나, v.1.1은 ‘vendor들이 BSL을 보다 쉽게 채택할 수 있도록 하기 위하여’ v1.1 버전을 만들었다고 설명합니다. v1.0 대비 주요 차이점은 아래와 같습니다.

• 변경 날짜(Change Date, BSL이 Open Source License로 전환되는 날짜): 소프트웨어 배포일로부터 4년 이내라는 조건이 추가됨. v1.0은 시간의 제약에 대한 언급 없음
• 변경 라이선스(Change License, BSL이 최종적으로 변환하는 Open Source License): GPL과 호환되어야 한다는 제한 사항 추가
• Additional Use Grant: v.1.0의 ‘Use Limitation’ 대신 도입. Licensor(License 제공자)가 Licensed code를 ‘production’에서 사용할 수 있는 상황을 제한하는 데 사용 가능(v1.0의 ‘Use Limitation’의 경우 라이선스가 부여된 소프트웨어를 사용할 수 없는 상황을 지정할 수 있었으므로, v1.0이 Blocklist였다면 v1.1에서 Allowlist로 변경되었다고 볼 수 있음)



HashiCorp는 Terraform9, Vegrant, Nomad 등 Cloud Computing Infrastructure provisioning, 보호, 실행, 연결할 수 있는 도구와 제품을 제공하는 S/W 회사로 2023년 8월 10일 BSL채택을 발표했습니다.10 앞으로 모든 HashiCorp의 제품들은 BSL v1.1로 출시, 배포됩니다.

성명문에서 HashiCorp는 Open Source code 및 프로젝트를 상업적 목적으로 활용하면서도 실질적 기여를 제공하지 않는 업체들이 있으며 이는 Open Source의 정신(자유로운 공유와 협업)에 부합하지 않는다고 설명합니다. 이러한 업체들의 행태가 사용자, 기여자, 파트너, 고객으로 구성된 비즈니스 커뮤니티의 성장과 유지에 위협이 된다는 것입니다. 또한, 무료로 사용할 수 있는 개방형 S/W를 지속적으로 제공하기 위해 ‘상업적 오픈소스 모델’이 진화해야 한다고 주장합니다.

이러한 ‘진화’의 방법으로 HashiCorp는 라이선스의 변경을 선택했습니다.11

9Terraform은 2009년 HashiCorp가 개발하여 오픈소스로 공개한 인프라스트럭처 자동화 도구(IT 인프라를 설정하고 관리하는 작업을 코드로 자동화하기 위한 도구)로 이를 사용하면, 서버나 네트워크와 같은 IT 인프라를 수동으로 설정하지 않고, 코드로 그 설정을 작성할 수 있습니다. 구축시간의 단축, 오류 발생 가능성의 감소 및 여러 클라우드 업체를 지원하기 때문에, 동일한 코드로 서로 다른 클라우드 환경에 적용할 수 있는 등의 장점을 바탕으로 널리 사용되는 기술입니다.

10“That is why today we are announcing that HashiCorp is changing its source code license from Mozilla Public License v2.0 (MPL 2.0) to the Business Source License (BSL, also known as BUSL) v1.1 on all future releases of HashiCorp products. HashiCorp APIs, SDKs, and almost all other libraries will remain MPL 2.0.”  HashiCorp adopts Business Source License

11“There are other vendors who take advantage of pure OSS models, and the community work on OSS projects, for their own commercial goals, without providing materialcontributions back. We don’t believe this is in the spirit of open source.
As a result, we believe commercial open source models need to evolve for the ecosystem to continue providing open, freely available software.”  HashiCorp adopts Business Source License

앞서 설명했듯이, BSL v1.1은 ‘변경 라이선스’와 ‘변경 날짜’를 지정할 수 있으며 ‘Additional Use Grant’를 통해 ‘production’에서 사용할 수 있는 상황을 제한할 수 있는데, HashiCorp는 이들 항목에 대해서 아래와 같이 정리하였습니다.

• 변경 날짜: 4년 (BSL v1.1의 최대치 적용)
• 변경 라이선스: BSL v1.1에서 MPL 2.0으로 ‘변경 날짜’ 이후에 전환(MPL 2.0은 GPL 2.0 및 이후 버전과 호환되기 때문에12, BSL v1.1의 기본 조건을 만족하고 있음)
• Additional Use Grant: 라이선스 변경 결정에 따라, 향후 HashiCorp의 모든 저작물들은 Open Source와 같이 복사, 수정, 재배포, 비상업적 사용, 상업적 사용을 허용하지만, ‘HashiCorp의 제품과 경쟁하지 않는다’는 특정 조건 안에서만 그 모든 권리를 누릴 수 있음13

이 중 마지막에 있는 ‘Additional Use Grant’ 부분이 HashiCorp의 라이선스 변경 시 가장 큰 이슈가 되는 부분입니다. HashiCorp의 제품들 중 특히 Terraform은 현재 공급되는 가장 인기 있는 코드형 인프라(Infrastructure as Code, IaC) 자동화 툴 중 하나이기 때문에, IaC 관련 업계를 비롯한 Open Source 커뮤니티는 HashiCorp의 이러한 결정이 ‘Terraform을 중심으로 구축된 전체 커뮤니티와 생태계를 위협한다’고 비판하고 있습니다.

12https://www.mozilla.org/en-US/MPL/2.0/

13“You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.”

HashiCorp의 BSL v1.1의 적용에 따라 2023년 8월 15일 Gruntwork, Spacelifts, env0, Scalr 등이 주축이 되어 OpenTF가 결성됩니다. 주요 목적은 Terraform이 항상 진정한 오픈소스(Truly Open Source - always)로 유지되도록 하는 것이며, OpenTF는 HashiCorp에 Terraform을 다시 Open Source License로 전환할 것을 촉구합니다. 만약 이러한 요구가 받아들여지지 않을 경우, 기존 MPL License의 Terraform fork하여 여러 회사에서 운영하는 ‘재단(Foundation)’을 통해 유지 관리한다는 계획이었습니다.

그 후, 9월 20일, OpenTF는 Linux Foundation과 손잡고 OpenTofu 프로젝트를 Linux Foundation 산하의 커뮤니티 프로젝트로 발표하였습니다. OpenTofu 프로젝트는 오픈소스 버전의 최신 Terraform을 Fork하여 기존과 같이 오픈소스로 개발 및 유지 관리하는 것이 목표입니다.

HashiCorp의 결정에 대해 지금 당장 판단하기는 어렵습니다. 오픈소스와 사업 사이에는 너무 많은 변수가 있고, ‘성공한’ 오픈소스의 기준은 시장에서의 가치이기 때문입니다. 오픈소스를 기반으로 사업을 하는 개발사의 라이선스 변경은 해당 프로젝트와 관련된 다른 프로젝트, 커뮤니티, 기업에게 크고 작은 직간접적 영향을 미치기 때문에, 누구에게도 쉬운 결정은 아닙니다. 하지만 HashiCorp의 사례와 같이 논란과 비난에도 불구하고 Open Source 프로젝트를 기반으로 사업을 추진하는 기업의 라이선스 변경은 최근 몇 년간 계속되어 왔습니다.

올해 8월 NIPA에서 운영하는 오픈소스 위키 홈페이지에 기획 기사로 <오픈소스 기업의 비즈니스와 라이선스 정책 변경>이라는 기사가 나왔습니다. 전통적으로 오픈소스 기업은 기업용 서비스 즉 기술지원 및 유지 관리를 통해 수익 창출을 모색해 왔는데, 시대가 변하고 경쟁사가 많아지면서 오픈소스 기업의 생존 전략이 달라지고 있다는 내용인데요. 최근 몇 년 사이 오픈소스 업계에 다양한 목소리와 이슈들이 늘어난 것이 느껴집니다.

포스팅 하단에 BSL 관련 레퍼런스로 다양한 자료를 남겨놓았으니 참고하시면 좋겠습니다.

오픈소스 프로젝트를 주도적으로 개발하고, 이를 기반으로 사업을 추진하던 기업들의 라이선스 변경은 최근 몇 년 간 계속되어 왔습니다. 다음은 기존의 오픈소스 라이선스를 상업적 사용에 대한 제한을 포함하는 비FOSS 라이선스로 변경한 회사들의 사례를 표로 정리한 것입니다.

아래의 표를 보면, 대부분의 대상 기업들이 MariaDB, Redis, MongoDB 등 클라우드 기반의 서비스를 위한 서버 측 소프트웨어 개발사임을 확인할 수 있습니다.

MariaDB는 2016년 BSL(Business Source License) 라이선스를 릴리즈하고, 이를 자사 제품에 처음 적용하였습니다. BSL은 라이선스 내에 명시된 일정 기간 동안 라이선스 사용 제한 조건을 부여하는 라이선스로, BSL이 적용된 소프트웨어는 라이선스에 명시된 기간 이후, 지정된 오픈소스로 전환됩니다.

지난 3월 라이선스 변경을 발표한 Redis는 이미 수차례에 걸쳐 자사 제품의 라이선스를 변경해왔고, 라이선스 변경 제품의 범위 또한 계속 확장되어 왔습니다. Redis의 최초 라이선스 변경은 Redis Modules을 AGPL 3.0에서 Apache2 modified with Common Clause로 변경하는 것이었습니다. 이후 Redis는 RSAL(Redis Source Available License)라는 자체 라이선스를 만들어 Redis Modules에 변경 적용하고, 점차 그 대상 소프트웨어의 범위를 확장하고 있습니다.

Sentry는 2019년 BSL로 변경하였으나, 2023년 소프트웨어를 서비스 형태로 제공하는 회사에 최적화된 FSL라이선스로 재 변경하였습니다.

MongoDB, Confluent, Timescale, Elastic 등도 각각 SSPL, Confluent Community License, Timescale License, Elastic License의 자체 라이선스를 만들고, 오픈소스 라이선스가 적용되어 배포되던 자사 제품 및 서비스를 자체 라이선스로 변경 적용하였습니다.

Cockroach Labs, Couchbase, HashiCorp, ArangoDB는 오픈소스로 배포되던 자사의 소프트웨어를 BSL(Business Source License)로 변경 적용하였고, Airbyte는 Elastic License로 변경하였습니다.

Redis와 Elastic은 자체 라이선스와 SSPL 둘 중 하나를 선택할 수 있도록 Dual Licensing 정책을 취하고 있습니다. Dual Licensing은 하나의 소프트웨어에 두 가지 이상의 서로 다른 라이선스를 적용하여 배포하는 방식입니다. 이 경우 사용자들은 적용된 라이선스 중에서 그들 자신에게 적합한 라이선스를 선택하여 사용할 수 있습니다.

변경 라이선스들의 공통적인 내용은 누구나 소스 코드를 확인할 수 있으며 사용, 복사, 배포, 제공 및 파생 저작물의 생성을 허용하는 ‘사용 가능 소스’이나, ‘상업적 사용이 제한’된다는 점입니다.

아래의 표는 각 라이선스의 주요 내용을 간략히 정리한 것으로, 라이선스 별 사용 제약 사항에 대해 보다 상세히 확인할 수 있습니다.

대개, 제 3자에 대한 서비스 제공을 제한하고 있으며, 지난 포스팅에서 살펴봤던 HashiCorp의 BSL(Business Source License) 사용 조건이나 및 FSL(Functional Source License) 및 Confluent Community License의 경우, 직접적으로 ‘경쟁업체’의 상업적 사용의 제한을 명시하고 있습니다.

FSL은 BSL을 변형하여 SaaS(Software as a Service) 회사에 적합하게 설계된 라이선스로, ‘경쟁 사용’의 금지를 라이선스 내 명시하여 BSL 보다 사용 제한 조건이 강화되었으나, 추가적인 사용 제한 조건이 없는 라이선스입니다.

FSL은 오픈소스 라이선스로의 전환 기간이 ‘출시 후 2년’으로 BSL의 ‘평균 4년’ 대비 짧고, 전환되는 오픈소스 라이선스는 허용적(Permissive) 라이선스로 분류되는 Apache 2.0 또는 MIT 라이선스만으로 제한하는 등의 차이점을 가지고 있습니다. 이러한 FSL의 특징은 회사가 초기에 자신들의 제품에 대한 충분한 보호를 받으면서, 사용자들이 나중에 소프트웨어를 자유롭게 사용할 수 있게 해줍니다.

FSL은 SaaS(Software as a Service) 회사에 최적화되어 있으므로, 소프트웨어를 직접 설치해서 사용하는 '온프레미스'(On-Premises) 방식이나, 소프트웨어 일부를 다른 제품에 통합시켜서 사용하는 '라이브러리 내장'(Library Embedding) 방식의 비즈니스 모델에서는 FSL의 제한 사항이 지나치게 엄격할 수 있습니다.

‘Common Clause’는 ‘판매’에 대한 권리를 제한하는 조건을 명시합니다. 여기서 설명하는 ‘판매’는 위의 표에서 확인할 수 있는 바와 같이 소프트웨어의 기능에 전적으로 또는 실질적으로 의존하는 제품이나 서비스를 제 3자에게 제공하는데 필요한 모든 권리의 행사를 의미합니다. 다만 ‘Common Clause’는 기존의 오픈소스 라이선스에 추가하여 사용하도록 설계되어 있어 주의가 필요합니다. Redis의 경우, Redis Modules의 Apache2 modified with Common Clause로의 최초 변경 당시 많은 사용자들이 해당 라이선스를 오픈소스 라이선스인 Apache2와 같은 조건의 라이선스로 잘못 이해하는 경우가 많아 결국 RSAL(Redis Source Available License)로 라이선스를 다시 변경하게 됩니다.¹

SSPL(Server Side Public License)은 위의 표에서 설명하는 다른 라이선스들과 달리 간접적 방식으로 경쟁업체의 상업적 사용을 제한합니다.

앞서 설명했듯이 SSPL은 MongoDB에서 릴리즈한 라이선스로 오픈소스 라이선스인 AGPL 3.0 라이선스를 기반으로 작성된 라이선스 입니다. SSPL은 GPL 3.0의 ‘13번 조항’을 변경하여 작성된 라이선스인 AGPL 3.0의 역시 ‘13번 조항’만을 변경하여 작성되었습니다. 따라서, 13번 조항을 제외한 나머지 조항들은 GPL 3.0과 동일한 조건이 적용됩니다.

AGPL 3.0의 13번 조항(‘네트워크를 통해 전달되는 소프트웨어’에 대한 조항)은 사용자에 의해 수정된 프로그램의 원본 소스 코드를 네트워크를 통해 상호작용하는 모든 사용자에게 무료로 제공할 것을 명시하고 하고 있습니다. 이에 따라 AGPL 3.0 라이선스가 적용된 프로그램의 경우, 서버에서 실행되는 소프트웨어에도 코드 공개 의무가 부여됩니다. 다시 말해 AGPL 3.0 라이선스는 네트워크 상에서 사용되는 소프트웨어도 Copyleft 원칙을 적용하는 것을 목표로 합니다.

SSPL은 SSPL이 적용되지 않은 다른 구성 요소까지 공개하도록, AGPL 3.0의 13번 조항을 ‘프로그램 또는 수정된 버전의 기능을 제 3자에게 서비스로 제공하는 경우, 서비스 소스 코드를 네트워크 다운로드를 통해 모든 사람이 무료로 이용할 수 있도록 해야한다’고 변경하고, ‘서비스 소스 코드’에 서비스와 상호 작용하는 모든 구성 요소를 포함하도록 하고 있습니다.

그런데, 이와 같이 배포하는 소프트웨어 및 서비스와 관련된 모든 구성요소에 대한 공개를 강제하는 것은, ‘오픈소스’의 조건에 위배됩니다. 오픈소스 라이선스를 인준하는 단체 중 하나인 오픈소스 이니셔티브(OSI)에서 제정한 오픈소스 정의(Open Source Definition)의 10가지 항목 중 9번째 항목은 ‘사용권이 부여된 소프트웨어와 함께 배포되는 다른 소프트웨어에 제한을 두어서는 안된다’는 내용입니다. SSPL은 서비스 전체 구성요소의 공개라는 극단적인 공개 조건을 통해 해당 항목을 위반하고 있어, 오픈소스 라이선스의 조건에 부합하지 않음으로 비FOSS 라이선스로 간주됩니다.²

    
1참조 링크: https://commonsclause.com/
        
2참조 링크: https://www.gnu.org/licenses/agpl-3.0.html, https://www.mongodb.com/legal/licensing/server-side-public-license

라이선스 변경의 결정은 비즈니즈 전략, 시장 상황, 고객의 요구사항 등 다양한 요인들을 종합적으로 고려해서 이루어집니다. 특히 클라우드 기반의 서비스를 위한 서버 측 소프트웨어 개발사들이 라이선스 변경 결정을 확대해 가는 이유를 다음과 같이 생각해볼 수 있습니다.

오픈소스는 관련 기술과 서비스 시장 확장 및 사용자 확보를 위해 흔히 사용되는 기술 개발 전략 중 하나입니다. 스타트업 등 작은 기업이 기술 홍보를 위해 오픈소스로 개발을 시작하지만, 커뮤니티 및 개발자들 간 협력을 이끌어 내는 것은 쉬운 일이 아닙니다. 결국, 오픈소스 개발사가 유지 보수를 거의 책임지는 형태로 운영되는 사례가 많습니다. 특히, 서버 측 소프트웨어는 복잡하고 방대한 시스템을 다루는 경우가 많아 개발 및 유지 보수에 상당한 투자와 노력이 필요합니다. MariaDB는 라이선스 변경 당시, 일반적으로 30% 정도인 서비스 수익으로는 개발 조직을 유지하기 어렵기 때문에, 소프트웨어 개발을 지속할 수 있는 새로운 비즈니스 모델의 구축하기 위하여 라이선스를 변경한다고 발표했었습니다.

대형 IT 기업들의 클라우드 시장의 진출 및 하이브리드 서비스(기업 설치형 프로그램과 클라우드 시스템을 병행하여 서비스 제공)의 확산 등으로 클라우드 시장의 경쟁은 심화되고 있습니다. 차별화된 서비스 제공은 기업의 수익성 및 경쟁력 강화의 기본 조건입니다.

그러나, 특정 서비스의 기반이 되는 오픈소스의 주요 개발사의 경우, 공개된 개발 과정을 통해 핵심 기술과 전략이 공개적으로 드러나기 쉬워, 경쟁업체에 쉽게 파악될 수 있다는 점이 부담으로 작용할 수 있습니다. MongoDB와 ArangoDB 등은 ‘오픈소스 프로젝트가 흥미를 끌면 대형 클라우드 벤더는 이를 통한 사업적 기회를 쉽게 포착하고 그로 인해 시장에서의 경쟁은 점점 치열해지지만, 정작 커뮤니티에 기여하는 이는 아무도 없다’며, 라이선스의 변경을 결정했습니다. Redis는 ‘성공한 오픈소스를 독점 서비스로 포장하고 수익원을 창출하는 클라우드 사업자를 막기 위해서’ 라이선스를 변경했다고 설명했습니다.

차별화된 기술의 보호를 위해 기업 내부 전용 소스를 별도로 관리하게 되면, 결국 개발 비용이 상승하여 오픈소스 개발을 통한 이득은 상쇄됩니다.

또한, 대규모 시스템의 특성상 라이선스 관리 상의 문제도 예상할 수 있습니다. 다양한 종류의 라이선스가 적용되는 시스템의 경우, 라이선스 별 소프트웨어의 호환성 문제도 고려해야 합니다. 비FOSS 라이선스로의 전환은 라이선스 관리의 간소화 및 라이선스 관련 법적 이슈 방지를 위한 방편이 될 수도 있습니다.

Wrap up

이상적인 오픈소스는 프로젝트에 대한 깊은 이해를 가진 개발자에게 해당 기능에 대한 검토 권한을 부여함으로써, 커뮤니티 내에서 책임과 권한을 공유하여 개발 부담을 나눕니다. 그러나 각 기업은 서로 다른 서비스 방향을 추구하기 때문에 새로운 기능을 추가할 때마다 많은 논의가 필요합니다. 때로는 주도권 확보를 위해 메인테이너 또는 검토자(리뷰어)의 권한을 분배하지 않는 경우도 있습니다. 어떤 방식이 개발 시간과 비용 부담을 줄이는냐는 상황에 따라 달라질 수 있습니다.

오픈소스 개발 방식은 공유를 통한 다양한 기술의 혁신을 이끌어냈습니다. 그러나 이것이 항상 사업의 성공을 보장하는 것은 아닙니다. 따라서, 오픈소스 개발의 궁극적인 목표인 기술 발전과 사업 성공 사이에서 균형을 찾는 것이 중요하며, 이를 위한 다양한 시도와 시행착오가 필요하다는 것을 알 수 있습니다.

아직까지 라이선스를 변경한 개발사의 결정이 사업적으로 적절하였는지 판단할 수 있는 근거는 없습니다. 또한, 커뮤니티의 대안 프로젝트나 fork 프로젝트가 원래 프로젝트의 성공을 뛰어넘는 경우도 없었습니다.

라이선스 변경은 ‘사업적’ 상황을 보완하기 위한 여러 전략적 시도 중 하나로 볼 수 있으며, 그 효과나 적절성에 대한 판단은 아직 이르다고 생각됩니다. 그러나, 비FOSS 라이선스로의 변경 사례가 계속될 것인지, 이에 대한 오픈소스 커뮤니티의 대응은 어떻게 변해갈 것인지 지켜보는 것은, ‘상업적’ 오픈소스가 진화해가는 방향을 가늠할 수 있는 좋은 지표가 될 수 있을 것입니다.

감사합니다.

Samsung Research S/W혁신센터의 황서영입니다.

[참고 1] MPL 2.0, GPL 호환성 보장 관련 부분 발췌14

14https://www.mozilla.org/en-US/MPL/2.0/

[참고 2] BSL 1.0 vs. 1.1

[참고 3] HashiCorp's BSL v1.1

[Business Source License 1.1] Business Source License 1.1 (hashicorp.com)

Parameters

Term

[참고 4]  APGL 3.0 라이선스와 SSPL 각각의 13번 항목