오픈소스 라이선스 가이드


full

0. 개요

ML2는 협업과 공유를 통해 함께 성장하는 머신러닝 커뮤니티를 만들고자 다양한 오픈소스 프로젝트들을 준비하고 있습니다. 오픈소스 정신이 확산되길 바라며 '한국저작권위원회의 오픈소스 소프트웨어 라이선스 가이드'를 참조하여 정리한 글을 공유합니다.
PART 1 에서는 오픈소스 라이선스 소개를 다루고 있습니다. 새로운 라이선스를 접했을 때 쉽게 파악할 수 있도록, 개념 설명부터 라이선스 종류와 내용 그리고 간단한 분류까지 도움이 되는 내용들로 구성하였습니다.
PART 2 는 오픈소스 라이선스와 관련된 법적 리스크에 대한 내용들을 담았습니다. 라이선스 내용이 복잡한 만큼 위반할 가능성이 높기 때문에 오픈소스를 사용하기 전에 어떠한 의무사항이 있는지 확인하고 발생할 수 있는 문제에 대비하는 것은 중요합니다.


PART 1. 오픈소스 라이선스 소개


1. 용어 설명

오픈소스 소프트웨어 라이선스를 알기 위해서는 지식재산권, 라이선스에 대한 이해가 선행되야 합니다. 오픈소스란 무엇을 의미하는지, 어디서 오픈소스 라이선스를 관리하는지를 살펴보는 것도 필요합니다. 그리고 오픈소스 라이선스에서 중요한 개념인 Copyleft까지 알아보겠습니다.

🗝️ 지식재산권

  • 지식재산권은 "인간의 창조적 활동 또는 경험 등을 통해 창출하거나 발견한 지식·정보·기술이나 표현, 표시 그 밖에 무형적인 것으로서 재산적 가치가 실현될 수 있는 지적창작물에 부여된 재산에 관한 권리." 입니다.
  • 소프트웨어 또한 ‘저작권(copyright)/ 특허권(patent)/ 상표권(trademark right)/ 영업비밀 ‘ 에 의해 보호받고 있습니다.
  • 저작권의 경우 저작물의 창작과 함께 자동적으로 부여됩니다.

🗝️ 라이선스

  • 권리자가 다른 사람에게 일정한 조건으로 특정 행위를 할 수 있는 권한을 부여할 수 있고 이와 같은 권한을 보통 ‘라이선스(license, 이용허락)’ 라고 합니다.
  • 여기서 라이선스는 소프트웨어를 사용할 수 있는 권한 또는 사용을 허가한다는 내용을 담은 문서 따위를 칭합니다.
  • 라이선시 (Licensee) : 라이선스를 받는 자
  • 라이선서 (Licenser) : 라이선스를 부여하는 자

🗝️ 오픈소스

  • 오픈소스 소프트웨어(Open Source Software, OSS)를 뜻하는 용어입니다.
  • 소스코드를 공개해 누구나 특별한 제한 없이 그 코드를 보고 사용할 수 있고, 오픈소스 라이선스를 만족하는 소프트웨어로서 일반적으로 자유롭게 복제/배포/수정할 수 있습니다.
  • 단순히 소스코드가 공개되어 있다고해서 오픈소스인것은 아니고 OSI가 정한 요건을 충족하여 오픈소스 라이선스 인증을 받아야 합니다. 💡

🗝️ OSI (Open Source Initiative)

  • 1998년에 결성된 오픈소스 활성화 및 오픈소스에 대한 인증을 담당하는 비영리 단체입니다.
  • OSI는 오픈소스 라이선스의 최소한의 기준인 OSD (Open Source Definition) 를 정의 해놓고 이 정의에 따라 인증하고 관리하고있습니다.

🗝️ 조합저작물(Larger Work)

  • 라이선스 적용 코드 전체나 그 일부를 본 라이선스의 적용을 받지 않는 코드와 결합한 저작물을 뜻합니다.

🗝️ Copyleft

(1) 정의

Copyleft는 저작권을 기반으로 한 정보의 공유를 위한 개념입니다. 정보의 사용 제한에 반대한다는 의미에서 Copy-right가 아닌 Copy-left라고 명칭한 것입니다. Copyleft는 소수에게만 지식과 정보가 독점되지 않고, 모든 사람에게 열려 있는 것을 목표로 합니다.

(2) 배경

Copyleft의 등장은 1976년으로 거슬러 올라갑니다. Li-Chen Wang은 Tiny Basic의 한 버전인 Palo Alto Tiny BASIC 을 배포하면서 소스코드를 자유롭게 사용하고 공유할 수 있음을 설명하기 위해 "@COPYLEFT ALL WRONGS RESERVED"라는 용어를 만들었습니다.
이후 리처드 스톨만이 1988년 GPL라는 라이선스를 공식화하기 위해 Copyleft 개념을 차용하면서 널리 퍼지게 되었습니다.

(3) 원칙

Copyleft개념을 라이선스 조항에 포함시킨 것을 Copyleft 라이선스 또는 Copyleft 조항이라고 합니다. Copyleft 라이선스에는 다음과 같은 원칙들이 포함되어 있습니다.

  • Freedom 작품을 연구하고 사용하는 자유, 다른 사람들과 같이 쓰고 복사하는 자유, 수정하는 자유, 2차 저작물을 배포할 자유를 보장합니다.
  • Reciprocity = 배포에서의 상호주의 위에서 언급한 자유를 보장하기 위해서 라이선스가 적용된 코드를 제3자에게 배포할 때 동일한 라이선스로 배포하도록 요구하기도 합니다.
(4) Copyleft 라이선스

Copyleft 라이선스는 위 원칙을 따라 배포시 소스코드 제공 의무를 부여하고 있으며 배포시 동일한 라이선스를 적용하도록 상호주의를 적용하고 있습니다. 하지만 조건에 따라 상호주의를 적용하지 않는 경우도 있습니다. 이를 정리하면 아래와 같습니다.
ninety


2. 오픈소스 라이선스란?

(1) 정의

오픈소스 소프트웨어 사용권으로, 오픈소스 소프트웨어 개발자와 이용자 간에 이용 방법 및 조건의 범위를 명시한 계약/사용권을 뜻합니다.
오픈소스 라이선스는 광범위한 사용권을 부여하면서 로열티를 요구하지는 않지만, 지켜야할 의무사항들이 존재합니다. 이러한 의무사항들을 위반할 경우에는 저작권 침해가 발생하여 책임을 져야 합니다.
오픈소스 라이선스는 오픈소스를 이용해 상업적인 이득을 취하는 것을 막지 않고,
(별도로 명시하는 경우를 제외) 일반적으로 오픈소스를 이용하여 산출된 결과물에 대해서도 제약을 가하지 않습니다. 단지, 오픈소스 일부가 결과물에 포함되는 경우에만 라이선스의 영향을 받게 됩니다.

(2) 독점 소프트웨어 라이선스와의 차이점

  • 라이선시는 해당 오픈소스 소프트웨어를 자유롭게 이용할 수 있습니다.
  • 라이선시는 해당 오픈소스 소프트웨어를 자유롭게 복제할 수 있으며, 일정한 조건하에 재배포할 수 있습니다.
  • 라이선시는 해당 오픈소스 소프트웨어를 자유롭게 수정하여 이용할 수 있으며, 일정한 조건하에 수정된 내용을 재배포할 수 있습니다.
  • 라이선시는 해당 오픈소스 소프트웨어의 소스코드를 자유롭게 획득하고 접근할 수 있습니다.

(3) 오픈소스 라이선스 특징

OSD(Open Source Definition)를 충족해야 OSI로부터 오픈소스 라이선스 인증을 받을 수 있기에, OSD의 내용은 오픈소스 라이선스의 공통된 특징이라 할 수 있습니다. OSI가 정한 OSD내용은 다음과 같습니다.

  • Free Redistribution
    소프트웨어의 재배포의 자유가 있으며, 로열티나 기타 다른 비용을 요구할 수 없음.
  • Source Code
    프로그램은 소스코드를 포함해야 하고, 소스코드는 프로그래머가 쉽게 수정할 수 있는 형태로 제공되어야 함.
  • Derived Works
    2차 저작물을 허용해야 함.
  • Integrity of The Author's Source Code
    라이선스는 수정된 소스코드로부터 만든 소프트웨어의 배포를 명시적으로 허락해야 함.
  • No Discrimination Against Persons or Groups
    개인이나 단체를 차별해서는 안됨.
  • No Discrimination Against Fields of Endeavor
    사용분야를 제한해서는 안됨.
  • Distribution of License
    소프트웨어에 부여된 권리는 모든 사용자에게 적용됨.
  • License Must Not Be Specific to a Product
    라이선스 적용의 동일성을 유지해야 함.
  • License Must Not Restrict Other Software
    다른 라이선스를 포괄적으로 수용해야 함.
  • License Must Be Technology-Neutral
    특정 기술이나 특정 인터페이스에만 국한되어 사용되도록 하면 안됨.
    Open Source Definition의 상세한 내용은 여기에서 확인할 수 있습니다.

3. 오픈소스 라이선스 종류

(1) 오픈소스 라이선스 배포 현황

eighty

OSI에 따르면 오픈소스 라이선스의 종류는 80여개가 넘는데요, 배포 현황을 보면 그 중 10가지 정도가 주로 쓰이고 있습니다. 본 포스트에서는 주로 사용되는 라이선스들을 위주로 살펴보겠습니다.

(2) 오픈소스 라이선스 분류

각 라이선스들의 내용을 살펴보기 전에, 주로 사용되는 라이선스들의 특징을 한 눈에 살펴보고자 주요 기준으로 분류해 보았습니다.

ninety

오픈소스 라이선스를 분류한 기준은 다음과 같습니다.

  • Reciprocal vs Permissive
    오픈소스 라이선스를 분류할 때 가장 중요한 기준은 Copyleft 조항이 있는지 여부입니다. Copyleft조항 즉, 배포시 소스코드 제공의무 있는지(Reciprocal) 없는지 (Permissive)로 우선 분류됩니다.
  • 조합저작물 작성 및 타 라이선스 허용
    Copyleft 중에서도 타 라이선스를 허용하는지에 따라 Strong Copyleft/ Weak Copyleft로 나눌 수 있습니다.
  • 추가 제약 존재
    Copylef가 아닌 라이선스 즉 Permissive 라이선스의 경우,공통 준수사항 외에 추가적인 제약사항이 존재하는지 여부로 나눌 수 있습니다.
  • 추가로, 라이선스의 출현 배경에 따라서 크게 MPL타입, GPL타입 그리고 BSD타입으로 나눌 수도 있습니다.

4. 오픈소스 라이선스 내용

(1) 오픈소스 라이선스 내용

라이선스마다 형식은 다양하지만 모두 오픈소스를 사용할때의 의무사항조건을 명시하고 있습니다.
간단한 예로 BSD-2-Clause 라이선스를 살펴보겠습니다. 우선 저작권 <연도>,<저작권자>를 표기하였고, 배포시 의무사항을 규정하고 있습니다. 또한 어떠한 보증도 제공하지 않는다는 조건을 명시하고 있습니다.

ninety

이 외에도 서문을 추가하거나 용어의 정의를 나열하는 등 내용이 추가되기도 합니다.
중요한 것은, 라이선스에는 배포시 의무사항조건이 정리되어 있다는 점입니다. 이러한 의무사항과 조건은 라이선스마다 상이한데요, 모두 합치면 11개 정도의 공통 쟁점으로 정리됩니다. 이 쟁점들을 어떻게 규정하는지, 예외사항은 무엇인지를 파악하면 라이선스를 쉽게 이해할 수 있습니다.

(2) 라이선스 비교표

오픈소스 라이선스의 공통 쟁점들을 기준으로 하여 라이선스를 비교해볼 수 있습니다. 다양한 라이선스 비교표 중에서 한국저작권위원회의 라이선스 비교표를 살펴보도록 하겠습니다.

🗂️ 라이선스 비교표- 한국저작권위원회 오픈소스 라이선스 종합정보 시스템

라이선스 비교표에 정리된 11가지의 공통 쟁점은 다음과 같습니다.

  • 복제, 배포, 수정의 권한 허용 - 해당 소스코드를 자유롭게 복제하고 배포하고 수정할 수 있음.
  • 배포 시 라이선스 사본 첨부 - 라이선스 하의 소스코드를 물리적으로 배포한다면 라이선스 사본(이용허락권)을 함께 배포하여 이용자가 해당 권리를 확인하고 사용할 수 있도록 해야 함.
  • 저작권 고지사항 또는 Attribution 고지사항 유지 - 코드의 상단에 삽입되어 있는 원작자의 저작권 고지사항을 지우면 안됨.
  • 배포 시 소스코드 제공의무(Reciprocity)와 범위 - 해당 오픈소스를 사용하여 개발할 경우, 개발 된 소스코드를 사용자에게 제공해야하는지에 대한 의무와 범위.
  • 조합저작물(Lager Work) 작성 및 타 라이선스 배포 허용 - 조합저작물을 작성해서 타 라이선스로 바꾸어 배포하는걸 허용하는지 여부.
  • 수정 시 수정 내용 고지 - 오픈소스를 수정한 경우 수정사항에 대해 고지를 해야 함.
  • 라이선시가 특허소송 제기 시 라이선스 종료 - 라이선시에게 특허소송을 제기 할 경우 라이선스가 종료됨.
  • 이름, 상표, 상호에 대한 사용제한 - 저작자 및 기여자의 이름·상표·상호를 홍보목적으로 사용가능한지에 대한 제한.
  • 보증의 부인 - 프로그램의 품질과 성능에 관련된 모든 위험은 사용자에게 있음. 프로그램에 결함이 있는 것으로 밝혀지면, 이에 따라 필요한 보수 및 복구를 위한 제반 경비는 사용자가 부담.
  • 책임의 제한 - 저작권자는 프로그램의 사용이나 작동 불능으로 인해 발생한 일반적이거나 특수한 손해, 우발적 또는 결과적 손해에 대해 책임지지 않음. 이러한 조건은 사용자나 제3자가 프로그램을 조작함으로써 발생된 손실이나 다른 소프트웨어와 프로그램을 함께 동작시키는 것으로 인해서 발생된 데이터의 상실 및 부정확한 산출 결과에도 적용 됨.

5. 주요 오픈소스 라이선스 소개

오픈소스 라이선스에 대해 개괄적으로 살펴보았으니 이제 각 라이선스를 구체적으로 살펴보겠습니다. 라이선스의 출현 배경에 따라 BSD형, GPL형, MPL형 순서로 정리하였습니다.

(1) BSD형

카피레프트(Copyleft) 조항을 포함하지 않고 소스코드 제공 의무도 없어 의무사항이 비교적 간단한 라이선스 입니다. BSD형의 라이선스로 배포되는 다양한 코드를 이용하여 자사의 제품을 만든 후 이를 상용 라이선스로 배포하는 것도 가능합니다.

✏️ BSD

BSD 3-Clause 원문 / BSD 2-Clause 원문 / BSD 1-Clause 원문/ 0BSD원문

  • BSD (Berkeley Software Distribution License) 계열 소프트웨어에 적용되는 라이선스 입니다.
  • 해당 라이선스의 버전으로는 BSD 4-Clause , BSD 3-Clause , BSD 2-Clause, BSD 1-Clause, 0BSD 가 있습니다.
  • 각 버전은 4개의 조항으로 구성된 BSD 4-Clause 라이선스에서 조항을 하나씩 삭제한 것입니다.
  • macOS, iOS, 솔라리스 등의 상업적인 운영 체제에도 많이 사용되고 있습니다.
  • [배포시 의무사항]
    • 재배포시 저작권 표시, 준수 조건 및 보증부인에 대한 고지사항을 소스코드 또는 문서 및 기타 자료에 포함해야 함.

✏️ Apache

Apache 2.0 원문

  • Apache Software Foundation 에서 배포한 라이선스로 아파치 웹서버 배포를 위해 만들어졌습니다.
  • 현재 사용되는 것은 Apache 2.0 버전으로 모든 아파치 재단의 소프트웨어는 해당 라이선스에 의해 배포되고 있습니다.
  • [배포시 의무사항]
    • 수취인에게 라이선스 사본 제공
    • 수정된 파일에 대해 수정사항을 표시한 안내문구 첨부
    • 저작권, 특허, 상표, attribution에 대한 고지사항을 소스코드 또는 "NOTICE" 파일 등에 포함
    • 최초개발자 등을 위해 보증을 면제하고, 책임을 제한

✏️ MIT

MIT 원문

  • MIT에서 해당 대학의 소프트웨어 공학도들을 돕기 위해 개발한 라이선스로, BSD 라이선스를 기반으로 만들어졌습니다.
  • MIT 라이선스로 공개된 소스를 이용할 경우 독점 소프트웨어의 개발도 가능합니다.
  • [배포시 의무사항]
    • 저작권 안내문구, MIT 라이선스 문구가 모든 복제본에 포함

[BSD형 요약]

eighty

출처: 한국저작권위원회 오픈소스라이선스 가이드 3.0

(2) GPL형

GNU 일반 공중 사용 허가서(GPL)는 자유 소프트웨어 재단에서 만든 라이선스입니다. BSD와 비슷하지만, Copyleft 조항이 있다는 점이 큰 차이점입니다.

✏️ GPL2.0

GPL2.0 원문

  • GNU General Public Lisence
  • GNU의 주축이었던 리차드 스톨먼이 제시한 라이선스 입니다.
    GNU는' GNU's Not UNIX'의 약자로 자유 소프트웨어 재단(Free Software Foundation)에서 진행하며 유지 중인 OS 프로젝트입니다.
  • GPL2.0를 사용한 대표적인 프로젝트로는 '리눅스 커널'이 있습니다.
  • GPL2.0에서 명시한 '파생 저작물'의 범위에 대한 논란이 있어 GNU에서 faq를 따로 정리하기도 하였습니다. 👾 Frequently Asked Questions about the GNU Licenses
  • [배포시 의무사항]
    • 각 복제본에 적절한 저작권 고지와 보증책임이 없음을 명시
    • GPL 라이선스를 언급하는 고지사항과 보증책임 관련 고지사항을 원본 그대로 유지
    • 프로그램을 양도 받는 모든 이들에게 프로그램과 함께 GPL 라이선스 사본 제공
    • 파일 수정의 경우 수정사실과 날짜를 파일에 명기
    • 원본저작물과 파생저작물을 GPL 2.0에 의해 배포
    • 원본저작물 및 파생저작물에 대한 소스코드를 제공하거나, 요청시 제공하겠다는 약정서 제공

✏️ GPL3.0

GPL3.0 원문

  • GPL2.0가 배포된 이후 몇가지 조항을 추가하여 만든 라이선스입니다.
  • 조항이 추가된 배경: 미국의 TiVo라는 회사에서 GPL2.0리눅스 커널을 이용한 DVR제품을 출시하고 소스코드도 공개하였으나, TiVo사가 제품을 수정하여 사용하는 것을 허용하지 않아 이용자들이 소스코드를 수정해서 TiVo제품에 포팅하였을 때 제대로 작동하지 않았습니다. 리처드 스톨만은 GPL2.0을 악용한다고 느껴 관련된 새로운 조항을 추가하였습니다.
  • '사용자 제품(user product)에 대한 인증키 등 설치정보(installation information)를 제공할 것' 이란 조항이 포함 된 것이 큰 특징입니다.

✏️ LGPL

LGPL3.0 원문

  • GNU Lesser General Public License
  • 주로 라이브러리에 사용하기 위해 GPL과는 별도로 만들어진 라이선스입니다.
  • 라이브러리까지 GPL의 카피레프트 조항이 적용되면 응용프로그램까지 GPL로 배포해야하는 부담이 있기 때문에, 해당 라이브러리를 이용한 응용프로그램은 Copyleft 조항을 적용하지 않고 소스코드 제공 의무도 없는 형태로 만들었습니다.
  • [배포시 의무사항]
    • 각 복제본에 저작권 고지와 보증책임이 없음을 명시
    • LGPL 3.0의 조건 및 제7조의 조건에 관한 내용을 있는 그대로 유지
    • 프로그램을 양도 받는 모든 이들에게 프로그램과 함께 GPL 및 LGPL 라이선스 사본 제공
    • 수정시 수정사실 및 일시를 명시
    • 원본저작물과 파생저작물을 LGPL3.0에 의해 배포
    • 원본저작물 및 파생저작물에 대한 소스코드를 제공하거나, 요청시 제공하겠다는 약정서 제공
    • 사용자제품에 대한 인증키 등 설치정보의 제공
    • 응용프로그램을 배포할 경우, LGPL 라이브러리를 사용하고 있다는 사실을 명시
    • 사용자가 라이브러리를 수정해도 응용프로그램을 사용할 수 있도록 (예를 들어 오브젝트코드 등을 제공하거나 공유라이브러리 방식등을 이용하여) 허용

✏️ AGPL

AGPL3.0 원문

  • GNU Affero General Public License
  • 오픈소스 라이선스들은 해당 SW를 복제하여 '배포'할 때 지켜야하는 요구사항들을 규정하고 있는데, 이를 반대로 해석하면 배포하지 않고 기업이 내부적으로만 사용하거나 네트워크 서버 형태로 이용하는 경우에는 라이선스에 따른 의무사항들이 거의 없게 됩니다.
  • 이러한 한계를 극복하려고 GPL 라이선스를 변경하여 네트워크 서버에 의해 서비스를 제공하는 경우에도 카피레프트 조항과 소스코드 제공 의무가 적용되도록 만든 라이선스 입니다.
  • 의무사항은 기본적으로 GPL과 동일하나 적용범위가 배포를 넘어서 네트워크 서버 형태로 SW를 이용하는 경우에도 적용된다는 점이 차이가 있습니다.
  • [배포시 의무사항]
    • 수정버전의 경우 네트워크를 통해 원격으로 대화하는 모든 사용자들에게 해당 소스를 받을 수 있는 기회를 제공해야 함
    • (이 외에도 GPL3.0의 의무사항을 준수해야 함)

[GPL형 라이선스 요약]

eighty

출처: 한국저작권위원회 오픈소스라이선스 가이드 3.0

[GPL형 호환성 문제]

  • GPL은 사용자들에게GPL에서 규정하고 있는 것 이외의 제한사항을 추가하지 못하도록 엄격하게 통제하고있기에 양립성 문제가 발생합니다. GPL타입 라이선스를 사용하기 전에 호환성을 꼭 확인해야 합니다.
  • GPL-Compatible, Incompatible

(3) MPL형

주로 기업들이 주도하는 오픈소스 프로젝트에서 사용하는 라이선스로, BSD 형 GPL형 라이선스와 다르게 처음부터 법률가들이 참여하여 만든 라이선스 입니다.

✏️ MPL

MPL2.0 원문

  • Mozilla Public License
  • 1998년 넷스케이프사가 자사의 브라우저를 오픈소스로 배포하면서 만든 라이선스입니다.
  • 현재 사용되는 것은 MPL2.0 버전입니다.
  • Copyleft조항이 있는데, 적용범위와 소스코드 제공범위는 LGPL에 가까습니다.
  • 대표적인 프로젝트로는 Firefox 웹브라우저가 있습니다.
  • [배포시 의무사항]
    • 원본 및 수정코드를MPL 2.0에 의해 배포
    • 라이선스 사본을 입수할 수 있는 방법에 대해 고지
    • 소스코드를 제공하거나 입수할 수 있는 방법에 대한 고지
    • 라이선스 고지사항에 포함된 내용의 수정 금지
    • 법령이나 규제로 인해 규정의 준수가 불가능할 경우 관련 제한사항과 영향을 받는 코드에 관한 설명문을 포함할 것

✏️ CPL, EPL

EPL2.0 원문

  • CPL = Common Public License
  • EPL = Eclipse Public License
  • IBM이 이클립스(Eclipse) 등 오픈소스 프로젝트를 진행하면서 만든 라이선스입니다.
  • CPL과 EPL은 특허보복조항에 관한 사항에서만 차이가 있고 다른 내용은 거의 동일합니다.
  • CPL은 2013년에 OSI 인증라이선스에서 제외되어 현재는 EPL만 사용되고 있습니다.
  • EPL은 GPL보다 약한 상호주의(Copyleft)조항을 가지고 있어 기업친화적인 오픈소스 라이선스라 할 수 있습니다.
  • [배포시 의무사항]
    • 오브젝트코드로 배포하는 경우 EPL 조건 준수, 보증부인, 책임의 배제, 소스코드의 확보방법 고지
    • 소스코드로 배포하는 경우 EPL 라이선스 적용
    • EPL 라이선스 사본 포함
    • 각 프로그램의 저작권 고지사항을 제거하거나 변경하는 것을 금지
    • 각 기여물의 창작자를 식별할 수 있도록 신분을 밝힐 것
    • 상업적 배포의 경우 기여자에게 책임이 발생하지 않도록 조치

[MPL형 라이선스 요약]

eighty

출처: 한국저작권위원회 오픈소스라이선스 가이드 3.0

PART 2. 오픈소스 라이선스 관련 리스크


6. 오픈소스와 관련된 법적 리스크

오픈소스 사용이 증가하면서 관련된 법률소송과 손해배상 사례도 늘고 있습니다. 오픈소스를 사용하면서 발생할 수 있는 법적 리스크는 무엇인지 살펴보겠습니다.

📋 오픈소스 라이선스의 위반

  • 오픈소스 라이선스에 명시된 의무사항을 준수하지 않는 경우 발생할 수 있는 법적 리스크입니다.
  • 라이선스 위반은 단순한 계약 위반을 넘어 저작권 침해가 되며 오픈소스 커뮤니티로부터 소송을 제기당할 수 있습니다.
  • 사례: BusyBox Settles GPL Lawsuit

📋 제 3자의 지적재산권 침해

  • 오픈소스 자체가 제3자의 특허권이나 저작권 등 지적재산권을 침해한 경우에 발생할 수 있는 리스크 입니다.
  • 구글의 안드로이드 운영체제(OS)로 구동되는 스마트폰이 애플과 마이크로소프트(MS)의 특허를 침해했다는 판결이 나오면서 스마트폰 제조사들도 책임을 지게된 사건이 그 예입니다.
  • 사레: Android Patent Licensing

📋 자사의 지적재산권 관리

  • 자사의 지적재산권이 오픈소스를 활용하면서 영향을 받을 수도 있어 유의해야 합니다.
  • 예를 들어, 자사가 오픈소스를 활용하여 GPL 라이선스로 배포하게 되면, 자사의 특허권이나 저작권에도 GPL 라이선스가 적용됩니다. 이 결과 자사의 특허권이나 저작권을 경쟁기업들이 무료로 사용할 수 있게 됩니다.

위와같은 법적 리스크가 존재하기 때문에 오픈소스를 사용하기 전에 개인/회사의 프로젝트가 해당 오픈소스 라이선스를 위반할만할 사항이 있는지, 개인/회사의 특허권에 어떠한 영향을 미칠지 등을 면밀히 살펴야 합니다.


7. 오픈소스 라이선스 주요 의무사항

위에서 오픈소스 사용시 발생할 수 있는 법적 리스크를 살펴보았는데요, 그 중에서도 '오픈소스 라이선스 위반'에 대해 자세히 알아보겠습니다. 라이선스 위반을 방지하기 위해 지켜야 하는 오픈소스 라이선스의 주요 의무사항들은 다음과 같습니다. (오픈소스 라이선스마다 의무사항이 상이하기 때문에, 명시한 주요 의무사항 외에도 해당 라이선스의 내용을 사전에 확인해야 합니다!)

💡 저작권 관련 문구 유지

  • 소프트웨어의 소스코드에 포함된 프로그램의 이름과 개발자, 버전, 연락처 등은 모두 저작인격권으로 보호받습니다.
  • 대부분 소스코드 상단에 개발자 정보와 연락처 등이 기록되어 있는데요, 개발자 정보를 임의로 수정하거나 삭제하여서는 안됩니다.
  • 특히, 수정된 결과물을 다시 공개하도록 규정하고 있는 ‘상호주의(reciprocal)’ 라이선스들의 경우 저작인격권으로 보호받기 때문에 소스코드상의 개발자 정보가 수정, 삭제된 채로 외부에 공개되면 저작권 침해문제가 발생할 수 있으니 유의해야 합니다.

💡 제품명 중복 방지

  • 소프트웨어의 제품명 또한 상표권으로 보호받습니다.
  • 오픈소스의 경우에 이와 동일한 이름을 (ex. GPL, Linux) 제품명이나 서비스명으로 사용하면 상표권 침해의 문제가 생기게 됩니다.

💡 서로 다른 라이선스의 조합시 호환성 여부 확인

  • 소프트웨어를 작성할때 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데요, 이러한 때 결합되는 각 코드의 라이선스가 서로 상충되는 경우 문제될 수 있습니다. 이를 '라이선스 양립성'이라고 합니다.
  • 서로 다른 라이선스로 배포된 오픈소스 소프트웨어를 결합하여 배포할 경우 반드시 두 개의 라이선스가 서로 호환되는지를 확인하여야 합니다.

💡 사용 여부 명시

  • GPL2.0, GPL3.0, LGPL, MPL등의 라이선스는 오픈소스를 사용하였다는 것을 명시하도록 요구하고 있습니다.

  • 명시 방식에는 차이가 있으나 배포시 반드시 포함해야 합니다.

    eighty

  • 파일이나 모듈 단위로 사용하더라도 위 예시처럼 오픈소스 출처를 명시해야 합니다.

💡 소스코드 공개

  • Copyleft 라이선스의 경우 소스코드 공개를 의무화하고 있습니다.
  • 라이선스에 따라 해당 오픈 소스의 소스 코드만 공개하거나, 해당 오픈 소스의 소스 코드를 수정 또는 추가한 부분만 공개하거나 또는 해당 오픈 소스와 링크가 걸린 부분까지 모두 공개해야 합니다.
  • 소스코드 공개 범위, 방식 등 관련된 사항들이 복잡하기 때문에 철저히 확인해야 합니다.

8. 오픈소스 라이선스 확인 방법

사용하려는 오픈소스가 어떠한 라이선스를 가지고 있는지 확인하는 것도 중요합니다. 라이선스에 따라 의무사항과 발생할 수 있는 리스크가 달라지기 때문입니다. 라이선스를 확인하는 방법으로는 '직접 확인'하는 방법과 '도구를 통해 확인'하는 방법이 있습니다.

🔎 직접 확인

  • 오픈소스 프로젝트 홈페이지나 Github에서 쉽게 라이선스를 확인할 수 있습니다.
  • 대부분의 오픈소스 소프트웨어 최상위 디렉토리 내에 LICENSE, COPYING 등의 이름으로 라이선스 파일이 존재합니다.
  • 파일 내 라이선스 문구가 명시되어 있어 이를 확인하거나 텍스트 검색을 통해 라이선스를 확인할 수 있습니다.

🔎 도구를 통해 확인

(1) 문자열 검색 도구

  • 소스파일 상단의 라이선스 문구를 확인해 자동으로 라이선스를 판단하는 방식입니다.
  • 문자열 검색 도구로 아래와 같은 서비스를 활용할 수 있습니다.

(2) 코드 스캔 도구

  • 오픈소스의 소스코드와 정확하게 일치하거나 유사한 패턴을 보이는 코드 조각이 존재하는지를 확인하는 방식입니다.
  • 다음과 같은 서비스들이 있습니다.

(3) 바이너리 스캔 도구

  • 소프트웨어를 소스코드 없이 바이너리로만 받는 경우 필요한 방식입니다.
  • 바이너리 형태의 소프트웨어에 오픈소스가 사용되었는지 확인할 수 있는 도구로는 SYNOPSYS가 있습니다.

+ 코드아이

한국저작권위원회는 소프트웨어 업체의 오픈소스 사용 리스크를 사전에 방지하기 위해 오픈소스 사용 여부를 확인할 수 있는 코드아이 란 서비스를 제공하고 있습니다. 해당 서비스 내용은 여기서 확인하실 수 있습니다.


마무리

오픈소스 라이선스와 관련한 다양하고 깊은 이야기들을 모두 담지 못하여 아쉽지만, 오픈소스 라이선스를 이해하고 주요 라이선스의 특징을 숙지하는데 본 포스트가 도움이 되었길 바랍니다.✨


📌 참조

cc
members

이진명

Jinmyoung LEE

Research Engineer

github   github