오픈소스 소프트웨어(OSS) 라이선스의 종류와 제약조건

들어가며

이전에 한국 저작권 위원회의 '오픈소스 SW 라이선스 교육'을 수강하고 그 내용을 정리한 글 입니다.

---

소프트웨어와 저작권

• UI의 다름은 중요하지 않고, 소스 코드의 유사도를 실제 비교한다.
• 오픈소스의 경우에도 감정 시 비교대상에서 최대한 배제된다.
• 원고의 SW를 의거하여 저작권을 위반하는 사례
  • 피고가 원고의 저작물에 접근이 가능했던 경우 원고의 SW를 의거해 제작했을 것으로 볼 수 있다.
  • 피고와 원고의 저작물에 동일한 오류(Common errors)가 존재하는 경우 의거관계가 사실상 추정되는 것으로 볼 수 있다.
• 오픈소스이지만 SW 기업의 기밀 자산으로 인식되는 경우 배포 등에 대해 업무상 배임 등에 해당할 수 있다.
  이 경우 배포 등에 대한 고의성이 입증되어야 한다.
• 업무상 저작권자의 저작물에 대한 보상금이 법적으로 정해진 금액보다 적은 경우 정해진 만큼 보상받을 수 있도록 지원되고, 해당 저작물로 인해 일정 금액 이상의 수익이 발생한 경우 추가적인 보상금을 지급하도록 함.
  (ex : 검정고무신 작가님)
• 저작인격권 : 저작자의 인격을 보호할 수 있는 권리
• 저작권법 제 46조
  1. 저작재산권자는 다른 사람에게 그 저작물의 이용을 허락할 수 있다.
     ...
• 일반적인 SW 라이센스 : SW를 최대한 자유롭게 사용하지 못하도록
• OSS 라이센스 : SW를 최대한 자유롭게 사용하도록

 

OSS 라이선스의 의의 및 기본 원리

• OSI 재단에 등록된 SW에 대한 라이선스
• 자유로운 재배포가 허용되어야 한다.
• 재배포 과정에서 상업적으로 사용하는 것에도 허용되어야 한다.
• 파생 저작물이 허용되어야 한다.(수정이 자유로워야 한다.)
• Field 제한을 넘어서지 말아야 한다.(ex: 경쟁 프로그램을 생성해서는 안된다)

 

Creative Commons License

• all rights reserved(C) : 조회 이외의 모든 라이선스를 허용하지 않음
• creative commons(CC) : 조건 준수 시 문제가 없음
  • BY : 저작자 명시
  • SA(Share Alike?) : 변경 시 공유 (ex: 위키피디아)
  • NC(None-Commercial) : 상업적 이용 불가
  • ND(None-Derivatives) : 변경 불가
• 위키피디아도 #Copilot 과 소송 진행 중

 

Linux Kernel 사례

openhub 등에서 오픈 소스 기여 조사가 가능함.
기여를 할 때 CLA 라는 문서에 동의를 해야 기여가 가능함

• 사용, 복제, 배포, 수정의 자유
• 소스코드의 제공
• 특정 Rule 준수 의무 존재
  • Permissive
    • ex 1) Apache 2.0 -> 특허, 상표, 개발자 메시지 등을 지우지 말라(개발자 명성 보존)
    • ex 2) Apache 2.0 -> 라이선스 카피본을 포함하라
    • ex 3) Apache 2.0 -> 수정 사항을 포함하라.
  • Copyleft
    • ex 1) GPL 2.0 -> GPL 라이선스를 가진 오픈소스 소프트웨어 사용 시 해당 SW도 GPL 라이선스를 적용하여 소스코드를 Open 하라.
    • 반드시 인터넷에 공개해야 하는 것은 아니고, 고객에게 소스 코드를 함께 제공해주는 형태로도 가능하고 고객이 외부에 배포하는 것을 막아서도 안됨.

 

MIT License

• MIT 에서 생성
• 마음대로 사용해도 좋다.
• License 정보와 저작권 정보만 유지되면 된다.
• 제약 조건
  • 보증 없음
  • 책임 없음

 

BSD License

• 버클리에서 생성
• Source 배포 시 저작권, License 정보 유지
• Binary 배포 시 저작권, License 정보 유지
• 오픈 소스를 사용해 개발된 제품 광고 문구에 Open Source 프로젝트의 정보 포함
• 제품 홍보, 판매 시 해당 재단의 허위 인증 정보 기재 금지(버클리에서 인증해주지 않았음!)
• 제약 조건
  • 보증 없음
  • 책임 없음

 

Apache License

• 특허 사용 허용(Loyallty free, 기여자에게 특허 무료 배포)
• Source 배포 시 저작권, License 정보 유지
• 파일 수정 시 수정 내용을 Notice
• 제약 조건
  • 상표 사용 금지(생태계 유지를 위한.. ex: Google 안드로이드)
  • 보증 없음
  • 책임 없음
• 라이선스 사용자가 제 3자에게 특허 소송을 제기한다면 부여받은 라이선스가 폐기된다. 그로 인해 오픈소스 커뮤니티 기여자들은 소송자를 대상으로 집단 소송을 제기할 수 있다.(오픈소스 커뮤니티를 상대로 특허 소송을 제기하지 말라)

 

GPL 2.0

• 소스코드 공개
• 동일 라이선스 제공
• Source 배포 시 저작권, License 정보 유지
• 파일 수정 시 수정 내용을 Notice
• 독립적인 별도의 SW에는 영향을 끼치지 않는다(완전히 별도임을 입증해야 함)
  • 동일한 실행파일에 포함되어있거나, 링크됨(별도가 아님으로 본다)
  • 별도로 분리되어 통신을 수행하는 경우 별도로 본다
  • 프로세스 ID가 별도인가
  • 등등
• Dynamic Linking을 사용하는 경우에도 동일하게 적용

 

GPL 3.0

• 소스코드 공개
• 동일 라이선스 제공
• 설치 등에 특정 메서드, 프로시저, 인증 키 등이 필요한 경우 그것도 명시
• Source 배포 시 저작권, License 정보 유지
• 파일 수정 시 수정 내용을 Notice

 

LGPL 2.1

• 소스코드 공개
• 동일 라이선스 제공(라이브러리에만 제공)
• Source 배포 시 저작권, License 정보 유지
• 파일 수정 시 수정 내용을 제공

 

AGPL 3.0

• 출처 공개
• 소스코드 공개
• 동일 라이선스 제공
• 네트워크를 통해 상호작용하는 앱에 대해서도 라이선스 적용(SaSS 등 클라우드 서비스 사용자)
• Source 배포 시 저작권, License 정보 유지
• 파일 수정 시 수정 내용을 제공

 

Server Side Public License

• 서비스의 소스 코드를 모두 Open
• 조건을 까다롭게 적용하여 보통 Dual License로 Commercial 라이선스를 사용하도록 유도함

 

MPL

• 출처 공개
• 라이선스 및 저작권 고지
• 파일 단위 라이선스

---

OSS 결합 형태 별 Case

• 완전 분리된 저작물의 형태로 배포된 경우에는 GPL에 해당하지 않을 수 있다.
• Linux Kernel, JDK 등은 예외 조건이 있다

LGPL 2.1

• 라이브러리가 단순 참조된 경우엔 라이브러리만 공개하고, 라이브러리가 실행 파일에 포함된 경우 Object 코드를 제공해야 함
• Reverese Engineering도 허용해야 함

LGPL 3.0(+GPL 3.0)

• LGPL 2.1의 소스 공개 의무사항 통일
• Yocto, QT 등에서 사용

AGPL(Affero General Public License)

• 네트워크를 통한 서비스의 소스도 공개해야 함

MPL(Mozilla Public License)

• 포함된 파일만 공개

EPL(Eclipse Public License)

• 포함된 모듈만 공개

---

참조

• OSI Approved Licenses
• Free Software Licenses
• SPDX License List
• Choose an open source license