Opensource SW License Guide
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 37
| Download | |
| Open PDF In Browser | View PDF |
오픈소스 소프트웨어 라이선스 가이드 3.0 CONTENTS 4 가이드 제공의 배경 CHAPTER CHAPTER CHAPTER 01 SW 지적재산권, 라이선스와 오픈소스 라이선스 7 - 16 1.1. 소프트웨어 지적재산권 8 1.2. 소프트웨어 라이선스 9 1.3. 오픈소스 라이선스 10 02 주요 오픈소스 라이선스 및 프로젝트 사례 19 - 54 2.1. BSD형 라이선스 및 주요 프로젝트 20 2.1.1. BSD 라이선스 20 2.1.2. Apache 라이선스 21 2.2. GPL형 라이선스 및 주요 프로젝트 25 2.2.1. GPL 2.0 25 2.2.2. GPL 3.0 36 2.2.3. LGPL 39 2.2.4. Affero GPL 43 2.2.5. GPL Exceptions 46 2.3. MPL형 라이선스 및 주요 프로젝트 48 2.3.1. MPL 48 2.3.2. CDDL 49 2.3.3. CPL, EPL 50 2.4. 폰트 라이선스 53 2.4.1. GPL Font Exception 53 2.4.2. SIL Open Font License (OFL) 54 2.4.3. Ubuntu Font License 54 03 라이선스 확인 방법 57 - 64 3.1. 직접 확인하는 방법 58 3.2. 도구를 이용하는 방법 60 3.2.1. 문자열 검색 도구 60 3.2.2. 코드 스캔 도구 61 3.2.3. 바이너리 스캔 도구 63 | 부록 | 기타 상담 사례 66 O P E N SOURCE SW LICENCE GUIDE 3.0 사례들을 구체적으로 다룸으로써 현장감을 살리고자 했다. 아무쪼록 이번 가이드가 우리 기업들에게 조금이나마 도움이 될 수 있기를 기대한다. | 오픈소스 소프트웨어 라이선스 가이드 3.0 | 오픈소스에 관한 법적 리스크는 오픈소스 라이선스 위반, 제3자의 지적재산권 침해, 가이드 제공의 배경 자사의 지적재산권 관리에 관한 리스크로 구분할 수 있다. 첫 번째, 라이선스 위반에 관한 리스크는 오픈소스에 관한 가장 기본적인 리스크인데, 오픈소스를 사용하면서 관련 라이선스를 준수하지 않는 경우 오픈소스 커뮤니티로부터 소송을 제기당할 수 있다는 점이다. 예를 들면 BusyBox와 관련하여 국내 대기업을 포함한 전 세계 다양한 기업들이 소송을 제기당한 사례가 대표적이다. 두 번째, 오픈소스 자체가 제3자의 특허권이나 저작권 등 지적재산권을 침해함으로써 발생할 수 있는 리스크이다. 예를 들어 삼성전자와 LG전자가 안드로이드 플랫폼 기반의 스마트폰을 제조하여 판매하고 있는데, 안드로이드 플랫폼이 마이크로소프트 등의 지적재산권을 포함하고 있을 경우 삼성전자와 LG전자가 부담해야 할 리스크이다. 과거에도 BSD, 리눅스, JBoss와 관련된 법적 분쟁들이 있었고, 최근에는 특히 안드로이드 인터넷 서버, 임베디드 분야를 중심으로 꾸준히 성장해 오던 오픈소스 소프트웨어가 플랫폼에 관한 분쟁이 생겨나고 있는 추세이다. 스마트폰 시대를 맞아 그야말로 소프트웨어 세계의 중심부를 점령하고 있다. 하지만 겉보기에 아무 문제없이 순항 중인 것처럼 보이는 분야나 기업에도 언제나 드러나지 않은 세 번째 리스크는 오픈소스를 활용하는 과정에서 자사의 특허권이나 저작권이 영향을 잠재적인 리스크들이 존재하기 마련이며 실제로 이러한 문제들이 표면으로 드러나고 받을 수 있다는 점이다. 예를 들면, 오픈소스를 활용하면서 자사가 수정했거나 새롭게 있다. 작성한 코드를 GPL 등의 오픈소스 라이선스로 배포하게 되면, 해당 코드와 관련된 자사의 특허권이나 저작권에 오픈소스 라이선스가 적용된다. 그 결과 자사의 특허권이나 국내 대기업을 포함한 전 세계 다양한 기업들이 오픈소스 라이선스를 잘못 다루어 소송을 저작권을 경쟁기업들이 무료로 활용할 수 있게 된다. 제기당하는가 하면, 상용 소프트웨어 기업들이 특허권 등을 무기로 오픈소스 진영을 공격하고 있다. 그럼에도 불구하고 소프트웨어가 진화하는 전반적 방향을 되돌리기는 이상과 같은 법적 리스크들은 기업에서 충분히 관리 가능한 리스크들이다. 따라서 경영자 어려워 보인다. 소프트웨어 기반이 없는 국내 기업들의 입장에서는 이와 같은 흐름을 잘 및 관리자들은 오픈소스에 관한 법적 리스크를 이해하고 자사의 리스크를 분석하고 따르면서 오픈소스의 법적 리스크를 최소화하는 것이 최선의 방책일 것이다. 대비책을 마련할 필요가 있다. 오픈소스를 사용할 때 발생하는 리스크는 법적 측면 이외에도 기술적 측면과 사업적 측면에서도 발생하게 된다. 각각의 리스크들이 모두 기업에서 오픈소스에 관한 법적 리스크를 체크하고 분석하는 데 조금이나마 도움을 중요하기 때문에 세부적으로 살펴보는 것도 중요하지만, 특히 CEO 등 경영자, 관리자의 주고자 오픈소스 라이선스 가이드 3.0을 제공한다. 입장에서는 모든 리스크들을 종합적으로 고려하는 시각을 가지는 것도 중요하다. 관리자의 입장에서는 각각의 리스크를 점검하되, 모두를 만족하게 할 수 없는 경우에는 우선순위를 최근 수년간 국내의 오픈소스 환경은 큰 변화를 겪고 있고, 복잡한 라이선스 이슈들도 정할 필요가 있다. 많이 발생하고 있다. 이러한 변화를 수용하여 이번 가이드에서는 활발하게 사용되고 있는 오픈소스 라이선스들에 대해 주요 의무사항, 대표적인 프로젝트, 주요 쟁점 및 고려사항 등을 체계적으로 설명하고자 했다. 아울러 기업의 오픈소스 담당자들이 궁금해 하는 4 5 C H A P T E R 01 | 오픈소스 소프트웨어 라이선스 가이드 3.0 | SW 지적재산권, 라이선스와 오픈소스 라이선스 O P E N SOURCE SW LICENCE GUIDE 3.0 C H A P T E R 방식을 구현하는 소프트웨어라면 프로그래밍 언어에 상관없이 특허권의 범위에 속한다. 상표권(trademark)이란 상표권자가 지정상품에 관하여 그 등록상표를 사용할 독점적인 권리로서 일정한 절차에 따라 등록하여야 효력이 발생한다. 이러한 상표를 사용하기 위해서는 반드시 상표권자의 허락을 얻어야 하며 허락받지 않고 상표를 이용할 경우 상표권의 침해에 해당한다. 공개되지 않은 소스코드는 영업비밀로서 보호를 받을 수 있다. 하지만 영업비밀은 일단 공개되면 더 이상 보호받기 어렵고, 또한 영업비밀을 알지 못하고 사용한 제3자에게 법적으로 문제를 삼을 수 없다는 한계가 있다. 이상과 같은 지적재산권들 중, 특히 저작권과 특허권을 비교해 보자. 두 권리는 권리의 발생요건, 내용, 효력 면에서 차이가 있기 때문에 주의할 필요가 있다. 예를 들면, 권리의 발생 측면에서는, 저작권은 프로그램을 창작하면서 자동으로 발생하지만, 특허권은 특허청에 출원하여 심사를 받고 등록해야만 권리가 발생하며 그 과정에서 상대적으로 오픈소스 소프트웨어에 관한 법적 리스크를 이해하기 위해서는 소프트웨어에 관한 많은 비용이 소요된다. 하지만 일단 권리가 발생한 후에는 특허권이 저작권보다는 더 강한 지적재산권과 라이선스에 관한 기본적인 개념을 이해할 필요가 있다. 오픈소스 라이선스는 효력을 지니게 된다. 예를 들면 저작권의 경우 코드로 구현된 표현만을 보호하기 때문에 소프트웨어 라이선스의 일종이기 때문이다. 소프트웨어 라이선스의 일반적인 내용을 클린룸(clean-room) 형태로 코드를 작성하는 경우에는 저작권 침해에 해당하지 않지만, 이해하면 오픈소스 라이선스의 특징을 더욱 잘 이해할 수 있다. 일반적인 특징을 이해한 특허권은 기능 자체를 보호하기 때문에 코딩을 다르게 하더라도 동일한 기능을 사용하는 후에는 오픈소스 라이선스 각각의 세부적인 쟁점들을 검토할 필요가 있다. 한 침해에 해당한다. 1.1. 소프트웨어 지적재산권 [ 저작권과 특허권의 비교 ] 프로그램 저작권 특허권 권리 발생 창작과 동시에 발생 특허출원, 심사, 등록 권리 내용 인격권 (공표권, 성명표시권, 동일성유지권) 재산권 (복제권, 개작권, 배포권, 전송권) 독점배타적 실시권 효력 범위 표현(코드)의 실질적 유사성 아이디어(알고리즘, 기능)의 동일성 소프트웨어를 보호하는 법적 장치, 즉 소프트웨어에 관한 지적재산권으로는 저작권, 특허권, 상표권, 영업비밀 등이 있다. 저작권(copyright)은 창작물에 대하여 창작자(저작자)가 취득하는 권리로서 창작의 결과물을 보호하며, 창작과 동시에 권리가 발생한다. 따라서 어떤 프로그래머가 소프트웨어를 개발하면 저작권이 자동으로 발생하며, 그 권리는 프로그래머 또는 그가 속한 회사에 부여된다. 저작권이 있는 저작물은 저작권자의 허락이 없이는 누구도 해당 저작물을 복제, 배포, 수정할 수 없다. 1.2. 소프트웨어 라이선스 소프트웨어에 대한 독점 배타권을 가진 권리자는 다른 사람들이 해당 소프트웨어를 특허권(patent)은 발명에 관하여 발명자(특허권자)가 갖는 독점배타권이다. 저작권과는 사용하거나 배포하는 것을 허락할 수 있다. 일반적인 상용 소프트웨어는 그 대가로 달리 일정한 방식으로 출원해야 하며, 심사를 통과한 후 등록되어야만 권리가 발생한다. 8 9 SW 지적재산권, 라이선스와 오픈소스 라이선스 SW 지적재산권, 라이선스와 오픈소스 라이선스 OPEN SOURCE SW LICENCE GUIDE 3.0 01 특허기술을 사용하기 위해서는 반드시 특허권자의 허락을 얻어야만 한다. 특허받은 | 오픈소스 소프트웨어 라이선스 가이드 3.0 | | 01 | O P E N SOURCE SW LICENCE GUIDE 3.0 계약의 목적, 정의조항, 실시권의 설정, 계약 기간, 로열티, 기록의 보관 등에 관한 간단한 대부분의 오픈소스 라이선스는 개발자 또는 기여자에 관한 사항과 저작권에 관한 사항을 내용만이 포함되어 있다. 그런데 미국의 소프트웨어 라이선스 계약서 내용을 보면 매우 제품에 표시하거나 포함하도록 요구하고 있다. 마치 저작인격권의 하나인 성명표시권과 상세한 내용을 담고 있다. 소프트웨어 계약은 다른 분야에 비해 상대적으로 역사가 유사하다. 길지 않아서 업계의 표준 관행이나 판결 등 분쟁해결의 기준이 명확하지 않다. 그래서 당사자들은 되도록 상세한 규정을 두고 싶어 하기 때문에 계약서 내용이 상세해지게 된다.3. You must retain, in the Source form of any Derivative Works that You 일반적인 상용 소프트웨어 라이선스의 주된 내용은 권리자가 사용자에게 라이선스를 distribute, all copyright, patent, trademark, and attribution notices from the 부여하고 사용자는 그 대가를 지급하는 것으로 구성되어 있다. 이렇게 거둬들인 수입으로 Source form of the Work. 권리자는 이익을 남기고, 또 일부는 R&D 자금으로 재투자하여 소프트웨어의 성능을 개선하거나 새로운 소프트웨어를 개발하게 된다. 오늘날 대부분의 소프트웨어 기업들이 이러한 비즈니스 모델을 가지고 있다. 코드를 수정한 경우 수정한 정보의 표시 이용자가 소스코드를 수정하였을 때에는 수정한 사람, 수정 일자 등 수정에 관한 1.3. 내용을 포함하도록 함으로써, 원본과 구별할 수 있도록 한다. 저작인격권의 하나인 오픈소스 라이선스 동일성유지권에 비유할 수 있다. 그렇다면 오픈소스 라이선스들은 일반적인 소프트웨어 라이선스와 어떻게 다른가? 일반 상용 소프트웨어와 마찬가지로 오픈소스에도 저작권 등 지적재산권이 있다. 그래서 권리자의 허락 없이 함부로 사용하면 소송을 당할 수 있다. 그런데 오픈소스의 권리자들은 2. You must cause any modified files to carry prominent notices stating that 되도록 많은 사람이 자유롭게 사용할 수 있도록 광범위한 라이선스를 부여하고 있다. You changed the files. 예를 들어 사용자들에게 사용에 대한 권리뿐만 아니라 마음대로 복제 및 배포를 할 수 있도록 하고, 소스코드까지 제공하여 마음대로 수정할 수 있도록 허락한다. 하지만 상용 소프트웨어처럼 그에 따르는 로열티를 요구하지는 않으며, 대신 몇 가지 지켜야 할 라이선스 정보의 제공 의무사항을 요구한다. 구체적인 예를 통해 몇 가지 의무사항을 살펴보기로 하자. 많은 오픈소스 라이선스들은 이용자들이 오픈소스에 관한 권리를 잘 이해할 수 있도록 배포자가 해당 라이선스의 사본을 함께 첨부할 것을 요구하고 있다. 1. You must give any other recipients of the Work or Derivative Works a copy of this License. 동일한 라이선스로 재배포할 것 (카피레프트) 라이선스에 따라 큰 차이를 보이는 부분은 ‘카피레프트(Copyleft)’ 1)에 관한 사항이다. [ 오픈소스 라이선스 모델 ] 10 1) 카피레프트(Copyleft)라는 용어는 원래 저작권(Copyright)에 반대한다는 의미로 “Copy-right”에서 “right” 대신 “left”로 바꾸어 사용하기 시작한 것이다. 그런데, FSF가 말하는 “소프트웨어의 자유”를 지키기 위한 구체적인 수단이 GPL이며, 그 중에서도 핵심적인 내용은 파생저작물을 GPL로 재배포할 것을 요구하는 조항이기 때문에, 보통 이 조항을 가리켜 카피레프트 조항이라고 부르고 있다. 11 SW 지적재산권, 라이선스와 오픈소스 라이선스 저작권, 개발자 및 기여자 정보의 표시 OPEN SOURCE SW LICENCE GUIDE 3.0 로열티를 요구한다. 국내에서 활용되는 소프트웨어 라이선스계약에는 일반적으로 | 01 | O P E N SOURCE SW LICENCE GUIDE 3.0 GPL을 대표로 하는 카피레프트 라이선스들은 이용자들이 소프트웨어를 수정한 후 배포하고자 할 때 수정된 소프트웨어도 동일한 라이선스로 배포할 것을 요구한다. SW 지적재산권, 라이선스와 오픈소스 라이선스 You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, … provided that you also meet all of these conditions: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be [ 삼성전자의 소스코드 제공 사이트 ] licensed as a whole at no charge to all third parties under the terms of this License. 소스코드의 제공 카피레프트 조항을 포함하는 라이선스의 경우, 소프트웨어를 배포할 때 소스코드까지 함께 배포하도록 요구한다. [ LG전자의 소스코드 제공 사이트 ] You may copy and distribute the Program (or a work based on it, under Section 2) in object code … provided that you also do one of the following: 주요 오픈소스 라이선스들에서 다루고 있는 공통적인 쟁점들을 정리하면 아래의 표와 a) Accompany it with the complete corresponding machine-readable source 같이 표시할 수 있다. 오픈소스 라이선스에서 공통으로 다루고 있는 쟁점들을 파악하고 code, 있으면, 새로운 라이선스를 접하더라도 한결 이해가 쉽다. 공통적인 사항에 대해 어떻게 규정하고 있는지, 예외적인 사항은 무엇인지 등만 체크하면 되기 때문이다. <사례> 국내 기업들의 소스코드 제공 [ 주요 오픈소스 라이선스의 특징 비교 ] 삼성전자와 LG전자는 웹사이트를 통해 휴대폰, TV 등 오픈소스를 이용하고 있는 제품들의 소스코드를 제공하고 있다. 라이선스의 특징 및 의무사항 BSD 복제·배포·수정의 권한 부여 O 배포시 라이선스 사본 첨부 저작권고지사항 또는 Attribution 고지사항 유지 배포시 소스코드 제공 의무(Reciprocity)와 범위 12 13 O Apache GPL 2.0 2.0 GPL 3.0 LGPL 2.1 MPL CDDL CPL/ EPL O O O O O O O O O O O O O O O O O O O O O file file module derivative work work based derivative on the work program OPEN SOURCE SW LICENCE GUIDE 3.0 | 01 | O P E N SOURCE SW LICENCE GUIDE 3.0 조합저작물(Larger Work)작성 및 타 라이선스 배포 허용 O Apache GPL 2.0 2.0 O O MPL CDDL CPL/ EPL O O O O O O O O GPL 3.0 LGPL 2.1 수정시 수정내용 고지 O O 명시적 특허라이선스의 부여 O O O O O 라이선시가 특허소송 제기시 라이선스 종료 O O O O O O O 이름, 상표, 상호에 대한 사용제한 O O 보증의 부인 O O O O O O O O 책임의 제한 O O O O O O O O 둘째, 해당 프로그램에는 소스코드가 포함되어 있어야 하며, 이용자가 소스코드 형태로 배포하는 것을 허용해야 한다. 예를 들면, 프리웨어(freeware)의 경우 자유로운 재배포가 허용되지만, 소스코드가 포함되어 있지 않기 때문에 오픈소스에 해당하지 않는다. OSI로부터 오픈소스 라이선스 인증을 받기 위해서는 이 밖에 8가지의 추가적인 요건을 충족시켜야 한다. 자세한 내용은 OSI의 사이트에서 확인할 수 있다.3) 라이선스별로 비교표를 만들어보는 것도 도움이 된다. 국내에서는 한국저작권위원회가 운영하는 OLIS 사이트(http://www.olis.or.kr)에서 67종의 오픈소스 라이선스를 정리하여 보여주고 있다. <상담 사례> 비상업용으로만 사용하도록 한 경우 Q: 구글의 안드로이드 플랫폼에는 netperf 라는 오픈소스가 포함되어 있습니다. netperf license를 찾아보니 다음과 같은 내용이 포함되어 있습니다. 그런데, non-commercial only라고 되어있는데, 우리 회사가 사용하여도 되는지요? The enclosed software and documentation includes copyrighted works of Hewlett<참고> OSI와 Open Source Definition Packard Co. For as long as you comply with the following limitations, you are hereby 오픈소스 라이선스들의 구체적인 내용은 라이선스마다 차이가 있지만, 모든 오픈소스 authorized to (i) use, reproduce, and modify the software and documentation, and to (ii) 라이선스가 공통으로 가진 특징이 있다. 왜냐하면 이러한 공통된 특징 혹은 요건을 distribute the software and documentation, including modifications, for non-commercial 2) 충족해야만 OSI(Open Source Initiative) 로부터 오픈소스 라이선스로 인증받을 수 있기 purposes only. 때문이다. 몇 가지 특징을 살펴보자. A: 라이선스 문구에 ‘non-commercial’ 이라는 조건이 포함되어 있으면 회사에서 상업적으로 활용하기는 어렵습니다. 다만, 이러한 조건이 포함되어 있으면 OSI의 인증을 첫째, 라이선스는 소프트웨어의 자유로운 재배포를 허용해야 하며, 사용자가 소프트웨어를 받기가 어려우며, 반대로 OSI의 인증을 받은 라이선스에는 이러한 조건이 포함되어 있지 상업용으로 사용하더라도 로열티 등의 명목으로 대가를 요구할 수 없다. 만약 어떤 않습니다. 참고로 현재 HP는 netperf 라이선스 외에 GPL로도 배포하고 있으므로, 상용으로 라이선스가 ‘비상업용(non-commercial)’으로만 배포할 수 있도록 허용한다면, OSI의 사용할 때에는 GPL로 배포되는 netperf를 사용할 수 있습니다.4) 요건을 충족하지 못하기 때문에 오픈소스 라이선스가 될 수 없다. 3) http://www.opensource.org/docs/osd 4) http://www.freshports.org/benchmarks/netperf 2) http://www.opensource.org/ 14 15 SW 지적재산권, 라이선스와 오픈소스 라이선스 BSD OPEN SOURCE SW LICENCE GUIDE 3.0 라이선스의 특징 및 의무사항 | 01 | O P E N SOURCE SW LICENCE GUIDE 3.0 <상담 사례> 표준을 구현한 오픈소스코드 SW 지적재산권, 라이선스와 오픈소스 라이선스 Q: Audio 또는 Video 코덱 중에 보면 ITU-T, 3GPP, ETSI와 같은 표준을 제정하는 협회에서 Reference Code를 오픈하여 누구나 참조하여 사용할 수 있도록 하고 있습니다. 그런데 이 소스 중 일부분이 GPL 라이선스로 배포되고 있습니다. 이런 경우 Audio, video 코드를 상업적으로 사용하기 위해서는 어떤 절차를 거쳐야 하는지 궁금합니다. A: 상업적으로 이용하기 위해서는 레퍼런스 코드의 권리자(특허권자를 포함)에게 허락을 받아야 합니다. 아울러 표준기관에서 배포하는 레퍼런스 코드를 직접 이용하는 것이 아니라 GPL로 배포되는 코드를 이용한다면 GPL의 조건도 준수해야 합니다. 예를 들면, FFmpeg의 주요 부분은 LGPL로 배포되고 있으므로 표준기관에서 배포하는 레퍼런스 코드가 아니라 LGPL로 배포되는 FFmpeg를 이용하기 위해서는 LGPL 조건을 준수해야 합니다. 한편, MPEG 기술에 대해서는 다수의 특허권이 관련되어 있기 때문에 경우에 따라서는 FFmpeg를 사용하기 위해서 MPEG에 관한 특허권자의 허락을 받아야 하는 경우도 있습니다. 예를 들어 MPEG LA는 FFmpeg을 사용하는 사용자에게 추후 특허권을 주장할 수 있으며, 이에 대해 사용자는 Royalty를 지급해야 할 수도 있습니다. 그리고 FFmpeg을 LGPL로 배포하고 있는 저작권자는 해당 소프트웨어 내 자신들의 특허가 아닌 제3자(MPEG LA)의 관련 특허가 있음(Non Royalty-Free Patents)을 사용자에게 공지하여, 사용 시 참고할 수 있도록 하고 있습니다.5) 물론 자신들의 특허는 LGPL로 배포하므로 Royalty-Free로 하였겠지만, 제3자의 특허는 어떻게 할 수 없으므로 사용자에게 그런 제3자 특허의 위험을 알리는 것입니다. 5) FFmpeg license 참조. FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg. Q: Is it perfectly all right to incorporate the whole FFmpeg core into my own commercial product? A: You might have a problem here. There have been cases where companies have used FFmpeg in their products. These companies found out that once you start trying to make money from patented technologies, the owners of the patents will come after their licensing fees. Notably, MPEG LA is vigilant and diligent about collecting for MPEG-related technologies. 16 17 OPEN SOURCE SW LICENCE GUIDE 3.0 | 01 | O P E N SOURCE SW LICENCE GUIDE 3.0 C H A P T E R 02 | 오픈소스 소프트웨어 라이선스 가이드 3.0 | 주요 오픈소스 라이선스 및 프로젝트 사례 O P E N SOURCE SW LICENCE GUIDE 3.0 O P E N SOURCE SW LICENCE GUIDE 3.0 C H A P T E R 02 사용하는 구조라면, 저작권자에게 BSD 3-Clause 라이선스로 변경하여 해결하라고 FSF는 | 오픈소스 소프트웨어 라이선스 가이드 3.0 | 안내하고 있다. 주요 오픈소스 라이선스 및 프로젝트 사례 이와 같은 이유로 카 인포테인먼트 시스템의 대표적인 오픈소스 플랫폼인 GENIVI 플랫폼에서 사용하지 말도록 금지하고 있는 라이선스에 BSD 4-Clause 라이선스가 포함되어 있다. BSD 3-Clause 라이선스에서 “제품에 대한 보증이나 홍보에 최초개발자나 기여자의 이름을 사용하지 못한다”는 조항을 삭제한 것이 BSD 2-Clause 라이선스다. 이는 BSD 라이선스 중 가장 간략하고 의무사항이 덜한 라이선스로 볼 수 있다. <프로젝트 사례> BSD 운영체제 운영체제는 현재 FreeBSD, OpenBSD, NetBSD, DragonFly BSD 등의 형태로 변형되어 계속해서 오픈소스로 배포되고 있다. 라이선스 및 주요 프로젝트 2.1. . 다 니 입 BSD형 것 BSD형 라이선스에는 BSD, MIT, Apache 라이선스 등이 포함되며, 비교적 오랜 역사를 2.1.2. Apache 라이선스 가진 라이선스들이다. 이들 라이선스는 카피레프트(Copyleft) 조항을 포함하지 않으며, Apache 라이선스는 아파치소프트웨어재단(Apache Software Foundation)에서 만들어 의무사항도 비교적 간단하다. 배포한 라이선스이다. 1.0과 1.1 버전은 BSD와 비슷하게 간단한 내용만을 담고 있었지만, 현재 사용되고 있는 2.0 버전은 2004년에 배포된 것으로 비교적 상세한 내용을 담고 있다. 2.1.1. BSD 라이선스 배포 시의 의무사항으로는 저작권, 특허, 상표, 권리귀속(attribution)에 대한 고지사항을 BSD 라이선스는 버클리 대학에서 만든 라이선스로, 소프트웨어를 재배포할 때 저작권 소스코드 또는 "NOTICE" 파일 등에 포함할 것과, 수취인에게 라이선스 사본을 제공하도록 표시를 할 것과 준수 조건 및 보증부인에 대한 고지사항을 소스코드 또는 문서 및 요구하고 있으며, 파일을 수정하여 배포할 경우 수정된 파일에 대해 수정사항을 표시한 기타자료에 포함할 것을 요구하고 있다. 안내 문구를 첨부할 것을 요구하고 있다. 하지만 카피레프트 조항을 포함하고 있지 않기 때문에 반드시 동일한 라이선스로 배포할 필요는 없으며, 소스코드 제공 의무도 없다는 4개의 조항으로 구성된 BSD 4-Clause 라이선스 (Original BSD 혹은 Old BSD 라고도 점에서 기본적으로 BSD 라이선스와 비슷한 것으로 평가할 수 있다. 불림)에는 “광고 조항”이 포함되어 있다. 이는 파생저작물의 모든 홍보물에 “This product includes software developed by the ” 문구를 포함해야 하는데, 이는 문제 소지가 있는 조항으로 판단되어 1999년 7월 이를 삭제한 BSD 3-Clause 라이선스 <상담 사례> Apache 코드와 BSD 코드를 링크한 경우 (Modified BSD 혹은 New BSD 라고도 불림)가 만들어졌다. Q: Apache 라이선스로 배포되는 파일과 BSD 라이선스로 배포되는 파일을 함께 링크한 20 BSD 4-Clause 라이선스의 광고 조항은 별도의 제한 사항으로 볼 수 있어 GPL과 경우 어떤 라이선스를 따라야 하는지 궁금합니다. 호환되지 않는다. 따라서 BSD 4-Clause 라이선스로 배포된 오픈소스가 GPL 프로그램을 A: BSD, Apache 등 BSD형 라이선스는 원 코드나 수정코드를 재배포할 때 동일한 21 OPEN SOURCE SW LICENCE GUIDE 3.0 1995년까지 활동했었던 버클리 대학의 컴퓨터시스템연구소(SCRG)가 최초로 배포한 BSD 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 BSD 라이선스로 배포되고 있는 대표적인 프로젝트는 BSD 운영체제이다. 1977년부터 O P E N SOURCE SW LICENCE GUIDE 3.0 라이선스로 배포해야 한다는 조항(카피레프트 조항)이 없기 때문에 배포자는 라이선스를 <상담 사례> 구글 안드로이드 SDK의 라이선스 자유롭게 선택할 수 있습니다. 이것은 두 개의 라이선스로 배포되는 코드를 링크할 때도 마찬가지입니다. 따라서 기업에서는 Apache 등 BSD형의 라이선스로 배포되는 다양한 Q : 구글이 제공하고 있는 안드로이드 SDK의 라이선스는 무엇입니까? 다른 안드로이드 코드를 이용하여 자사의 제품을 만든 후 이를 상용 라이선스로 배포하는 것도 가능합니다. 플랫폼과 마찬가지로 Apache 등의 오픈소스 라이선스로 제공되고 있나요? 구글이 다만, 이러한 경우에 소스코드를 공개할 필요는 없지만, Apache 라이선스 등이 요구하는 제공하고 있는 안드로이드 SDK를 기반으로 우리 회사의 SDK를 만들어 배포하는 것이 기타의 사항(저작권 및 개발자 표시, 수정내용 고지 등)은 준수해야 합니다. 가능한가요? A: 그렇지 않습니다. 구글은 안드로이드 SDK에 대한 별도의 사용조건(라이선스)을 정하고 있습니다. 여기에 따르면 이용자들은 구글의 SDK를 함부로 복제, 수정, 재배포, 역컴파일, 리버스 엔지니어링 하거나 이를 기반으로 한 파생저작물을 만들 수 없습니다.7) 구글이 이와 <프로젝트 사례> 안드로이드 플랫폼 같은 제한을 둔 것은 하나의 애플리케이션이 다양한 제조사에서 만든 안드로이드폰에서 Forge.net의 5,000개 이상의 프로젝트가 Apache 라이선스로 배포되고 있다. 또한, 작동될 수 있도록 호환성을 확보하기 위한 것으로 보입니다. 다만 구글의 SDK 사용조건은 2008년 5월 구글은 블로그를 통해 Google Code의 100,000여개 프로젝트 중 25%가 구글이 만든 부분에만 적용됩니다. 만약 구글의 SDK 내에 GPL/LGPL과 같이 사용자에게 Apache 라이선스를 사용하고 있다고 발표했었다.6) 소스를 제공하고 수정/배포를 허락하는 오픈소스가 포함되어 있다면 해당 소프트웨어 라이선스 조항을 살펴보시기 바랍니다. 최근 Apache 라이선스로 배포되는 가장 큰 프로젝트는 안드로이드 플랫폼이다. 커널과 애플리케이션을 제외한 안드로이드 플랫폼의 많은 부분은 Apache 라이선스로 배포되고 있다. 하지만 일부 구성요소들은 CPL, EPL, GPL, LGPL 등으로 배포되고 있으며, 이들은 Apache 라이선스가 아닌 각각의 라이선스 규칙을 따라야 한다는 점을 주의할 필요가 있다. <참고> 안드로이드 애플리케이션의 라이선스 이슈 미들웨어가 Apache 라이선스로 배포되는 경우 애플리케이션의 라이선스에는 영향을 미치지 않는다. 그 결과 애플리케이션의 개발자들은 자유롭게 라이선스를 결정할 수 [ 안드로이드 플랫폼의 구성부분과 해당 라이선스 ] 있다. 유료의 상용 라이선스를 선택하는 것도 물론 가능하다. 구글이 안드로이드 플랫폼에 APACHE2 bionic/linker APACHE2 dalvik APACHE2 dalvik/libcore-disabled/instrument APACHE2 dalvik/libcore-disabled/sound APACHE2 dalvik/libcore/annotation APACHE2 dalvik/libcore/archive APACHE2 dalvik/libcore/auth APACHE2 dalvik/libcore/awt-kernel APACHE2 dalvik/libcore/crypto APACHE2 dalvik/libcore/dalvik APACHE2 dalvik/libcore/logging APACHE2 dalvik/libcore/luni APACHE2 dalvik/libcore/luni-kernel APACHE2 dalvik/libcore/math … CPL dalvik/libcore/junit EPL prebuilt/common/eclipse EPL prebuilt/common/osgi EPL prebuilt/darwin-x86/swt ... GPL external/blktrace GPL external/e2fsprogs GPL external/e2fsprogs/e2fsck ... LGPL external/e2fsprogs/lib/blkid LGPL external/e2fsprogs/lib/e2p ... MIT external/e2fsprogs/lib/ss OSL1 external/elfutils W3C dalvik/libcore/xml 대한 라이선스를 GPL이 아닌 Apache 라이선스로 결정한 것은 더욱 많은 개발자들의 참여를 끌어내기 위해서이다. 스마트폰의 경쟁력은 얼마나 많은 애플리케이션을 확보하고 있는가에 달려 있다. 구글의 입장에서는 GPL로 대변되는 오픈소스의 정신을 존중하는 것도 중요했지만, 개발자들에게 라이선스를 선택할 수 있는 자유를 주어 보다 많은 애플리케이션이 개발될 수 있도록 하는 것이 더 중요했다고 볼 수 있다. 그런데 애플리케이션에 따라서는 기존의 오픈소스를 기반으로 개발되는 것도 있다. 이러한 경우 해당하는 오픈소스 라이선스를 지켜야 하는 것은 물론이다. 예를 들어 GPL로 배포되는 오픈소스를 기반으로 안드로이드 애플리케이션을 개발하는 경우 GPL에 따라 소스코드를 제공해 주어야 한다. 앱스토어(안드로이드 마켓)를 통해 직접 소스코드를 7) Android SDK Terms and Conditions 3.4 You may not use the SDK for any purpose not expressly permitted by the License Agreement. Except to the extent required by applicable third party licenses, you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK; or (b) load any part of the SDK onto a mobile handset or any other hardware device except a personal computer, combine any part of the SDK with other software, or distribute any software or device incorporating a part of the SDK. 6) 위키피디아 참조. 2010년 9월 Google Code 프로젝트에서는 OSI 인증라이선스 모두를 받아들이는 것으로 변경했다. 22 23 OPEN SOURCE SW LICENCE GUIDE 3.0 부분만은 사용자가 수정하여 재배포할 수 있습니다. 상세한 라이선스 의무사항은 SDK 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 아파치 서버 등 아파치재단의 프로젝트들뿐만 아니라, (2008년 조사결과) Source O P E N SOURCE SW LICENCE GUIDE 3.0 제공하는 것은 어려우므로 애플리케이션의 일정 부분에 소스코드를 제공한다는 안내를 조합저작물(Larger Work)작성 및 타 라이선스 배포 허용 하고 다른 웹서버를 통해 소스코드를 제공하는 방법을 고려할 수 있다. 이러한 사항을 수정시 수정내용 고지 O 명시적 특허라이선스의 부여 O 라이선시가 특허소송 제기시 라이선스 종료 O 지키지 않는 경우 라이선스 위반에 해당하여 소송을 당할 수 있다. 이러한 경우 애플리케이션 개발자가 책임을 지는 것과는 별도로, 앱스토어 운영사도 라이선스 위반에 대한 책임이 있는가? 이 문제는 이용자의 저작권 침해에 대해 네이버 등 서비스제공자도 책임을 져야 하는가의 문제와 유사하다. 서비스유형에 따라 다른 판결이 이름, 상표, 상호에 대한 사용제한 O O 보증의 부인 O O 책임의 제한 O O 나오고 있지만, 권리자가 권리침해가 있다는 통지를 해오는 경우 서비스제공자는 즉시 관련 저작물을 삭제하는 것으로 대응하고 있다. 2.2. GPL형 라이선스 및 주요 프로젝트 <위반 사례> GNU Go와 Apple 앱스토어 가진다는 점에서 BSD와 비슷하지만, 카피레프트 조항과 소스코드 제공 의무를 가지고 앱스토어에 등록하면서 GPL을 따르지 않은 것이다. FSF는 Robota사에 GPL을 지킬 것을 있다는 점에서 큰 차이가 있다. 카피레프트의 적용 범위 및 소스코드 제공 의무의 범위는 요구하는 한편, Apple에 대해서도 몇 가지 쟁점에 대해 컴플라이언스를 요구하였다. 하지만 GPL, LGPL, AGPL 각각에 차이가 있다. Apple은 앱스토어에서 GNU Go를 삭제하는 결정을 내렸다. FSF가 Apple에게 지적한 문제 중의 하나는 Apple의 앱스토어 서비스 약관이 GPL에 관한 이용자들의 권리를 제한하고 있다는 점이었다. 예를 들어 GPL은 이용자들에게 어떠한 2.2.1. GPL 2.0 GPL 2.0으로 배포되는 오픈소스는 i) 각 복제본에 적절한 저작권 표시와 보증책임이 추가적인 제한을 하지 못 하게 하고 있는데, 앱스토어의 서비스 약관에는 다운로드받은 없음을 명시하고, ii) GPL 라이선스를 언급하는 고지사항과 보증책임 관련 고지사항을 애플리케이션을 iPhone OS에서만 (iPad, iPhone, iPod touch) 이용하도록 제한하고 원본 그대로 유지하고, iii) 소프트웨어를 양도받는 모든 이들에게 소프트웨어와 함께 GPL 있으므로 GPL을 위반한다는 것이다. 하지만 Apple의 입장에서는 앱스토어 서비스약관을 라이선스 사본을 제공하고, iv) 파일을 수정한 경우 수정했다는 사실과 날짜를 파일에 변경하기는 어려웠기 때문에, GPL을 따르기보다는 차라리 GNU Go를 삭제하는 결정을 명기해야 한다. 그리고 v) 원본저작물과 파생저작물(derivative work)을 GPL 2.0에 의해 내린 것이다. 배포해야 하며, vi) 원본저작물 및 파생저작물에 대한 소스코드를 제공하거나, 요청 시 제공하겠다는 약정서를 제공해야 한다. 여기서 i) ~ iv)의 의무사항은 Apache 라이선스와 동일하거나 유사한 내용이지만, v) 및 vi)의 의무사항은 BSD형의 라이선스에서는 찾아볼 BSD형 라이선스 요약 수 없는 내용이다. [ BSD형 라이선스의 주요 내용과 특징 비교 ] 라이선스의 특징 및 의무사항 복제·배포·수정의 권한 부여 BSD Apache 2.0 O O 배포시 라이선스 사본 첨부 저작권고지사항 또는 Attribution 고지사항 유지 <참고> 파생저작물의 범위에 관한 해석 오픈소스 현장에서는 GPL 2.0에서 언급하고 있는 파생저작물(derivative work) 8)의 O O O 8) GPL 2.0 "... These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." 배포시 소스코드 제공 의무(Reciprocity)와 범위 24 25 OPEN SOURCE SW LICENCE GUIDE 3.0 대부분 FSF(Free Software Foundation)에서 주도하여 만든 것이다. 비교적 오랜 역사를 회사가 GPL로 배포되고 있는 GNU Go라는 게임을 iPhone용 게임으로 변경하여 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 GPL형 라이선스에는 GPL 2.0, GPL 3.0, LGPL 2.1, LGPL 3.0, AGPL 3.0 등이 포함되며, Apple의 앱스토어에서 GPL 라이선스위반 사례가 발생했었다. Robota Softwarehouse라는 O P E N SOURCE SW LICENCE GUIDE 3.0 범위가 어디까지인지에 관해 논란이 많다. 일반적으로 계약이나 법 조항이 명확하지 않은 형태로 통신하는 경우, 플러그인이 fork나 exec을 이용하는 경우 등은 별도의 저작물로서 경우 당사자의 의도나 거래 관행 등을 종합적으로 고려하여 법원에서 결정하게 된다. GPL이 적용되지 않는다고 답변하고 있다. GPL도 명확하지 않은 부분이 많으며, 최종적으로는 법원에서 가려지겠지만, GPL을 만든 FSF에서는 GPL의 해석에 도움을 주고자 많은 FAQ를 제공하고 있다.9) 그런데, FSF의 이와 같은 해석이 저작권법상의 파생저작물 또는 2차적 저작물의 범위를 벗어난다는 주장도 일부 있다. GPL 3.0에서는 이와 같은 비판을 고려하여 “derivative 예를 들면, GPL로 배포된 소프트웨어를 수정하였거나 새로운 소프트웨어에 정적 works”라는 용어를 삭제하고 “Work based on the program”으로 통일하고 있다. 링크시키는 경우, 즉 두 개의 모듈이 동일한 실행 파일에 포함되어 있을 경우는 해당 실행 파일에 포함된 모든 소스는 GPL이 적용된다. <프로젝트 사례> 리눅스 커널 GPL 2.0으로 배포되는 대표적인 프로젝트는 리눅스 커널이다. 리누스 토발즈가 만들어 GPL 2.0으로 배포한 이후 많은 개인 및 기업들의 기여 때문에 진화됐다. 리눅스 커널 소스코드의 루트 디렉토리에 있는 ‘CREDITS’라는 파일에는 리눅스 소스코드를 제공할 때는 CREDITS 파일이 빠지지 않도록 신경 써야 한다. [ CREDITS 파일의 내용 ] This is at least a partial credits-file of people that have contributed to the 또한, 동일한 바이너리에 포함되지 않더라도 동적 링크 등의 방식으로 공유주소영역에서 Linux project. It is sorted by name and formatted to allow easy grepping and 링크되어 실행되도록 설계된 경우, 플러그인이 동적으로 링크되어 함수를 호출하고 beautification by scripts. The fields are: name (N), email (E), web-address (W), 데이터구조를 공유하는 경우에도 GPL 소프트웨어와 함께 링크되어 실행되는 PGP key ID and fingerprint (P), description (D), and snail-mail address (S). 소프트웨어에도 GPL이 적용되어 소스코드를 제공해야 한다. Thanks, Linus ---------N: Matti Aarnio E: mea@nic.funet.fi D: Alpha systems hacking, IPv6 and other network related stuff D: One of assisting postmasters for vger.kernel.org's lists S: (ask for current address) S: Finland CREDITS와 같은 디렉토리에 있는 COPYING 파일에는 리눅스 커널이 GPL 2.0에 의해 배포되고 있다는 것과 리눅스의 정상적인 시스템 콜에 의해 커널 서비스를 이용하는 ‘user 반면, 두 개의 프로그램이 파이프(pipes), 소켓(sockets), command-line arguments programs’에는 저작권이 적용되지 않는다는 리누스 토발즈의 글이 포함되어 있다. ‘user 9) http://www.fsf.org/licensing/licenses/gpl-faq.html. 26 27 OPEN SOURCE SW LICENCE GUIDE 3.0 저자에 관한 이름 등은 함부로 변경하거나 삭제할 수 없다. 따라서 리눅스 커널의 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 프로젝트에 기여한 개인들의 이름, 주소, ID, 이력 등이 나타나 있다. GPL 2.0에 따르면 O P E N SOURCE SW LICENCE GUIDE 3.0 programs’이 GPL의 적용대상에서 제외된 것처럼, 커널 모듈도 GPL의 적용대상에서 셋째, 모듈 내 리눅스 커널 소스의 일부가 전혀 사용되지 않았을 경우여야 한다. 리눅스의 제외되는가에 대해 많은 논란이 있다. 오픈소스 커뮤니티의 일부 개발자 및 기업들은 커널 표준 커널 모듈 인터페이스만을 사용해 모듈을 제작하였다면 문제없지만, 커널 소스가 모듈도 GPL의 적용대상이 되지 않는 것으로 해석하기도 하지만, 적지 않은 수의 기여자, 모듈 내 일부라도 포함되었다면 리눅스의 파생저작물로 판단할 수밖에 없다. 즉 커널에 대한 권리자들이 이러한 해석에 반대하고 있다. 오히려 저작권법의 관점에서 보면 일부의 권리자들이 소송을 제기하는 것도 가능하므로, 각 기업의 입장에서는 한편, 대부분의 GPL 오픈소스가 FSF의 권유에 따라 “either version 2 of the License, 보수적인 판단을 하는 것이 낫다. or any later version”에 의해 배포되는 반면, 리눅스 커널은 2.0에 의해서만 배포된다. 그 결과 기여자 중 일부가 반대한다면 리눅스 커널이 GPL 3.0으로 전환하는 것은 [ COPYING 파일의 내용 ] 불가능하다고 볼 수 있다. NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls … Also … but the instance of code that it wrote it. Q: 리눅스 커널의 경우 모듈로 제공되는 드라이버에 대한 공개 여부가 논란이 있는 것 Also note that the only valid version of the GPL as far as the kernel is 같은데 어떻게 대응해야 하는가요? concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or A: GPL 2.0에 대한 FSF의 해석에 따르면, 커널과 동적 링크된 모듈은 파생저작물에 whatever), unless explicitly otherwise stated. 해당하기 때문에 원칙적으로 소스코드를 제공해야 합니다. 그런데, “정상적인 시스템 Linus Torvalds 콜에 의해 커널 서비스를 이용하는 User Program은 GPL 2.0의 적용을 받지 않는다”는 리눅스 커널 라이선스 문구를 인용하면서, 커널 모듈 표준 인터페이스를 사용할 경우에는 각 기업에서 GPL의 적용을 받지 않는 커널 모듈이라고 주장하기 위해 최소한 지켜야 하는 예외적으로 GPL이 적용되지 않는다는 견해도 있습니다. 실제로 일부 기업들은 디바이스 기준은 다음과 같다. 드라이버에 대한 소스코드를 제공하지 않고 있습니다. 리눅스 커널 모듈에 GPL이 적용되는지에 대한 문제는 아직 명확한 해석이나 판결이 첫째, 커널 모듈 라이선스를 GPL로 선언하지 않아야 한다. 즉, MODULE_ 없습니다. 최소한 앞에서 설명한 세 가지를 만족하지 못한다면 커널 모듈은 GPL의 LICENSE("GPL")로 선언된 매크로가 존재해서는 안 된다. 이는 커널 모듈에서 GPL로 적용을 받는 것이 명백하고, 만족한다 하더라도 이는 법원의 명확한 판결이 아니므로, export 된 커널 함수(EXPORT SYMBOL이 아닌 EXPORT_SYMBOLE_GPL로 export 된, 직접적인 소송에서는 다른 판단이 나올 수도 있습니다. 따라서 각 기업에서는 소스코드를 10) 이하 GPL-ONLY Symbol) 를 사용하지 않았음을 의미한다. (MODULE_LICENSE("GPL") 제공하든지, 아니면 법적 리스크를 감수하면서 자사의 영업비밀로 보호하는 전략을 취하는 매크로가 선언되지 않은 상태에서 GPL-ONLY Symbol을 사용할 경우 모듈 빌드시 error 등의 전략적인 판단을 해야 합니다. message를 표시하며 빌드되지 않는다.) 둘째, Linux-Only Driver가 아니어야 한다. 이는 리누스 토발즈의 의견에 따라 Linux <참고> 소스코드의 제공범위 외 다른 OS 상에서 동작하는 드라이버를 리눅스 상에 포팅한 것이라면 리눅스(GPL)의 제공할 소스코드의 범위에 관하여 GPL 2.0은 “all the source code for all modules it 파생저작물로 보지 않을 수 있다. 하지만 리눅스 상에서만 동작하는 드라이버라면 contains, any associated interface definition files, the scripts used to control compilation 리눅스의 파생저작물이 아니라는 주장의 설득력이 떨어진다. and installation of the executable”이라고 규정하고 있다. 따라서, 소스코드를 컴파일해서 바이너리를 생성하기 위한 build script를 제공할 필요가 있으며, 생성된 바이너리를 제품에 설치하기 위한 install script를 제공해야 한다. (단, 사용자가 생성한 바이너리를 제품에 10) Kernel 개발자들이 GPL-ONLY Symbol의 비율을 높여가고 있기 때문에 GPL-ONLY Symbol의 수는 커널버전이 올라갈수록 증가하고 있다 : 2.5.75 (5개) ⇒ 2.6.10 (400여개) ⇒ 2.6.18 (1,000여개) ⇒ 3.0 (500여개) ⇒ 3.8 (7,000여개) ⇒ 3.18 (10,000여개) ⇒ 4.4 (11,000여개) ⇒ 4.8 (12,000여개) 28 설치 시 제품이 정상 동작하지 않을 경우는 각 기업이 전략적으로 판단하여 install script를 29 OPEN SOURCE SW LICENCE GUIDE 3.0 <상담 사례> 리눅스 커널 모듈의 소스코드 제공여부 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 refers to (the Linux kernel) is copyrighted by me and others who actually O P E N SOURCE SW LICENCE GUIDE 3.0 제공하지 않을 수 있다) 그리고 소스를 컴파일하기 위한 tool chain은 사용자가 인터넷을 Linux Kernel 헤더 파일을 include하는 경우에는 이 User Space 프로그램을 Linux Kernel의 통해 쉽게 얻을 방법만 명시한다면 직접 제공하지 않아도 무방하지만, 그렇지 못할 경우는 파생저작물로 간주하지 않습니다.14) 제공해야 하는 것으로 해석할 수 있다. 하지만, GPL 2.0에서 언급하고 있는 “실행파일을 컴파일하고 설치하기 위한 scripts”가 정확히 어디까지인지는 여전히 불명확하다. 예를 들면, 소스를 컴파일해서 실행 파일을 만들기 위해서 tool chain도 제공해주어야 하는지, <상담 사례> 리눅스 커널 모듈을 BSD OS에 사용하는 경우 실행 파일을 하드웨어에 설치하기 위해 설치 방법까지 알려주어야 하는지 등은 여전히 Q: 제 연구실에서 리눅스 커널 모듈의 형태로 개발한 소프트웨어를 미국에 있는 협력 명확하지 않는 것으로 볼 수 있다. 이용자들이 자유롭게 수정하여 이용할 수 있도록 한다는 대학에서 BSD 라이선스의 OS에 활용하려고 합니다. 미국 대학에서 개발된 소프트웨어는 GPL의 취지를 고려한다면 모두 포함해야 한다는 것이 맞고, FSF도 대체로 그렇게 해석하고 현재 저희의 소프트웨어 없이도 동작 가능한 별도의 독립 소프트웨어 패키지인데, 저희의 있다. 하지만 GPL이 명확하게 규정하고 있지 않다는 점, 현실적으로 보안등 다양한 이유로 소프트웨어를 사용하여 성능 향상을 꾀하고 있습니다. 협력 대학에서 (저희 소프트웨어에는 기업들이 제공하기가 쉽지 않다는 점 등을 고려하면 다른 해석도 가능하다. 최종적으로는 수정을 가하지 않은) 통합된 소프트웨어 패키지를 BSD 라이선스로 배포하고자 합니다. 법원이 판단해야겠지만, 그 전까지는 각 기업이 전략적으로 판단할 수밖에 없다. 저희가 만든 리눅스 커널 모듈을 GPL이 아닌 BSD 라이선스로 배포될 때 GPL을 위반하는 A: 경우를 나누어 보겠습니다. 첫째, 연구실에서 해당 모듈 전체를 자체 개발한 경우에는, 리눅스 커널과 함께 배포하는 경우라면 리눅스 커널의 라이선스인 GPL의 영향을 받겠지만, Q: GPL로 공개된 오픈소스 패키지의 바이너리를 수정하지 않고 제품에 탑재하여 리눅스 커널을 배포하지 않고 모듈만을 배포하는 경우에는 리눅스 커널의 라이선스와 배포하였습니다. 이 경우에도 소스코드를 공개해야 하나요? 상관없이 커널 모듈을 별도의 라이선스로 배포하는 것이 가능합니다. A: FSF FAQ에 따르면 오픈소스를 바이너리 형태로 다운받아서 수정하지 않고 그대로 둘째, 연구실에서 개발한 커널 모듈이 기존의 커널 모듈을 수정하여 작성한 경우라면, 제품에 사용하여 배포하는 경우에도 GPL 요구사항에 따라 소스코드를 함께 배포해야 기존의 커널 모듈이 어떠한 라이선스에 의해 배포되었는지에 따라 다릅니다. 만약 GPL에 11) 의해 배포된 것이라면 수정된 커널 모듈도 GPL에 의해 배포해야 합니다. 합니다. 결론적으로, 커널 모듈 전체를 별도로 작성한 경우라면 미국 대학 측에 GPL이 아닌 BSD 또한 바이너리를 다운로드 받을 수 있는 website link만 제공하거나, standard version 대비 12) 라이선스로 허락해 줄 수 있습니다. 그런데, BSD로 허락해 줄 경우, 다른 사람들도 BSD로 수정한 부분의 소스코드만을 제공하는 것은 GPL 요구사항을 만족시킬 수 없습니다. 사용 가능하기 때문에, 차후 수익모델 등의 창출에 어려움이 있습니다. 이 경우, 커널 모듈을 GPL로 배포하되, BSD와 결합 가능하다는 예외조항을 설정하는 형태로 할 수 있습니다. <상담 사례> GPL 헤더파일 사용 시 의무사항 Q: GPL인 헤더파일을 include하여 자사 소프트웨어에 사용할 경우, 자사 소스코드도 공개해야 하나요? <참고> 소스코드를 제공해야 하는 대상 A: GPL 헤더파일 내 소스코드를 복사하여 가져오거나, include하여 사용하는 소프트웨어도 GPL 오픈소스를 사용하는 소프트웨어를 바이너리 형태로 배포할 경우 소스코드도 GPL의 파생저작물이 되어 소스 공개 등 GPL 의무사항 준수가 필요합니다. 그러나 FSF를 함께 제공해야 한다면, 과연 누구에게 소스코드를 제공해야 하는가를 분명하게 인지할 이끄는 리차드 스톨만은 리눅스 커널 메일링 리스트13)를 통해 GPL 헤더파일 부분이 단지 필요가 있다. 우선 SI 업체에서와 같이 해당 소프트웨어의 바이너리를 제공받는 측에 structure definitions, typedefs, enumeration constants, 단순 macros 등 이라면 이를 소스코드를 함께 제공한다면 그 순간 소스코드 제공에 대한 의무사항은 모두 만족하게 사용하는 소프트웨어를 GPL의 파생저작물로 보지 않아도 된다고 언급하였습니다. 된 것이며, 향후 제3자의 소스코드 제공 요청에 대해서 응답해주어야 하는 의무는 없다. 또한 참고로 Linux의 User Space 프로그램이 일반적인 시스템콜을 이용하기 위한 목적으로 그러나, 임베디드 시스템과 같이 불특정 다수에게 바이너리가 포함된 제품을 배포하는 11) http://www.gnu.org/licenses/gpl-faq.en.html#UnchangedJustBinary 12) https://www.gnu.org/licenses/gpl-faq.en.html#DistributingSourceIsInconvenient 13) http://lkml.iu.edu/hypermail/linux/kernel/0301.1/0362.html 30 14) http://elinux.org/Legal_Issues#Use_of_kernel_header_files_in_user-space 31 OPEN SOURCE SW LICENCE GUIDE 3.0 <상담 사례> GPL 바이너리를 수정하지 않고 재배포 시 의무사항 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 것은 아닌가요? O P E N SOURCE SW LICENCE GUIDE 3.0 상황에서 해당 제품의 저장 공간의 제약 등으로 소스코드를 함께 배포할 수 없는 모두 이용자들에게 추가적인 제한을 가하는 조항들로 해석된다. 반대로, GPL과 LGPL은 경우에는 소스코드를 제공하겠다는 약정서(Written Offer)를 제품과 함께 제공하는 방법을 코드 공개 범위는 다르지만, 다른 내용은 같기 때문에 라이선스를 변경하거나(예를 들어 채택할 수 있다. 다만, 이 경우에는 출시된 제품에 대해 최소 3년간 소스코드를 요청하는 LGPL을 GPL로 Relicensing) 라이선스를 변경하지 않더라도 공개범위가 더 큰 라이선스인 누구에게든지 완전한 소스코드를 제공해야 하는 의무가 있다. 그러므로 각 기업에서는 GPL로 배포한다면 양립 가능한 것으로 볼 수 있다. GPL을 포함하여 FSF가 만든 라이선스 소스코드를 제공하는 방법에 대해서도 신중한 선택을 해야 한다. 간의 양립성에 대해서는 GNU 사이트에서 확인할 수 있으며,16) 아울러 FSF는 GPL과 양립 가능한 오픈소스 라이선스의 목록도 제공하고 있다.17) [ GNU GPL 계열 라이선스 간 양립성 ] 배포하고 싶은 프로젝트 <참고> 오픈소스 라이선스의 양립성(Compatibility) GPLv2 only 가능 가능 불가 GPLv2 혹은 이후 버전 가능 가능 가능 GPLv3 불가 GPLv3로 변환할 경우 가능 가능 LGPLv2.1 only 보통 각 라이선스의 요구사항을 모두 충족시킬 수 없는 경우 이러한 문제가 발생하며, 라이선스의 요구사항을 충족시키지 못하는 경우는 라이선스 위반에 해당하기 때문에 둘 이상의 오픈소스를 결합할 때에는 각 라이선스가 서로 양립 가능한지 미리 조사해야 한다. 경우, MPL은 MPL로 배포된 오픈소스에 해당하는 소스코드로부터 파생된 부분을 동일한 MPL로 배포하기를 요구하고, GPL은 GPL로 배포된 오픈소스에 해당하는 소스코드로부터 파생된 부분뿐만 아니라, 그와 링크된 전체의 소스코드를 GPL로 배포하기를 요구하기 때문에 이 두 라이선스의 요구를 동시에 충족시키는 것은 불가능하다. GPLv2로 변환할 GPLv2로 변환할 경우 가능 경우 가능 GPL로 변환할 경우 가능 LGPLv3 혹은 이후 버전 불가 GPL로 변환할 GPLv3로 변환할 경우 가능 경우 가능 GPLv3로 변환할 GPLv3로 변환할 GPLv3로 변환할 경우 가능 경우 가능 경우 가능 가능 가능 GPLv3로 변환할 경우 가능 LGPLv2.1 혹은 GPLv2로 변환할 GPL로 변환할 GPLv3로 변환할 이후 버전 경우 가능 경우 가능 경우 가능 가능 가능 가능 GPLv3로 LGPLv3로 변환하거나 GPLv3로 변환할 GPLv3로 변환할 업그레이드할 업그레이드할 경우 가능 경우 가능 경우 가능 경우 가능 LGPLv3 불가 GPLv2 only 가능 가능 불가 GPLv2 혹은 이후 버전 가능 가능 가능 GPLv3 불가 GPLv3로 업그레이드할 경우 가능 가능 LGPLv2.1 only 가능 가능 가능 가능 가능 가능 LGPLv2.1 혹은 이후 버전 가능 가능 가능 가능 가능 가능 LGPLv3 불가 가능 가능 가능 가능 가능 예를 들면, 각각 GPL과 MPL로 배포되는 오픈소스의 소스코드를 함께 결합해 사용하는 Use a Library 형태로 사용 LGPLv2.1 혹은 이후 버전 GPLv2로 변환할 GPL로 변환할 GPLv3로 변환할 경우 가능 경우 가능 경우 가능 둘 이상의 오픈소스 소스코드를 사용하여 새로운 프로그램을 개발할 경우, 각 오픈소스의 라이선스 요구사항이 서로 상충하는가의 문제를 양립성(Compatibility) 문제라고 한다. LGPLv2.1 only GPLv2로 변환할 GPLv2로 변환할 경우 가능 경우 가능 GPL로 변환할 경우 가능 가능 불가 GPL로 변환할 GPLv3로 변환할 경우 가능 경우 가능 GPLv3로 변환할 GPLv3로 변환할 GPLv3로 변환할 경우 가능 경우 가능 경우 가능 특히 GPL과 관련하여 양립성 문제가 많이 발생하는 이유는, GPL은 사용자들에게 GPL에서 규정하고 있는 것 이외의 제한사항을 추가하지 못하도록 엄격하게 통제하고 하지만, 대부분의 라이선스는 다른 라이선스와의 양립성 정보를 일일이 제공하고 15) 32 있기 때문이다. 예를 들면, 많은 오픈소스 라이선스가 특허 관련 조항, 준거법(choice of 있지는 않기 때문에, 각 라이선스의 양립 여부를 판단하기 위해서는, 라이선스 law) 등과 관련하여 GPL과 다른 내용을 포함하고 있는데, GPL의 입장에서는 이런 내용이 FAQ를 참조하거나 라이선스 관계자나 권리자에게 연락을 취하여야 한다. 예를 들면, 15) GPL 2.0. "[any distributed work] that ... contains or is derived from the [GPL-licensed] Program ... be licensed as a whole ... under the terms of [the GPL].", and that the distributor not "impose any further restrictions in the recipients' exercise of the rights granted" 16) http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility 17) http://www.gnu.org/licenses/license-list.html 33 OPEN SOURCE SW LICENCE GUIDE 3.0 Copy Code 형태로 사용 GPLv3 혹은 이후 버전 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 GPLv2 only GPLv2 혹은 이후 버전 O P E N SOURCE SW LICENCE GUIDE 3.0 EPL의 경우에는 제3자의 소스코드와 결합하는 문제에 대해서, Eclipse 재단의 Legal - 충돌사유 •GPL은 licensee의 권리를 제한하는 것을 못하도록 하였으나, EPL은 2조 및 7조의 제한처럼 GPL에 없는 제한이 포함되어 있으므로 양립불가 •특정 프로그램(소프트웨어)이 GPL 2.0과 EPL 1.0으로 배포되는 경우, 본 프로그램을 활용하는 자가 특허권 보유시, GPL 2.0 특허권을 행사를 할 수 있으나, EPL 1.0으로는 행사가 불가함으로 여기에서 충돌이 발생 Advisor(license@eclipse.org)에게 연락을 취하도록 권장하고 있다. <참고> 라이선스 충돌 해결방안 라이선스 충돌 해결방안 한편, 양립성 문제는 각각의 라이선스에 대한 내용뿐만 아니라 소프트웨어의 결합방식에 - 파생저작물의 범위가 중복되지 않도록 분리설계 - 라이선스 충돌이 발생하지 않는 다른 라이선스 소프트웨어로의 대체 Proprietary 라이선스와 오픈소스 라이선스간의 충돌 오픈소스 라이선스간의 충돌 따라서도 다르게 발생합니다. 예를 들면, GPL의 경우에는 링크를 통해 결합한 코드도 (예: 오픈소스의 상용 버전 존재시 상용버전으로 대체) - 저작권을 가지고 있는 자사 Proprietary 소프트웨어의 라이선스 변경 (예: Proprietary 라이선스 → 오픈소스 라이선스) - 라이선스 충돌이 발생하지 않도록 오픈소스의 자체개발 파생저작물로 보고 모두 GPL 라이선스로 배포할 것을 요구하기 때문에 충돌문제가 발생하지만, EPL 등 약한 카피레프트(weak copyleft) 조항을 가진 라이선스들은 대부분 오브젝트 또는 실행 파일들을 commercial 라이선스를 포함한 다른 라이선스로 배포할 수 있도록 허용하고 있습니다. 소스코드만 EPL 등으로 배포하면 됩니다. - 파생저작물의 범위가 중복되지 않도록 분리설계 - 라이선스 충돌이 발생하지 않는 다른 라이선스 소프트웨어로의 대체 Q: LGPL, EPL, Apache, BSD로 배포되고 있는 오픈소스 library들을 수정하지 않는 Q: GPL과 EPL간에 라이선스 충돌 발생 이유는 코드공개 범위가 다르기 때문인지요? 조건에서 하나의 응용프로그램에서 링크시켜(import 시켜) 써도 라이선스 양립성 위반에 아니면, 동일한 코드에 대해 GPL은 GPL로 배포해야 하고, EPL은 EPL로 배포해야 해당하지 않습니까? 하므로 충돌이 발생하는 것인지요? 만약 후자의 경우라면 코드공개 의무가 있는 오픈소스 A: LGPL, EPL 등의 라이선스들은 카피레프트 조항을 가지고 있고 라이선스의 내용도 라이선스는 GPL 소프트웨어와 파생저작물이 겹칠 경우 모두 GPL과 충돌이 발생한다고 다르므로 각각의 라이선스로 배포되는 코드들을 결합하는 경우 양립성 문제가 발생할 봐도 될지요? 수도 있습니다. 그런데, GPL과는 달리 약한 카피레프트 조항을 가지고 있는 라이선스들은, A: 단순히 코드공개 범위가 다르다고 해서 충돌이 발생하는 것은 아닙니다. GPL과 LGPL은 링크를 통해 연결하는 별도의 코드(모듈)에 대해서는 영향을 미치지 않습니다. 따라서 코드 공개범위는 다르지만, 다른 내용은 같기 때문에 양립 가능한 것만 보아도 알 수 질문과 같이 각각의 라이선스로 배포되는 라이브러리들을 수정도 하지 않고 단순히 링크만 있지요. EPL은 특허 관련 조항, 준거법(choice of law) 등에 관해서도 규정하고 있는데, 시켜 사용하는 경우에는 양립성 문제가 없는 것으로 보입니다. 다만, 개별적인 라이선스 GPL의 입장에서는 이런 내용이 모두 라이선시들에게 추가적인 제한을 가하는 조항들로 준수 의무, 즉 라이선스 사용 여부 명시, 라이선스 사본 첨부 및 저작권 고지사항 포함, 해석될 수 있기 때문에 충돌하는 것입니다. 소스코드의 제공(LGPL, EPL의 경우) 등의 사항들은 지켜야 함은 물론입니다. GPL 2.0 EPL 1.0 licensor는 licensee의 권리 행사를 제한할 수 있는 어떠한 사항도 임의대로 추가할 수 없음(제6조). Licensor가 특허권 보유시 특허권 행사할 수 없음 을 묵시적으로 규정하고 있으나, Licensee가 특허 권 보유시 규정이 없음.(제7조) Licensor가 특허권 보유시, Royalty free로 특허권 을 행사할 수 없음(제2조). Licensee가 본 Program에 대한 특허권 보유시, 해당 특허권으로 특허권을 행사하면 행사한 날로 부터 License가 종료됨(제7조). EPL은 뉴욕주의 법률과 미국 지식재산권법의 적용 을 받음. <상담 사례> GPL인 OOO 오픈소스 패키지 내 GPL과 양립할 수 없는 License의 파일이 존재 Q: GPL 2.0인 OOO 오픈소스 패키지 내에 APSL 1.2의 소스코드가 포함된 것을 확인하였습니다. APSL 1.2는 GPL 2.0과 양립할 수 없는 것으로 아는데, 이 오픈소스 패키지를 사용해도 되는지 궁금합니다. A: GPL과 양립할 수 없는 라이선스의 소프트웨어를 GPL 프로그램에 포함해서 배포하는 것은 두 라이선스의 의무사항을 동시에 충족할 수 없는 문제를 유발합니다. 먼저, APSL 1.2의 소스코드가 GPL인 OOO 오픈소스와는 별도로 테스트 등을 위해 추가된 파일은 34 35 OPEN SOURCE SW LICENCE GUIDE 3.0 <상담 사례> GPL과 EPL의 양립성 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 <상담 사례> 약한 카피레프트(week copyleft) 라이선스간의 양립성 O P E N SOURCE SW LICENCE GUIDE 3.0 아닌지 확인하시기 바랍니다. 이 경우에는 GPL 프로그램을 배포할 때 테스트용 파일은 불구하고 Tivo는 이를 막고 있다는 것이다. 스톨만은 이와 같은 GPL의 남용행위를 제외할 수 있으므로 라이선스 양립성 문제를 회피할 수 있습니다. 하지만, 실제로 OOO Tivoization이라고 이름 짓고, 이를 방지하기 위해 GPL 3.0에 다음과 같은 규정을 오픈소스의 소스코드를 컴파일하여 프로그램을 생성할 때, APSL 1.2의 소스코드도 마련하였다. 포함되는 구조라면, OOO 오픈소스의 저작권자에게 연락하여 라이선스 양립성 문제를 제기하고, APSL 1.2의 소스코드를 GPL과 호환될 수 있는 라이선스로의 변경을 요청하여 GPL 코드를 특정한 사용자 제품(User Product)에 포함하거나 혹은 그와 함께 배포하는 양립성 문제를 해결하는 것이 OOO 오픈소스를 라이선스 문제없이 사용할 수 있는 방법일 경우에는 해당 소스에 설치 정보(Installation Information)를 함께 제공해야 한다. 것입니다. 이때 ‘사용자 제품(User Product)’이란 통상적인 소비자 제품이나 집안에서 쓰일 목적으로 설계되었거나 판매되는 제품을 말하며, ‘설치 정보(Installation Information)’란 소프트웨어를 수정하여 해당 제품에 설치하고 실행하는 데 필요한 방법(methods), 2.2.2. GPL 3.0은 GPL 2.0이 배포되고 난 이후 오픈소스 환경을 둘러싼 다양한 변화들을 소프트웨어가 ROM에 설치된 경우처럼, 해당 제품의 제조업체나 여타 제3자도 수정된 수용하여 만든 라이선스이다. GPL 3.0의 의무사항으로는 i) 각 복제본에 저작권 고지와 코드를 제품에 설치할 수 없는 경우에는 설치정보를 제공하지 않아도 된다. 또한, 보증책임이 없음을 명시할 것, ii) GPL 3.0의 조건 및 제7조의 조건에 관한 내용을 있는 사용자가 설치하거나 수정한 저작물 및 해당 제품에 대한 지원서비스나 보증, 업데이트를 그대로 유지할 것, iii) 소프트웨어를 양도받는 모든 이들에게 소프트웨어와 함께 GPL 계속해서 제공할 필요는 없다. 그리고 사용자의 수정으로 인해 네트워크의 작동에 라이선스 사본을 제공할 것, iv) 소프트웨어를 수정했을 경우 수정사실 및 일시를 명시할 실질적이고 부정적인 영향을 끼치거나, 네트워크를 통한 통신 규칙 및 프로토콜을 것, v) 원본저작물과 그에 기반한 저작물(Work based on the program)을 GPL 3.0에 의해 위반하는 경우에는 네트워크에 대한 접속을 거부할 수 있다. 배포할 것, vi) 원본저작물 및 그에 기반한 저작물(Work based on the program)에 대한 소스코드를 제공하거나, 요청 시 제공하겠다는 약정서를 제공할 것, vii) 사용자 제품(user product)에 대한 인증키 등 설치정보(installation information)를 제공할 것, viii) 차별적인 <상담 사례> Secure Boot가 적용된 제품의 설치 정보 특허라이선스 계약을 체결하지 말 것 등의 내용이 포함되어 있다. Q: Secure Boot 기능 적용제품의 GPL 의무사항 준수 방법에 대해 문의합니다. GPL의 의무사항을 준수하려면 Secure Boot 기능이 적용된 Embedded Linux 탑재제품의 경우 i) ~ vi) 의 내용은 GPL 2.0의 내용과 같거나 내용을 더욱 명확히 하는 것이었지만, vii) 및 Linux에 대한 소스코드 이외 Build Script와 Install Script까지 제공해야 할까요? 실제 제공을 viii)의 내용은 GPL 3.0에 처음으로 포함된 내용으로 많은 논란을 불러일으켰다. 하더라도 Install script로는 install이 되지 않는데도 말입니다. 아니면 소스코드와 Build Script까지만 제공하면 되는 것일까요? 36 <참고> Tivoization과 설치정보의 제공 A: Secure Boot는 Intel社에서 개발한 특허 기술로, 보안이나 안정성을 위해 특정 제품의 미국의 TiVo 라는 회사는 케이블방송 또는 위성방송 등의 방송프로그램을 하드디스크에 플래시 메모리에 포함된 펌웨어를 인가되지 않은 것으로 변경하는 것을 방지하는 녹화하거나, 경우에 따라서는 개인 PC나 DVD 등에 저장할 수 있도록 하는 DVR(digital 기술입니다. Secure Boot 장치는 ‘저장장치’ 및 ‘비밀키로 암호화된 실행코드’와 결합되어 video recorder)제품을 시장에 출시하여 성공하였다. 한편 해당 제품에는 리눅스 커널 있고, 호스트 프로세서는 Secure Boot에 포함된 것과 동일한 비밀키로 실행코드를 등 GPL 소프트웨어가 포함되어 있었기 때문에 TiVo는 GPL 2.0의 규정에 따라 관련 생성하여, Secure Boot 장치 내의 실행코드와 대응될 경우에만 이를 실행하는 방식으로 소스코드를 이용자들에게 제공하였다. 그런데 이용자들이 해당 소스코드를 수정하여 다시 펌웨어의 변경을 제한합니다. TiVo의 제품에 포팅하였으나 정상적으로 작동하지 않았다. 이는 TiVo사가 이용자들이 TiVo社 또한 Secure Boot와 동일한 목적으로 펌웨어의 변경을 제한하였던 사례 중 하나로 해당 제품을 수정하여 사용하는 것을 허용하지 않았기 때문이다. 이와 같은 TiVo의 알려져 있는데, TiVo社는 자사에서 판매하는 DVR(Digital Video Recorder) 장치가 동작하기 정책에 대해 스톨만은 TiVo가 GPL을 악용하고 있다고 주장하였다. GPL의 근본 목적은 위한 펌웨어를 리눅스 커널에 기반을 두어 개발하였고, 리눅스 커널이 GPL 2.0을 따르는 이용자들이 해당 소프트웨어를 자유롭게 수정하여 사용할 수 있도록 하는 것임에도 오픈소스이기 때문에, TiVo社는 GPL 2.0의 요구사항에 따라 제품 판매 시 소스코드를 37 OPEN SOURCE SW LICENCE GUIDE 3.0 절차(procedures), 인증키(authorization keys) 혹은 여타 정보 모두를 의미한다. 다만 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 GPL 3.0 O P E N SOURCE SW LICENCE GUIDE 3.0 제공하였지만, TiVo社의 DVR 장치는 전자서명 기술을 통해 사용자가 수정한 펌웨어를 대해서는 별도의 라이선스 적용이 가능하다는 예외를 설정할 수 있습니다. 그누보드18)의 동작시킬 수 없게 제한해 두었기에 사용자들은 제공받은 소스코드를 수정하여 제작한 core는 GPL 2.0으로 배포하고 스킨이나 플러그인은 저작자마다 개별적인 라이선스를 펌웨어를 동일한 DVR 장치에 사용할 수 없었습니다. 적용할 수 있도록 한 것과 비슷합니다. 또는 처음부터 ABC 패키지를 LGPL로 배포하여 GNU 프로젝트를 지원하는 FSF 측에서는 TiVo社가 비록 GPL 2.0의 요구사항은 모두 ABC 자체를 수정한 것은 소스코드를 공개하도록 하고, 별도의 라이브러리 형태로 추가된 준수하고 있지만, Free Software Definition에서 소개하고 있는 자유 중 하나인, “원 버전을 모듈에 대해서는 개별적인 라이선스 적용이 가능하도록 할 수 있습니다. 제로보드19) core의 대신하여 수정된 버전을 사용할 수 있는 자유”를 제대로 보장하고 있지 못하고 있음을 소스코드가 LGPL v2로 배포되고 있는 것과 비슷합니다. 지적하였습니다. 아울러 GPL 3.0에서는 “Tivoization”이나 “Secure Boot”에 대항하여 수정된 펌웨어를 사용할 수 있는 자유를 보장하기 위한 조항을 새로이 추가하였습니다. 반면에, Linux Kernel의 주 개발자인 Linus Torvalds는 전자서명 기술을 이용한 TiVo社의 2.2.3. LGPL 라이브러리에 GPL 라이선스를 적용하게 되면 응용프로그램까지 GPL로 배포해야 하므로 계속해서 GPL 2.0을 유지하고 있습니다. 사용자는 해당 라이브러리의 사용을 꺼리게 된다. FSF는 GPL의 내용을 약간 수정하여 위와 같은 내용을 종합해 볼 때, GPL 3.0으로 배포된 오픈소스를 사용하는 경우에는, 라이브러리 자체를 수정한 경우에는 카피레프트 조항을 적용하지만, 해당 라이브러리를 Secure Boot가 적용되어 있더라도, GPL 3.0의 Tivoization 관련 요구사항을 만족하기 이용한 응용프로그램은 카피레프트 조항을 적용하지 않고 소스코드 제공 의무도 없는 위해서는 소스코드와 설치정보(Installation Information) 까지 함께 제공하여, 수정된 형태로 LGPL 라이선스를 만들었다. 펌웨어를 사용할 수 있는 자유를 가능한 보장해야 하는 것으로 판단됩니다. 한편, GPL 2.0에도 “compilation과 installation을 위한 script”가 분명히 언급이 되어 있기 LGPL의 의무사항은 i) 각 복제본에 적절한 저작권 안내와 보증책임이 없음을 명시할 것, 때문에 install 정보 미제공에 대해서는 문제가 될 수 있다고 판단됩니다. TiVo의 사례를 ii) LGPL 라이선스를 언급하는 안내 사항과 보증책임 관련 고지사항을 원본 그대로 유지할 보고 GPL 3.0이 나온 건 알고 있었지만, 그렇다고 GPL 2.0에서는 install 정보제공 의무가 것, iii) 소프트웨어를 양도받는 모든 이들에게 소프트웨어와 함께 LGPL 라이선스 사본을 없다고 단정하기는 어렵습니다. TiVo의 이슈가 이후 더 이상 진행되지 않은 것뿐이지 제공할 것, iv) 라이브러리 형태로의 수정을 허용하며, 만약 수정한 경우 수정사실과 이슈가 여전히 잠재되어 있다고 봅니다. 날짜를 파일에 명기할 것, iv) 원본저작물과 파생저작물을 LGPL 또는 GPL에 의해 배포할 것, v) 원본저작물 및 파생저작물에 대한 소스코드를 제공하거나, 요청 시 제공하겠다는 약정서를 제공할 것, vi) 응용프로그램을 배포할 경우, LGPL 라이브러리를 사용하고 <상담 사례> 오픈소스로 배포하는 LMS의 라이선스 선택 있다는 사실을 명시할 것, vii) 사용자가 라이브러리를 수정해도 응용프로그램을 사용할 Q: 회사에서 LMS(학습관리시스템) 오픈소스 패키지 ABC를 개발하였고, 최근 커뮤니티를 수 있도록 (예를 들어 응용프로그램의 오브젝트 코드를 제공하거나, 해당 라이브러리의 통해 소스를 공개했습니다. ABC 패키지는 GPL 3.0 라이선스로 배포합니다. ABC는 형태를 공유 라이브러리 방식 등을 이용하여) 허용할 것 등이다. i) ~ v)의 내용은 GPL 제로보드 같은 모듈형 시스템이기 때문에 모듈 추가가 자유롭습니다. (단, 모듈은 core 2.0과 동일하거나 유사하지만, vi) ~ vii)은 LGPL에 특유한 내용이다. 와 메모리를 공유함, 예를 들면 토론을 위한 모듈을 추가할 수 있음) ABC 패키지는 GPL 3.0 라이선스를 적용하고, 외부 개발자들이 추가로 개발하는 모듈은 저작자가 개별적으로 <프로젝트 사례> GNU C Library 라이선스를 지정하여 상업용으로 판매하도록 하는 것이 가능한가요? 그리고, ABC LGPL로 배포되는 대표적인 프로젝트는 GNU C Library 또는 glibc이다. glibc는 GNU 패키지를 이용해 커스터마이징 사업을 하는 업체에서 모듈을 추가로 개발하고 고객사에 프로젝트에서 배포되는 C 표준 라이브러리이다. 1980년대부터 FSF에서 만들어 배포하기 비용을 받으면서도 추가한 모듈에 대한 소스코드를 공개하지 않을 수 있나요? 시작했는데, 1990년대 초반 리눅스 커널 개발자들이 glibc에서 분기(fork)된 별도의 Linux A: 개발회사가 ABC 패키지에 대한 모든 권리를 가지고 있다면 어떠한 형태로의 라이선스 적용이 가능합니다. 따라서, ABC를 GPL 3.0에 의해서 배포하면서 추가 개발한 모듈에 38 18) http://www.sir.co.kr/main/gnuboard4/license.php 19) http://xe.xpressengine.net 39 OPEN SOURCE SW LICENCE GUIDE 3.0 LGPL은 주로 라이브러리에 사용하기 위해 FSF가 GPL과는 별도로 만든 라이선스이다. 구동시킬 수 있으므로 큰 문제가 되지 않는다고 주장하였습니다. Linux Kernel 또한 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 펌웨어 제한에 대해 보안 측면에서 유익하며, 수정한 펌웨어는 다른 하드웨어를 통해 O P E N SOURCE SW LICENCE GUIDE 3.0 libc 프로젝트를 진행하였다. 그런데, FSF에서 1997년 POSIX 표준에 가깝고 다양한 기능을 2. LGPL 라이브러리를 동적 링크 시 요구사항 추가한 glibc 2.0을 배포하자 리눅스 커널 개발자들은 별도의 프로젝트를 포기하고 FSF의 LGPL 라이브러리를 동적 링크하는 애플리케이션을 배포하는 경우에는 (즉, LGPL glibc에 합류하였다. 다만, glibc의 크기, 속도 등에 만족하지 못하는 오픈소스 개발자들을 라이브러리가 동적 라이브러리 (예: *.so 파일)) LGPL 라이브러리의 소스코드를 공개해야 중심으로 지금도 별도의 프로젝트들이 진행되고 있다. 예를 들면, 안드로이드 플랫폼에서 합니다. 이외, 애플리케이션의 소스코드나 오브젝트 코드는 공개할 필요 없습니다. 이는 사용되는 Bionic(BSD)이 대표적이며, 이밖에 dietlibc(GPL), eglibc(LGPL), uClibc(LGPL), 사용자가 수정한 LGPL 라이브러리는 애플리케이션과 Relink 하지 않고도 애플리케이션 20) Newlib , Klibc(GPL) 등이 있다. 동작 시 반영되기 때문입니다. <상담 사례> LGPL Library를 링크하여 사용 시 소소 코드 공개 의무사항 Q: 프로그램을 개발하면서 LGPL 라이브러리를 링크하여 사용할 때 소스코드 공개에 대한 의무사항이 궁금합니다. 요구합니다.21) LGPL 라이브러리를 정적 링크하는 애플리케이션을 배포하는 경우에는 (즉, LGPL 라이브러리가 정적 라이브러리 (예: *.a 파일)) LGPL 라이브러리의 소스코드를 공개해야 할 단, LGPL 라이브러리가 애플리케이션에 포함되어 함께 배포되는 것이 아니라, 사용자의 뿐만 아니라, 애플리케이션의 오브젝트 코드도 공개해야 합니다. 이는 사용자에게 LGPL 컴퓨터에 이미 존재하고 있는 LGPL 라이브러리를 배포한 애플리케이션이 동적 링크하여 라이브러리를 수정하고, 수정된 라이브러리를 포함한 애플리케이션을 생성하기 위해 Relink 사용하는 구조라면, LGPL 라이브러리의 소스코드조차도 공개할 필요 없습니다. 할 수 있는 방법을 제공하기 위한 LGPL의 요구사항을 충족시키기 위해서입니다. <상담 사례> 자체개발한 라이브러리의 라이선스 선택 Q: 제가 만든 라이브러리를 사용할 경우, 제 라이브러리를 사용했다는 것을 알리고 싶고, 일반적으로 소스 공개의 의무는 없지만, 만약 저의 소스를 고칠 경우 제 소스의 경우에만 변경사항을 공개하길 원합니다. GPL처럼 전체 소스의 공개를 원하지 않습니다. 상업용 프로그램 개발에도 이용되는 방향도 권장하는 바입니다. 또한, 가급적 다른 라이선스들과도 양립 가능하기를 원합니다. 그래서 관심 있게 보고 있는 것이라면 LGPL과 MPL 이긴 한데요. LGPL, MPL 등 여러 라이선스로 허락해서 사용자들이 원하는 라이선스를 선택해서 사용할 수 있도록 하는 것이 가능한가요? 그리고, 동적 링크는 소스공개 의무가 없는 것으로 알고 있는데, LGPL 라이브러리를 정적링크를 이용하여 사용할 때에는 링크된 응용프로그램의 소스코드까지 같이 제공해야 하나요? A: 프로그램의 권리자는 자신의 프로그램을 어떠한 라이선스를 통해서도 배포할 수 있습니다. 또한, 복수의 라이선스를 선택하여 배포할 수도 있습니다. 모질라 프로젝트의 20) Newlib은 여러 가지 오픈소스 라이브러리로부터 가져왔기 때문에 라이선스도 각각의 라이브러리에 따른다. http://www.sourceware.org/newlib/. 21) https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic 40 경우 MPL, GPL, LGPL의 세 가지 라이선스로 배포되고 있습니다. 41 OPEN SOURCE SW LICENCE GUIDE 3.0 1. LGPL 라이브러리를 정적 링크 시 요구사항 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 A: LGPL은 라이브러리를 정적 링크할 때와 동적 링크할 때 다소 다른 의무사항을 O P E N SOURCE SW LICENCE GUIDE 3.0 LGPL 라이브러리를 정적으로 이용하는 경우에도 응용프로그램의 소스코드 제공 의무는 <상담 사례> GPL과 LGPL의 양립성 없습니다. 다만, 이용자들이 라이브러리를 수정하여 다시 응용프로그램을 이용할 수 있도록 Q: GPL과 LGPL이 양립 가능한(compatible) 이유가 LGPL은 GPL로 재라이선스(re-license) 애플리케이션의 오브젝트 코드를 제공할 의무가 있습니다. 가능하기 때문에(LGPL 3조) 양립 가능한 것인지요? 아니면, GPL로 재라이선스하지 않더라도 양립할 수 있는 것인지요? 아울러 GPL 적용시 기존 LGPL 표시를 GPL로 변경하여야 한다고 되어 있는데요, LGPL을 GPL로 재라이선스할 시 LGPL 소프트웨어의 <상담 사례> LGPL인 Java 라이브러리(Jar) 사용 수백~수천 개의 코드 파일 상단에 LGPL 표시를 GPL로 바꾸는 작업을 해야 하는지요? Q: LGPL인 Jar 파일을 import하여 사용하려고 합니다. 이때 소스 공개 의무사항이 어떻게 아니면 꼭 그렇게 하지 않더라도 다른 방식으로 표기가 가능한 것인지요? 되는지 궁금합니다. A: LGPL도 GPL처럼 “추가적인 제한(further restriction)"을 금지하는 규정을 가지고 A: LGPL은 GPL과는 달리, 라이브러리를 링크하여 사용하는 애플리케이션에 대해서는 있습니다. LGPL의 입장에서 보면 GPL의 카피레프트조항이 추가적인 제한에 해당하기 소스코드 공개를 요구하지 않습니다. Java의 JAR 파일을 import 하는 것은 동적 링크를 때문에 양립하지 않을 수 있습니다. 하지만 LGPL은 제3조를 통해 GPL로 배포할 수 생성하는 것과 유사하게 동작한다고 볼 수 있으므로 LGPL인 JAR 파일을 import 하여 있도록 허용함으로써 GPL과의 양립성을 갖게 됩니다. LGPL 3조는 사용자가 LGPL 코드를 수정하여 재배포할 때 LGPL이 아니라 GPL로 배포할 수 있으며, 만약 GPL로 배포할 거라면 자체에 대한 소스코드는 공개해야 합니다.22) 경우에는, GPL의 해석상 LGPL 코드도 GPL로 배포해야 하므로 GPL로 재라이선스해야 하는 것으로 해석됩니다. 하지만, LGPL 코드를 전혀 수정하지 않았거나, 약간 수정했더라도 <상담 사례> 오픈소스를 이용한 웹서비스 수정한 사람이 굳이 GPL로 배포할 것을 원하는 것이 아니라면, 굳이 GPL로 재라이선스할 Q: 홈페이지를 만들어 웹서비스를 제공하려 하고 있습니다. 1차적으로 LGPL이 걸린 필요는 없을 것 같습니다. GPL의 해석에는 맞지 않지만, 현실적으로 여기에 이의를 오픈소스를 이용하여 결과를 얻어내고, 이 결과를 이용, 분석하여 2차적인 결과를 만들어 제기하거나 비난할 사람은 없어 보입니다. 그렇다면 굳이 번거롭게 표시를 모두 바꿀 내게 됩니다. 이 2차적인 결과를 상업적인 용도로 사용하려 합니다. 이렇게 사용하는 것이 필요는 없을 것 같습니다. 문제가 없나요? 더불어, LGPL이나 GPL일 경우에도 같이 설명해 주셨으면 좋겠습니다. A: 오픈소스 라이선스는, 오픈소스를 이용해 상업적인 이득을 취하는 것을 막지 않으며, 별도로 명시하는 경우를 제외하고는, 일반적으로 오픈소스를 이용하여 산출된 결과물에 2.2.4. Affero GPL 대해서도 제약을 가하지 않습니다. LGPL로 배포된 오픈소스 또한, 상업적인 이용에 제한을 BSD, Apache, GPL, LGPL, MPL, EPL 등 대다수의 오픈소스 라이선스들은 해당 두고 있지 않으며, 산출된 결과물이 라이선스의 영향을 받지는 않습니다. GPL 또한, 상업적 소프트웨어를 복제하여 ‘배포(distribute)’할 때 지켜야 하는 다양한 요구사항들을 규정하고 이용에 제한을 두지 않고 있으며, 그 결과물에 대한 정책도 동일합니다. GPL FAQ에서는 있다. 이를 반대로 해석하면 해당 소프트웨어를 배포하지 않고 기업이 해당 오픈소스를 오픈소스의 단순이용 결과물에 대해서는 소프트웨어의 이용자에게 저작권이 발생하게 내부적으로만 사용하거나 네트워크 서버 형태로 이용하고 있는 경우에는 라이선스에 따른 되며, 다만, 오픈소스 일부가 결과물에 포함되는 경우에만 라이선스의 영향을 받게 된다고 의무사항들이 거의 없다는 점이다. 명시하고 있습니다.23) 오픈소스 라이선스의 이러한 한계에 대해 비판적인 견해를 가지고 있던 Affero 프로젝트24)는 기존의 GPL 라이선스를 변경하여 네트워크 서버에 의해 서비스를 제공하는 경우에도 카피레프트 조항과 소스코드 제공 의무가 적용되도록 하였다. Affero GPL의 의무사항은 GPL과 기본적으로 동일하다. 다만, 그 적용의 범위가 단순한 ‘배포’를 넘어서 22) http://www.gnu.org/licenses/lgpl-java.html 23) http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF 참조 42 24) http://www.affero.org/ 43 OPEN SOURCE SW LICENCE GUIDE 3.0 모든 표시를 GPL로 바꾸라는 의미입니다. LGPL 코드를 GPL 코드와 결합하여 배포하는 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 사용하는 애플리케이션의 소스코드는 공개할 필요가 없습니다. 단, LGPL인 JAR 파일 O P E N SOURCE SW LICENCE GUIDE 3.0 네트워크 서버 형태로 소프트웨어를 이용하는 경우에도 적용된다는 점에 차이가 있다. <참고> GPL 3.0과 AGPL GPL의 개정 과정에서도 네트워크 서비스의 경우에도 GPL을 적용할 것인가에 관한 논의가 있었지만, 최종적으로 GPL 2.0과 마찬가지로 GPL 3.0도 배포(Convey)의 경우에만 Affero GPL 1.0 적용하기로 했다. 다만 Affero GPL의 취지를 존중하여, 특별한 조항을 두게 되었다. 2.d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any GPL은 원칙적으로 이용자들에게 GPL이 규정하고 있는 내용 이외에 다른 추가적인 user interacting with the Program was given the opportunity to request 제한(further restriction)을 부가하지 못하도록 하고 있으며, 그 결과 이와 같은 제한을 transmission to that user of the Program's complete source code, you must 가진 다른 오픈소스 라이선스들과는 양립 불가능(incompatible)하다. Affero GPL 또한 not remove that facility from your modified version of the Program or work GPL보다 엄격한 제한을 하고 있으므로 원칙적으로 GPL과 양립 불가능하다. 그러나 based on the Program, and must offer an equivalent opportunity for all GPL 3.0 제13조에서는 이와 같은 제한사항에도 불구하고 GPL 3.0과 Affero GPL 3.0은 users interacting with your Program through a computer network to request 양립 가능하다고 규정하였으며, Affero GPL도 3.0 버전을 배포하면서 비슷한 조항을 immediate transmission by HTTP of the complete source code of your 삽입하였다. modified version or other derivative work. Notwithstanding any other provision of this License, you have permission to 대표적인 오픈소스 라이선스는 CPAL과 APSL이다. link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to Common Public Attribution License Version 1.0 the part which is the covered work, but the special requirements of the GNU 15. ADDITIONAL TERM: NETWORK USE. Affero General Public License, section 13, concerning interaction through a The term “External Deployment” means the use, distribution, or communication network will apply to the combination as such. of the Original Code or Modifications in any way such that the Original Code or Modifications may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the <상담 사례> SaaS 형태로 오픈소스를 이용하는 경우 grants of license hereunder, You must treat any External Deployment by You of the Original Code or Modifications as a distribution under section 3.1 and make Q: 우리 회사에서 IT 자원은 회사의 IDC에 설치하고, 고객에게는 네트워크를 통해 서비스를 Source Code available under Section 3.2. 제공하는 형태인 IaaS(Infrastructure as a Service), PaaS(Platform aaS), SaaS(Service aaS)를 기획하고 있습니다. 만약 이러한 서비스를 제공하면서 소프트웨어를 도입, 수정해서 적용하는 경우 소스코드 공개의 의무가 발생하는 건가요? Apple Public Software License A: GPL을 비롯한 대부분의 오픈소스 라이선스의 의무사항은 소프트웨어를 배포할 때 1.4 "Externally Deploy" means: (a) to sublicense, distribute or otherwise make 발생합니다. 따라서 네트워크 서비스를 통해 오픈소스를 이용하는 경우에는 소스코드 제공 Covered Code available, directly or indirectly, to anyone other than You; and/ 등의 의무가 발생하지 않습니다. 그런데 일부 오픈소스 라이선스는 네트워크 서비스 형태로 or (b) to use Covered Code, alone or as part of a Larger Work, in any way to 오픈소스를 이용하는 경우에도 소스코드 제공 등의 의무가 있다고 규정하고 있습니다. provide a service, including but not limited to delivery of content, through Affero GPL, Common Public Attribution License 등이 대표적입니다. 따라서 이용하고자 electronic communication with a client other than You. 44 하는 오픈소스의 라이선스를 구체적으로 확인할 필요가 있습니다. 45 OPEN SOURCE SW LICENCE GUIDE 3.0 13. Use with the GNU Affero General Public License. Affero GPL과 같이 네트워크 서버에도 라이선스 의무사항을 준수할 것을 요구하는 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 GPL 3.0 <사례> CPAL, APSL O P E N SOURCE SW LICENCE GUIDE 3.0 <상담 사례> AGPL 라이브러리를 이용한 소프트웨어 As a special exception, you may create a larger work that contains part or Q: Linux에서 파일을 처리하는 AGPL 라이브러리를 가져다 수정하여 다른 OS에 포팅한 all of the Bison parser skeleton and distribute that work under terms of your 후, 수정된 라이브러리를 사용하여 네트워크상으로 서비스를 제공하는 소프트웨어를 choice, so long as that work isn't itself a parser generator using the skeleton or a modified version thereof as a parser skeleton. Alternatively, if you modify 개발하였습니다. 저희가 수정한 AGPL 라이브러리의 소스코드는 공개할 수 있습니다. or redistribute the parser skeleton itself, you may (at your option) remove 그런데, Network로 서비스하는 소프트웨어는 보안 등 여러 가지 문제로 인해 공개하기가 this special exception, which will cause the skeleton and the resulting Bison 어렵습니다. 라이브러리를 사용하여 네트워크상으로 서비스를 제공하는 소프트웨어의 output files to be licensed under the GNU General Public License without this 소스를 공개해야 하나요? special exception. This special exception was added by the Free Software A: 원칙적으로 AGPL 프로그램을 수정하거나 파생저작물을 만들어 이용하는 경우, 수정 Foundation in version 2.2 of Bison. 버전 및 파생저작물에 대한 소스코드를 컴퓨터 네트워크를 통해 원격으로 대화하는 모든 프로그램 사용자들에게 제공해야 합니다. 따라서, AGPL 라이브러리를 수정하여 Classpath exception 프로그램의 소스코드를 제공해야 할 것으로 보입니다. GNU Classpath25) 프로젝트는 자바 언어의 가상머신 및 컴파일러에서 사용되는 핵심 수 있도록, GNU Classpath 등 Classpath exception이 적용된 수정하지 않은 core class 2.2.5. library를 link하여 생성한 program은 GPL의 영향을 받지 않는다. 예를 들면, OpenJDK GPL Exceptions 프로젝트에서 가상머신 자체는 GPL 2.0으로 배포하고, Class library와 가상머신 내의 여러 오픈소스 프로젝트들은 해당 프로젝트는 GPL로 배포되길 바라면서 이를 활용하여 Public API로 노출되는 부분은 Classpath exception으로 배포하고 있다. 동작하는 프로그램들은 GPL의 copyleft 조항에서 자유로울 수 있도록, GPL 2.0의 2조를 다소 완화한 조건으로 배포할 수 있도록 허락해주는 exception을 추가하기도 한다. 이는 Autoconf exception 추가적인 제한 사항을 주는 것이 아니므로 GPL과도 호환된다. GNU Autoconf26)는 M4 매크로의 확장 패키지로, 소스코드 패키지들의 환경을 설정하는 쉘 스크립트를 자동으로 생성한다. Autoconf는 GPL로 배포되며, configure.ac의 시스템 Bison Exception 정보를 입력받아, Autoconf의 일부분과 결합, configure 스크립트를 생성한다. Bison은 GNU 파서 생성기로, 정의된 문법을 처리하고 해석하여 C 코드로 만들어주는 도구다. Bison의 주요 결과물(Bison parser implementation file)은 상당 부분 Bison의 이에 해당 configure 내에 autoconf의 일부가 포함될 수밖에 없음에도 해당 configure는 소스코드를 그대로 복사하여 skeleton 코드를 포함하게 된다. 일반적인 GPL이라면 이 GPL의 파생저작물이 되지 않도록 예외를 적용해주는 것이 autoconf exception이다. skeleton 코드에도 GPL이 적용되어야 하고, 이에 따라 bison 결과물인 C 파일과 이를 사용하는 프로그램 모두 GPL이 적용되어, 사용자들이 bison 사용을 부담스러워할 수 GCC Runtime Library Exception (GCC RLE) 있다. GCC27)는 GNU 대표적인 컴파일러로, 이 Exception의 목적은 non-GPL 소스코드를 이에 Bison에 예외 조항을 추가하여 Bison이 생성하는 소스코드에 대해서는 GPL 적용이 GCC로 컴파일할 때, GCC Runtime Library (header file 포함)가 Program에 포함되는 되지 않도록 예외를 추가하였다. 것을 허용하기 위한 것이다. 이 Exception에 의하면, "정당한 Compile 과정 (Eligible Compilation Process)" 중 Independent Module과 GCC Runtime Library가 결합하여 소스코드 내 GPL 라이선스 설명 아래 다음과 같은 문구가 있으면 Bison exception이 적용되는 파일로 볼 수 있다. 46 25) https://www.gnu.org/software/classpath/ 26) https://www.gnu.org/software/autoconf/autoconf.html 27) https://gcc.gnu.org/ 47 OPEN SOURCE SW LICENCE GUIDE 3.0 클래스 라이브러리를 자유 소프트웨어로 대체하기 위한 프로젝트이다. 이를 널리 사용할 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 소프트웨어개발에 사용하셨다면 수정된 라이브러리 및 해당 라이브러리를 이용하는 서비스 O P E N SOURCE SW LICENCE GUIDE 3.0 형성된 Target Code라면, 이는 GPL에 상관없이 다른 라이선스로 배포될 수 있다. 표시, 개발자 및 권리자에 관한 사항들을 그대로 표시할 것과, ii) 배포 시 MPL 라이선스 사본을 첨부할 것, iii) 수정했을 경우에는 최초개발자의 코드로부터 파생되었다는 사실, GCC Runtime Library는 libgcc, libstdc++, libfortran, libgomp, libdecnumber 등이 수정사항 및 날짜 등을 포함한 파일(Exhibit A)을 소스코드의 각 파일에 포함할 것, iv) 원본 있다. 만약 GCC Runtime Library가 정당한 컴파일 과정에 의해서가 아닌, 다른 방법으로 및 수정코드를 MPL에 의해 배포할 것과, v) 수정코드에 대한 소스코드를 전자배포방식 Program에 포함된 경우에는 GPL 의무사항을 모두 준수해야 한다. 등을 통해 제공할 것, vi) MPL 코드를 사용할 때 제3자의 지식재산권에 의한 라이선스가 필요하다는 사실을 알고 있는 경우 “LEGAL” 파일에 관련 내용을 포함할 것 등이다. GPL형 라이선스 요약 MPL 2.0은 MPL 1.1에 비해 더욱 짧고 이해하기 쉽게 만든 라이선스이다. 특히 Apache [ GPL형 라이선스의 주요 내용과 특징 비교 ] 라이선스의 특징 및 의무사항 GPL 2.0 GPL 3.0 LGPL AGPL 3.0 복제·배포·수정의 권한 부여 O O O O 배포시 라이선스 사본 첨부 O O O O 저작권고지사항 또는 Attribution 고지사항 유지 O O O O 수정시 수정내용 고지 이후 버전들과 양립할 수 있게 된 것이 큰 변화이다. <참고> MPL의 소스코드 제공범위 derivative work MPL에도 카피레프트 조항이 포함되어 있다는 점에서 GPL과 유사하다. 즉 수정한 코드에 O O O O 대한 소스코드를 제공해야 한다. 그런데 MPL은 “수정(modification)”의 의미를 “원 코드 O 명시적 특허라이선스의 부여 O O 라이선시가 특허소송 제기시 라이선스 종료 O O 또는 이전 수정코드의 내용이나 구조에 추가되거나 삭제되는 것을 말하며, 코드가 복수의 파일로 배포될 경우에는 i) 원 코드나 이전 수정코드를 포함하는 파일의 내용에 추가하거나 삭제된 코드, ii) 원코드나 이전 코드의 일부분을 포함하는 새로운 파일”을 말하는 것으로 이름, 상표, 상호에 대한 사용제한 보증의 부인 O O O O 정의하고 있다. 따라서 MPL 코드가 포함되지 않은 새로운 파일을 만든 경우에는 MPL 책임의 제한 O O O O 코드와의 결합방식에 상관없이 소스코드를 제공할 필요가 없는 것으로 해석할 수 있다. <프로젝트 사례> Firefox 웹브라우저 2.3. MPL형 라이선스 및 주요 프로젝트 MPL 라이선스로 진행되는 대표적인 프로젝트는 Firefox 등 Mozilla가 진행하는 프로젝트들이다. 2010년 7월 현재, Firefox는 전 세계 웹 브라우저 시장에서 23%의 MPL형 라이선스는 주로 기업들이 주도하는 오픈소스 프로젝트에서 사용하는 점유율로 익스플로러에 이어 2위를 차지하고 있다. 그런데, MPL 라이선스는 GPL 형의 라이선스로 MPL, CDDL, EPL 등이 포함된다. BSD형과 GPL형의 라이선스와는 달리, 라이선스와 양립성이 없으므로 GNU 프로젝트와 모질라 프로젝트를 함께 이용하는 것이 처음부터 법률가들이 참여하여 만들었기 때문에 소프트웨어 라이선스의 관점에서는 불편하다. 이러한 문제점을 해결하기 위해 Mozilla는 Firefox를 포함한 대부분의 프로젝트에 더욱 정교하다고 볼 수 있지만, 프로그래머들에게는 그만큼 복잡하고 이해하기 어려운 대해 MPL뿐만 아니라 GPL, LGPL 라이선스를 적용하여 배포하는 트리플(triple) 라이선스 라이선스들이다. 카피레프트 조항을 포함하고 있다는 점에서 GPL형과 비슷하지만, 적용 정책을 채택하고 있다. 한편 “Mozilla Firefox”는 상표로 보호되고 있으며 일정한 조건을 범위와 소스코드 제공범위는 GPL보다는 LGPL에 가까운 것으로 볼 수 있다. 만족하는 경우에만 상표로 사용할 수 있다. 그 결과 Debian 프로젝트에서는 Firefox를 수정한 웹 브라우저를 “Iceweasel”이라는 이름으로 사용하고 있다. 2.3.1. MPL MPL은 1998년 넷스케이프사가 자사의 브라우저를 오픈소스로 배포하면서 만든 2.3.2. CDDL 라이선스이다. MPL로 배포되는 오픈소스를 이용하기 위해서는 i) 원 코드에 포함된 저작권 48 CDDL은 썬(sun)이 자사의 유닉스 운영체제인 솔라리스를 오픈소스로 배포하면서 만든 49 OPEN SOURCE SW LICENCE GUIDE 3.0 조합저작물(Larger Work)작성 및 타 라이선스 배포 허용 2.0에서 Secondary License로 정의한 라이선스인 GPL 2.0, LGPL 2.1, AGPL 3.0과 각각 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 배포시 소스코드 제공 의무(Reciprocity)와 범위 based derivative derivative work on the work work program License 2.0과 양립할 수 있게 되었으며 특허 관련 조항들이 정비되었다. 또한 MPL O P E N SOURCE SW LICENCE GUIDE 3.0 라이선스이다. MPL을 참조하여 만들었기 때문에 MPL의 내용과 비슷하다. i) 저작권 등 때 지켜야 할 의무사항으로는 i) 각 코드의 저작권 고지사항을 제거하거나 변경하지 말 권리관련 사항, 라이선스 관련 사항 등의 고지사항을 제거하거나 변경할 수 없으며, ii) 배포 것과, ii) EPL 라이선스 사본을 포함할 것과, iii) 각 기여물의 창작자를 식별할 수 있도록 시 CDDL 라이선스 사본을 첨부해야 하며, iii) 수정한 경우 수정코드의 기여자임을 밝혀야 신분을 밝힐 것과, iv) 오브젝트코드로 배포하는 경우 EPL 조건을 준수하고, 보증부인 및 한다. iv) 원본 및 수정코드를 CDDL에 의해 배포해야 하며, v) 수정코드에 대한 소스코드를 책임배제에 관한 내용과 소스코드의 확보방법을 알려 줄 것, v) 소스코드로 배포하는 경우 합리적인 방식으로 제공해야 한다. EPL 라이선스를 적용할 것과, vi) 상업적 배포의 경우 기여자에게 책임이 발생하지 않도록 조치할 것 등의 내용을 포함하고 있다. <프로젝트 사례> 오픈 솔라리스 CDDL로 배포되는 대표적인 사례는 썬(Sun)의 솔라리스 운영체제이다. 리눅스, BSD 등 오픈소스 경쟁제품들에 대응하여 썬의 핵심 제품 중의 하나인 솔라리스를 오픈소스화한 <상담 사례> CPL로 배포되는 Juzzle을 사용하는 경우 것이다. 그런데 2009년 오라클이 썬을 인수하면서 썬이 추진해 왔었던 오픈소스 정책에 Q: Juzzle28)을 사용하고 있습니다. CPL 1.0으로 배포되는 것으로 알고 있습니다. 상업적이든 많은 변화가 나타나고 있다. 자바(Java)의 지적재산권에 기반을 둔 구글을 상대로 소송을 비상업적이든 관계없이 사용할 수 있나요? 소스코드를 수정해서 사용하는 경우 어떠한 제기한 사례도 이러한 변화를 보여준다. 향후 오픈 솔라리스의 전망도 불투명한 상황이다. 할 사항은 무엇인가요? CPL도 마찬가지입니다. 수정 여부와 상관없이 CPL 코드를 이용하는 경우 저작권 <상담 사례> CDDL 오픈소스를 이용한 제품의 소스코드 고지사항을 제거하거나 변경하지 말 것, CPL 라이선스 사본을 첨부할 것, 오브젝트 Q: CDDL로 배포되는 오픈소스를 이용하여 만든 B2B 제품을 타 업체에 납품하고 있습니다. 코드로 배포하는 경우 소스코드의 확보방법을 고지할 것, 소스코드로 배포하는 경우 CPL CDDL의 경우, 소스코드에 대해 수정을 하였을 경우, 고지사항을 작성하여 두거나 자사 라이선스를 적용할 것 등이 있습니다. 덧붙여 소스코드를 수정하여 배포하는 경우에는 사이트를 통해서 소스코드를 공개하면 되는 것으로 알고 있습니다. 만약, 소스코드를 기여자로서 창작자를 식별할 수 있도록 신분을 밝힐 것 등이 포함됩니다. 수정하지 않고, 있는 그대로의 라이브러리를 사용하였을 경우에도, 고지사항을 작성하거나 소스코드를 공개해야 하는지 궁금합니다. A: CDDL로 배포되는 오픈소스를 오브젝트 형태로 재배포하는 경우에는 프로그램에 대한 <참고> 소스코드의 제공범위 소스코드를 기여자로부터 제공받을 수 있다는 사실을 밝히고 수취인이 이 소스코드를 EPL도 카피레프트 내용을 포함하고 있다. 재배포 시에 EPL이 적용되는 프로그램은 소프트웨어 교환에 통상적으로 사용되는 매체를 통해 적절한 방법으로 구할 방법을 “기여(Contribution)”의 개념에 의해 결정된다. EPL은 “기여(물) 이란, a) 최초 기여자의 알려주어야 합니다. 따라서 CDDL 코드를 수정하지 않고 사용하는 경우라면, 해당 경우, 본 계약서에 따라 배포된 최초의 코드 및 문서를 말하며, b) 이후의 각 기여자의 소스코드를 제공받을 수 있는 사이트를 적절히 안내하면 직접 소스코드를 제공하지 않아도 경우에는 i) 프로그램에 대한 변경사항 및 ii) 프로그램에 대한 추가사항을 말한다”고 되는 것으로 해석됩니다. 다만, 소스코드 제공 의무를 제외한 기타의 준수사항들(보증의 규정하고 있으며, 이때 “프로그램에 대한 추가사항 중에서, (i) 다른 라이선스 계약서에 부인 및 책임의 제한 등)은 지켜야 합니다. 따라 프로그램과 관련하여 배포된 소프트웨어의 별도 모듈인 경우, 그리고 (ii) 프로그램의 파생저작물이 아닌 경우는 기여에 포함되지 않는다”고 규정하고 있다. 다시 말해서 EPL의 경우에는 “모듈(module)”을 기준으로 소스코드의 제공범위를 결정한다. 2.3.3. CPL, EPL CPL과 EPL은 IBM이 이클립스(Eclipse) 등 오픈소스 프로젝트를 진행하면서 만든 라이선스이다. CPL과 EPL은 특허보복조항에 관한 사항에서만 차이가 있고 다른 내용은 모두 동일하다. IBM은 현재 EPL만 사용하고 있다. EPL로 배포되는 소프트웨어를 배포할 28) http://www.juzzle.org. 50 51 OPEN SOURCE SW LICENCE GUIDE 3.0 A: OSI에서 인증한 오픈소스 라이선스들은 모두 상업적 이용에 제한하지 않고 있으며, 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 의무사항이 있나요? 또는 소스코드를 수정하지 않고 프로그램을 이용만 하는 경우 지켜야 현재 오라클은 오픈 솔라리스의 배포를 중단하고 있다. O P E N SOURCE SW LICENCE GUIDE 3.0 <프로젝트 사례> 이클립스(Eclipse) 프로젝트 <상담 사례> CPL, EPL의 소스코드 공개범위 EPL로 배포되는 대표적인 프로젝트는 이클립스(Eclipse)이다. 이클립스는 Q: CPL, EPL의 경우 공개 범위가 어떻게 되는 건가요? 모듈 단위로 공개한다고 하는데, 통합개발환경(IDE)을 포함한 대표적인 소프트웨어 개발 환경이다. 주로 자바로 작성되어 모듈의 의미가 애매해서 정확한 가이드가 있었으면 합니다. 또, CPL과 EPL간의 차이가 자바 애플리케이션 개발 도구로 사용되지만, 플러그인 시스템을 통해 확장하는 것이 뭔지도 상세한 설명 부탁드립니다. 가능하므로 C, C++, COBOL, Python, Perl, PHP 등으로 개발할 때도 이용할 수 있다. A: MODULE 단위 소스코드 공개 요구사항은 원 저작물의 소스코드를 수정하여 새로운 소프트웨어에 포함하였을 경우에 해당되며, 원 저작물을 사용하면서 수정한 부분에 대하여, MPL형 라이선스 요약 원 저작물의 소스코드에서부터 존재하던 파일 중 수정된 부분을 포함하는 모듈을 모두 [ MPL형 라이선스의 주요 내용과 특징 비교 ] 공개하여야 합니다. 이에 따라, 일반적으로 원 저작물의 모듈을 새로운 소프트웨어에 라이선스의 특징 및 의무사항 CPL/EPL 복제·배포·수정의 권한 부여 O O O 됩니다. 이러한 ‘모듈’의 범위에 대해서는 상황에 따라 다르지만, 일반적인 모듈의 정의에 배포시 라이선스 사본 첨부 O O O 따라 특정 기능을 수행하는 단위를 기준으로 하여 배포하여야 하는 것으로 판단됩니다. 저작권고지사항 또는 Attribution 고지사항 유지 O O O CPL과 EPL에서는 다음과 같은 내용을 포함하여 별도의 모듈인 경우 소스코드의 배포시 소스코드 제공 의무(Reciprocity)와 범위 file file module 제공범위에 포함하지 않는 것으로 보고 있습니다. 조합저작물(Larger Work)작성 및 타라이선스 배포 허용 O O O where such changes and/or additions to the Program originate from and are distributed 수정시 수정내용 고지 O O O by that particular Contributor. A Contribution 'originates' from a Contributor if it was added 명시적 특허라이선스의 부여 O O O to the Program by such Contributor itself or anyone acting on such Contributor's behalf. 라이선시가 특허소송 제기시 라이선스 종료 O O O Contributions do not include additions to the Program which: (i) are separate modules of 이름, 상표, 상호에 대한 사용제한 O O software distributed in conjunction with the Program under their own license agreement, 보증의 부인 O O O and (ii) are not derivative works of the Program. 책임의 제한 O O O 새로이 생성한 부분 중 기존 모듈에 해당되지 않는 부분에 대해서는 공개하지 않아도 한편, CPL과 EPL은 특허보복조항의 적용 범위에 관해서만 차이가 있고 나머지 내용은 동일합니다. 즉, EPL은 CPL 제7조 중 아래의 내용만 삭제하고 이름을 바꾼 것입니다. CPL의 경우 라이선시가 기여자를 상대로 (모든) 소프트웨어 관련 특허침해소송을 제기하는 경우 라이선스가 종료하는 것으로 규정하고 있었는데, 특히 다수의 특허 포트폴리오를 2.4. 폰트 라이선스 가지고 있는 기업의 입장에서는 부담스러운 내용이었기 때문에 이 부분을 삭제하고, EPL로 오픈소스 소프트웨어 확산과 함께 오픈소스 폰트도 많이 만들어지고 있다. 2014년 배포되고 있는 해당 소프트웨어와 관련된 특허침해소송의 경우로만 제한한 것입니다. 어도비와 구글이 손을 잡고 무료 폰트를 공개하기 시작했으며, 현재 구글은 http:// CPL 1.0 제7조 fonts.google.com 을 통해 오픈소스 폰트를 공개하고 있다. “If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall 2.4.1. GPL Font Exception 폰트의 저작권법 특성상, GPL 폰트를 내장한 문서는 GPL의 파생저작물로 간주 될 수 terminate as of the date such litigation is filed.” 있다. 하지만, 이는 대부분 폰트 저작권자의 의도는 아닐 것이다. 이와 같은 이유로 FSF (Free Software Foundation)의 David "Novalis" Turner는 2005년 4월, font exception을 만들었다. 즉 GPL Font Exception이 적용된 폰트라면 폰트 자체는 GPL에 의해 저작권 및 52 53 OPEN SOURCE SW LICENCE GUIDE 3.0 CDDL 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 MPL 적용하기 위해 인터페이스의 수정 등을 거치는 경우가 해당하며, 파생저작물의 저작자가 O P E N SOURCE SW LICENCE GUIDE 3.0 라이선스 고지와 해당 폰트 공개 의무사항을 준수해야 하지만, 폰트가 적용된 문서에는 GPL이 적용되지 않는 것이다. GPL Font Exception As a special exception, if you create a document which uses this font, and embed this font or unaltered portions of this font into the document, this font does not by itself cause the resulting document to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the document might be covered by the GNU General Public License. If you modify this font, you may extend this exception to your version of the font, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.29) 지적재산권, 라이선스와 라이선스 | 01 | |SW 라이선스 및 프로젝트 프로젝트 사례 주요오픈소스 오픈소스 라이선스 오픈소스 및 사례 | |02 | 주요 02 2.4.2. OPEN SOURCE SW LICENCE GUIDE 3.0 SIL Open Font License (OFL) SIL Open Font License는 SIL International에서 자신들의 unicode 폰트를 배포할 때 사용하는 라이선스로 저작권 및 라이선스 고지를 하면 자유롭게 사용 가능하다. 폰트 자체를 단독으로 판매 금지하는 조항이 있어 GPL과 호환되지 않으며, 다른 프로그램과 함께 배포하거나 판매하는 것은 허용된다. 2.4.3. Ubuntu Font License Ubuntu Font License(UFL)는 Ubuntu에서 만든 Ubuntu Font Family를 배포할 때 사용하는 라이선스이다. OFL의 영향을 받아 만든 라이선스이지만, 해당 폰트를 배포할 때 다시 Ubuntu Font License로 배포해야 하는 copyleft 성격을 지니고 있다는 점에서 큰 차이를 갖는다. 배포 시 의무사항으로는 저작권 및 라이선스 고지를 해야 하며, 수정 여부에 관계없이 폰트 소프트웨어의 모든 부분은 다시 UFL로 배포되어야 한다. Font를 배포하는 것을 목적으로 하는 것이 아닌 문서에 해당 UFL 하의 Font가 적용되어 사용된 경우는 라이선스의 적용 대상이 아니므로, 이는 GPL Font Exception과 유사하다고 볼 수 있다. 추가적인 의무사항으로, 원본은 Font 명칭도 그대로 사용해야 하며, 상당한 변형이 있는 수정 버전은 원본 이름 및 유사한 명칭이 아닌 전혀 새로운 명칭을 사용해야 하며, 변형이 크지 않은 수정 버전은 원본 명칭을 유지하면서 “derivative x”를 추가하는 형식으로 원본의 이름과 구분하게 해야 한다. 29) http://www.gnu.org/licenses/gpl-faq.en.html#FontException 54 55 C H A P T E R 03 | 오픈소스 소프트웨어 라이선스 가이드 3.0 | 라이선스 확인 방법 O P E N SOURCE SW LICENCE GUIDE 3.0 O P E N SOURCE SW LICENCE GUIDE 3.0 C H A P T E R 03 | 오픈소스 소프트웨어 라이선스 가이드 3.0 | 라이선스 확인 방법 또한, 오픈소스는 소스 파일 내 라이선스 문구가 명시되어 있으므로 오픈소스 사용자는 각 파일 내 포함된 문구를 통해 라이선스를 확인할 수 있다. 오픈소스 라이선스 의무사항을 올바르게 준수하기 위해서는 배포하는 소프트웨어 내에 어떠한 오픈소스가 사용되었는지를 먼저 파악해야 한다. 소프트웨어를 개발하면서 사용한 오픈소스를 파악하는 방법은 직접 확인하는 방법과 Tool을 이용하는 방법으로 구분할 수 있다. 3.1. 직접 확인하는 방법 주요 오픈소스의 패키지 내에는 라이선스 정보를 나타내는 파일이 포함되어 있다. 최상위 디렉토리 내에 LICENSE, COPYING 등의 이름으로 존재하며, 오픈소스 사용자는 이 이처럼 소프트웨어 개발자들이 사용하려는 오픈소스의 라이선스를 직접 확인하고, 이를 30) 개발팀 내에서 공유할 수 있는 문서에 기재해 나가는 형태로 오픈소스 확인 프로세스를 소프트웨어 내에 포함된 오픈소스 및 각 라이선스 정보를 확보할 수 있게 된다. | 03 | 갖춘다면, 개발이 완료되는 시점에 별도의 자동화 도구를 이용하지 않고도 개발 라이선스 확인 방법 30) TLDRLegal (https://tldrlegal.com/)에서 제공하는 라이선스 검색 기능을 이용하면 텍스트 검색을 통해 라이선스 정보를 확인할 수 있다. 58 59 OPEN SOURCE SW LICENCE GUIDE 3.0 파일을 통해 패키지가 어떤 오픈소스 라이선스로 배포되고 있는지를 확인할 수 있다. O P E N SOURCE SW LICENCE GUIDE 3.0 문자열 검색 기능을 수행하는 도구들은 다음과 같으며 모두 오픈소스로 공개되어 있어서 기업이 무료로 사용할 수 있다. 1. FOSSology31) : GPL 2.0 2. Ninka32) : GPL 3.0 3. TripleCheck33) : AGPL 3.0 하지만, 문자열 검색 도구는 소스 파일 내 라이선스 고지 문구가 삭제된 경우, 오픈소스 사용 여부를 발견할 수 없다는 약점이 존재한다. 따라서, 문자열 검색 도구를 기업이 효과적으로 사용하기 위해서는 개발자들이 소스 파일 내 라이선스 고지 문구를 이처럼 직접 확인하는 방법은 소프트웨어 개발팀의 규모가 일정 수준 이하이고, 오픈소스 수정하거나 삭제하지 않도록 충분한 교육이 선행되어야 한다. 라이선스 교육이 충분히 선행되었을 경우에 적합하다. 3.2.2. 3.2. 코드 스캔 도구 도구를 이용하는 방법 코드 스캔 도구는 오픈소스의 소스코드와 정확하게 일치하거나 유사한 패턴을 보이는 코드 조각이 존재하는지를 확인하는 기능을 수행한다. 따라서, 소스코드 내 라이선스 소프트웨어 내 오픈소스 포함 여부를 확인하기 위한 도구는 다음 세 가지 형태로 분류할 문구가 삭제된 경우에도 FOSSology 등의 문자열 검색 도구와는 달리 코드 스캔 도구는 수 있다. 소스코드 내의 문자열을 검색하는 도구와 실제 소스코드 내용을 스캔하여 오픈소스 검출이 가능하다. 오픈소스코드와 비교하는 도구, 그리고 소스코드 없이 바이너리를 스캔하여 오픈소스를 확인하는 도구이다. 코드 스캔 기능을 수행하는 도구들은 다음과 같으며, 모두 라이선스를 구매해야 사용할 수 있는 상용 도구이다. 3.2.1. 문자열 검색 도구 문자열 검색 도구는 소스 파일 상단의 라이선스 문구를 검색하여 자동으로 라이선스를 Black Duck Protex34) 판단하는 기능을 수행한다. Palamida35) OpenLogic36) (현재 Rogue Wave) Protecode37) (현재 Synopsis) 31) http://fossology.org 32) http://ninka.turingmachine.org 33) http://triplecheck.net/download.html 34) https://www.blackducksoftware.com 35) http://www.palamida.com/ 36) http://www.roguewave.com/products-services/open-source-support 37) http://www.protecode.com/ 60 61 라이선스 확인 방법 소스코드와 일치하는 오픈소스 정보를 제공한다. | 03 | 오픈소스를 취합하여 오픈소스 데이터베이스를 구축하고, 이를 활용하여 사용자의 OPEN SOURCE SW LICENCE GUIDE 3.0 코드 스캔 도구를 제공하는 기업들은 Github 등 오픈소스 호스팅 사이트에서 주기적으로 O P E N SOURCE SW LICENCE GUIDE 3.0 하지만 오픈소스는 특성상 시간이 지나면서 여러 개발자에 의해 수정, 배포가 반복되면서 <상담 사례> 소스 파일 내 라이선스 문구와 COPYING 파일의 라이선스 정보가 다를 경우 다수의 새로운 오픈소스로 배포될 수도 있는데, 코드 스캔 도구는 오랜 시간 동안 이런 Q: 사용하려는 OOO 오픈소스 패키지의 최상위 디렉토리 내에 존재하는 COPYING 파일은 형태로 생성된 오픈소스를 모두 데이터베이스에 포함하게 되고, 그 결과로 분석 대상 GPL 3.0인 반면, 소스 파일 내 라이선스 문구는 GPL 2.0입니다. 어떤 라이선스로 판단해야 코드에 대해 다수의 오픈소스와 일치하는 분석 결과를 보여주게 된다. 일반적으로 코드 할까요? 스캔 도구가 제공하는 기능은 이렇게 분석 대상 코드와 일치하는 데이터베이스 내의 A: 오픈소스는 통상 최상위 디렉토리 내에 “LICENSE”, “NOTICE”, “README”, “COPYING” 오픈소스를 찾아주는 역할만 수행하고, 실제 정확한 출처는 사용자가 직접 판단해야 하는 등의 파일을 포함해서 라이선스 정보를 고지합니다. 역할을 요구한다. 오픈소스 라이선스에 익숙하지 않은 사용자는 이러한 판단을 하기가 이와는 별도로 COPYING 파일의 경우, GPL이나 LGPL 등 라이선스의 “사본 동봉 의무”에 쉽지 않으며, 특히 해당 소프트웨어를 개발한 사람이 아니면 잘못된 판단을 할 가능성이 따라 포함되는 경우도 있으므로, 해당 라이선스가 전체 소스 파일에 적용되는 것은 아닐 수 높다. 따라서, 코드 스캔 도구에서 검출이 된 코드 조각에 대해서는 도구 사용자가 아닌 있음에 주의가 필요합니다. COPYING 파일 내 라이선스 문구와 소스 파일 상단의 라이선스 해당 코드의 개발자에게 코드 출처를 확인하여 라이선스를 판단하는 것이 효과적인 코드 문구가 서로 다르다면, 각 소스 파일에 대해서는 먼저 소스 파일 내 라이선스 문구를 스캔 도구의 사용 방법이다. 기반으로 라이선스를 판단해야 합니다. 만약, 소스 파일 내의 라이선스 문구와 최상위 디렉토리 내의 라이선스 정보 파일 내 한국저작권위원회에서는 오픈소스 사용 여부를 확인해 볼 수 있도록 코드아이를 개발하여 38) 국내 영세업체를 대상으로 무상 서비스를 제공하고 있다. 라이선스가 서로 전혀 다를 경우에는 저작권자에게 연락하여 해당 오픈소스를 어떤 라이선스로 공개한 것인지 확인을 요청하는 것이 좋습니다. 실제, 일부 오픈소스 소스코드 파일이나 폴더를 선택해 검사를 요청하면, 서버에 저장된 데이터베이스와 저작권자의 경우, 실수로 잘못된 라이선스 정보 파일이 포함된 것을 뒤늦게 확인하여 수정 비교해 검사 보고서를 제공한다. 소스코드는 암호화된 상태로 SSL(Secure Socket Layer) 후 재배포하는 경우가 있습니다. 상에서 전달되기 때문에 유출될 위험은 없다. 코드아이는 현재는 900만 파일의 오픈소스 | 03 | 데이터베이스를 보유하고 있으며, 앞으로도 지속해서 데이터베이스를 늘려가고 있으므로 3.2.3. 바이너리 스캔 도구 지원하고 있다. 3rd Party로부터 소프트웨어를 받을 때는 대부분 소스코드 없이 바이너리 형태로 입수한다. 그런데, 지금까지 언급한 도구들은 모두 바이너리 형태의 소프트웨어에 대해서는 오픈소스 확인 기능을 제공하지 못한다. 하지만, 3rd Party로부터의 소프트웨어 입수가 증가하는 소프트웨어 개발 환경을 고려하면 바이너리 형태의 소프트웨어에 대한 오픈소스 및 라이선스의 확인이 필요한 것은 자명하다. 38) https://www.olis.or.kr/ossw/codeEye/introduction.do 62 63 라이선스 확인 방법 소프트웨어 업체의 오픈소스 사용에 대한 리스크를 좀 더 철저히 방지할 수 있도록 OPEN SOURCE SW LICENCE GUIDE 3.0 코드아이를 사용하여 자신의 O P E N SOURCE SW LICENCE GUIDE 3.0 바이너리 형태의 소프트웨어를 스캔하여 오픈소스 사용 여부를 확인할 수 있는 도구는 다음과 같다. 부록 BAT39) : 오픈소스 기반 (Apache 2.0, 단, 데이터베이스는 상용) Codenomicon AppCheck40) (현재는 Synopsis) : 상용 도구 바이너리 스캔 도구로는 BAT가 오픈소스로 공개되어 있어서 동작 원리 파악이 가능하다. BAT는 분석 대상 바이너리에 대해 hexdump, strings 등의 명령어를 이용하면 String 정보를 추출하고, 이를 오픈소스 데이터베이스 내 String 정보와 비교하여 오픈소스 사용 여부를 판단한다. 이러한 방식은 간단하고, 아키텍처나 컴파일러와 관계없이 사용 가능한 | 오픈소스 소프트웨어 라이선스 가이드 3.0 | 기타 상담 사례 장점이 있지만, 바이너리 분석 특성상 소스코드를 직접 분석하는 도구에 비해 정확도가 떨어진다. 39) http://www.binaryanalysis.org 40) http://www.codenomicon.com/products/appcheck/ 64 O P E N SOURCE SW LICENCE GUIDE 3.0 O P E N SOURCE SW LICENCE GUIDE 3.0 | 부록 | 기타 상담 사례 A: 폰트포지, 잉크스케이프, 김프는 전부 오픈소스이며, 폰트포지는 BSD License, 잉크스케이프와 김프는 GPLv2로 배포되고 있습니다. BSD License의 경우 해당 라이선스로 배포되는 오픈소스를 상업용 소프트웨어에 포함하더라도 소스코드 제공 등의 요구사항이 존재하지 않는 매우 자유로운 라이선스입니다. 더불어 그 사용에 대해서도 별도의 제약을 가하지 않으므로 산출된 결과물 또한 상업적 이용에 문제가 없을 것으로 판단됩니다. GPL의 경우 GPL로 배포된 오픈소스 일부분이 결과물에 포함되는 형태에서만 그 결과물이 GPL의 영향을 받게 됩니다. 따라서, GPL로 배포된 오픈소스를 단순히 사용만 하는 경우에는, 산출 결과물의 저작권이 소프트웨어를 사용하여 결과물을 제작해낸 사용자에게 있는 것으로 판단됩니다. 하지만, 가장 정확한 것은 각 폰트 파일이나 그림을 제작하고 GPL로 배포한 저작권자에게 문의하여 상용으로 사용해도 좋은지 확인하는 것이 상담 사례 B2B에서의 라이선스 준수 좋겠습니다. Q: 오픈소스를 이용하여 제품을 만들고 직접 판매나 배포 시에는 제품 약관이나 설명서에 해당 "고지사항"을 작성하여 두거나 자사 사이트를 통해서 소스코드를 공개해 두면 되는 것으로 이해했습니다. 궁금한 점은 위와 같은 B2C가 아닌 B2B일 경우 제품이나 상담 사례 MySQL의 라이선스 애플리케이션을 타 업체에 납품 또는 판매를 할 때는 어떻게 규정을 지켜야 하는 것인지 다소 애매한 부분이 있는 것 같아 질의 드립니다. 오픈소스가 들어간 제품을 납품받은 Q: MySQL Community Server를 다른 소프트웨어(자사에서 개발한)와 결합하여 사용할 때 업체도 오픈소스 규정을 똑같이 지켜야 하는지요? 아니면 상관없이 제품을 제공한 생길 수 있는 라이선스 쟁점은 무엇입니까? 업체에서만 오픈소스의 규정을 정확히 준수하면 되는지요? A: MySQL은 이른바 ‘듀얼 라이선스 정책’으로 GPL 2.0과 Commercial License, 두 가지 A: 오픈소스 라이선스에 규정된 의무사항은 대부분 오픈소스 소프트웨어를 ‘배포’할 라이선스를 통하여 배포됩니다. Commercial License를 구매하여 사용하는 경우에는 때 발생하는 의무입니다. 따라서 오픈소스가 포함된 제품을 다른 업체로부터 납품받은 Commercial License에 따라 대가를 지불한 만큼 문제점이 없을 것이며, Commercial 업체가 이 제품을 ‘배포’한다면 동일한 의무사항이 발생합니다. 실제 오픈소스 라이선스 License를 구매하지 않고 사용하는 경우에는 GPL에 적용되므로, GPL 요구사항에 따라 위반으로 소송을 제기당했었던 많은 기업이 다른 업체로부터 납품받은 제품 때문에 결합된 소프트웨어의 소스코드를 공개하여야 할 의무가 있습니다. 문제가 되었던 사례들이 많습니다. 따라서 오픈소스가 포함된 제품을 납품받아 판매하는 타 소프트웨어가 MySQL(GPL 2.0)과 결합하는 경우, 정적/동적 링크를 포함하여 2차적 기업의 입장에서는 납품업체로부터 소스코드를 제공받을 필요가 있으며, 자신들도 배포 시 저작물에 해당하는 경우에는 GPL로 배포하여야 하며 GPL의 요구사항을 준수하여야 의무사항을 준수해야 합니다. 합니다. 덧붙여, GPL을 포함한 오픈소스 라이선스들은 대부분 상용제품에 포함해 유료로 판매하는 것을 허용하지만, GPL은 상용 소프트웨어와 결합할 경우 상용 소프트웨어도 GPL이 적용되어 공개해야 하므로 유의하시기 바랍니다. 만약 GPL 요구사항에서 벗어나고 싶을 때는 MySQL과 완전하게 독립적인 소프트웨어로 인정받거나 MySQL의 Commercial 상담 사례 오픈소스를 이용하여 만든 폰트파일, 그림 등 License를 구매하는 방법이 있습니다. Q: 리눅스 운영체제에서 폰트포지 1), 잉크스케이프(Inkscape), 김프(GIMP)와 같은 오픈소스(무른모)로 새로 편집한 그림이나 폰트 파일, 또는 리눅스용 프로그래밍 언어 프로그램으로 짜서 저장한 파일을 갖고 상용으로 배포하려고 합니다(판매 목적으로). 상담 사례 Artistic License의 준수사항 그래도 되나요? 만약에 상용으로 배포한 그 파일들은 오픈소스 라이선스에 위반되나요? Q: Artistic License 2.0의 소스코드 배포 시, 실행 파일 배포 시, 수정 코드 배포 시 의무사항과 위반 사례를 알고 싶습니다. 1) 폰트포지(FontForge)는 미국의 조지 윌리엄즈(George Williams)가 만든 폰트 개발 프로그램이다. 명조체나 고딕체, 붓글씨체, 손글씨체 등을 만들어 저장할 수 있으며, 그 파일로 트루타입, 오픈타입 파일로 생성하는 기능을 갖는다. 툴이 매우 불편하여 다른 그래픽프로그램을 함께 써야 하는 번거로움이 있다. 상용 프로그램인 폰트랩(FontLab), 아시아폰트스튜디오(AsiaFontStudio), 이카루스(Icarus)에 해당한다. 66 A: Artistic License 2.0은 ‘표준 버전(Standard Version)’과 ‘수정 버전(Modified Version)’을 67 O P E N SOURCE SW LICENCE GUIDE 3.0 구분하여 의무사항을 규정하고 있습니다. 공통적으로 지켜야 할 의무사항으로는 배포 없을 때는 저작물을 이용하는 사람이 저작권 관련 고지사항 및 오픈소스 라이선스 관련 시 원본의 저작권 고지사항과 관련된 부인사항을 그대로 전부 포함하여야 하는 것 등이 정보를 명확히 알 수 있도록 애플리케이션 정보 소개 페이지나, 안내, 구매, 다운로드 있습니다. 페이지에 이를 명시하여 알리는 것으로 대신하거나 FTP, 웹사이트 등을 이용하여 이러한 표준 버전은 원 코드를 수정되지 않았거나, 저작권자에 의해 명시적으로 요구된 정보를 제공하는 등의 방법으로 요구사항을 만족시킬 수 있을 것으로 판단됩니다. 추가로 수정사항(버그 교정, 이식성 변경 등)에 따라 수정된 소프트웨어를 말합니다. 표준 버전을 LGPL Library의 소스도 Application과 함께 배포하거나 사용자가 해당 소스를 요청할 수 소스코드를 포함하지 않고 배포하는 경우, 표준 버전의 소스코드를 구할 방법을 안내하는 있도록 소스요청 E-mail address 혹은 직접 Download 받을 수 있는 웹사이트를 명시하는 문구를 포함해야 합니다. 방법으로 함께 제공해야 합니다. ‘수정 버전’은 저작권자에 의해 명시되지 않은 수정사항을 포함하는 버전을 말하며, 수정 버전을 배포할 때는 표준 버전과의 차이점을 명확히 기록하여야 하며, 다음 조건들 중 적어도 하나 이상을 충족하여야 합니다. 상담 사례 BusyBox를 포함한 프로젝트 1. 표준 버전의 저작권자가 당신의 수정사항들을 표준 버전에 포함할 수 있도록, 수정 Q: 아래와 같이 BusyBox를 프로젝트에 포함시켜 사용할 경우, BusyBox 소스코드만 버전을 원본 라이선스에 따라 표준 버전의 저작권자가 사용할 수 있도록 함 오픈하면 되는지 당사가 개발한 프로그램의 소스코드도 오픈해야 하는지 확인 2. 사용자가 당신의 수정 버전을 설치함으로써 표준 버전의 설치나 실행이 방해되지 않도록 부탁드립니다. 보장(표준 버전과 다른 이름을 사용) 1. BusyBox의 소스코드는 수정하지 않았으며, busybox build해서 나온 실행 파일(elf- 3. 수정 버전의 복제본을 양도받는 어느 누구라도, 원본 라이선스 혹은, 양도받은 복제본과 format)을 사용 동일한 라이선스를 이용하여 수정 버전의 소스코드 형식을 다른 사람에게 제공할 수 있도록 2. BusyBox에서 여러 가지 명령어를 사용할 수 있는데 저희는 거기서 mount 명령어를 사용 허용 3. 수행되는 동작은 아래 그림처럼 UI에서 관련 정보를 설정하면 demon에서 busybox Artistic License에 대한 위반 사례에 대해서는, Artistic License가 요구하고 있는 mount를 실행시키는 구조 의무사항에서, 수정된 소스코드의 공개를 강제하지 않는 자유로운 성격을 띠고 있으므로 UI(Setting) → NFS/CIFS demon → busybox mount set IP/PATH/(id/pw) 대중에 공개적으로 알려진 위반 사례가 많지 않지만, 최근 미국 고등법원의 판결로 이슈가 되고 있는 Jacobsen v. Katzer 사례2)가 존재합니다. A: GNU GPL 2.0으로 배포되고 있는 BusyBox는 라이선스에 따라 정적 혹은 동적으로 링크된 소스코드까지 함께 제공하여야 하는 요구사항을 준수하여야 합니다. ELF(Executable and Linkable Format) 파일 포맷은 실행, 오브젝트 코드, 공유 라이브러리, 상담 사례 LGPL 라이브러리를 이용한 스마트폰 애플리케이션 코어 덤프 등에 사용될 수 있으며, ELF 바이너리를 통해 단순히 실행시킬 수도 있지만, Q: LGPL로 있는 Library를 사용하여 스마트폰에 Application을 만들어 Store에 올리려고 특성에 따라 라이브러리로도 이용 가능한 파일 포맷입니다. 준비 중입니다. 웹 사이트도 없고, 이때 LGPL의 라이선스 문항을 어디에 넣어야 할지 BusyBox를 빌드하여 ELF 파일을 단순히 실행(execute)하여 사용하는 경우, 독립적인 문의합니다. 그냥 binary 파일에 licence.txt로 resource 파일에 포함해서 Application과 함께 프로세스로 동작하기 때문에 배포 시 요구사항에서 BusyBox를 제외한 나머지 부분에 배포하면 되는지요? 대한 소스코드 제공 의무가 발생하지 않습니다. 즉, 라이브러리로 링크시키는 형태가 아닌, A: 오픈소스 저작권자들은 일반적으로, 배포되는 소프트웨어 내에 “Notice”, “License” 데몬을 통해 단순히 바이너리가 실행되는 형태로 사용하는 경우에는 배포시 소스코드 제공 혹은, “Copyright” 등의 이름을 가진 문서를 포함해 이를 통해 저작권 관련 고지사항을 의무가 BusyBox에 해당하는 소스코드에 대해서만 발생하게 됩니다. 이와 달리, BusyBox의 명시하도록 권장하고 있지만, 만약, 특수한 상황에서 위와 같은 문서 파일을 포함할 수 ELF 파일을 라이브러리의 형태로 링크하여 사용하는 경우에는, 정적/동적 링크 여부를 떠나 링크되어 연결되는 소프트웨어 전체에 대한 소스코드 제공 의무가 발생하게 됩니다. 2) Robert Jacobsen은 JMRI(Java Model Railroad Interface) 프로젝트를 Artistic License로 배포했는데, Matthew Katzer와 그의 회사인 KAMIND Associate가 모형기차 프로그램을 개발하면서 JMRI 프로젝트 일부를 사용하였지만, 저작권 문구 및 고지사항 포함 등의 요구사항을 지키지 않았다. Jacobsen은 Katzer의 행위에 대해 Artistic License 위반 및 저작권 침해로 간주하고 소송을 제기했다. 캘리포니아 북부 지방 법원은, Katzer의 행위에 대해 저작권 침해에는 해당하지 않으며 단순한 라이선스 계약 위반이라고 판결하였다. 하지만, 항소법원은 라이선스 계약 위반 및 저작권 침해에도 해당하는 것으로 판결하였다. 68 따라서, BusyBox의 사용에 있어서 단순실행 혹은 라이브러리 링크 여부가 주요 관건이 될 것으로 판단됩니다. 69 O P E N SOURCE SW LICENCE GUIDE 3.0 있지만, 관련 사항에 대해서는 담당 변호사에게 자문을 구하도록 하고 있으며, 직접적인 상담 사례 R을 이용한 상용 소프트웨어의 개발 답변을 줄 수 없다고 명시하고 있습니다. 따라서, GNU·GPL이 사유 소프트웨어와 Q: 저희가 개발하는 S/W의 기능 추가를 위해 GPL 2.0을 따르는 오픈소스를 사용하는 데 결합할 수 없다고 명시하고 있음에도 불구하고, R(D)-COM이 사유 소프트웨어인 있어서 문제가 없는지 문의합니다. 마이크로소프트社의 엑셀 등과 GPL이 적용된 R을 연결하기 위해 사용되는 소프트웨어로 1. R3) : 통계용 Open Source S/W (GPL 2.0) 소개되어 있지만, 실질적으로 다른 소프트웨어와 함께 사용하는 경우에는 GPL이 적용된 R 2. qpcR4) : 저희가 추가하려는 기능의 핵심 모듈이 들어있는 패키지로 R이 기본적으로 패키지와의 동작 관계를 명확하게 확인하여야 할 것으로 판단됩니다. 설치되어 있어야 함. 3. R(D)-COM Interface5) : 저희가 개발하려는 S/W와 R 간의 Interface를 위한 S/W 위의 세 가지 모두 소스코드는 수정하지 않을 것이며, 아래와 같은 구조로 사용하려고 합니다. 위와 같이 사용하려고 할 때, 라이선스 관련 위배 사항이 없는 지 궁금하며, 위배 사항이 있을 경우 어느 정도까지 소스 공개가 되어야 하는 지 궁금합니다. A: R(D)-COM은 별도의 라이선스 정책을 적용하고 있지는 않지만, 이미 GPL이 적용된 R과의 결합 정도에 따라 GPL 적용 여부가 결정될 것으로 판단됩니다. GPL FAQ에 의하면 결합 정도에 따른 GPL 적용 범위의 구분 기준을 제시하고 있습니다. 예를 들어, 프로그램의 플러그인이 동적 링크로 실행되는 경우 메인 프로그램이 확장된 경우에 해당하여 GPL 적용 범위에 포함되지만, fork나 exec을 사용하는 경우에는 별도의 프로그램에 해당하여 포함되지 않습니다. 또는 두 개의 프로그램이 공유된 메모리를 사용하여 복합데이터 구조와 통신하는 경우 GPL 적용 범위에 포함되지만, 파이프(pipe), 소켓(socket), command-line argument 형태로 통신하는 경우에는 포함되지 않습니다. 당사가 개발한 소프트웨어와 R(D)-COM이 통신하는 경우에도, 소프트웨어 사용 환경 및 적용 범위를 고려하고 위의 구분 기준에 비추어 결합 정도를 판단하여야 할 것입니다. 만약 GPL의 적용 범위에 포함되는 것으로 판단되면 GPL 사본 첨부, 저작권 고지사항 유지, 프로그램 소스코드 제공 등의 GPL 요구사항을 준수하여야 합니다. R 코어 팀에서 제공하는 FAQ에서도, R 패키지의 상업적 이용을 제한하지 않는다고 말하고 3) http://www.r-project.org/. 4) http://cran.at.r-project.org/web/packages/qpcR/index.html 5) http://cran.at.r-project.org/other-software.html 70 71 | 오픈소스 소프트웨어 라이선스 가이드 3.0 | 2016년 11월 인쇄 2016년 11월 발행 기 획 한국저작권위원회 공유정보팀 글쓴이 3.0 - 김경애, 이철남 2.0 - 김경애, 이철남, 방효근, 이명화, 김수현 발행처 문화체육관광부, 한국저작권위원회 인 쇄 (주)선명씨앤피 저작권자표시-비영리-변경금지 2.0 대한민국 이용자는 아래의 조건을 따르는 경우에 한하여 자유롭게 이 저작물을 복제, 배포, 전송, 전시, 공연 및 방송할 수 있습니다. 다음과 같은 조건을 따라야 합니다. 저작권자표시. 귀하는 원저작자를 표시하여야 합니다. 비영리. 귀하는 이 저작물을 영리 목적으로 이용할 수 없습니다. 변경금지. 귀하는 이 저작물을 개작, 변형 또는 가공할 수 없습니다. •귀하는 이 저작물의 재이용이나 배포의 경우, 이 저작물에 적용된 이용허락조건을 명확하게 나타내어야 합니다. •저작권자로부터 별도의 허가를 받으면 이러한 조건들은 적용되지 않습니다. •Nothing in this license impairs or restricts the author's moral rights.
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.4 Linearized : Yes Tagged PDF : Yes XMP Toolkit : Adobe XMP Core 5.6-c067 79.157747, 2015/03/30-23:40:42 Create Date : 2016:11:25 14:26:35+09:00 Metadata Date : 2016:11:25 14:27:01+09:00 Modify Date : 2016:11:25 14:27:01+09:00 Creator Tool : Adobe InDesign CC 2015 (Windows) Instance ID : uuid:ffce4217-2573-4f30-9075-40a934166f1b Original Document ID : xmp.did:946D79E60F206811822AB705A2FE567B Document ID : xmp.id:4d417fbf-b1e4-2244-b944-dfcdcb245598 Rendition Class : proof:pdf Derived From Instance ID : xmp.iid:58ac9db7-ed61-914c-addb-894ffccc603c Derived From Document ID : xmp.did:9fd5e529-cc36-4a49-a752-fd80acefd21e Derived From Original Document ID: xmp.did:946D79E60F206811822AB705A2FE567B Derived From Rendition Class : default History Action : converted History Parameters : from application/x-indesign to application/pdf History Software Agent : Adobe InDesign CC 2015 (Windows) History Changed : / History When : 2016:11:25 14:26:35+09:00 Format : application/pdf Producer : Adobe PDF Library 15.0 Trapped : False Page Count : 37 Creator : Adobe InDesign CC 2015 (Windows)EXIF Metadata provided by EXIF.tools