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 정의

     

    http://opensource.org/

    1. 자유로운 재배포
    2. 원시코드 제공
    3. 파생저작물
    4. 저작자의 소스코드 원형 유지: 최초 원시코드 & 패치
    5. 개인 및 단체에 대한 차별 금지
    6. 사용 분야에 대한 차별 금지
    7. 라이센스의 배포
    8. 특정 제품에만 유효한 라이센스 금지
    9. 다른 소프트웨어를 제한하는 라이센스 금지
    10. 라이센스의 기술 중립성

     

     

     

    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 1.1 소스코드 공개 의무

     

    MPL 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
    • 네이버 블러그 공유하기
    • 네이버 밴드에 공유하기
    • 페이스북 공유하기
    • 카카오스토리 공유하기