Version 1.0.0 개발자, 관리자, OS 전문가및기업을위한실무지침 오픈소스라이선스해설 오픈소스라이선스준수방법 Karsten Reincke Greg Sharpe
Version 1.0.0 개발자, 관리자, OS 전문가및기업을위한실무지침 오픈소스라이선스해설 오픈소스라이선스준수방법 * Karsten Reincke Greg Sharpe 2015. 3. 2 저작권과이용허락안내 *) 본문서내용은 Creative Commons Attribution-ShareAlike 3.0 라이선스 (http://creativecommons.org/licenses/by-sa/3.0/de/) 에의해사용허가된내용입니다. 본문서와동일하거나유사한라이선스에의한저작물을배포 하고 저자가지정한방식의저작물로판단 한다면제약없이 공유 ( 복제, 배포및전송하기위한 ) 또는 수정 을할수있습니다. : 인터넷에서재사용시적절한방식으로최초저자들을언급하고, 이들의스폰서도이치텔레콤 ( 주 )(Deutsche Telekom AG) 명칭을제시하며, http://www.telekom.com에링크를적용하기바랍니다. 문서유형으로재사용시에는서문에서 http://www.telekom.com, 최초저자그리고스폰서인도이치텔레콤 ( 주 ) 에대한내용을간략하게제시하기바랍니다. 일반적인인용문인경우에는과학표준방식을사용하면됩니다. [mycsrf (= mind your Scholar Research Framework ) c K. Reincke CC BY 3.0 http://mycsrf.fodina.de/) 를기초한내용 ] ) Deutsche Telekom AG, Products & Innovation, T-Online-Allee 1, 64295 Darmstadt ) Deutsche Telekom AG, Telekom Deutschland GmbH, Landgrabenweg, Bonn 본문서내용은정보통신산업진흥원이위저작권이용허락에따라번역하여배포합니다. (2017년 6월 30일 ) 본번역내용에대한오탈자및잘못된내용에대한수정정보는공개SW포털홈페이지나아래이메일로보내주시면감사하겠습니다. * 공개SW포털홈페이지 www.oss.kr / 이메일 oss@nipa.kr
오픈소스커뮤니티에는다수의사람들이활동하고있습니다. ( 임의로선정된전문가들보다더영향력있음 ). 이커뮤니티로부터지원을받는데대해영광으로생각합니다. 이분들에게감사를드립니다. ( 알파벳순서로열거 ): Eitan Adler, Stefan Altmeyer (Deutsche Telekom AG), Ronald Dauster, John Dobson, Steffen Härtlein, Ta Id Holmes (Deutsche Telekom AG), Michael Kern (Deutsche Telekom AG), Michael Machado (Deutsche Telekom AG), Thorsten Müller (Deutsche Telekom AG), Tanja Neske (Deutsche Telekom AG), Oliver Podebradt (Deutsche Telekom AG), Thomas Quiehl (Deutsche Telekom AG), Peter Schichl (Deutsche Telekom AG), Michael Schierl, Helene Tamer (T-Systems Internationl AG), Bernhard Tsai (Deutsche Telekom AG), Thomas Weischuh (Amadeus Germany GmbH), 외
목차 1 서론 12 2 오픈소스 : 동일한관념, 다양한라이선스 17 2.1 GNU Affero General Public License(GPL) 의보호기능 28 2.2 아파치라이선스 (Apache-2.0) 의보호기능 28 2.3 BSD 라이선스의보호기능 28 2.4 CDDL 라이선스의보호기능 [ 추후보완 ] 29 2.5 Eclipse Public License(EPL) 의보호기능 29 2.6 European Union Public License(EUPL) 의보호기능 31 2.7 GNU General Public License(GPL) 의보호기능 32 2.7.1 GPL-2.0 33 2.7.2 GPL-3.0 33 2.8 Lesser GNU General Public License(LGPL) 의보호기능 34 2.8.1 LGPL-2.1 35 2.8.2 LGPL-3.0 36 2.9 MIT 라이선스의보호기능 37 2.10 Mozilla Public License(MPL) 의보호기능 37 2.11 Microsoft Public License(MS-PL) 의보호기능 39 2.12 Postgres License(PostgreSQL) 의보호기능 39 2.13 PHP 라이선스의보호기능 40 2.14 요약 40 3 오픈소스 : 일부부작용에대해 43 3.1 불명확하게특허를공개하는문제 43 3.1.1 AGPL 특허관련조항 46 3.1.2 Apache-2.0 특허관련조항 47 3.1.3 CDDL 특허관련조항 48 3.1.4 EPL 특허관련조항 49 3.1.5 EUPL 특허관련조항 50 3.1.6 GPL 특허관련조항 50 3.1.6.1 GPL-2.0 50 3.1.6.2 GPL-3.0 51 3.1.7 LGPL 특허관련조항 51 3.1.7.1 LGPL-2.1 51 3.1.7.2 LGPL-3.0 52 3.1.8 MPL 특허관련조항 52 3.1.9 MS-PL 특허관련조항 53-1 -
3.2 부가사항 : 링킹이부차적기준이되는이유 53 3.3 부가사항 : 오픈소스의기본개념 - 파생저작물 이란? 57 3.4 부가사항 : 리버스엔지니어링과오픈소스 59 3.4.1 LGPL-2의리버스엔지니어링 63 3.4.1.1 언어적해석 63 3.4.1.2 논리적해석 66 3.4.1.3 경험적해석 69 3.4.1.4 최종결론 71 3.4.1.4.1 라이브러리의일부를수동으로복제한저작물배포시 Copyleft 가적용된다. 71 3.4.1.4.2 스크립트배포시리버스엔지니어링을필요로하지않는다. 72 3.4.1.4.3 정적결합된바이트코드배포시리버스엔지니어링허가가필요하다 73 3.4.1.4.4 정적결합된바이너리배포시리버스엔지니어링허가가필요하다 73 3.4.1.4.5 동적결합이가능한바이트코드및링킹가능한오브젝트코드는리버스엔지니어링허가를필요로하지않는다. 75 3.4.1.4.6 리버스엔지니어링허가가있을때와없을때의 LGPL-2.0 컴플라이언스 76 3.4.1.5 최종확보 77 3.4.2 LGPL-3.0의리버스엔지니어링 79 3.4.3 기타오픈소스라이선스의리버스엔지니어링 84 3.4.4 오픈소스라이선스의리버스엔지니어링 : 개요 86 3.5 부가사항 : 라이선스준수성문제 [ 추후보완 ] 87 3.6 부가사항 : 오픈소스소프트웨어와수익 [ 추후보완 ] 87 4 오픈소스사용사례 : 개념과분류체계 88 5 오픈소스사용사례 : 과업목록 (To-Do List) 을충족시키는라이선스찾기 92 5.1 관련정보수집을위한표준포맷 92 5.2 분류적오픈소스사용사례파인더 94 5.3 오픈소스사용사례및그과업목록참고자료 96 6 오픈소스라이선스준수 : 과업목록 107 6.1 누군가에게파일을 제공 함에있어서의일반적설명 107 6.2 AGPL 라이선스소프트웨어 108 6.2.1 AGPL-3.0-C1: 단독으로소프트웨어사용 108 6.2.2 AGPL-3.0-C2: 수정하지않은소프트웨어를독립적인소스코드형태로배포 109 6.2.3 AGPL-3.0-C3: 수정하지않은소프트웨어를독립적인바이너리형태로배포 109 6.2.4 AGPL-3.0-C4: 수정하지않은라이브러리를임베디드소스코드형태로배포 110 6.2.5 AGPL-3.0-C5: 수정하지않은라이브러리를임베디드바이너리형태로배포 111 6.2.6 AGPL-3.0-C6: 수정한프로그램을소스코드형태로배포 112 6.2.7 AGPL-3.0-C7: 수정한프로그램을바이너리형태로배포 113-2 -
6.2.8 AGPL-3.0-C8: 수정한라이브러리를독립적인소스코드형태로배포 114 6.2.9 AGPL-3.0-C9: 수정한라이브러리를독립적인바이너리형태로배포 115 6.2.10 AGPL-3.0-CA 수정한라이브러리를임베디드소스코드형태로배포 116 6.2.11 AGPL-3.0-CB: 수정한라이브러리를임베디드바이너리형태로배포 117 6.2.12 AGPL-3.0-CC: 수정한프로그램을네트워크와연계하여실행 118 6.2.13 AGPL-3.0-CD: 수정한임베디드라이브러리를네트워크와연계하여실행 120 6.2.14 논의및설명 121 6.3 아파치라이선스소프트웨어 125 6.3.1 Apache-2.0-C1: 단독으로소프트웨어사용 125 6.3.2 Apache-2.0-C2: 수정하지않은소프트웨어를소스코드형태로배포 126 6.3.3 Apache-2.0-C3: 수정하지않은소프트웨어를바이너리형태로배포 126 6.3.4 Apache-2.0-C4: 수정한프로그램을소스코드형태로배포 127 6.3.5 Apache-2.0-C5: 수정한프로그램을바이너리형태로배포 128 6.3.6 Apache-2.0-C6: 수정한라이브러리를독립적인소스코드형태로배포 129 6.3.7 Apache-2.0-C7: 수정한라이브러리를독립적인바이너리형태로배포 129 6.3.8 Apache-2.0-C8: 수정한라이브러리를임베디드소스코드형태로배포 130 6.3.9 Apache-2.0-C9: 수정한라이브러리를임베디드바이너리형태로배포 131 6.3.10 논의및설명 132 6.4 BSD 라이선스소프트웨어 133 6.4.1 BSD-3-Clause-C1: 단독으로소프트웨어사용 134 6.4.2 BSD-3-Clause-C2: 수정하지않은소프트웨어를소스코드형태로배포 135 6.4.3 BSD-3-Clause-C3: 수정하지않은소프트웨어를바이너리형태로배포 135 6.4.4 BSD-3-Clause-C4: 수정한프로그램을소스코드형태로배포 136 6.4.5 BSD-3-Clause-C5: 수정한프로그램을바이너리형태로배포 136 6.4.6 BSD-3-Clause-C6: 수정한라이브러리를독립적인소스코드형태로배포 137 6.4.7 BSD-3-Clause-C7: 수정한라이브러리를독립적인바이너리형태로배포 137 6.4.8 BSD-3-Clause-C8: 수정한라이브러리를임베디드소스코드형태로배포 138 6.4.9 BSD-3-Clause-C9: 수정한라이브러리를임베디드바이너리형태로배포 139 6.4.10 BSD-2-Clause-C1: 단독으로소프트웨어사용 139 6.4.11 BSD-2-Clause-C2: 수정하지않은소프트웨어를소스코드형태로배포 140 6.4.12 BSD-2-Clause-C3: 수정하지않은소프트웨어를바이너리형태로배포 140 6.4.13 BSD-2-Clause-C4: 수정한프로그램을소스코드형태로배포 141 6.4.14 BSD-2-Clause-C5: 수정한프로그램을바이너리형태로배포 141 6.4.15 BSD-2-Clause-C6: 수정한라이브러리를독립적인소스코드형태로배포 142 6.4.16 BSD-2-Clause-C7: 수정한라이브러리를독립적인바이너리형태로배포 142 6.4.17 BSD-2-Clause-C8: 수정한라이브러리를임베디드소스코드형태로배포 143 6.4.18 BSD-2-Clause-C9: 수정한라이브러리를임베디드바이너리형태로배포 144 6.4.19 논의및설명 144 6.5 CDDL 라이선스소프트웨어 [ 추후보완 ] 146-3 -
6.5.1 CDDL-1: 단독으로소프트웨어사용 147 6.5.2 CDDL-2: 수정하지않은소프트웨어를소스코드형태로배포 147 6.5.3 CDDL-3: 수정하지않은소프트웨어를바이너리형태로배포 147 6.5.4 CDDL-4: 수정한프로그램을소스코드형태로배포 148 6.5.5 CDDL-5: 수정한프로그램을바이너리형태로배포 148 6.5.6 CDDL-6: 수정한라이브러리를독립적인소스코드형태로배포 148 6.5.7 CDDL-7: 수정한라이브러리를독립적인바이너리형태로배포 149 6.5.8 CDDL-8: 수정한라이브러리를임베디드소스코드형태로배포 149 6.5.9 CDDL-9: 수정한라이브러리를임베디드바이너리형태로배포 149 6.5.10 논의및설명 150 6.6 EPL-1.0 라이선스소프트웨어 150 6.6.1 EPL-1.0-C1: 단독으로소프트웨어사용 151 6.6.2 EPL-1.0-C2: 수정하지않은소프트웨어를소스코드형태로배포 152 6.6.3 EPL-1.0-C3: 수정하지않은소프트웨어를바이너리형태로배포 152 6.6.4 EPL-1.0-C4: 수정한프로그램을소스코드형태로배포 153 6.6.5 EPL-1.0-C5: 수정한프로그램을바이너리형태로배포 154 6.6.6 EPL-1.0-C6: 수정한라이브러리를독립적인소스코드형태로배포 155 6.6.7 EPL-1.0-C7: 수정한라이브러리를독립적인바이너리형태로배포 156 6.6.8 EPL-1.0-C8: 수정한라이브러리를임베디드소스코드형태로배포 157 6.6.9 EPL-1.0-C9: 수정한라이브러리를임베디드바이너리형태로배포 158 6.6.10 논의및설명 159 6.7 EUPL-1.1 라이선스소프트웨어 161 6.7.1 EUPL-1.1-C1: 단독으로소프트웨어사용 162 6.7.2 EUPL-1.1-C2: 수정하지않은소프트웨어를독립적인소스코드형태로배포 162 6.7.3 EUPL-1.1-C3: 수정하지않은소프트웨어를독립적인바이너리형태로배포 163 6.7.4 EUPL-1.1-C4: 수정하지않은라이브러리를임베디드소스코드형태로배포 164 6.7.5 EUPL-1.1-C5: 수정하지않은라이브러리를임베디드바이너리형태로배포 164 6.7.6 EUPL-1.1-C6: 수정한프로그램을소스코드형태로배포 165 6.7.7 EUPL-1.1-C7: 수정한프로그램을바이너리형태로배포 166 6.7.8 EUPL-1.1-C8: 수정한라이브러리를독립적인소스코드형태로배포 167 6.7.9 EUPL-1.1-C9: 수정한라이브러리를독립적인바이너리형태로배포 168 6.7.10 EUPL-1.1-CA: 수정한라이브러리를임베디드소스코드형태로배포 169 6.7.11 EUPL-1.1-CB: 수정한라이브러리를임베디드바이너리형태로배포 169 6.7.12 논의및설명 170 6.8 GPL 라이선스소프트웨어 172 6.8.1 GPL-2.0-C1: 단독으로소프트웨어사용 173 6.8.2 GPL-2.0-C2: 수정하지않은소프트웨어를독립적인소스코드형태로배포 173 6.8.3 GPL-2.0-C3: 수정하지않은소프트웨어를독립적인바이너리형태로배포 174 6.8.4 GPL-2.0-C4: 수정하지않은라이브러리를임베디드소스코드형태로배포 175-4 -
6.8.5 GPL-2.0-C5: 수정하지않은라이브러리를임베디드바이너리형태로배포 176 6.8.6 GPL-2.0-C6: 수정한프로그램을소스코드형태로배포 177 6.8.7 GPL-2.0-C7: 수정한프로그램을바이너리형태로배포 177 6.8.8 GPL-2.0-C8: 수정한라이브러리를독립적인소스코드형태로배포 179 6.8.9 GPL-2.0-C9: 수정한라이브러리를독립적인바이너리형태로배포 180 6.8.10 GPL-2.0-CA: 수정한라이브러리를임베디드소스코드형태로배포 181 6.8.11 GPL-2.0-CB: 수정한라이브러리를임베디드바이너리형태로배포 182 6.8.12 GPL-3.0-C1: 단독소프트웨어사용 183 6.8.13 GPL-3.0-C2: 수정하지않은소프트웨어를독립적인소스코드형태로배포 183 6.8.14 GPL-3.0-C3: 수정하지않은소프트웨어를독립적인바이너리형태로배포 184 6.8.15 GPL-3.0-C4: 수정하지않은라이브러리를임베디드소스코드형태로배포 185 6.8.16 GPL-3.0-C5: 수정하지않은라이브러리를임베디드바이너리형태로배포 185 6.8.17 GPL-3.0-C6: 수정한프로그램을소스코드형태로배포 186 6.8.18 GPL-3.0-C7: 수정한프로그램을바이너리형태로배포 187 6.8.19 GPL-3.0-C8: 수정한라이브러리를독립적인소스코드형태로배포 188 6.8.20 GPL-3.0-C9: 수정한라이브러리를독립적인바이너리형태로배포 189 6.8.21 GPL-3.0-CA: 수정한라이브러리를임베디드소스코드형태로배포 190 6.8.22 GPL-3.0-CB: 수정한라이브러리를임베디드바이너리형태로배포 191 6.8.23 논의및설명 192 6.9 LGPL 라이선스소프트웨어 196 6.9.1 LGPL-2.1-C1: 단독으로소프트웨어사용 197 6.9.2 LGPL-2.1-C2: 수정하지않은소프트웨어를독립적인소스코드형태로배포 198 6.9.3 LGPL-2.1-C3: 수정하지않은소프트웨어를독립적인바이너리형태로배포 198 6.9.4 LGPL-2.1-C4: 수정하지않은라이브러리를임베디드소스코드형태로배포 199 6.9.5 LGPL-2.1-C5: 수정하지않은라이브러리를임베디드바이너리형태로배포 200 6.9.6 LGPL-2.1-C6: 수정한프로그램을소스코드형태로배포 201 6.9.7 LGPL-2.1-C7: 수정한프로그램을바이너리형태로배포 201 6.9.8 LGPL-2.1-C8: 수정한라이브러리를독립적인소스코드형태로배포 202 6.9.9 LGPL-2.1-C9: 수정한라이브러리를독립적인바이너리형태로배포 202 6.9.10 LGPL-2.1-CA: 수정한라이브러리를임베디드소스코드형태로배포 203 6.9.11 LGPL-3.0-CB: 수정한라이브러리를임베디드바이너리형태로배포 204 6.9.12 LGPL-3.0-C1: 단독으로소프트웨어사용 206 6.9.13 LGPL-3.0-C2: 수정하지않은소프트웨어를독립적인소스코드형태로배포 206 6.9.14 LGPL-3.0-C3: 수정하지않은소프트웨어를독립적인바이너리형태로배포 207 6.9.15 LGPL-3.0-C4: 수정하지않은라이브러리를임베디드소스코드형태로배포 208 6.9.16 LGPL-3.0-C5: 수정하지않은라이브러리를임베디드바이너리형태로배포 208 6.9.17 LGPL-3.0-C6: 수정한프로그램을소스코드형태로배포 209 6.9.18 LGPL-3.0-C7: 수정한프로그램을바이너리형태로배포 210 6.9.19 LGPL-3.0-C8: 수정한라이브러리를독립적인소스코드형태로배포 211-5 -
6.9.20 LGPL-3.0-C9: 수정한라이브러리를독립적인바이너리형태로배포 212 6.9.21 LGPL-3.0-CA: 수정한라이브러리를임베디드소스코드형태로배포 213 6.9.22 LGPL-3.0-CB: 수정한라이브러리를임베디드바이너리형태로배포 214 6.9.23 논의및설명 215 6.10 MIT 라이선스소프트웨어 219 6.10.1 MIT-C1: 단독으로소프트웨어사용 220 6.10.2 MIT-C2: 수정하지않은소프트웨어배포 220 6.10.3 MIT-C3: 수정한프로그램배포 221 6.10.4 MIT-C4: 수정한라이브러리를독립적으로배포 221 6.10.5 MIT-C5: 수정한라이브러리를임베디드컴포넌트로배포 222 6.10.6 논의및설명 223 6.11 MPL-2.0 라이선스소프트웨어 223 6.11.1 MPL-2.0-C1: 단독으로소프트웨어사용 224 6.11.2 MPL-2.0-C2: 수정하지않은소프트웨어를소스코드형태로배포 225 6.11.3 MPL-2.0-C3: 수정하지않은소프트웨어를바이너리형태로배포 225 6.11.4 MPL-2.0-C4: 수정한프로그램을소스코드형태로배포 226 6.11.5 MPL-2.0-C5: 수정한프로그램을바이너리형태로배포 227 6.11.6 MPL-2.0-C6: 수정한라이브러리를독립적인소스코드형태로배포 228 6.11.7 MPL-2.0-C7: 수정한라이브러리를독립적인바이너리형태로배포 229 6.11.8 MPL-2.0-C8: 수정한라이브러리를임베디드소스코드형태로배포 230 6.11.9 MPL-2.0-C9: 수정한라이브러리를임베디드바이너리형태로배포 231 6.11.10 논의및설명 233 6.12 Microsoft Public 라이선스 234 6.12.1 MS-PL-C1: 단독으로소프트웨어사용 235 6.12.2 MS-PL-C2: 수정하지않은소프트웨어배포 235 6.12.3 MS-PL-C3: 수정한프로그램을소스코드형태로배포 237 6.12.4 MS-PL-C4: 수정한프로그램을바이너리형태로배포 237 6.12.5 MS-PL-C5: 수정한라이브러리를독립적인소스코드형태로배포 237 6.12.6 MS-PL-C6: 수정한라이브러리를독립적인바이너리형태로배포 238 6.12.7 MS-PL-C7: 수정한라이브러리를임베디드소스코드형태로배포 238 6.12.8 MS-PL-C8: 수정한라이브러리를임베디드바이너리형태로배포 239 6.12.9 논의및설명 239 6.13 PostgreSQL 라이선스소프트웨어 240 6.13.1 PostgreSQL-C1: 단독으로소프트웨어사용 241 6.13.2 PostgreSQL-C2: 수정하지않은소프트웨어배포 241 6.13.3 PostgreSQL-C3: 수정한프로그램배포 241 6.13.4 PostgreSQL-C4: 수정한라이브러리를독립적으로배포 242 6.13.5 PostgreSQL-C5: 수정한라이브러리를임베디드컴포넌트로배포 242 6.13.6 논의및설명 243-6 -
6.14 PHP-3.0 라이선스소프트웨어 243 6.14.1 PHP-3.0-C1: 단독으로소프트웨어사용 244 6.14.2 PHP-3.0-C2: 수정하지않은소프트웨어를소스코드형태로배포 244 6.14.3 PHP-3.0-C3: 수정하지않은소프트웨어를바이너리형태로배포 245 6.14.4 PHP-3.0-C4: 수정한프로그램을소스코드형태로배포 246 6.14.5 PHP-3.0-C5: 수정한프로그램을바이너리형태로배포 246 6.14.6 PHP-3.0-C6: 수정한라이브러리를독립적인소스코드형태로배포 247 6.14.7 PHP-3.0-C7: 수정한라이브러리를독립적인바이너리형태로배포 247 6.14.8 PHP-3.0-C8: 수정한라이브러리를임베디드소스코드형태로배포 248 6.14.9 PHP-3.0-C9: 수정한라이브러리를임베디드바이너리형태로배포 249 6.14.10 논의및설명 250 7 결론 251 8 부록 253 8.1 OSLiC 인용스타일에관한몇가지추가설명 253 8.2 일부오픈소스에관한오해 254 8.2.1 이유 (Why) 256 8.2.2 무엇 (What) 263 간행물, 쇼트컷, 약어 265 참고문헌 268-7 -
주요부분 작업목록에 AL, AFL, CDDL, MPL-1.[0 1], MS-RL, OSL 삽입 소프트웨어개발측면에서파생저작물 (derivative work) 개념설명을개선 / 정리 proapse를 snimoli 및 v.v로변환하는수정사항다루기 라이선스호환성논의 오픈소스와수익간의관계설명 간행물리스트업데이트
표 0.1: 오픈소스라이선스해설 (Open Source License Compendium) 진행경과 2015-03-01 1.0.0 발표 AGPL관련 6번째문항추가 OSUC-03에 AGPL 서브타입 L(ocal) & I(nternet) 내용추가 AGPL 파인더및라이선스준수과업목록추가 2015-01-21 0.99.9 리버스엔지니어링도전에대한솔루션추가 2014-03-09 0.99.1 LATEXsource로부터 OSCAd사용용도로데이터파일생성 LGPL C9 사례의버그수정 6장의일반적인수정 2014-01-08 0.98.2 CDDL 내특허관련문구에대한섹션추가 PDF 파일에하이퍼링크추가 (hyperref, pdftex 사용 ) 1장부터 5장까지일반적인수정 2013-11-27 0.98.1 한국 FLOSS 컨퍼런스발표 2013-08-19 0.97.2 M.Schierl이제안한오타수정 파생저작물관련내용추가 OSLiC은프로토타입사례에대해다룬다는내용추가 2013-07-28 0.97.1 간접적으로사용된 2차문헌추가 LGPL 특성파인더개선 OSCAd와일치, 인터페이스개선 2013-05-20 0.96.1 Linux Days 발표 오픈소스사용사례라이선스특정사용사례명명변경 OSCAd 컨텐츠와버전일치 2013-04-15 0.95.2 유럽자유소프트웨어재단 (FSFE) LLW 후발표 알려진대부분의 OSI 라이선스의과업목록 (to-do list) 향상된 GPL과 EUPL 파인더 간소화된형태와개선된구조로된 OSLiC 파인더 통합된부문과간행된신규원본 2013-04-05 0.95.1 FSFE LLW 전발표 허용되는모든약한효력의카피레프트라이선스의과업목록 통합된부문과간행된신규원본 2013-03-15 0.94.1 Chemnitzer Linux Day 공개 허용되는모든 week copyleft 라이선스의과업목록 부문통합과신규원본간행 2013-03-08 0.90.1 CeBIT 공개 추가된일부주요라이선스의과업목록 부문통합과신규원본간행 2013-02-16 0.8.90 CeBIT 전공개 주요라이선스이행사항에중점을두어새로논의되는구조 새로이가름하는라이선스검토 하향식의새서론내용 2012-12-28 0.8.0 내부연말 (EOY) 공개 branch kreinck에통합된편재되어있는대다수의개선사항 2012-08-25 0.5.2 공개를통한변경내용확장 MIT 라이선스를충족시키는과업목록 Eclipse 스펠체킹방법사용 2012-07-06 0.4.0 공개를통한변경내용 오픈소스사용사례정의및분류체계 오픈소스사용사례에입각한파인더 해당 BSD 특정미니파인더 BSD 라이선스를충족하는과업목록
2012-03-22 0.2.1 커뮤니티초판으로간행된골자 2012-01-31 0.1.8 머리말로기존의서론에관한재차설명 더간략하게하향식으로작성된서론삽입 OSLiC 경고문삽입 osccopiedbutnotread.bib 확대 정기간행물및쇼트컷리스트추가 많은문헌데이터추가 2011-09-29 0.1.4 문서이력통합 오자삭제 영어교사의리뷰포함 John의개선의견포함 2011-09-12 0.1.0 서론정리 : 목적및방법 - 10 -
경고문 본저작물은오픈소스커뮤니티와공동작업을통해앞으로도충분히더보완되어야한다. 그리고궁극 적으로 한마리의물고기보다무리의물고기가더많이알고있다 는통찰력을인정하는인식위에서 신뢰할만한정보가전달되어야한다. 그럼에도불구하고본문서 (OSLiC, Open Source License Compendium) 는저자와기고자들이제시하는의견이상을제공할수는없다. 본해설서의목적은오픈소스라이선스에대한논의를단지한목소리로전달하는것이다. 저자와기고자를보상청구및피소로부터보호하기위해약간의수정을거친 GPL3 경고문을채택하였다 : 본문서 (OSLiC) 는법률적용에의해허용되는범위까지어떤보증도제공되지않는다. 저작권소유자및기타당사자들은특정용도에대한적합성과상품성을은연중에보증하는것을포함하여명시적이든묵시적이든보증하지않고 있는그대로 내용을제공하는것이다. 본문서 (OSLiC) 의품질과이행과관련되는전체리스크는사용자가부담하여야한다. 본문서 (OSLiC) 에결함이있는것으로판단되면사용자는필요한모든정비, 정정또는수정에대한비용을부담하여수정할수있다. 적용가능한법률에의해요구되거나서면합의가이루어지지않는한어떠한경우에도저작권자와본문서 (OSLiC) 를수정및제공하는기타당사자는손해배상가능성에대해통지를받았더라도본문서 (OSLiC) 를사용하거나 ( 자료의손실, 부정확하게제공되는자료, 사용자나제3자가입는손실, 다른의미의기술과본문서상의잘못인용등을포함하는 ) 사용불능으로인해발생하는일반적, 특수적, 부수적, 결과적손해를포함하여손해배상에대한책임을지지않는다. 특히본문서 (OSLiC) 는사용자에게있어서변호사에의한법률조언또는법적검토를대신할수없고 대체될수없다. 그러나법적상담인이 1) 최종적으로검토해야하는해결방법을찾는데개발자, 관리자, 오픈소스전문가및기업에게기여할수는있다. 1) 독일독자의경우 : OSLiC 는물론독일의 비사법적법률서비스에관한법률 (RDG, Rechtsdienstleistungsgesetz) 을중요시한다. 일반대중에게언급하는법적의견을담고있을뿐이다. OSLiC 는일반대중에게법적문제와관련된정보를전달하기기위한목적으로만사용하는것으로서이해할수있다.
1 서론 이번장에서는 OSLiC 의기본개념, 사용방법및실제로이해할수있는방법에대해간략하게설명한다. 이문서는 우리가사용하고있는오픈소스소프트웨어의라이선스에따라행동하기위해필요한것은무엇인가? 라는오직한가지주제에만초점을맞춘다. 오픈소스라이선스해설 (Open Source License compendium) 은이질문에간단하고쉽게방법을이해하는방향으로신뢰성있는답변을하는것을목적으로한다. 그러나본해설서는다른일반적인오픈소스에관한문서들과는다르다. 2) 오히려라이선스준수를위한활동을단순화하기위한도구가되는것이그의도이다. 본해설서는도이치텔레콤 ( 주 ) 의일부소프트웨어개발자및프로젝트관리자들이직면한과제에대응하기위해필요에의해작성되었다. 물론회사자체는직원들이라이선스에부합되게행동하길원하지만유감스럽게도회사내에서사용하는일부오픈소스라이선스에부합하기위해정확히해야할일을간단히열거한참조문을찾을수없었다. 텔레콤프로젝트의동료들및심지어 OSLiC의초기저자인우리들의경우에도오픈소스소프트웨어를사용하고각각의라이선스를준수하기위해서오픈소스라이선스전문가가되기를원하지않았다. 또한우리는변호사도되고싶지않았다. 단지그당시에대부분의시간과자원이요구되었던일을보다효과적으로수행하기를원했다. 우리는오픈소스라이선스의정글속에서올바른방향을결정하는것대신에프로젝트별로그리고반복적으로사용할수있는명확한지침을찾는중이었다. 우리는성능을향상시키는고품질의오픈소스를사용하는것을매우선호했다. 그리고우리는이를합법적으로사용하기를원했다. 하지만우리는많은다른오픈소스라이선스의법적제약에대해힘들게논의하는것은원하지않았다. 우리가필요로하는것은하나의사용하기쉬우면서직접적으로실행가능한목록을나열하는문건이었다. 우리만의쓰임새와라이선스에맞는과업목록 (to-do list) 을얻고싶었다. 우리는오픈소스라이선스를준수했음을확신하기위한신뢰할만한작업목록이필요했다. 우리가처음시작했을때는그런개론은존재하지않았다. 이문제를해결하기위해우리회사는세가지를결정을내렸다 : 2) 반면에오픈소스를다루는글들이무수히많다. 이러한책들과기사들을통해지식을넓히려고시도하는것은그글속에파묻혀의미를잃어버릴가능성이있다 : 우리의 2차문헌목록은이러한 압도당할위험 을개략적으로알려주고있다. 하지만그럼에도불구하고 OSLiC의마지막에있는도서목록은전부가될수없다. 심지어그것을완성하려는의도도없다. 그것은단지배경지식을명확히표시하기위한용도이며, OSLiC에서직접인용하지않는다. 만약우리가오픈소스 ( 라이선스 ) 주제에대해좋은개요를얻기위해두권의책을제시해야한다면우리는다음과같이표기할것이다. (a) the Rebel Code (for a Germanversion cf. Moody, Glyn: Die Software-Rebellen. Die Erfolgsstory von Linus Torvalds undlinux; transl. from the American [edition, 2000] by Annemarie Pumpering; Landsberg am Lech: verlag moderne industrie, 2001, ISBN 3 478 38730 2, passim for an Englishversioncf. Moody,Glyn:RebelCode:LinuxAndTheOpenSourceRevolution;[NewYork]:BasicBooks,2002,ISBN978 07382067 07,p.passim) 그리고 (b)the legalbasicconditions (cf.jaeger,tilla.axelmetzger:opensourcesoftware.rechtlicher ahmenbedingungenderfreiensoftware;3rdedition. Mu nchen: VerlagC.H.Beck, 2011,passim). 하지만우리는다행이도그렇게하도록강요당하지않았다.( 배경지식이외에는의존하지않았다 ) - 12 -
첫번째결정은오픈소스라이선스전문가위원회로활동하도록소규모의직원들을지원하는것이었다. 그들은회사전체를위한서비스를제공해야한다. 프로젝트들, 매니저들, 그리고개발자들은그들이특정환경에처해있을때오픈소스라이선스를준수하기위해해야할일들에대해이위원회에질문을할수있어야한다. 그리고이위원회는요청자가해당오픈소스라이선스에따라행동하고있음을확신할수있는신뢰성있는과업목록을제공해야한다. 이결정의배경은간단했다. 모든새로운프로젝트에대해반복적으로개발자를선택 ( 및교육 ) 해야하는대신하나의중앙전문가그룹이있는경우비용을절감하고품질을향상시킬수있다는것이다. 그래서 OSRB(the Telekom Open Source Review Board, 텔레콤오픈소스검토위원회 ) 는자기구성적이고상향식으로운영되는커뮤니티로서초기의전문가그룹으로설립되었다. 우리회사가취한두번째결정은텔레콤오픈소스검토위원회가체계적으로위원회의결과물들을재사용가능한해설서의형태로수집하게하는것이다. 이결정의개념또한간단했다. 내부서비스가알려질수록작업량은증가할것이며작업이많을수록리소스가많아지고비용이높아진다. 따라서본해설서는비용을절감하고요청자들이라이선스전문가가되지않고서도스스로그답을찾을수있게만드는것이다. 모든기본사례에서그들의작업에대해 OSRB에서분석한결과를요청하는것대신에스스로해설서에서답을찾아야만했다. 그렇게함으로서기획된텔레콤오픈소스해설서는향후위원회가방대해지는것을예방할것이다. 우리회사가취한세번째결정은텔레콤오픈소스검토위원회가오픈소스프로젝트를일반적으로사용하는협력방식으로해설서를작성하도록하는것이었다. 이결정의이유는간단했다. 대체적으로추후에오픈소스검토위원회에의해검토되는것이아니라간단한매뉴얼을통해프로젝트, 프로그래머및관리자들의오픈소스라이선스준수를보장해야한다면이해설서는특히더신뢰성이있어야한다. 오픈소스작업모델에는협력공동체의지속적인검토가품질을향상시킨다는이미잘알려진특징이있다. 따라서내부 텔레콤 (Telekom) 유인물 을작성하는것뿐만아니라전체커뮤니티가더광범위한오픈소스라이선스해설을사용, 수정및재배포할수있도록하는결정은품질향상을위한것이었다. 결과적으로오픈소스검토위원회는 OSLiC를일련의 LATEXsources로발표하기로결정했으며공개저장소인 GitHub를통해출간하기로했다. 3) 그리고 OSLiC는크리에이티브커먼즈저작자표시-동일조건변경허락 3.0 독일라이선스를적용하기로했다. 4) 하지만 OSLiC 를무료책으로출간하는것은 ( 적어도텔레콤오픈소스검토위원회에있어서는 ) 수년동 안많은직원과회사의삶을풍요롭게하고단순화시킨오픈소스커뮤니티에감사의뜻을전하는또다 른중요한의미가내포되어있다. 3) 다음링크를통해코드를받을수있으며 https://github.com/dtag-dbu/oslic; 프로젝트정보는 http://dtag-dbu.github.com/oslic/ 또는 http://www.oslic.org/ 에서찾을수있다. 4) 본내용은크리에이티브커먼즈저작자표시 - 동일조건변경허락 (Creative Commons Attribution-ShareAlike) 3.0 독일라이선스에의해사용이허가된다. 본문서와동일하거나유사한라이선스에의한저작물을배포 하고 저자가지정한방식의저작물로중시 한다면제약없이 공유 ( 복제, 배포및전송 ) 또는 수정 ( 개작 ) 을할수있다. 인터넷에서재사용시적절한방식으로최초저자들을언급하고, 이들의스폰서인도이치텔레콤 ( 주 ) 의명칭을제시하며 http://www.telekom.com 링크를적용하기바란다. 문서유형으로재사용시문서에 http://www.telekom.com, 최초저자그리고스폰서인도이치텔레콤 ( 주 ) 에대해간략하게소개하기바란다. 일반적인인용문의경우에는과학표준방식을사용한다. - 13 -
전체적으로 OSLiC 는 5 가지의원칙을따른다. 과업목록 (To-do lists) 을중심으로논의 : 오픈소스소프트웨어및라이선스를구체적으로사용하는법에대한정보수집을위해간단한양식에기초하여 OSLiC에서는각각의과업목록 (To-do lists) 을제공한다. 그리고, 요청자들이라이선스준수를할수있도록인도하는사용이용이한파인더를제공하도록한다. 또한, OSLiC의이러한모든요소는사용법자체를방해하지않고이해하기쉽도록소개되고논의되어야한다. 철저하게명확한출처를포함하는인용문 : OSLiC 는개정가능하고신뢰할수있어야한다. 그것은누가 왜어떤정보를누구로부터, 어떤버전에서그리고왜사용하는지를총체적으로언급하고명시해야한다. 5) 숲을개간하지않지만풀을베어길을내기 : OSLiC 는라이선스와그것의법적인특징에대해다루어야만 한다. 하지만이는모든세부적인측면을다룬다는것은아니다. 다른대안 6) 이있을수있더라도특정사용 사례에서의라이선스에따라가능한이행방법에초점을두어야한다. 라이선스문구의내용을신중히고려하기!: OSLiC에서는법적논의에관한전반적인설명을제공하지않아야하며여기에관여하지않아야한다. 여기에서는라이선스를준수하기위해각각의라이선스와사용사례를위한신뢰할수있는한가지방법만을찾는것이어야한다. 이런분석의주요출처에서는오픈소스라이선스를정확히이해하고있어야한다. ( 자선변호사및합리적인주장을펼치는소프트웨어개발자의해석에의해뒷받침되거나그에근거하는 ). OSLiC에서는소프트웨어개발자를대상으로때로는개발자에의해오픈소스라이선스가작성된다는점을중요시한다. 군중에대한신뢰!: OSLiC 는도이치텔레콤 ( 주 ) 의직원이아닌다른사람들에의해장려되고고무되는개 선및조정을위해개방되어있어야한다. 이런원칙에입각하여 OSLiC 를사용하는두가지방법을제공한다. 5) 이를위해우리는주석이나힌트를내포하는대신에 구식 문헌스타일의각주를사용한다. 우리는사용자가원하는대로댓글과힌트를검토또는무시할수있도록하고싶지만대규모의내포된댓글이나잦은페이지전환으로인한방해를받지않고모든의견과힌트를검토하거나무시할수있게했다. 현대작가가이드에서는덜요란한스타일을선호한다는점은알고있다.(pars pro toto cf. MLA: MLA Handbook for Writers of Research Papers; 7th edition.new York: The Modern Language Association of America, 2009, ISBN978 1 60329 024 1,passim) 하지만인터넷출처의잦은변경때문에제기되는신뢰성있는활용을원할경우이방법은여전히다소부정확하다 ( 세부사항 OSLiC, pp.308. OSLiC 인용스타일에관한몇가지추가설명에서이방법을쓴동기참조 ) cf. Reincke, Karsten: Classical Scholar Texts WithFootnotes based on LaTeX, BibTeX, Koma, jurabib and mykeds-csr; 2012 (URL: http://www.fodina.de/en/closedprojects/latex-addons/classical-scholar.html) reference download: 2013-02-10, passim. For a more elaborated legitimizing versioncf. Reincke, Karsten: (Geistes-) Wissenschaftliche Texte mit jurabib. Dienst am Leser, Dienstam Scholaren: Uber Anmerkungsapparate in Fußnoten - aber richtig. [n.l.], 2012(URL: http://download.fodina.de /fodina ClassicalScholarFoNoDe.pdf) reference download: 2013-02-10, passim). 6) OSLiC는특정필요성에관련하여프로젝트에대해조언하지않는다. 이는변호사와법률전문가의업무로남아야한다. OSLiC는변호사의법적조언또는법적검토를대신할수없고대체되지않는다. 이내용은개발자, 관리자, 오픈소스전문가및회사가최종적으로법률고문이검토해야하는해결법을찾는데기여하도록한다. 독일독자들에게다시반복하지만 OSLiC는물론독일의 비사법적법률서비스에관한법률 (Rechtsdienstleistungsgesetz) 을존중한다. 단지이문서는일반대중에게언급하는법적의견을담고있을뿐이다. 다만법적문제에대한표현과토론에대한단순한보편적접근을지향하는선에서이해되기를바란다.( nur an die Allgemeinheit gerichtete Darstellung und ErörterungvonRechtsfragen ). - 14 -
다른무엇보다도독자들은자신들이꼭필요로하는과업목록을쉽고빠르게찾기를기대한다. 다음 그림이그절차이다. 7) 7) 잘알려진 빠르고야비한해커 에관해서는 ( 우리또한그런경향이있지만 ) 여기서편법 ( 손쉬운방법 ) 을포함시켰다. 사용하고자하는오픈소스패키지라이선스를이미알고여기서정의한오픈소스사용사례의의미에매우정통하다면 5.1 장의 OSLiC 5 가지질의양식, 분류적오픈소스사용사례파인더또는오픈소스사용사례로고심하지않고 6 장에있는해당라이선스에대한설명으로바로건너뛸수있다. 상세하게오픈소스라이선스만을다룬일부장은일련의라이선스별사용사례를제공하는라이선스특정탐색기로부터시작한다. 단, 라이선스의복잡성에따라일부의경우골자만남길수는있다. 이방법의단점은 OSLiC 가체계적으로안내하는과정없이스스로사용사례에관한지식을적용해야하며부작용이있을수있다는것이다. - 15 -
두번째, 독자들은전체분석내용을이해하고싶어할지도모른다. 따라서여기에서는라이선스를준 수하는행동의기초로서오픈소스라이선스분류체계에대해간략히논의한다. 8) 그리고, 오픈소스라이 선스에따르는일부부작용을고려한다. 9) 최종적으로오픈소스사용사례구조에대해학습한다. 10) 많은사람의많은소망인 행복한 ( 합법적인 ) 해킹! 이담고있는사용, 변경, ( 재 ) 배포를강조하면서이 서론을마치고자한다. 8) OSLIC 2. 오픈소스 : 동일한관념, 여러다른라이선스, 17 쪽 9) OSLiC 3. 오픈소스 : 일부부작용에대하여 ), 43 쪽 10) OSLiC 4. 오픈소스사용사례 : 개념과분류체계, 88 쪽 - 16 -
2 오픈소스 : 동일한관념, 다양한라이선스 이장에서는자유오픈소스소프트웨어에관해서같은목적을갖는다양한라이선스모델을설명하고자한다. 먼저우리는라이선스들을그룹화하는기존방법들의한계에관해논하려한다. 기존의그룹은실제라이선스사례에따라행동하기위한간단한조건들을제공하는 가상의프로토타입라이선스 라는의미로종종사용되었다. 하지만, 우리가지켜야하는것은이런그룹들의일반적인조건들이아닌각라이선스들의세부조건들이다. 그럼에도불구하고우리는오픈소스라이선스들을구조화하는새로운방식을제시하려한다. 각라이선스들은어떠한대상 ( 사람또는단체 ) 으로부터다른대상을지키기위한목적들을갖게되는데우리는이목적들을기준으로공통된그룹을나눌것이다. 이러한패턴을통해서우리는실제로모든오픈소스라이선스들을그룹화할수있다. 오픈소스라이선스그룹화 11) 는일반적으로진행되었다. 일련의오픈소스라이선스 12) 는그자체로이미여러그룹화기준에의해정해진한무리이다. 오픈소스라이선스가되기원하는각소프트웨어라이선스들 [ ] 는반드시 [ ] 조건을따라야함 은오픈소스정의 (Open Source Definition, OSD) 13) 에포함되는 배포조건 을가지게된다. 각라이선스들은 Open Source Initiative(Open Source Initiative) 14) 에의해관리가되는 OSD 기준으로분류가된다. 따라서 OSD는 비오픈소스라이선스그룹 15) 과 잠재적인오픈소스라이선스그룹 을구분하게된다. 자유소프트웨어라이선스 (Free Software License) 를그룹화하기위한또다른방법은 자유소프트웨어정의 (Free Software Definition, FSD) 에의해지정된다. 이자유소프트웨어정의는자유소프트웨어라이선스에의해충족되어야하는 4가지조건이포함된다. 자유소프트웨어정의에준하는라이선스에의해 어떠한목적을위해프로그램을실행하는자유, 작동방식을학습하고필요에맞게조정하는자유, 복제물을재배포하는자유, 그리고마지막으로 프로그램을개선하고개선사항을공개하는자유 16) 가허용되어야한다. 의외로이정의는소스코드는공개적으로이용이가능해야한다는요구사항이 유일하게 도출되는조건임을내포하고있다. 개선된버전을공표하는자유와변경할자유 가 의미가있어야 한다면 프로그램의소스코드이용 은전제조건이된다. 따라서소스코드이용가능성은자유소프트웨어의필수조건이된다. 17) 11) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스 ; 2012 [n.y.] (URL:http://opensource.org/licenses/alphabetical) - 참고자료다운로드 : 2013-01-22, wp. 참조 12) Open Source Initiative: Open Source Initiative; 2012 [n.y.] (URL: http://www.opensource.org/about/) - 참고자료다운로드 : 2013-01-22, wp. 참조 13) Open Source Initiative: 오픈소스정의 ; 2012 [n.y.] (URL: http://www.opensource.org/docs/osd) - 참고자료다운로드 : 2012-06-21, wp. 참조 14) 더정확하게는 : 오픈소스소프트웨어정의를충족하는것만이오픈소스라이선스가되기위한필수조건이다. 오픈소스라이선스가되기위한충분한조건은공식오픈소스라이선스승인과정을제공하는 OSI 로부터승인을받는것이다 (Open Source Initiative: [OSI] 라이선스검토프로세스 ; 2012 [n.y.] (URL: http://www.opensource.org/approval) - 참고자료다운로드 : 2013-01-22, wp 참조 ). 15) 조금더명확하게하자면, 오픈소스라이선스가되기위한필요조건은 OSD 를만족시키는것이다. 오픈소스라이선스가되기위한충분조건은 OSI 가제공하는공식절차를통과한오픈소스라이선스승인이다. (cf. Open Source Initiative: The [OSI] License Review Process; 2012 [n.y.] <URL: http://www.opensource.org/approval> - reference download: 2013-01-22, wp). 16) 리처드스톨만 : 자유소프트웨어정의, 1996, 41 쪽참조 17) 참고문헌참조 - 17 -
오픈소스소프트웨어정의와자유소프트웨어정의간의차이는종종강조의차이로설명되어왔다. 18) 두가지정의는 거의정확히동일한범위의소프트웨어를다루지만 자유소프트웨어재단 (Free Software Foundation) 은 자유사항을강조하길선호하고 Open Source Initiative(OSI) 는철학적으로무관한 개발방법론 을강조하길원한다. 19) 자유소프트웨어라이선스와자유소프트웨어그룹의세번째방법은 데비안사회계약 (Debian Social Contract) 에포함된 데비안자유소프트웨어가이드라인 에의해지정되었다. 데비안자유소프트웨어가이드라인은데비안자체로말해주듯이 9가지를정의하는기준을포함하며 오픈소스정의기준으로서자유 ( 문자그대로!) 소프트웨어커뮤니티에서채택 해왔다. 20) 이방법을대략적으로이해하면이 3가지정의가외연적으로동일하고내면적으로만다르다는결론에도달할수있다. 그러나사실이아니다. 차이를밝히기위해여러라이선스군 ( 群 ) 의차이를정할수있는것이무엇인지에대한질문을통해 Open Source Initiative 승인라이선스, 오픈소스소프트웨어정의에준하는라이선스, 데비안자유소프트웨어가이드라인에준하는라이선스및자유소프트웨어정의에준하는라이선스군 ( 群 ) 을외연적으로비교하였다. 21) 첫째, 가장결정하기쉬운차이는단방향으로포함되는것이다. 정의에의해 OSI(Open Source Initiative 승인 ) 라이선스와 OSD( 오픈소스소프트웨어정의 ) 에준한라이선스는 OSD( 오픈소스소프트웨어정의 ) 요구사항에부합한다. 22) 그러나 OSI(Open Source Initiative) 승인라이선스만이 OSI(Open Source Initiative) 의프로세스를성공적으로통과하였고 23) 이에따라정식으로오픈소스라이선스로실리게되었다. 24) 한편으로는 OSI(Open Source Initiative) 승인라이선스는오픈소스라이선스이며그반대의경우도마찬가지이다. 다른한편으로는 OSI(Open Source Initiative) 승인라이선스와오픈소스라이선스는 OSD ( 오픈소스소프트웨어정의 ) 에준한라이선스이지만그반대의경우는아니다. 둘째, 유사한논증을통해 DFSG( 데비안자유소프트웨어가이드라인 ) 에준한라이선스와 OSI(Open Source Initiative) 승인라이선스를구별할수있다. 언급한대로 OSD( 오픈소스소프트웨어정의 ) 는 데비안자유소프트웨어가이드라인에기반을두고있고하나의정의에부합하는어떤라이선스는거의다 18) 이는또한리처드스톨만 (Richard M. Stallman) 의관점이다. 한편으로그는 자유소프트웨어운동 과 오픈소스운동 은일반적으로 기본원칙은차이가있지만실제권장사항은다소일치한다. 그리고 오픈소스운동을적으로생각하지않는다. 고명시하였다. 다른한편으로는오픈소스운동의경우, 소프트웨어가오픈소스가되어야하는이슈는실제적문제이지윤리적문제가아니며, 자유소프트웨어운동의경우비자유소프트웨어는사회문제이고자유소프트웨어가해결책 이라고언급하여두가지운동에대해기술하였다.( 자유소프트웨어자유사회 에실린리처드스톨만의 자유소프트웨어가 오픈소프트웨어 보다나은이유 (Why Free Software is Better than Open Software ), 1998 년최초작성, 55 쪽참조 ). 스톨만은간단한방법으로견해를간략히제시하였다. 오픈소스 는사용자들이자유를누려야한다는의견을제기하려는목적으로고안되지않았다. 그러나친구들은 자유에대한생각을퍼뜨리고 이에따라 자유소프트웨어 를고수하길 원한다 ( 상기인용글과동일, 59 쪽 ). 이의견을다시짚어보면 오픈소스는개발방법론이고자유소프트웨어는 윤리적의무 에근간하는사회운동이다. 라고표현하고있다. Commununications of the ACM 6 월호에실린리처드스톨만의 관점 : 오픈소스 에는자유소프트웨어관점이생략된이유 (Viewpoint: Why Open Source Misses the Point of Free Software), 2009 년 6 월참조. (URL: ttp://doi.acm.org/10.1145/1516046.1516058) - 참고자료다운로드 : 2011-12-29, 31 쪽 19) Debian( 데비안 ): 데비안자유소프트웨어가이드라인 (DFSG); 2013 [n.y.] (URL: http://www.debian.org/social_contract#guidelines) 참조 - 참고자료다운로드 : 2013-01-22, p.wp. 20) Debian( 데비안 ): 데비안자유소프트웨어가이드라인 (DFSG); 2013 [n.y.] (URL: http://www.debian.org/social_contract#guidelines) 참조 - 참고자료다운로드 : 2013-01-22, p.wp. 21) 실제로존재하는라이선스의부분집합은확대될수있고정의에맞는신규라이선스로개발될수있으므로정의에대한외연적기능을분석하기위해가능한표준에준한모든라이선스를고려해야한다. 22) Open Source Initiative: 오픈소스정의, 2012, wp. 참조 23) 참고문헌참조 24) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 - 18 -
른정의에부합한다. 25) 그러나정의에부합한다는것은정식오픈소스라이선스가되기에불충분하다. 라이선스는 OSI(Open Source Initiative) 로부터승인을받아야한다. 26) 따라서 Open Source Initiative 승인라이선스또한데비안자유소프트웨어가이드라인에준한라이선스가되지만반대의경우는아니라는결론이나온다. 셋째, 수년간 27) 보여왔던 몇가지예외사항 을무시함으로서그들의 친척같은 (kinsmanlike) 관계때문에적어도오픈소스소프트웨어정의에준하는라이선스는데비안자유소프트웨어가이드라인에준하는라이선스이며그반대의경우도마찬가지이다. 마지막으로 ( 잠재적 ) 자유소프트웨어라이선스집합은다른모든 3 개집합보다커야한다. 한편으로는 FSD( 자유소프트웨어정의 ) 에따르면자유소프트웨어라이선스는소프트웨어를판독할수있는것뿐만아니라사용, 변경및배포가허용되어야한다. 28) 이조건은 자유로운재배포, 소스코드, 파생저작물 (Derived Work) 이라는주제와관련한처음 3 개의 OSD( 오픈소스소프트웨어정의 ) 단락에포함되어있다. 29) 한편, OSD( 오픈소스소프트웨어정의 ) 는 FSD( 자유소프트웨어정의 ) 에의해언급되지않는요구사항과 OSD( 오픈소스소프트웨어정의 ) 에준한라이선스로서의자격이되기위해라이선스에의해충족되어야하는요구사항을몇가지더포함한다. 30) 모든 FSD( 자유소프트웨어정의 ) 조건은충족하지만 OSD( 오픈소스소프트웨어정의 ) 에있는몇가지요구사항을따르지않는라이선스가존재할수있다는결론이나온다. 31) 따라서모든 ( 잠재적 ) 자유소프트웨어라이선스세트가모든 ( 잠재적 ) 오픈소스라이선스보다크고 OSD( 오픈소스소프트웨어정의 ) 에준한라이선스보다도커야한다. 이상황을아래그림과같이나타낼수있다. 25) 포겔 : 오픈소스소프트웨어작성, 2006, 233 쪽참조 26) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 27) 포겔 : 오픈소스소프트웨어작성, 2006, 233 쪽참조 28) 스톨만 : 자유소프트웨어정의, 1996, 41 쪽참조 29) Open Source Initiative: 오픈소스정의, 2012, wp. 참조 30) 예를들어, 라이선스는기술중립적이어야한다. 라는조건을참고한다 ( 위책과동일 ). 31) 다시언급하자면실제기존의라이선스집합이아닌외연적정의가능성을고려해야한다. 여기서, GPL, LGPL 또는 AGPL 과같은실제기존의모든자유소프트웨어를오픈소스라이선스로분류하는것은부적절하다. 여기서는 OSD( 오픈소스소프트웨어정의 ) 가아닌 FSD( 자유소프트웨어정의 ) 를이행하는라이선스를야기할수있다는사실을언급하고있다. - 19 -
위그림을보면오픈소스라이선스를분류하기위해더추가할군 ( 群 ) 이없을것이라는것을더길게설명하지않아도될것이다. 한편, 가장큰군 ( 群 ) 에서는오픈소스라이선스에관하여나타내고있지않는다. 반면에오픈소스라이선스군에서는라이선스를충족하기위해해야할행위가구체적으로명시되지않은단지오픈소스정의를기준으로한요소들만모았다. 다음레벨의오픈소스라이선스군 ( 群 ) 은 OSI(Open Source Initiative) 승인라이선스의내부구조와관계가있다. 심지어, OSI(Open Source Initiative) 자체적으로라이선스목록을놓고서 OSI 사이트방문자들의요구에더부합하는보다나은유형의그룹화에대해최근에논의하였다. 32) OSI(Open Source Initiative) 는최종적으로 대중적이고널리사용되거나영향력이큰커뮤니티에서사용되는라이선스, 특수목적의라이선스, 기타라이선스, 더대중적인라이선스들이많이포함된라이선스, 재사용불가라이선스, 대체된라이선스, 임의로폐기된라이선스, 비분류라이선스 의범주로분류하였다. 33) 오픈소스라이선스유형을구성하는또다른방법은 학술기관이원래지었던명칭으로이름지은 학술적라이선스 (academic licenses) 34), 파생저작물의소스코드를공개해야하는요구사항을포함하여동일한라이선스에의거저작물을파생저작물을배포자가공개해야 하는특징으로이름지은상호적라이선스 (reciprocal license) 35), 산업표준 의재사용가능성을나타내기때문에이름지은표준라이선스 32) Open Source Initiative: OSL 메일링리스트. 라이선스 - 논의. 신규 Open Source Initiative 라이선스시작페이지초안 ; 2012 [n.y.] (URL: http://projects.opensource.org/pipermail/license-discuss/2012-april/000332.html) - 참고자료다운로드 : 2013-01-29, wp. 참조 33) Open Source Initiative: 카테고리별오픈소스라이선스 ; 2013 [n.y.] (URL: http: //opensource.org/licenses/category) - 참고자료다운로드 : 2013-01-29, wp. 참조 34) Rosen, Lawrence: Open Source Licensing. Software Freedom and Intellectual Property Law; Upper Saddle River, New Jersey: Prentice Hall PTr, 2005, ISBN 0 13 148787 6, p. 69. 참조 35) id., l.c., p. 70. 참조 - 20 -
(standard license) 36), 그리고음악, 예술, 영화, 문학작품등소프트웨어이외의것을나타내기위해이 름지은컨텐츠라이선스 (content license) 37) 등으로분야를나누어 오픈소스라이선스유형 을고안한것 이다. 두가지유형의분류체계는새로운 ( 소프트웨어 ) 프로젝트에사용하고자하는적합한라이선스를찾는데직접적인도움을준다. 그러나이러한분류를통해라이선스준수활동을추론할수없다. 이유형들은대부분라이선스외부기준만을고려하여정의되기때문이다. 특정기관에서제작한라이선스든또는산업표준이나소프트웨어가아닌다른유형의저작물을다루는라이선스든상관없이본질적으로라이선스준수활동을제공하지못한다. 학술적라이선스와상호적라이선스로그룹화하는행위만이라이선스이행업무의개념을고려하고있다. 단, 이들라이선스들이 파생저작물의소스코드를배포하기위해적용되는라이선스에따른의무사항없이어떠한목적으로든소프트웨어를사용할수있도록허가 한다는세부조항에따라 학술적라이선스의정의를확대하였을경우 에그렇다. 38) 이추가세부조항과관련하여 학술적라이선스 (academic licenses) 와상호적라이선스 (reciprocal license) 군은오픈소스라이선스의 주요분류 이다. 39) 정의에의하면이라이선스들은반대가될뿐아니라반대되는모순을구성한다. 그러나오픈소스라이선스집합내부에본질적대립과이율배반을형성하고있다는점을명심해야한다 40). 학술적라이선스 (academic licenses) 와상호적라이선스 (reciprocal license) 를본질적유사성에따라묶는방법은허용적라이선스 (permissive license) 와약한카피레프트라이선스 (weak copyleft license), 그리고강력한카피레프트라이선스 (strong copyleft license) 로그룹화하는것이다. 심지어위키피디아는 그들을 상호주의및동일조건변경허락 의요구사항을가진 카피레프트라이선스 와대조되고어떻게소프트웨어가재분배되는지에대한최소한의요구사항을가지는자유소프트웨어라이선스의집단 이라는의미로 관대한 ( 허용적 ) 자유소프트웨어라이선스 (permissive free software licence) 라는용어를사용하였다. 41) 몇몇의다른필자들은내포된 카피레프트 효과의연속으로서, 소스코드의수정이있을시반드시공표해야하기때문에, 학술적라이선스 (academic licenses) 를 허용적라이선스 라고명명하고, 상호적라이선스 (reciprocal license) 를 제한적라이선스 라고구분하였다. 그들은파생저작물이같은라이선스아래에서공표되어야하는 강력한제한적라이선스 의일부분을소개한다. 42) 묶는방법에대한다음수정은 36) 참고문헌참조 37) id., l.c., p. 71. 참조 38) 참고문헌참조 39) id., l.c., p. 179. 참조 40) 이러한이유로 오픈소스라이선스 (OSL) 는상호적라이선스 이고 학술적자유라이선스 (Academic Free License(AFL)) 는상호주의조항이없는정확한동일한라이선스 라고한다면약간의혼란을주게된다. (id., l.c., p. 180 참조 ). 만약, BSD 라이선스가 AFL 이고 AFL 이 OSL 이아니며그리고 OSI 가 OSL 만승인한다면 BSD 라이선스는승인된오픈소스라이선스가될수없다. (Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 ) 41) 위키피디아 ( 영문판 ): 허용적자유소프트웨어라이선스 (Permissive free software licence); n.l., 2013 [n.y.] (URL: http://en.wikipedia.org/wiki/permissive_free_software_licence) - 참고자료다운로드 : 2013-02-02, wp. 참조 42) pars pro toto cf. Buchtala, Rouven: Determinanten der Open Source Software-Lizenzwahl. Eine spieltheoretische Analyse; Frankfurt am Main, Berlin, Bern [... etc.]: Peter Lang, 2007 (= - 21 -
엄격한카피레프트조항에따른 [ 오픈소스 ] 라이선스 43), 제한된카피레프트조항에따른 [ 오픈소스 ] 라이선스 44), 그리고 어떠한제약도없는카피레프트 [ 오픈소스 ] 라이선스 45) 로분류하여묶는방법을사용한다. 마지막으로다음관점은약한카피레프트 (weak copyleft) 와강력한카피레프트 (strong copyleft) 로분류하는방법과연관된다. 약한카피레프트가적용된소프트웨어는변경될때카피레프트조항을준수해야하고그에링크된다른소프트웨어는변경에는해당하지않는다. 반면에 강력한카피레프트는이를이용하여만들어진모든종류의파생저작물들역시카피레프트조항의영향을받는다고기술한다. 46) 적합한분류와명명에대한접근방식을기반으로 47) 다음과같은그림을전개할수있다. 확장성에기초한오픈소스라이선스분류체계는명확하게알려져있고종종혹은덜분명하게거론되고 Informationsmanagement und strategische Unternehmensfu ḧrung), [Vol./No.] 12), ISBN 978 3 631 57114 9, p. 57. 43) 최초에는 Lizenzen mit einer strengen Copyleft-Klausel 로명시됨. Jaeger a. Metzger : 오픈소스소프트웨어. Rechtliche Rahmenbedingungen der Freien Software, 2011, 24쪽참조 44) 최초에는 Lizenzen mit einer beschränkten Copyleft-Klausel 로명시됨. 인용한글과동일, 71쪽참조 45) 최초에는 Lizenzen ohne Copyleft-Klausel 로명시됨. 인용한글과동일, 83쪽참조 46) 위키피디아 ( 영문판 ): Copyleft; n.l., 2013 [n.y.] (URL: http://en.wikipedia.org/wiki/copyleft) - 참고자료다운로드 : 2013-02-02, wp. 참조 47) 마지막으로다른문맥에서중요하게생각되는다른분류방식도존재한다. 예를들어 ifross license는주요분류로 Open Source Licenses 와그아래부분류로 Licenses without Copyleft Effect, Licenses with Strong Copyleft, Licenses with Restricted Copyleft, Licenses with Restricted Choice, 또는 Licenses with Privileges 포함한다. 그리고이러한분류를 OSI에의해목록화된것이아닌라이선스로나타낸다. (ifross: License Center; 2011 [n.y.] URL: http: //www.ifross.org/ifross_html/lizenzcenter-en.html reference download: 2013-02- 26, wp 참조 ). 오픈소스소프트웨어정의의미를참고하면이는충분히타당하다 (Open Source Initiative: The Open Source Definition, 2012, wp 참조 ). The OSLiC는 OSI(Open Source Initiative: The Open Source Licenses, alphabetically sorted, 2012, wp 참조 ) 에의해목록화된향상된오픈소스라이선스를참조하여대상의단순화를원한다 (cf. Open Source Initiative: The [OSI] Licence Review Process, 2012, wp 참조 ). - 22 -
있다. 48) 유감스럽게도이분류체계는여전히오해의소지가있는다음과같은메시지를일부포함하고있다. Permissive( 허용적 ) 는매우긍정적인의미를내포하고있다. 따라서허용적라이선스 (permissive license) 와카피레프트라이선스 (copyleft license) 를비교할때허용적라이선스는카피레프트라이선스보다어떤면에서더낫다는것을암묵적으로들어낸다. 자연스럽게확장된정의를혼란스러워하게되고해당명칭의내포적인영향력때문에이러한결론을내리게된다. 하지만, 인간의사고방식이기에어쩔수없다. 이기본메시지가반드시 잘못 된것은아니다. 카피레프트 에의해도입된무엇인가를환원해야하는의무사항에비해제한없이오픈소스소프트웨어를사용하고싶은사람들이나회사에게는편리할수있다. 49) 그러나카피레프트라이선스보호를강조하는사람이나기업이있을수있다. 실제로적어도오픈소스라이선스 50) GPL 51) 는자유를보호하기위해개발자들이그들의 동료 (neighbours) 및아래의수정사항들을위해개발되었다. 52) 따라서 카피레프트 는 프로그램을자유소프트웨어로만들기위해그리고모든수정, 확장된버전의프로그램또한자유소프트웨어로만들기위한방법론 53) 이다. 이방법 54) 은 코드와자유는법적으로분리불가능 55) 을위한것이다. 제한되지않고보호되길바라는이러한상이한이해관계때문에더나은명칭 관대한라이선스군의편견없는이름 을찾는것이나을지도모른다. 그러나우리는최소한이분류체계는등급을없애는기본메시지를담고있음을알고있어야한다. 48) FSF( 자유소프트웨어재단 ) 에서도 허용적비 - 카피레프트자유소프트웨어라이선스 (permissive non-copyleft free software license) 라는용어를사용하며 (pars prototo: cf. Free Software Foundation: Various Licenses and Comments about Them; 2013 [n.y.] hurl: http://www.gnu.org/licenses/license-list.htmli reference download: 2013-02-08, wp/section Original BSD license ) 약한카피레프트 및 강력한카피레프트 라는용어와이를대조한다 (pars pro toto: cf. id., l.c., wp/section European Union Public License 참조 ) 49) 사실상카피레프트는카피레프트가아니다. 정의를떠나서그영향은카피레프트 방법 을적용하기위한조건을정하는특정라이선스에좌우된다. 예를들어 GPL 에서카피레프트영향은 배포되는 기준에묶여진다. 나중에이조건들을체계적으로다룰것이다 (see chapter Open Source Use Cases: Concept and Taxonomy, pp. 103). 이에따라, 여기서 일반화하는 형식으로설명한다. 50) RMS 는이를자유소프트웨어라이선스로불리는것을선호한다. (s. p. 18) 51) 원본소스참조 Free Software Foundation: GNU General Public License, version 2; 1991 [n.y. of the html page itself] hurl: http://www.gnu.org/licenses/gpl-2.0.htmli reference download: 2013-02-05, wp. OSLiC 안에서우리는오픈소스라이선스에대해문서적으로접근하기때문에 OSI 에서배포되는버전을지속적으로참조한다. OSI-GPL 에대하여 Open Source Initiative: GNU General Public License, version 2 (GPL-2.0). Version 2, June 1991; 1991 [n.y. of the html page itself] hurl:http://opensource.org/licenses/gpl-2.0i reference download: 2013-02-05, wp 참조 52) GNU 프로젝트의역사는여러번언급됐다. GNU 프로젝트와초기설립에대하여 pars pro toto Williams, Sam: Free as in Freedom. Richard Stallman s Crusade for Free Software; Beijing [... etc.]: O Reilly, 2002, ISBN 0 596 00287 4, passim 참조. 광범위한여론조사 pars pro toto Moody: Die Software-Rebellen, 2001, passim 참조. 매우짧은버전에서리처드스톨만은일찍이자유소프트웨어재단이붕괴되었던시기에 단지실행사본을받기위해이웃을도와주지않는다는명확한약속을서명해야하는 기밀유지협약서 (nondisclosure agreement) 를목격했다고언급하였다 : 협조하는공동사회는금지되었다. (Stallman, Richard M.: The GNU Project; originally published in Open Sources: Voices from the Open Source Revolution, O Reilly, 1999 ; In Stallman: Free Software, Free Society: Selected Essays, 2002, p. 16 참조 ). 53) 리처드스톨만 : What is Copyleft?( 카피레프트란무엇인가?) 1996 년최초작성 ; In Stallman: Free Software, Free Society( 자유소프트웨어, 자유사회 ): Selected Essays( 선정에세이 ), 2002, 89 쪽참조 54) 미국법적저작권체계에근거하여이방법에서는두가지단계를사용한다. 첫째는 저작권으로보호받는다. 이며, 둘째는 배포조항이변경되지않는경우에만프로그램의코드또는그파생된프로그램을사용, 수정및재배포할권한을모든사람에게제공하는법적수단인배포조항 이추가된다. ( 참고문헌참조 ) 55) 참고문헌참조 - 23 -
오해의소지가있는다른해석은 직관에반대되는 카피레프트 개념의사용으로부터나온다. 관대한라이선스와반대로카피레프트라이선스군을나타냄으로써함축적으로두가지메시지를띄운다. 첫째, 갖고있던수정된프로그램을재배포하는것은카피레프트라이선스를충분히준수하는것이다. 둘째, 허용적라이선스는소프트웨어사용권을확보하기위해어떤것도요구하지않는다. 그렇게해석되지않기를바라더라도 인간이늘하듯 가능한단순하게사물을받아들이는경향이있다. 56) 여러측면이존재하기때문에카피레프트라이선스와허용적라이선스의모순을이와같이이해한다면심각한일반화를하는것으로받아들이는것이된다. 반면 강력한카피레프트 를적용한 GPL의경우에도파생저작물을단지재배포하는것이외의임무를부여한다. 예를들어 GPL 라이선스를적용하는프로그램을받아서사용하는사람에게는프로그램과함께라이선스사본을같이제공하는것 을요구하고있다. 57) 또한 약한카피레프트 라이선스를적용할경우이라이선스에따라충족해야하는더많은다른기준이요구된다. 예를들어 EUPL에서는소스코드와함께바이너리를직접제공하지않는허가권자 (licensor) 는무료로자신의저작물의소스코드버전을제공해야하지만 58) 동일한상황에서 MPL은 배포하는비용이내의수수료를그소스코드형태의사본을확보하는데요구할수있다 59) 는것을요구한다. 그리고마지막으로허용적라이선스준수사용을위해작업을완수해야하며더나아가다양한일을요구한다. 예를들어 BSD에서는 배포 / 재배포시위의저작권고지문을포함하도록하고필요시재작성하여포함할것을 요구한다. 저작권고지문 의구조때문에이의무적고지는소프트웨어저작자 / 저작권소유자의이름이공표되어야한다는점을암시한다. 60) 이와반대로아파치라이선스 (Apache License) 에서는 저작물에배포의일환으로 고지 (NOTICE) 텍스트파일이포함된다면사용자가배포하는파생저작물에는파일의중심부분 ( 저작자 / 저작권소유자이름이외에더많은정보가들어갈수있는부분 ) 을공개적으로자주제시해야하는 61) 고지파일내에들어있는판독가능한귀속고지 (attribution notices) 가포함되어야한다. 따라서 ( 그리고이분류체계에대한직관적해석에반하여 ) 의심할여지없이각각의오픈소스라이선스는가장허용적인라이선스이더라도어떤활동을통해요건이충족되어야한다. 이작업을확인하기위해서라이선스분류체계의일반화된개념이아닌라이선스자체를살펴보아야한다. 이와같이잘알려진유형으로오픈소스라이선스를분류한다하더라도특정개별라이선스의준수활동을알아낼수없 56) 저자들의경험에비추어가끔은그와같이단순하게받아들이기때문에자신의독자적존재를부각시키고관리수준에서결정을한다. 그러나이는관리자의잘못이아니다. 이들의업무는정보를합치고, 개괄하여간략히나타내는것이다. 세부내용으로다른사람들을당황하게하지않고보다나은관점을제공하는것이전문가의일이다. 57) Open Source Initiative: The GPL-2.0 License (OSI), 1991, wp. 1. 참조 58) 독일버전의 EUPL 에서는 problemlos und unentgeltlich auf den Quellcode (zugreifen können) 라는문구를사용한다 (Europäische Gemeinschaft a. European commission Joinup: Open-Source-Lizenz für die Europäische Union; 2007 (URL: http://joinup.ec.europa.eu/system/files/de/eupl v.1.1 - Lizenz.pdf) - 참고자료다운로드 : 2013-02-08, 3 쪽, section 3). 영어버전에는 소스코드는쉽고자유롭게이용할수있다 라는상세내용을담고있다 ( 유럽공동체 a. European commission Joinup: European Union Public Licence v. 1.1. 2007 (URL: http://joinup.ec.europa.eu/system/files/en/eupl v.1.1 - Licence.pdf) - 참고자료다운로드 : 2013-02-08, 2 쪽, section 3). 59) Open Source Initiative: Mozilla Public License 2.0 (MPL-2.0); 2013 [n.y.] (URL: http://opensource.org/licenses/mpl-2.0) - 참고자료다운로드 : 2013-02-07, section 3.2.a. 참조 60) Open Source Initiative: The BSD 2-Clause License; 2012 [n.y.] (URL: http://www.opensource.org/licenses/bsd-2-clause) - 참고자료다운로드 : 2012-07-03, wp. 참조 61) Open Source Initiative: Apache License, Version 2.0; 2004 [ 페이지 n.y.] (URL: http://opensource.org/licenses/apache-2.0) - 참고자료다운로드 : 2013-02- 07, wp. section 4.4. 참조 - 24 -
다. 내포된메시지와일반화된일부개념을가지고살아가길원한다면분류체계만으로충분할것이다. 그러나분류체계는오픈소스라이선스를충족하기위해해야하는일을결정하는데적절한수단이아니다. 특정오픈소스소프트웨어의사용권한을확보하기위한라이선스준수활동은라이선서가소프트웨어에부여한특정오픈소스라이선스에근거해야한다. 여기에지름길이란없다. 인간은결론적으로특정목적을위한큰영역의세부적인사항에대해논의해야할경우에도그영역에대한설명을위해일반화되고체계화된관점을필요로한다. 오픈소스라이선스의영역에대해논의하고구성할수있는더욱영리한방법이있을것이다. 따라서여기서는오픈소스라이선스를분류하는다른방법에접근하려한다. 62) 일반적으로라이선스들은공통목적이있다. 그공통목적은라이선스를통해무언가로부터사람또는대상을보호하는것이다. 이임무의구조는 3가 ( 價 ) 의동사인 보호하다 (protect) 라는단어의성격에기초한다. 이구조는보호하는사람또는대상과보호받을사람또는대상과연결된다. 즉, 보호물 / 보호자와이에대항하는피보호물 / 피보호자와연결시킨다. 일반적으로라이선스가이런역할을한다. 또한라이선시의 권한 을 보호 하는것은 GPL2.0 63), LGPL-2.1 64) 그리고 GPL3.0 65) 에서확실하게언급되었다 (LGPL-3.0에서이목적이계승됐듯이 ) 66). 이관점에서일반적으로오픈소스라이선스는보호하기위해고안된것으로가정한다. 라이선스는소프트웨어사용자 ( 수령자 ), 참여자그리고개발자및배포자그리고더나아가소프트웨어자체를보호할수있다. 그리고아래와같은여러위협으로부터보호할수있다. 첫째, 오픈소스소프트웨어라는측면에서사용자는소프트웨어사용, 수정및재배포할권한을잃어버릴 위험으로부터보호받을수있으며또한특허분쟁으로부터보호받을수있다추정한다. 둘째, 오픈소스참여자와배포자는코드개선및파생코드의형태의피드백손실과보증청구및특허 분쟁으로부터보호받을수있다추정한다. 셋째, 오픈소스프로그램과그특정형태는 ( 배포가능하거나불가능할수있고수정가능하거나불가능 할수있으며바이너리또는소스코드로배포될수있는 ) 추가개발하는부분의재사유화와독점에대 해보호받을수있다추정한다. 넷째, 오픈소스컴포넌트에기반한새로운개발물들은소프트웨어를자유롭게사용하는세상을확대 하기위해소프트웨어사유화에대항하여보호받을수있다추정한다. 67) 62) 궁극적으로, 라이선스자체를항상살펴보아야한다는사실을인정할수밖에없더라도 63) Open Source Initiative: The GPL-2.0 License (OSI), 1991, wp. (Preamble( 전문 ). 참조 64) Open Source Initiative: The GNU Lesser General Public License, 버전 2.1 (LGPL-2.1); 1999 [html 페이지 n.y.] (URL: http://opensource.org/licenses/lgpl-2.1) - 참고자료다운로드 : 2013-03-06, wp. Preamble( 전문 ). 참조 65) Open Source Initiative: GNU General Public License, 버전 3 (GPL-3.0); 2007 [html 페이지 n.y.] (URL: http://opensource.org/licenses/gpl-3.0) - 참고자료다운로드 : 2013-03-05, wp. Preamble( 전문 ). 참조 66) Open Source Initiative: The GNU Lesser General Public License, 버전 3.0 (LGPL-3.0); 1999 [html 페이지 n.y.] (URL: http://opensource.org/licenses/lgpl-3.0) - 참고자료다운로드 : 2013-03-06, wp. 표제 (prefix). 참조 - 25 -
이러한관점을존중하며라이선스특정보호기능을보다더세밀하게그려보게된다. 따라서다음페이 지에서각각의오픈소스라이선스의보호기능을설명하고추론할것이다. 표 2.1 은빠른참조를위해간 략하게나타낸것이다 68) 67) 더엄격한버전에서라이선스의기능은일련의오픈소스소프트웨어정체현상이방지되도록커뮤니티를보호하는권한으로확인할수있다. 68) 27 쪽 ( 표위치 ) - 26 -
표 2.1: 보호자관념의오픈소스라이선스 오픈소스 라이선스 a 사용자 이미소스또는 바이너리를입수한자 권한상실 사용수정재배포 특허 분쟁 보호하는대상기여자 ( 배포자 ) 오픈소스 소프트웨어를 미배 포 확산시키는자다음항목에대항 피드백 손실 보증 청구 특허 분쟁 오픈소스소프트웨어배포시상태비수정수정소스바이바이소스너리너리 이미공개된소프트웨어독점화 및재사유화 추가개발물사유화 Apac he 2.0 ü ü ü ü ü ü ü ü BSD 3-Cl ü ü ü ü ü ü 2-Cl ü ü ü ü ü ü MIT ü ü ü ü ü ü MS-P L ü ü ü ü ü ü ü ü Post gres ü ü ü ü ü ü QL PHP 3.0 ü ü ü ü ü ü CDD L 1.0 ü ü ü EPL 1.0 ü ü ü ü ü ü ü ü ü ü ü EUPL 1.1 ü ü ü ü ü ü ü ü ü ü ü LGPL 2.1 ü ü ü ü ü ü ü ü ü 3.0 ü ü ü ü ü ü ü ü ü ü ü 1.0 MPL 1.1 2.0 ü ü ü ü ü ü ü ü ü ü ü MS- RL ü ü ü AGPL 3.0 ü ü ü ü ü ü ü ü ü ü ü ü ü 2.1 ü ü ü ü ü ü ü ü ü ü GPL 3.0 ü ü ü ü ü ü ü ü ü ü ü ü a) ü 는열에나타낸대상에대하여라이선스에의해보호된다는표시이며, 는열에나타낸대상에대해라이선스에의해보호되지않는다는표시이며, 는해당문구가여전히평가되어야한다는표시이다. 이탤릭체로표현된라이선스명칭은해당마인드맵 ( 42 쪽 ) 에서다뤄지지않고이표에서만열거됨 - 27 -
2.1 GNU Affero General Public License(AGPL) 의보호기능 [TODO...] 2.2 아파치라이선스 (Apache-2.0) 의보호기능 승인된오픈소스로서 69) 아파치라이선스 70) 는소스코드또는바이너리파일의사본을사용, 수정또는배포할권리의상실로부터사용자를보호한다. 71) 게다가특허조항에있어서 72) 아파치 2.0 프로젝트는특허분쟁으로부터사용자를보호한다. 73) 이러한특허조항과 보증제한 (disclaimer of warrnaty)" 그리고 책임제한 (limitation of liability) 으로인해아파치라이선스는기여자와배포자를특허분쟁과보증청구로부터보호한다. 74) 마지막으로아파치-2.0은저작물을폐쇄된소프트웨어로변환하는라이선스변경으로부터배포된소스코드를보호한다. 그이유는첫째, 저작물또는파생저작물을받아서사용하는다른사용자에게 ( 아파치 ) 라이선스사본을제공 해야하며둘째, 배포하는파생저작물의소스코드형태 로, 모든저작권, 특허, 상표및귀속고지를보유 해야하고셋째, 받아서사용하였던최초패키지에의해공급되는고지 (NOTICE) 파일의판독가능한사본을포함 해야하기때문이다. 75) 그러나아파치라이선스에서는 카피레프트 소프트웨어가아니기때문에피드백손실로부터기여자를보호하지않는다. 아파치라이선스는소스코드배포를요구하는문구가들어있지않다. 같은맥락에서아파치-2.0은배포되지않은소프트웨어나배포된바이너리에대하여독점화 ( 수정또는수정되지않은형태모두 ) 로부터보호하지않는다. 그이유는아파치라이선스는바이너리가배포자에의해수정된소스에좌우된다할지라도소스코드의공급없이바이너리를 ( 재 ) 배포하는것을허용하기때문이다. 마지막으로, 아파치-2.0은사유화로부터추가개발물을보호하지않는다. 2.3 BSD 라이선스의보호기능 승인된오픈소스라이선스 76) 로서 BSD 라이선스 77) 는소스코드또는바이너리파일의사본을사용, 수정 69) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 70) 아파치라이선스버전 2.0 은아파치소프트웨어재단이관리한다 (Apache Software Foundation: Apache License, 버전 2.0; 2004 (URL: http://www. apache.org/licenses/license-2.0) 참고자료다운로드 : 2011-08-31, wp 참조 ). Open Source Initiative 는아파치라이선스사본을제공하며 (Open Source Initiative: APL-2.0, 2004, wp 참조 ) 공식승인된오픈소스라이선스로싣고있다 (Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp 참조 ). Open Source Initiative 는아파치라이선스 1.1 을 대체라이선스 로분류한다 (Open Source Initiative: 카테고리별오픈소스라이선스, 2013, wp 참조 ). 아파치소프트웨어재단은동일한취지로 1.0 및 1.1 배포버전을 기록물 로분류한다 (Apache Software Foundation: 라이선스 ; 2013 [n.y ] (URL: http://www.apache.org/licenses/) 참고자료다운로드 : 2013-02-25, wp 참조 ). 그래서, OSLiC 는가장최신버전인아파치 -2.0 에만초점을맞춘다. 초기의아파치라이선스에따라이행해야하는자들은이를 BSD-2-Clause 및 BSD-3-Clause 라이선스의동류로이해하는데이는도움이될것이다. 71) Open Source Initiative: APL-2.0, 2004, wp. 2. 참조 72) OSLiC 47 쪽 (3.1.2) 73) 참고문헌참조 74) 참고문헌참조 75) 참고문헌참조 76) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 77) BSD 는버클리소프트웨어배포의약자이다. BSD 라이선스공개및명명에대한자세한설명인 Open Source Initiative: The BSD 3-Clause License; 2012 [n.y.] (URL: http://www.opensource.org/licenses/bsd-3-clause) - 참고자료다운로드 : 2012-07-04, wp. 사설참조 - 28 -
또는배포할권리의상실로부터사용자를보호한다. 78) 추가로 무보증조항 (No Warranty Clause 이라는내용이포함되었기때문에소프트웨어사용자의보증청구로부터기여자그리고 ( 또는 ) 배포자를보호한다. 79) 그리고마지막으로소스코드가폐쇄되는라이선스변경으로부터기존에배포된소스코드를보호한다. 그이유는 해당소스코드의재배포및수정에는저작권고지, 이에관련된조건리스트, 그리고권리포기내용이포함 되어야하기때문이다. 80) 그러므로소스코드를독점화하는것과관계없이기존 BSD 라이선스가적용된코드를다른라이선스를적용하여배포하는것은올바르지않다. 81) 하지만 BSD 라이선스프로젝트는특허분쟁에대하여기여자또는배포자를보호하지않으며 ( 어떠한특허조항도포함되어있지않기때문에 ), 기여자를피드백손실로부터보호하지않는다 ( copyleft 소프트웨어가아니기때문에 ). 또한, 수정또는수정되지않은형태에관계없이배포되지않는소프트웨어와배포된바이너리의독점화로부터보호하지않는다. 그이유는소스코드를공급하지않고도바이너리만의재배포를허용하기때문이다. 82) 마지막으로 BSD 라이선스는사유화로부터추가개발물을보호하지않는다. 2.4 CDDL 의보호기능 승인된오픈소스라이선스 83) 로서 CDDL(Common Development and Distribution License) 는소스코드 또는바이너리사본을사용, 수정또는배포할권리의상실로부터사용자를보호한다. 84) [...] 2.5 Eclipse Public License(EPL) 의보호기능 승인된오픈소스라이선스 85) 로서 EPL(Eclipse Public License) 86) 은소스코드또는바이너리사본을사용, 78) Open Source Initiative: 오픈소스정의, 2012, wp. 1. 참조 79) Open Source Initiative: The BSD 2-Clause License, 2012, wp. 참조 80) 참고문헌참조 81) 일반적인상식에서다른자체라이선스에의거저작물을대체할수있는 BSD 라이선스에대해들어본적이있을수있다. BSD 라이선스가모든상황에서유효하지않다는점을받아들인다면맞는말이다. 수정된저작물 ( 파생저작물 ) 의소스코드를재배포할필요가없다. 받은버전을수정하고결과물을바이너리로서만배포하며개선사항을비밀로해둘수있다. 그러나수정프로그램의소스코드를배포한다면 수정되었든수정되지않았든소스로재배포하는행위는그소스코드재배포시위의저작권고지, 조건리스트및뒤따르는권리포기가유지된다는조건에서허용되기 때문에라이선싱이유지된다. ( 참고문헌참조 ) 82) BSD-2CL 라이선스 ( 참고문헌참조 ) 와 BSD-3CL 라이선스참조 (Open Source Initiative: The BSD 3-Clause License, 2012, wp) 83) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 84) Open Source Initiative: Common Development and Distribution License (CDDL-1.0); 2004 [n.y. of the html page itself] URL: http://opensource.org/licenses/cddl-1.0i reference download: 2013-04-19, wp.?. 참조 85) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 86) 픈소스이니시어티브 : 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 [86] Eclipse Public License, 버전 1.0 은이클립스소프트웨어재단 (Eclipse Software Foundation) 에서관리한다 ( 이클 립스재단 : Eclipse Public License, 버전 1.0; 2005 [n.y.](url: http://www.eclipse.org/org/documents/epl-v10.php) - 참고자료다운로드 : 2013-02-20, wp)) 물론 OSI 도복사본을제공한다.( Open Source Initiative: Eclipse Public License, Version 1.0; 2005 [n.y. of the page itself] hurl: http://opensource.org/licenses/epl-1.0i { reference download: 2013-02-20, wp 참조 ). - 29 -
수정또는배포할권리의상실로부터사용자를보호한다. 87) 또한특허조항에따르면 88) EPL은특허분쟁에대해서도사용자를보호한다. 89) 특허조항외에도 EPL은 무보증 (no warranty) 과 책임제한 (disclaimer of liability) 부분을포함한다. 90) 이세가지요소는모두기여자와배포자를특허분쟁과보증청구로부터보호한다. 마지막으로 EPL은소프트웨어를독점소프트웨어로리셋하는라이선스변경으로부터배포된소스코드를보호한다. 먼저, EPL은 EPL을적용하여배포된어떠한저작물이 소스코드형태로배포된다면 ( 이때 ) 이는마찬가지로 (EPL) 협약하에배포되어야한다 이러한배포가능행위시 각 [ 배포된 ] 프로그램의복사본 또는프로그램패키지에 반드시 EPL의 복사본 을삽입해야한다. 91) 하지만허용적라이선스와는반대로 EPL은수정된또는수정되지않은것과는관계없이배포된소스코드만을보호하는것은아니다. EPL은수정된또는수정되지않은바이너리또한보호한다. EPL은라이선스에 프로그램을위한소스코드를사용가능함 이명시된경우나 라이선시 가 소프트웨어교환에관례적으로쓰이는매체를통해또는매체에서합당한방식으로이를확보할수있는 경우수정하는 기여자 와배포자가 자체라이선스협약하에오브젝트코드의형태로프로그램을배포 할수있도록허용한다. 92) 그러므로 EPL은카피레프트라이선스라는결론을내린다. 하지만 EPL은효력이강력한카피레프트를포함한라이선스는아니다. EPL에서약한효력의카피레프트 만 있다. 93) 실제로 EPL에서는 EPL 라이선스에따른 프로그램 ( 오브젝트형태로배포된 ) 의위치의경우일치하는소스코드를어디에서얻을수있는지알수있도록해야한다. 94) 프로그램 이란용어는 EPL에따라배포된기여 (contribution) 로정의되며 기여 라는용어는 ( 다른요소외에 ) 프로그램의변경된내용및프로그램에추가된내용 을나타낸다. 95) 이는다음과같은정의가내려질수있다. 프로그램 은 기여 로정의할수있고 기여 는 프로그램 으로정의할수있다. 그럼에도불구하고라이선스는호의적으로해석해야한다. 논란의여지가없는점은여기에있다. EPL 라이선스에따라수정된프로그램, 라이브러리, 모듈또는플러그인을배포해야한다면수정된소스코드또한공개해야한다. EPL 라이선스에따른프로그램 ( 프로시져호출을추가하여이를사용하는대신에수정하였던 ) 에의해사용되는일부자체플러그인또는추가라이브러리를 추가 한다면두가지부분의코드를공개해야한다.( 프로그램및추가된요소의코드 ). 이런의미에서 EPL에서는다른약한효력의카피레프트를활용하는라이선스와같이독점화로부터바이너리가확실히보호된다. 그러나 EPL 라이선스에따르지않는다른상위프로그램의구성요소로사용되는 EPL 기반라이브러리만을배포한다면, 이라이브러리는상위개발물을따르지않는다.( 단, 라이브러리자체가지배적인추가개발물에의해전달되는프로시져또는 ( 프로그램 ) 함수를불러내지않는경우 ). 이러한이유로, 라이브러리에는추가되는것이없으며, 해당라이브러리외의코드는공개하지않아야한다. 따라서 EPL에서는예를들어 GPL과같은취지의효력이강력한카피레프트를사용하지는않는다. 87) 참고문헌참조, wp. 2a. 88) OSLiC 49 쪽참고 89) 참고문헌 wp. 2b & 2c. 90) 참고문헌 wp. 5 & 6. 참조 91) 참고문헌 wp. 3. 참조 92) Open Source Initiative: EPL-1.0, 2005, wp. 3, 특히, 3.b.iv. 참조 93) 인터넷에서상반되는세부내용을발견할수있더라도그러하다. 전체를대표하는부분 ifross: ifross Lizenz-Center, 2011, wp 참조 : 이페이지는 강력한카피레프트효력 이있는다른라이선스 부문의 EPL 를열거하고있다. 94) Open Source Initiative: EPL-1.0, 2005, wp. 3, 특히, 3.b.iv. 참조 95) 참고문헌 wp. 1. 참조 - 30 -
2.6 European Union Public License(EUPL) 의보호기능 승인된오픈소스라이선스 96) 로서, European Union Public License(EUPL) 97) 는받은소스코드또는바이너리사본을사용, 수정또는배포하는권리의상실로부터사용자를보호한다. 98) 또한해당특허조항 99) 에근거하여 EUPL은특허분쟁에대해서도사용자를보호한다. 100) 이특허조항외에도 EUPL에는추가로 보증제한 과 책임제한 에대한내용을담고있다. 101) 이세가지요소에의해특허분쟁과보증청구에대해기여자와배포자가보호된다. 끝으로, EUPL은또한독점화및재사유화로부터배포된소스를그리고피드백손실로부터기여자를보호한다. 이런보호는두가지조치에근거한다. 첫째, EUPL에는 원저작물과원저작물기반파생작의사본 을반드시 EUPL 조항에의거 하여배포해야한다는사항이규정된 카피레프트조항 이라는제목의단락이포함되어있다. 102) 둘째, EUPL은 ( 저작물을지속적으로배포또는전달하는 한 ) 각라이선시는 소스코드를쉽고자유롭게이용할수있는저장소 (repository) 를 ( 표시하여 ) 또는직접적으로 소스코드를제공 해야한다. 103) 이조건은 EUPL에게매우중요하기때문에라이선스에서메시지가반복되고있다. 또다른단락에서 EUPL은 저작물이실행코드 (Executable Code) 로제공된다면라이센서는저작물복사본과함께저작물의기계판독형소스코드복사본을추가적으로제공하거나라이센서가저작물을지속적으로배포하는동안소스코드를쉽고자유롭게이용할수있는저장소를고지문에표시 할것을요구하고있다. 104) EUPL에의해 원저작물또는이의파생작 으로서정의되는 저작물 의의미에서볼때 105) EUPL은카피레프트라이선스임에틀림없다. 그러나 EUPL은강력한카피레프트를포함하는라이선스는아니다. EUPL의핵심을받아들인다면해당라이선스는보통두가지의상황에서모두소스코드를공개해야하기때문에 ( 재 ) 사유화및독점화로부터원저작물의수정물뿐만아니라추가개발물을보호하는것으로보인다. 이와같이이해한다면, EUPL은 강력한카피레프트라이선스 일것이다. 그러나 EUPL은추가로 호환성조항 (Compatible clause) 을포함함에따라 라이선시가호환성라이선스하의원저작물과다른저작물에기초한파생작또는사본을배포한다면, 호환성라이선스조항에기반하여배포가가능하다 는것을명시하는조항을포함한다. 106) ( 호환성라이선스 라는용어는예를들어, Eclipse Public License와같은호환가능한라이선스리스트에의해명확히정의된다. 107) 이런호환성조항에근거하여추가개발물의코드를공개 96) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 97) European Union Public License(EUPL) 버전 1.1 은유럽연합 (European Union) 에서관리하며, Joinup 이란명칭하에주관하고있다 (European Community( 유럽공동체 ) a. European commission Joinup: EUPL-1.1/EN, 2007, wp 참조 ). EUPL 은공식적으로여러언어를독일어로번역하였다 ((Europäische Gemeinschaft a. European commission Joinup: EUPL-1.1/DE, 2007, wp 참조 ). 이와같이다중언어로되어있기때문에, Open Source Initiative 는자체버전을제공하지않지만유럽호스트 Joinup 의랜딩페이지에링크된랜딩 ( 시작 ) 페이지만을제공 (Open Source Initiative: European Union Public License, version 1.1 (EUPL-1.1; 2007 [html 페이지 n.y. ] (URL: http://opensource.org/licenses/eupl-1.1) - 참고자료다운로드 : 2013-03-04, wp 참조 ). 98) Europäische Gemeinschaft a. European commission Joinup: EUPL-1.1/DE, 2007, wp. 2. 참조 99) OSLiC 50 쪽참고 100) 유럽공동체 a. European commission Joinup: EUPL-1.1/EN, 2007, wp. 2 참조, 말미에서. 101) 참고문헌 wp. 7 & 8. 참조 102) 참고문헌 wp. wp. 5. 참조 103) 참고문헌참조 104) 참고문헌 wp. 3. 참조 105) Open Source Initiative: EUPL-1.1 (OSI), 2007, wp. 1 참조 106) 참고문헌 wp. 5. 참조 107) Appendix 참조 - 31 -
하는의무사항은뒤집어질수있다. 첫단계에서 EUPL을따르는라이브러리를사용하면서 EPL 108) 을따르는다소무익한추가기능어플리케이션정도를공개할수있다. 두번째단계에서 EUPL 라이선스싱을유지하는대신에 EPL에기반하여배포할수있는 EUPL 라이브러리 가추가한다. 그리하여최종적으로약한효력의카피레프트라이선스인 Eclipse Public License에기반하여동일한저작물이확보된다. 109) EUPL-1.1의보호기능은라이선스내용자체를기준으로추정할만큼포괄적이지않으므로 110) EUPL 저자가강력한카피레프트라이선스를작성하고자한다는인상이독자에게심어진다하더라도기껏해야약한효력의카피레프트라이선스가될수있다. 그러나 EUPL 라이선스에서는사유화에대해추가개발물이보호되지않는다. 2.7 GNU General Public License(GPL) 의보호기능 GPL로알려진 GNU General Public License는자유소프트웨어재단에서관리하고제공되는라이선스로서 GNU 운영체제홈페이지 의일부로운영되고있다. 111) 현재, OSI가승인하는오픈소스라이선스에는 112) GPL-2.0 113), GPL-3.0 114) 두가지버전이있다. 두가지 GPL 버전이동일한결과와취지를목표로하고있지만문맥과논증구조에대해선다른경향이다. 따라서이두라이선스는별도로다루어야할것이다. 2.7.1 GPL-2.0 GPL-2.0 의보호기능은쉽게결정될수있다. 첫째, 소프트웨어를받은사용자가수정되지않은 소스코 드의사본 115) 을 복사및배포 하고, 사본또는그일부분을수정하여그수정본을배포 116) ( 소스코드 형태뿐만아니라바이너리형태로도 117) ) 할수있다. 그러므로승인된오픈소스라이선스 118) 에따라 108) 라이선스내용을따른다면다소무익한어플리케이션은 EUPL 라이브러리의함수를호출하여 EUPL 라이브러리에의존해야할필요가없다. 라이선스내용은 양립성라이선스에의한다른 [ 그밖의 ] 저작물은 파생작 과함께배포될수있음을 제시할뿐이다. 이표현에의해라이선스에서는파생작과다른저작물간에대비를이루고있다 ( 다른저작물은반드시파생작이될필요는없음을제시 ). 109) OSLiC 49 쪽참고 110) EUPL 의보호기능을규정하는유형은 FSF 에서처음에제시하고있다.(Free Software Foundation: Various Licenses and Comments about Them, 2013, pp. wp. section `European Union Public License'). The EU answers that publishing such a trick will comprise its user in the eyes of the open source community (cf. European Community a. European commission Joinup: New FSF statements on the EUPL are a step in the right direction; 2013 [n.y] hurl: https://joinup.ec.europa.eu/community/eupl/news/ new-fsf-statements-eupl-are-step-right-directioni { reference download: 2013-03-05, p. wp 참조 ). 이는의심할여지없이사실이다. 하지만, 이러한논쟁은 EUPL 에의해제기된보호막의구멍을막지못한다. 111) 자유소프트웨어재단 : GNU 운영체제 [:] 라이선스 ; 2011 (URL: http://www.gnu.org/licenses/) - 참고자료다운로드 : 2013-03-25, wp. 참조 112) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 113) 최초버전은 FSF 에서제공, Free Software Foundation: The GPL-2.0 License (FSF), 1991, wp. Open Source Initiative 에서제공하는버전참조, Open Source Initiative: GPL-2.0 License (OSI), 1991, wp. 참조 114) 최초버전은 FSF 에서제공 Free Software Foundation: GNU General Public License [version 3]; 2007 [html 페이지 n.y. ] (URL: http://www.gnu.org/licenses/gpl.html) - 참고자료다운로드 : 2013-03-06, wp 참조. Open Source Initiative 에서제공하는버전 Open Source Initiative: GPL-3.0 License (OSI), 2007, wp. 참조 115) Open Source Initiative: GPL-2.0 License (OSI), 1991, wp. 1. 참조 116) 인용한글과동일, wp. 2. 참조 117) 인용한글과동일, wp. 3. 참조 118) Open Source Initiative: 알파벳순서로분류한오픈소스라이선스, 2012, wp. 참조 - 32 -
GPL-2.0은배포받은소스코드나바이너리사본의사용, 수정, 배포할권리상실로부터사용자를보호한다. 둘째, GPL2.0은보증청구 119) 와피드백의손실로부터 ( 카피레프트에효력에의해 120) ) 사용자를보호한다. 셋째, GPL2-0은사유화에대해서거의완전히소스코드그자체를보호한다. 원저작물의일부를새파생작에복사하여 121) 다시제작한 ( 원저작물을 기반으로한작업 ) 바이너리수정버전만을처음에배포하더라도소스코드 122) ( 즉, 수정된전체저작물 123) ) 를제공해야한다. 이수정된 [ 원본 ] 프로그램을기반으로한저작물 은매우넓은의미로해석해야한다. 이는 copyright에의거한프로그램또는파생작 을의미한다. 다시말해, 글자그대로또는수정되거나다른언어로번역되든간에프로그램또는그일부를포함하는저작물을뜻한다. 124) 이러한이유로, 소프트웨어배포에서, GPL-2.0은소프트웨어의재사유화뿐만아니라추가개발물을사유하는것에대해서도대항하여보호한다. 그러나 GPL-2.0 에의해특허분쟁에대해서는사용자나기여자또는배포자가보호받지못하며 125), ( 재 ) 사유화에대해배포되지않은 ( 수정된 ) 소프트웨어는보호되지않는다. 126) 2.7.2 GPL-3.0 GPL-3.0에서중요한변경사항은 GPL 적용저작물 (covered work) 의 유포 (propagate) 또는 전송 (convey) 라는문구의사용이다. GPL 적용저작물 은 수정되지않은프로그램또는그프로그램을기반으로한저작물 을나타낸다. 특정프로그램을기반으로하는저작물 은 초기 저작물의 수정된버전 으로정의되는데여기서 수정된버전 이란특정프로그램을전체혹은일부분을 ( 복제 )( 수정 ) 하는것으로부터만들어지는수정된저작물을의미한다. 127) 반면에 저작물유포 는대중이이용할수있게하는 복사, 배포 ( 수정본, 원본 ) 와 개인사본을수정하거나컴퓨터에서실행하는것을제외한 기타유형의저작물을다루는행위를나타낸다. 128) 셋째, GPL-3.;0에서는저작물을 convey 하는것은 다른사람들이복사본을만들거나배포받을수있게하는모든유형의배포행위를의미한다 라고명시하고있다. 129) 이설명은받는사람이활발히프로그램을복사하거나패치 (fetch) 하는경우도배포행위라는점을명확히하는것에도움이된다. 119) Open Source Initiative: GPL-2.0 라이선스 (OSI), 1991, wp. 11, 12. 참조 120) 인용한글과동일, wp. 3. 참조 121) 인용한글과동일, wp. 2. 참조 122) Open Source Initiative: GPL-2.0 License (OSI), 1991, wp. 1. 참조 123) 인용한글과동일, wp. 3. 참조 124) 인용한글과동일, wp. 0. 참조 125) OSLiC, 50 쪽 126) 이는 AGPL 이비슷해지려는 GPL 의 부족한 부분이다. GPL-2.0 라이선스에따른서버소프트웨어를수정하여사회에다시개선된소프트웨어를제공할의무없이수정된소프트웨어기반서비스제공을위해자체기계에설치할수있다. 그러나적어도독일에서는이점에서엄격한제한을중시하는것으로보인다. 보유컴파트먼트로소프트웨어를배호하는것은 (GPL-2.0 라이선스소프트웨어의경우 ) 소스코드도배포해야하는의무를유발하는배포행위이다. [ 중요 : 인용문필요함!] 127) Open Source Initiative: GPL-3.0 라이선스 (OSI), 2007, wp. 0. 참조 128) Open Source Initiative: GPL-3.0 라이선스 (OSI), 2007, wp. 0. 참조. GPL 3.0 은특정제약사항을직접다루지않고전세계국가의저작권체계에적용할필요가있다. 따라서이라이선스에서는 FSF 취지에서 저작물을유포 라는문구의의미는일반적으로 개인사본을수정하거나컴퓨터에서실행하는것을제외하고 이문구가적용되어야하는특정저작권체계라고명시하고있다. 129) 위책과동일참조 - 33 -