오픈소스 라이선스 검증 이해하기
오픈소스란?
오픈소스는 소스코드가 공개되어 있는 SW를 이야기함.
FSF의 자유소프트웨어와 오픈소스를 통틀어 이야기하는데
자유소프트웨어는 엄격한 GPL조항 때문에 상용SW개발에 이용할 수 없어 대부분 기업들이 사용을 꺼려함.
그래서 소스공개를 더 활발히 하기 위해 오픈소스란 개념이 태어난 것.
이 오픈소스는 OSI (Open Source Initiative)가 결성되어 라이선스의 최소한의 기준을 정의한 OSD(Open Source Definition)를 가지고 인증, 관리를 하며 널리 사용되기 시작함.
라이선스의 내용
라이선스 안에는 형식은 다양하지만 모두 의무사항과 조건을 명시하고 있음.
이 의무사항과 조건을 정리하면 11가지 쟁점으로 나눌수 있음
- 쟁점 11가지
- 복제, 배포, 수정의 권한 허용 - 해당 소스코드를 자유롭게 복제하고 배포하고 수정할 수 있음.
- 배포 시 라이선스 사본 첨부 - 라이선스 하의 소스코드를 물리적으로 배포한다면 라이선스 사본(이용허락권)을 함께 배포하여 이용자가 해당 권리를 확인하고 사용할 수 있도록 해야 함.
- 저작권 고지사항 또는 Attribution 고지사항 유지 - 코드의 상단에 삽입되어 있는 원작자의 저작권 고지사항을 지우면 안됨.
- 배포 시 소스코드 제공의무(Reciprocity)와 범위 - 해당 오픈소스를 사용하여 개발할 경우, 개발 된 소스코드를 사용자에게 제공해야하는지에 대한 의무와 범위.
- 조합저작물(Lager Work) 작성 및 타 라이선스 배포 허용 - 조합저작물을 작성해서 타 라이선스로 바꾸어 배포하는걸 허용하는지 여부.
- 수정 시 수정 내용 고지 - 오픈소스를 수정한 경우 수정사항에 대해 고지를 해야 함.
- 라이선시가 특허소송 제기 시 라이선스 종료 - 라이선시에게 특허소송을 제기 할 경우 라이선스가 종료됨.
- 이름, 상표, 상호에 대한 사용제한 - 저작자 및 기여자의 이름·상표·상호를 홍보목적으로 사용가능한지에 대한 제한.
- 보증의 부인 - 프로그램의 품질과 성능에 관련된 모든 위험은 사용자에게 있음. 프로그램에 결함이 있는 것으로 밝혀지면, 이에 따라 필요한 보수 및 복구를 위한 제반 경비는 사용자가 부담.
- 책임의 제한 - 저작권자는 프로그램의 사용이나 작동 불능으로 인해 발생한 일반적이거나 특수한 손해, 우발적 또는 결과적 손해에 대해 책임지지 않음. 이러한 조건은 사용자나 제3자가 프로그램을 조작함으로써 발생된 손실이나 다른 소프트웨어와 프로그램을 함께 동작시키는 것으로 인해서 발생된 데이터의 상실 및 부정확한 산출 결과에도 적용 됨.
주요 라이선스 들
크게 3가지로 나뉨
BSD, GPL, MPL
- 각 용어 개념
- Reciprocal vs Permissive오픈소스 라이선스를 분류할 때 가장 중요한 기준은 Copyleft 조항이 있는지 여부입니다. Copyleft조항 즉, 배포시 소스코드 제공의무 있는지(Reciprocal) 없는지 (Permissive)로 우선 분류됩니다.
- 조합저작물 작성 및 타 라이선스 허용Copyleft 중에서도 타 라이선스를 허용하는지에 따라 Strong Copyleft/ Weak Copyleft로 나눌 수 있습니다.
- 추가 제약 존재Copyleft가 아닌 라이선스 즉 Permissive 라이선스의 경우,공통 준수사항 외에 추가적인 제약사항이 존재하는지 여부로 나눌 수 있습니다.
- 추가로, 라이선스의 출현 배경에 따라서 크게 MPL타입, GPL타입 그리고 BSD타입으로 나눌 수도 있습니다.
라이선스의 범람
관련 내용
https://ko.wikipedia.org/wiki/라이선스_범람#cite_note-5
라이선스를 이것저것 승인해서 라이선스가 너무 많아지니
각 각 라이선스를 가진 오픈소스 여러개를 사용해야하는 프로젝트에서
각 라이선스끼리 충돌하는 문제가 발생
그래서 각 라이선스끼리 호환이 되는지도 중요한 문제가 된다.
호환
GPL과 호환되는 라이선스의 목록
http://www.gnu.org/licenses/license-list.html
아파치 라이선스는 GPLv3과 호환된다. 그러나 그것은 일방적으로 되는 것이다.
즉, GPLv3 소프트웨어는 아파치 라이선스 소프트웨어를 포함할 수 있으나, 그 역은 불가능
라이선스 주요 의무사항
- 의무사항
- 소프트웨어의 소스코드에 포함된 프로그램의 이름과 개발자, 버전, 연락처 등은 모두 저작인격권으로 보호받습니다.
- 대부분 소스코드 상단에 개발자 정보와 연락처 등이 기록되어 있는데요, 개발자 정보를 임의로 수정하거나 삭제하여서는 안됩니다.
- 특히, 수정된 결과물을 다시 공개하도록 규정하고 있는 ‘상호주의(reciprocal)’ 라이선스들의 경우 저작인격권으로 보호받기 때문에 소스코드상의 개발자 정보가 수정, 삭제된 채로 외부에 공개되면 저작권 침해문제가 발생할 수 있으니 유의해야 합니다.
- 소프트웨어의 제품명 또한 상표권으로 보호받습니다.
- 오픈소스의 경우에 이와 동일한 이름을 (ex. GPL, Linux) 제품명이나 서비스명으로 사용하면 상표권 침해의 문제가 생기게 됩니다.
- 소프트웨어를 작성할때 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데요, 이러한 때 결합되는 각 코드의 라이선스가 서로 상충되는 경우 문제될 수 있습니다. 이를 '라이선스 양립성'이라고 합니다.
- 서로 다른 라이선스로 배포된 오픈소스 소프트웨어를 결합하여 배포할 경우 반드시 두 개의 라이선스가 서로 호환되는지를 확인하여야 합니다.
- GPL2.0, GPL3.0, LGPL, MPL등의 라이선스는 오픈소스를 사용하였다는 것을 명시하도록 요구하고 있습니다.
- 명시 방식에는 차이가 있으나 배포시 반드시 포함해야 합니다.
- Copyleft 라이선스의 경우 소스코드 공개를 의무화하고 있습니다.
- 라이선스에 따라 해당 오픈 소스의 소스 코드만 공개하거나, 해당 오픈 소스의 소스 코드를 수정 또는 추가한 부분만 공개하거나 또는 해당 오픈 소스와 링크가 걸린 부분까지 모두 공개해야 합니다.
- 소스코드 공개 범위, 방식 등 관련된 사항들이 복잡하기 때문에 철저히 확인해야 합니다.
💡 저작권 관련 문구 유지
Naver 오픈소스프로젝트 egjs 소스코드 예시
- 파일이나 모듈 단위로 사용하더라도 위 예시처럼 오픈소스 출저를 명시해야 합니다.
라이선스 확인 방법
- 확인 방법
- 오픈소스 프로젝트 홈페이지나 Github에서 쉽게 라이선스를 확인할 수 있습니다.
- 대부분의 오픈소스 소프트웨어 최상위 디렉토리 내에 LICENSE, COPYING 등의 이름으로 라이선스 파일이 존재합니다.
- 파일 내 라이선스 문구가 명시되어 있어 이를 확인하거나 텍스트 검색을 통해 라이선스를 확인할 수 있습니다.
🔎 도구를 통해 확인
(1) 문자열 검색 도구- 문자열 검색 도구로 아래와 같은 서비스를 활용할 수 있습니다.
- 소스파일 상단의 라이선스 문구를 확인해 자동으로 라이선스를 판단하는 방식입니다.
- 오픈소스의 소스코드와 정확하게 일치하거나 유사한 패턴을 보이는 코드 조각이 존재하는지를 확인하는 방식입니다.
- 다음과 같은 서비스들이 있습니다.
- 소프트웨어를 소스코드 없이 바이너리로만 받는 경우 필요한 방식입니다.
- 바이너리 형태의 소프트웨어에 오픈소스가 사용되었는지 확인할 수 있는 도구로는 SYNOPSYS가 있습니다.
+ 코드아이
한국저작권위원회는 소프트웨어 업체의 오픈소스 사용 리스크를 사전에 방지하기 위해 오픈소스 사용 여부를 확인할 수 있는 코드아이 란 서비스를 제공하고 있습니다.
참조
오픈소스 라이선스 가이드
오픈소스 라이선스 소개와 관련된 법적 리스크에 대한 내용을 담았습니다.
blog.kc-ml2.com