300x250
목차
1. 공개SW 라이센스 관리 필요성
1) 공개SW의 활용
- 소스코드, 라이브럴, 유틸리티, 툴, 완제품 수준에 이르기까지 다양한 방법으로 활용될 수 있음
- 특히, 다양한 공개SW를 활용함에 있어서는 결합형태에 따라 소스코드 공개 범위가 상이할 수 있어, 결합 형태에 따른 라이센스 호환성을 검토해야 하며, 이슈는 보통 소스 코드와 라이버리 수준의 결합 형태에서 많이 발생함
2) 공개SW 유입 경로
- 내부적 검토 완료 된 공개SW
- 정책, 절차, 라이센스 등이 수립되어 있어야 함 -> 문제점 : 그런 조직이 많지 않음
- 개발자가 다운로드 한 검토되지 않은 공개SW
- 활용 단계에서 아무런 정책 없이 개발자 자의적으로 공개SW를 사용하는 경우가 많음
-> 현재 SW개발은 복합 지적 재산권을 구성하고 있음 (우리가 소유권을 갖고 있을 수도, 협력 업체가 갖고 있을 수도 있는 상황)
-> 라이센스를 이해하고 있지 못하다면 법률적 분쟁, 금전적 손실, 지적 재산권 손해 등의 문제가 발생할 수 있음
3) 공개SW 분쟁사례
- Eduroam : 에듀로움 무선 교육망 관련 비영리 목적의 배포행위도 저작권 위반이라는 법정 사례
- 삼성전자 exFAT : 유럽에서 발생한 코드 유출 및 GPL 공개로 인한 분쟁
- Google v. Oracle : API 저작권에 대한 공정사용에 대한 법정 사례
- Xiaomi : Mi 시리즈의 코드 공개 사례
- 한글과 컴퓨터 v. Artifex : 한글오피스 ghostscript에 대한 법정 사례
4) 공개SW 관리체계 구축
- 현재 공개SW를 사용하는 조직은 매우 많지만, 이를 제대로 관리하며 사용하는 조직은 많지 않음
- 적어도 '관리단계' 정도는 가야 그 조직이 관리체계가 어느 정도 적절히 운영되고 있다고 볼 수 있음
2. 공개SW 라이센스 이해
1) 공개SW의 정의
- 공개SW와 상용SW의 공통점 : 저작권이 있음
- 차이점 : 저작권리의 행사 방식
- 공개SW 저작권자 : 소스 코드를 공개하고 누구나 복제, 설치, 사용, 변경, 재배포가 가능하도록 저작권리를 행사함
- -> 사용자에게 책임을 부여함 (자신이 코드를 사용, 수정을 할 시 공유하도록 하는 등)
- EX)
문제는, 저작권자들 마다 사용자에게 부여하는 책임의 범위가 다름 -> 2,000여종의 License가 존재
분쟁, 이슈를 예방하려면 공개SW에 고지된 License 조항들을 명확하게 판별하여 사용해야 함.
2) 공개SW 라이센스 개념 분류
- Non-Open Source Software : 상용SW
- Free & Open Source Software : 공개SW
- 초창기 - Free Software : 누구든지 실행, 채택, 재배포할 수 있게 함
- 이후 - Open Source Software : 코드가 공개 되더라도, 저작권자들이 보상을 받을 수 있어야 함
- Copyleft(Protective) License : 사용자들도 수정, 보완한 내용을 모두 공개해야 함
- Permissive License : 사용자들이 파생저작물을 자유롭게 다루도록 둠
- BSD, MIT : 고지만 해라!
- MPL, EPL, LGPL : 파생 저작물을 수정, 보완한 일부분을 조건에 따라 공개해라!
- GPL : 전부 공개해라!
3) Open Source Initiative 공개SW 정의
- 자유로운 재배포
- 원시코드 제공
- 파생저작물
- 저작자의 소스코드 원형 유지: 최초 원시코드 & 패치
- 개인 및 단체에 대한 차별 금지
- 사용 분야에 대한 차별 금지
- 라이센스의 배포
- 특정 제품에만 유효한 라이센스 금지
- 다른 소프트웨어를 제한하는 라이센스 금지
- 라이센스의 기술 중립성
4) 공개SW 라이센스 주요용어 및 개념
- 라이센스 (라이선스) - 네이버 국어사전
- 행정상의 허가나 면허, 또는 그것을 증명하는 문서, 면허, 면허장으로 순화
- 수출입이나 그 밖의 대외 거래의 허가 또는 그 허가증
- 외국에서 개발된 제품이나 제조 기술의 특허권, 또는 그것의 사용을 허가하는 일. 면허, 면허장, 사용권, 허가, 허가장으로 순화
- 수취, 실행만 하는 경우에는 아무런 공개SW 라이센스 의무사항이 발생되지 않음 (제 3자에게 배포하는 경우에만 발생)
- 공개범위 : 소스코드를 공개해야 함
- 특허 포기 : 특정 라이센스의 경우, 특허권을 포기해야 함
- 양립성 : 공개SW 여러가지를 사용하는 경우가 많은데, 라이센스 간의 충돌이 발생해서는 안됨
5) 라이센스 사용 빈도
- Permissive License가 점점 많아지고 있음
6) 주요 라이센스 및 의무사항
- 주요 공개SW 라이센스인 GPL, LGPL, CPL, MPL 등은 공개SW 코드 뿐만 아니라 사용자 코드 공개의무 발생
- 공개SW를 활용하면서 공개하기 어려운 코드를 보호하기 위해서는 적절한 라이센스 관리가 필수!
(1) GPL의 주요 특징
- GPL 2.0 코드 공개 범위
- 수정한 내용에 대한 소스 공개 의무 발생, SW를 수정하거나 새로운 SW를 링크시키는 경우 하나의 프로세스로 동작하는 전체 프로그램의 소스 코드 공개 (동일한 실행 파일에 포함되는 경우, 공유주소영역에서 링크되어 실행되는 경우)
- 소스 코드 공개 예외상황
- 리눅스 기반으로 개발된 Application, 커널 모듈 형태로 작성된 Loadable Device Driver 등에 의한 정상적인 리눅스 system call을 사용하는 경우
- Class Path Exception인 경우
- 2개의 프로그램이 파이프(Pipe), 소켓(Socket), command line arguments 형태로 통신하는 경우
(2) LGPL 2.1 소스코드 공개 범위
-> GPL 2.0을 다소 완화한 라이센스
LGPL로 공개된 공개SW는 반드시 라이브러리(소프트웨어 기능 or 데이터의 집합) 형태로 사용해야 함
크게 두 가지 방식으로 나뉨
(3) MPL 1.1, 2.0 소스코드 공개의무
- MPL 2.0의 경우, 사용자의 선택에 따라 여러 라이센스 중 다른 라이센스로 배포를 할 수 있기 때문에 양립성 측면에서 중요
(4) 고지의무와 이행 방법
대부분의 License들은 고지의 의무를 요구한다. (Permissive License들도 고지를 요구함)
- File Scope Approach : 공개되는 file의 headline 부분에 고지
- Centralized Approach : 전체 file에는 어려우니, Author or Copying or text file 등을 만들어서 종합적으로 고지
- Hybrid Approach : file 단위, 종합적인 고지를 종합적으로 진행
- Free Software Foundation이 제시하는 방법 : 파일의 헤더에 다음을 포함
- 프로그램의 이름, 간략한 설명
- 저작자의 저작권 문구
- 이 프로그램이 오픈소스 프로그램이라는 것, 적용 라이센스의 종류
- 간략한 보증부인조항
- 라이센스 전체를 얻을 수 있는 URL 포인터
728x90
최근댓글