쉐어소스 등 오픈소스 소프트웨어 라이선스와 비슷해 보이는 (가칭)유사 라이선스로의 전환이 기업의 소프트웨어 유지보수에 미치는 영향 –신동명 연구소장 (엘에스웨어)
최근 Elastic, MongoDB, 그리고 최근 IBM에 인수된 HashiCorp 등 OSS(Open Source Software)사업을 영위하는 업체들이 자사 OSS(Open Source Software)의 라이선스를 (가칭)유사 라이선스로 전환하는 사례가 빈번해지고 있어, 이 소프트웨어를 사용하는 기업들의 주의가 필요하다.
유사 라이선스는 여러 가지 측면에서 OSS(Open Source Software) 라이선스와 유사한 특징을 지니고 있지만, 특정 조항으로 인해 OSS(Open Source Software) 라이선스로 분류할 수 없는 라이선스이다. SSPL(Server Side Public License), RSAL(Redis Source Available License), BSL(Business Source License) 등은 각각의 독특한 특징을 가지고 있으며, 이들 특징이 OSS(Open Source Software) 라이선스 단체인 OSI(Open Source Initiative)가 제시하는 기준들을 벗어나기에 유사 라이선스로 분류한다. 예를 들어, OSI(Open Source Initiative)는 자유로운 재배포, 차별 금지, 소스코드 사용 제한 금지 등을 OSS(Open Source Software) 라이선스의 조건으로 제시하고 있다. 그러나 SSPL(Server Side Public License)이나 RSAL(Redis Source Available License)은 클라우드 서비스 제공자 등을 대상으로 상업적 사용을 금지하고, BSL(Business Source License)은 일정 기간 상업적 사용을 제한하는 등 다양한 제한을 규정하고 있다.
이러한 제한 대상이나 기간이 한정되어 있는 점 외에는 소스코드가 공개되며, 제한 대상이 아니면 사용 시, 비용이 청구되지 않는 점 등에서 OSS(Open Source Software)와 유사해 보일 수 있으므로, 이러한 소프트웨어를 사용할 때에는 OSS(Open Source Software)로 착각하지 않도록 더욱 조심해야 한다.
이러한 유사 라이선스의 등장은 클라우드 서비스 제공자(CSP)로 인해 기존 OSS(Open Source Software) 비즈니스 모델로는 이익을 내기 어려운 경우, 또는 더 많은 이익을 추구하고 싶지만 OSS(Open Source Software) 개발 모델의 이점도 유지하고 싶은 OSS(Open Source Software) 개발사의 고민에서 비롯된 결과라고 볼 수 있다.
최근 들어 쉐어소스 소프트웨어 라이선스나 소스 접근 가능 소프트웨어 라이선스와 같이 OSS(Open Source Software) 라이선스처럼 보이지만 OSS(Open Source Software) 라이선스보다 더 제약이 가해진 유사 라이선스로 전환되는 사례가 종종 발생하고 있다. 이는 오픈소스를 사용하는 기업이 소프트웨어 유지보수 과정에서 주의해야 할 요소를 하나 더 추가하는 결과를 초래하고 있다. 이러한 라이선스 전환은 이미 개발된 기존 소프트웨어에는 영향을 미치지 않지만, 이후의 유지보수 과정이나 자주 사용하던 OSS(Open Source Software)를 새로운 프로젝트에 사용하려는 상황에서 라이선스 전환 여부를 인지하지 못함으로 인해 의도치 않은 라이선스 위반을 초래할 수 있으므로 주의가 필요하다.
OSS(Open Source Software)는 그 라이선스 조건 하에서 사용할 수 있다는 점은 잘 알려져 있다. 하지만, OSS(Open Source Software)의 라이선스가 생물처럼 변경 또는 전환될 수 있다는 점을 간과하는 경우가 많다. 라이선스의 중요성을 인지하고 있는 사람이더라도 처음 사용할 때 라이선스를 확인하지만 이후에는 새삼스럽게 다시 검토하는 경우가 별로 없다.
그러나 OSS(Open Source Software) 라이선스는 종종 부분 변경(ex: GPL 2.0 -> GPL 3.0)이 되거나, 다른 라이선스로 전환된다. 많은 사람들이 기여한 OSS(Open Source Software)는 라이선스 변경 과정이 매우 논쟁적이고 쉽지 않지만, 기업이 주도적으로 개발하는 OSS(Open Source Software)는 비교적 수월하게 라이선스 변경이 이루어질 수 있다.
또한, 최근에는 유사 라이선스로 변경되는 OSS(Open Source Software)가 많이 등장하고 있다. 앞서 소개한 Elastic, MongoDB, HashiCorp가 개발한 소프트웨어가 그 예다. 이러한 소프트웨어를 구성요소로 사용하고 있었다면, 구성요소를 자동 업데이트만 하더라도 변경 또는 전환된 라이선스를 위반할 수 있다.
이미 컴플라이언스 툴을 적극적으로 활용하고 있는 기업이라면, 라이선스 변경 및 전환에 대한 인지 및 점검이 용이할 수 있다. 그러나 그렇지 않은 대부분의 기업에게는 이러한 라이선스 변경이나 전환이 잘 숨겨놓은 함정처럼 느껴질 수 있을 것이다. 의도된 것이라기보다는 OSS(Open Source Software)의 배포 방식에 기인한 필연적 상황이다. 우리가 보험이나 쇼핑몰을 사용할 때, 사전에 등록을 하고 등록 과정에서 제공한 연락처 정보를 통해 이용 약관이 변경될 때 개별적으로 고지받는 것과는 달리, OSS(Open Source Software)는 개발자나 메인테이너에게 별도 사용 허락을 받지 않고 사용하기 때문에 라이선스 변경 및 전환 여부를 개별적으로 고지할 방법이 없다. 따라서 부지불식간에 라이선스가 변경된 것처럼 느낄 수 있는 것이다.
물론, OSS(Open Source Software)의 저장소나 소스코드의 Readme 파일을 확인하면 라이선스 변경 여부는 알 수 있다. 그러나 대부분의 개발자는 소프트웨어의 인터페이스가 변경되지 않는 한, 사용 중인 수많은 OSS(Open Source Software)의 라이선스 변경 여부를 매번 확인하지 않고 그저 새로운 버전으로 업데이트만 한다. 현대적 개발 환경에서는 패키지 관리자가 자동으로 최신 버전으로 소스코드 업데이트를 도와주기 까지 해주기 때문에, 라이선스가 변경되었는지 모른 채로 라이선스를 위반하는 상황이 발생할 수 있다. 자동화된 패키지 관리 시스템이 라이선스 위반을 부추기는 결과를 낳게 된다.
물론, 유지보수 과정에서 발생한 문제라면 고의성이 없기에 이러한 상황에서 바로 고소까지 진행하고 철저한 공방이 이루어지지는 않을 것이라고는 생각하나, 새로운 프로젝트를 시작한다면 기존에 잘 사용하던 OSS(Open Source Software)가 아직도 OSS(Open Source Software)인지, 라이선스는 변경 또는 전환되지 않았는지 확인해 보아야 할 것이다.
오픈소스 라이선스 돌다리도 항상 두들겨 보고 건너야 하는 시대가 되었다.
