최근 대부분의 개발 프로젝트에서는 오픈소스가 사용되고 있습니다.
매우 작은 모듈 또는 라이브러리만 사용된 경우에서부터 대부분이 오픈소스 코드로 개발된 경우에 이르기까지 그 사용 양태는 매우 다양합니다. 또한 전통적 의미의 소프트웨어뿐만 아니라 임베디드 등 영역의 프로젝트에서도 오픈소스가 많이 사용되고 있습니다. 이러한 상황에서, 많은 IT 기업들은 오픈소스의 사용과 관련하여 발생할 수 있는 법적 리스크를 줄이기 위해 오픈소스 라이선스에 대한 교육 프로그램을 진행하고 있습니다.
하지만 위와 같은 교육 프로그램을 운영하기 어려운 중소규모 업체나, 또는 최근 모바일 앱 시장에 진입한 신규 개발인력의 경우, 오픈소스를 사용하는 개발자들 스스로 라이선스와 관련된 여러 이슈들을 연구해야 하는 상황에 처해 있는 경우가 많습니다.
이하에서는 위와 같이 어려움을 겪고 있는 개발자 분들께 도움을 드리고자, 대표적인 오픈소스 라이선스의 종류 및 내용을 개괄해 본 뒤 개발자의 입장에서 유의해야 할 점에 대해 말씀드리고자 합니다.
1. 오픈소스 라이선스의 종류
현재 OSI (Open Source Initiative)가 오픈소스의 개념에 부합한다고 인정한 오픈소스 라이선스만 해도 70개 정도나 됩니다. 그러나 실제로는 대부분의 경우 MIT License, Apache License, BSD License, Mozilla Public License, Eclipse Public License, GPL V2 그리고 LGPL 정도만이 사용되고 있습니다.
이하에서는 우선 이 중 다시 사용빈도가 높은 MIT, Apache, GPL V2및 LGPL에 대해 보다 자세하게 살펴봅니다.
가. MIT License
이 라이선스는 MIT에서 학생들의 개발 프로젝트 배포를 위해 만든 라이선스입니다. 사용상 제약이 거의 없는 느슨한 라이선스라고 할 수 있습니다.
사용자는 재배포시 MIT License의 사본만 첨부하면 원 코드를 마음대로 개작, 변경할 수 있고 상용 소프트웨어를 포함하여 어떤 용도로도 사용할 수 있습니다. 또한 사용자는 재배포시 소스코드를 제공할 필요도 없습니다. 현재 MIT License는 jQuery, Ruby on Rails 및 X Window 등에 사용되고 있습니다.
나. Apache License
이는 Apache Software Foundation에서 아파치 서버 코드의 배포를 위해 만든 라이선스입니다.
역시 재배포시 라이선스 사본을 첨부하면 마음대로 개작, 변경, 상업적 용도로 사용 등이 가능하며, 소스코드 공개 의무 또한 없습니다. MIT License와 구별되는 점이라면, 해당 소프트웨어의 전부 또는 일부가 특허에 의해 보호되고 있는 경우, 그 특허에 대한 명시적인 (무료) 라이선싱 수단을 Apache License 제3조를 통해 제공하고 있다는 것입니다. 현재 이 라이선스는 Apache, SVN, NuGet, Android 등에 사용되고 있습니다.
다. GPL V2
GPL (GNU General Public License)은 Open Software Foundation (OSF)에서 만든 자유 소프트웨어 라이선스로서, 공익적 요소를 유지하기 위해 상당히 많은 제약 사항을 포함하고 있습니다. GPL V2는 1991년에 발표된 GPL의 두 번째 버전으로 카피레프트 진영에서 가장 선호되고 있는 라이선스이며, 현재 Linux 커널, Git, WordPress 등에 사용되고 있습니다.
이 라이선스에 따르면 사용자는 마음대로 변경, 개작할 자유는 있지만 이러한 2차적 저작물(derivative works)을 재배포하는 경우 반드시 소스코드를 공개해야 하며, 재배포 또한 GPL V2에 의하여 이루어져야 합니다. 또한 소스코드를 공개하지 않는 경우에는 바이너리도 배포가 불가능합니다.
라. LGPL
LGPL (Lesser GPL)은 GPL을 기반으로 GPL의 강력한 제약을 조금 완화해 준 라이선스라 할 수 있습니다. GPL과 MIT License의 절충 형태라 보시면 됩니다. 애초에 라이브러리 연결을 염두에 두고 만들어진 라이선스이며, 현재 수많은 오픈소스 라이브러리의 배포에 사용됩니다.
사용자는 마음대로 변경, 개작할 자유가 있으며 2차적 저작물의 재배포시 소스코드를 공개해야 한다는 점은 GPL과 같습니다. 그러나 LGPL로 배포된 라이브러리를 단순히 링크하는 경우에는 링크된 소프트웨어의 소스코드를 공개할 필요가 없습니다. 동적링크를 사용하는 경우(DLL로)에는 아무런 제약이 없으며, 정적링크를 사용하는 경우에는 재배포시 (라이브러리를 수정하여 재컴파일 할 수 있도록) 링크된 프로그램의 오브젝트 파일을 제공하면 됩니다.
2. 개발자 입장에서 유의해야 할 점
최근 우리 기업들이 오픈소스를 사용하면서 라이선스를 준수하지 않아 외국에서 소송을 당하는 사례들이 발생하고 있습니다. 결국 라이선스를 위반했다고 인정되면 그 라이선스를 통해 배포된 오픈소스 코드를 사용할 권리를 상실하는 것이므로, 패소한 기업은 라이선스를 준수하고 계속 제품 또는 서비스를 판매해야 하는 상황에 이르게 됩니다.
물론 이러한 소송의 경우 원고가 비영리단체이며 라이선스를 준수하면 원래 무료로 사용 가능한 상황이었다는 점에서 인정되는 손해배상액이 다른 침해소송에 비해 상대적으로 적은 액수가 되기는 합니다만, 그래도 소송수행을 위해 국내 및 해외 대리인을 선임하는 등에 소요되는 수억원의 비용은 중소규모 업체 입장에서는 부담스러울 수밖에 없습니다.
게다가 2차적 저작물의 재배포시 전면적인 소스코드 공개를 요구하는 GPL V2와 같은 라이선스를 위반한 경우에는, 결국 회사에서 개발한 소프트웨어의 소스코드를 모두 공개하지 않으면 제품 또는 서비스의 발매가 불가능한 상황에 이르게 될 수 있으므로 더욱 각별히 유의할 필요가 있다고 생각됩니다.
결국 사용하고자 하는 오픈소스 코드가 어떠한 라이선스로 배포된 것인지, 그리고 그 라이선스의 제약 사항에는 무엇이 있는지 충분히 숙지한 뒤 라이선스를 준수하여 사용하는 것이 바람직할 것입니다. 또한 대부분의 프로젝트에는 여러 개의 오픈소스가 포함되는데, 이 경우 서로 다른 라이선스가 중복 적용 가능한 것인지를 꼭 확인해 볼 필요가 있습니다(compatibility 확인, 이에 대해서는 다른 포스팅을 통해 말씀드립니다).
이때 오픈소스 관련 소송이 있는 경우라면 개발자 출신 변호사 등 법률전문가와 상담할 필요가 있겠습니다만, 특정 라이선스로 배포되는 오픈소스 코드의 사용여부를 결정해야 하는 경우 등이라면 한국저작권위원회에서 운영하는 OLIS를 이용하시는 것이 좋다고 생각됩니다. OLIS 사이트는 많은 양의 라이선스 관련 정보를 축적하고 있고, 소프트웨어 라이선스 전문가가 라이선스 사용에 대한 상담도 해 주고 있습니다.
KASAN_오픈소스 라이선스의 종류 및 개발자 입장에서 오픈소스 코드 사용시 유의해야 할 점.pdf
[질문 또는 상담신청 입력하기]
기술자문계약서(국문)_sample.docx
스톡옵션 계약서 샘플.doc
