부끄럽지만 용기내어 고백해볼게요. 크리에이티브 커먼즈 코리아 활동가로 지내면서 크리에이티브 커먼즈 라이선스(CCL)엔 어느정도 익숙하고 많은 사례도 접해왔지만, ‘오픈소스를 활용하고 오픈소스를 만들자’라고 주창하는 오픈소스 개발자로서 오픈소스 라이선스에 대한 기본 지식은 부족했습니다. 그냥 GPL, 아파치, MIT 라이선스가 주석으로 붙어 있으면 ‘아, 오픈소스구나’라고 생각하는 정도였죠. 많은 사람들이 가져다 쓰는 오픈소스 소프트웨어를 가져다 쓰면서도 ‘어떻게 공개해야 하지?’라는 고민은 해본 적 없었습니다. 특정 오픈소스 프로젝트에서 ‘우리가 오픈소스 정책을 바꿨어. 왜 이런 결정을 내렸냐면…’ 이라는 공지를 보며 제대로 이해를 못하면서 그냥 넘어간 적도 있었습니다.
부끄럽지만 고백합니다…. CC0.
그래서 격주에 한 번 연재하는 춘식이의 코드이야기를 기회삼아 스스로 오픈소스 라이선스에 대해 공부할 기회를 갖기로 마음먹었습니다. 대표적인 오픈소스 라이선스들을 알아보고, 특징과 조건들을 비교해보았습니다. 대표 적용 사례도 소개합니다. 여기 정리한 라이선스 외에도 수많은 오픈소스 라이선스들이 존재하며 여기 있는 라이선스조차도 제가 정리하지 못한 많은 부분들이 많지만, 앞으로는 오픈소스 SW를 활용하거나 오픈소스 SW를 만들 때 라이선스에 대해 한 번쯤 고민할 수 있는 계기가 됐으면 좋겠습니다. 수정하거나 보완할 내용이 있으면 알려주시기 바랍니다.
*이하 설명하고 있는 오픈소스 라이선스는 소스코드에 적용되는 라이선스이며 일반적으로 소스코드에 대한 문서나 콘텐츠에 대한 라이선스는 CCL 등 별도의 라이선스를 적용합니다.
라이선스 종류
Apache License
– 아파치 라이선스는 아파치소프트웨어재단이 자기네 SW에 적용하기 위해 자체적으로 만든 라이선스다. 소스코드 공개 의무 같은 의무사항은 없지만, 아파치 라이선스 소스코드를 수정해 배포하는 경우 아파치 라이선스 버전 2.0을 꼭 포함시켜야 하며 아파치재단에서 만든 소프트웨어임을 밝혀야 한다.
GNU(Gnu is Not Unix) General Public License(GPL)
– 자유소프트웨어재단에서 만든 라이선스다. GNU 프로젝트로 배포하는 소프트웨어(Emacs, GNU 디버거(GDB), GNU 컴파일러 모음(GCC) 등)에 적용하기 위해 리처드 스톨만이 만들었다. 가장 큰 특징은 자유소프트웨어재단답게 가장 강력한 제약 조건을 포함하고 있는 카피레프트 조항이다. GPL 프로그램은 어떤 목적으로, 어떤 형태로든 사용할 수 있지만 사용하거나 변경된 프로그램을 배포하는 경우 무조건 동일한 라이선스 즉, GPL로 공개해야 한다.
– 적용 사례 : 모질라 파이어폭스(v2.0), 리눅스 커널(v2.0), 깃(v2.0), 마리아DB(v2.0), 워드프레스(v2.0), 드루팔(v2.0)
GNU Affero GPL(AGPL)
– GPL을 기반으로 만든 라이선스로 버전1, 2는 아페로, 가장 최신 버전인 버전3은 자유소프트웨어재단에 의해 개발됐다. 수정한 소스코드를 서버에서만 사용하는 개발자가 그 프로그램을 배포하지 않을 경우 사용자는 소스코드를 가질 수가 없는 문제를 해결하기 위해 마련됐다. 서버에서 프로그램을 실행해 다른 사용자들과 통신하면, 실행되고 있는 프로그램의 소스코드를 사용자들이 다운로드할 수 있게 해야 한다는 독특한 조항을 담고 있다.
– 적용 사례 : 몽고DB(v3.0)
GNU Lesser GPL(LGPL)
– 자유소프트웨어재단의 강력한 철학이 담긴 GPL의 카피레프트 조항을 보완하기 위해 만든 라이선스다. GPL은 단순히 소프트웨어를 사용하기만 하더라도 해당 소스코드를 GPL로 공개해야 하는 부담감 때문에 상용 소프트웨어로 쓰기 부담스럽다는 단점이 있다. 그래서 좋은 자유 소프트웨어 제품이 더 많이 쓰이고 표준이 되도록 유도하기 위해 단순한 라이브러리·모듈 링크를 허용한 라이선스이다. 원래는 한정된 라이브러리에만 적용하려는 의도로 ‘Library GPL’이라는 이름을 붙였으나, 모든 라이브러리에 적용된다는 오해를 사 ‘Lesser GPL’로 변경됐다.
– 적용 사례 : 모질라 파이어폭스(v2.1)
MIT License
– MIT 라이선스는 미국 매사추세츠공과대학교(MIT)에서 해당 대학 SW 공학도들을 돕기 위해 개발한 라이선스다. 라이선스와 저작권 관련 명시만 지켜주면 되는 라이선스로, 가장 느슨한 조건을 가진 라이선스 중 하나이기 때문에 인기가 많다.
– 적용 사례 : 부트스트랩 , Angular.js, Backbone.js, jQuery
Artistic License
– 펄 프로그래밍 언어를 사용하던 래리 월이 표준 펄 기능을 위해 만든 라이선스다. 이 단어의 어원은 문학에서 문법상 틀린 표현이라도 시적인 효과를 위해 허용한다는 걸 의미하는 ‘Articstic License'(시적 허용)를 참조해 만들어졌다.
– 적용 사례 : NPM(Node Package Manager)(v2.0)
Eclipse License
– 이클립스사에서 비즈니스 환경에 적합하도록 만든 기업 친화적인 라이선스로, 강력한 카피레프트 조항이 담긴 GPL보다 제약 조건이 완화된 라이선스이다.
– 적용 사례 : 이클립스(v1.0)
Berkeley Software Distribution(BSD) License
– 버클리의 캘리포니아대학에서 배포하는 공개 SW 라이선스다. BSD 자체가 공공기관에서 만들어낸 것이므로 공공의 몫으로 돌려주자는 의미가 강하므로, 라이선스 자체에는 아무런 제한 없이 누구나 자신의 용도로 사용할 수 있다. 라이선스 및 저작권 표시 조건 외엔 제약이 없는, 굉장히 자유로운 라이선스 중 하나이다.
– 적용 사례 : Nginx(The BSD 2-Clause License)
Mozilla Public License(MPL)
– 모질라 공용 허가서는 과거 넷스케이프 웹브라우저의 소스코드를 공개하기 위해 개발된 라이선스다. 초기 1.0버전은 넷스케이프 커뮤니케이션의 변호사였던 밋첼 베이커가 작성했고, 1.1과 2.0버전은 모질라재단이 작성했다. MPL의 특징은 소스코드와 실행파일의 저작권을 분리했다는 점이다. 수정한 소스코드는 MPL로 공개하고 원저작자에게 수정한 부분에 대해 알려야 하지만, 실행파일은 독점 라이선스로 배포할 수 있다. 즉 사용한 MPL 소프트웨어와 수정한 MPL 소프트웨어에 대한 공개 의무만 가지며, 별도의 소스코드와 실행파일은 독점 라이선스를 가질 수 있다.
조건표
| 라이선스 | 필수 사항(Required) | 허락 조건(Permitted) | 금지 조건(Forbidden) |
|---|---|---|---|
| Apache License 제약조건:하 |
|
|
|
| GPL v2.0/v3.0 제약조건:상 |
|
|
|
| GNU AGPL (Affero GPL) v3.0 제약조건:최상 |
|
|
|
| GNU LGPL (Lesser GPL) v2.1/v3.0 제약조건:중 |
|
|
|
| MIT License 제약조건:하 |
|
|
|
| Artistic License 제약조건:하 |
|
|
|
| Eclipse License 제약조건:중 |
|
|
|
| BSD License 제약조건:하 |
|
|
|
| MPL v2.0 (Mozilla Public License) 제약조건:중 |
|
|
|
| Beerware 제약조건: 최하 |
|
뭐가 이리 복잡해! 그냥 나중에 만나면 맥주나 한 잔 사줘! – Beerware License 적용하기. CC BY-NC-SA, Image from @slworking2 – https://flic.kr/p/bEj5mo
- CC BY 3.0, http://choosealicense.com/licenses/
- CC BY-NC-SA 2.0, https://wiki.kldp.org/wiki.php/OpenSourceLicenseGuide#s-3.2.4
- CC BY-SA 3.0, https://ko.wikipedia.org/wiki/GNU_약소_일반_공중_사용_허가서
- CC BY-SA, https://en.wikipedia.org/wiki/Affero_General_Public_License
- CC BY-SA, https://en.wikipedia.org/wiki/Eclipse_Public_License
- CC BY-SA, https://en.wikipedia.org/wiki/Artistic_license
글_장승훈. 크리에이티브 커먼즈 코리아와 코드나무 활동가. 히피개발자를 꿈꾸며 독학하는 대학생. 웹과 IT기술이 보다 나은 세상을 만들 수 있다고 믿습니다. 트위터_@thechunsik
출처 : http://www.bloter.net/archives/209318
'프로그래밍 > ETC...' 카테고리의 다른 글
| REST(Representational State Transfer), RESTful 개념 (0) | 2018.02.19 |
|---|---|
| 코딩 테스트 연습할 곳 (0) | 2018.01.27 |
| 똑똑한 인재만 모아놓은 프로젝트 팀, 결국 산으로 가는 이유 (0) | 2018.01.07 |
| 조직, 프로젝트 구성원의 역할 (0) | 2018.01.07 |
| [ 개발자 업무 파악 ] SI와 SM의 차이와 하루일과 (0) | 2018.01.03 |
