오픈소스 라이선스 (정리)
라이선스 종류
오픈소스 라이선스를 분류한 기준은 다음과 같습니다.
- Reciprocal vs Permissive
오픈소스 라이선스를 분류할 때 가장 중요한 기준은 Copyleft 조항이 있는지 여부입니다. Copyleft조항 즉, 배포시 소스코드 제공의무 있는지(Reciprocal) 없는지 (Permissive)로 우선 분류됩니다. - 조합저작물 작성 및 타 라이선스 허용
Copyleft 중에서도 타 라이선스를 허용하는지에 따라 Strong Copyleft/ Weak Copyleft로 나눌 수 있습니다. - 추가 제약 존재
Copylef가 아닌 라이선스 즉 Permissive 라이선스의 경우,공통 준수사항 외에 추가적인 제약사항이 존재하는지 여부로 나눌 수 있습니다. - 추가로, 라이선스의 출현 배경에 따라서 크게 MPL타입, GPL타입 그리고 BSD타입으로 나눌 수도 있습니다.
Copyleft는 저작권을 기반으로 한 정보의 공유를 위한 개념입니다. 정보의 사용 제한에 반대한다는 의미에서 Copy-right가 아닌 Copy-left라고 명칭한 것입니다. Copyleft는 소수에게만 지식과 정보가 독점되지 않고, 모든 사람에게 열려 있는 것을 목표로 합니다.
# 1 BSD 형
카피레프트(Copyleft) 조항을 포함하지 않고 소스코드 제공 의무도 없어 의무사항이 비교적 간단한 라이선스 입니다. BSD형의 라이선스로 배포되는 다양한 코드를 이용하여 자사의 제품을 만든 후 이를 상용 라이선스로 배포하는 것도 가능합니다.
1. BSD(Berkeley Software Distribution) License
버클리의 캘리포니아대학에서 배포하는 공개 SW 라이선스다. BSD 자체가 공공기관에서 만들어낸 것이므로 공공의 몫으로 돌려주자는 의미가 강하므로, 라이선스 자체에는 아무런 제한 없이 누구나 자신의 용도로 사용할 수 있습니다. 라이선스 및 저작권 표시 조건 외엔 제약이 없는, 굉장히 자유로운 라이선스 중 하나입니다.
– 적용 사례 : Nginx(The BSD 2-Clause License)
2. Apache License
아파치 라이선스는 아파치소프트웨어재단이 자기네 SW에 적용하기 위해 자체적으로 만든 라이선스입니다. 소스코드 공개 의무 같은 의무사항은 없지만, 아파치 라이선스 소스코드를 수정해 배포하는 경우 아파치 라이선스 버전 2.0을 꼭 포함시켜야 하며 아파치재단에서 만든 소프트웨어임을 밝혀야 합니다.
– 적용 사례 : 안드로이드, 하둡
3. MIT License
MIT 라이선스는 미국 매사추세츠공과대학교(MIT)에서 해당 대학 SW 공학도들을 돕기 위해 개발한 라이선스입니다. 라이선스와 저작권 관련 명시만 지켜주면 되는 라이선스로, 가장 느슨한 조건을 가진 라이선스 중 하나이기 때문에 인기가 많습니다.
– 적용 사례 : 부트스트랩 , Angular.js, Backbone.js, jQuery
# 2 GPL 형
GNU 일반 공중 사용 허가서(GPL)는 자유 소프트웨어 재단에서 만든 라이선스입니다. BSD와 비슷하지만, Copyleft 조항이 있다는 점이 큰 차이점입니다.
1. GPL(General Public License - GNU(Gnu is Not Unix))
자유소프트웨어재단(FSS)에서 만든 라이선스입니다. GNU 프로젝트로 배포하는 소프트웨어(Emacs, GNU 디버거(GDB), GNU 컴파일러 모음(GCC) 등)에 적용하기 위해 리처드 스톨만이 만들었습니다. 가장 큰 특징은 자유소프트웨어재단답게 가장 강력한 제약 조건을 포함하고 있는 카피레프트(Copyleft) 조항입니다. GPL 프로그램은 어떤 목적으로, 어떤 형태로든 사용할 수 있지만 사용하거나 변경된 프로그램을 배포하는 경우 무조건 동일한 라이선스 즉, GPL로 공개해야 합니다.
– 적용 사례 : 모질라 파이어폭스, 리눅스 커널, 깃, 마리아DB, 워드프레스, 드루팔
2. LGPL(GNU Lesser GPL)
자유소프트웨어재단의 강력한 철학이 담긴 GPL의 카피레프트 조항을 보완하기 위해 만든 라이선스입니다. GPL은 단순히 소프트웨어를 사용하기만 하더라도 해당 소스코드를 GPL로 공개해야 하는 부담감 때문에 상용 소프트웨어로 쓰기 부담스럽다는 단점이 있습니다. 그래서 좋은 자유 소프트웨어 제품이 더 많이 쓰이고 표준이 되도록 유도하기 위해 단순한 라이브러리·모듈 링크를 허용한 라이선스입니다. 원래는 한정된 라이브러리에만 적용하려는 의도로 ‘Library GPL’이라는 이름을 붙였으나, 모든 라이브러리에 적용된다는 오해를 사 ‘Lesser GPL’로 변경됐습니다.
– 적용 사례 : 모질라 파이어폭스
3. AGPL(GNU Affero GPL)
GPL을 기반으로 만든 라이선스로 버전1, 2는 아페로, 가장 최신 버전인 버전3은 자유소프트웨어재단에 의해 개발됐습니다. 수정한 소스코드를 서버에서만 사용하는 개발자가 그 프로그램을 배포하지 않을 경우 사용자는 소스코드를 가질 수가 없는 문제를 해결하기 위해 마련됐습니다. 서버에서 프로그램을 실행해 다른 사용자들과 통신하면, 실행되고 있는 프로그램의 소스코드를 사용자들이 다운로드할 수 있게 해야 한다는 독특한 조항을 담고 있습니다.
– 적용 사례 : 몽고DB
4. Artistic License
펄 프로그래밍 언어를 사용하던 래리 월이 표준 펄 기능을 위해 만든 라이선스입니다. 이 단어의 어원은 문학에서 문법상 틀린 표현이라도 시적인 효과를 위해 허용한다는 걸 의미하는 ‘Articstic License'(시적 허용)를 참조해 만들어졌습니다.
– 적용 사례 : NPM(Node Package Manager)
# MPL 형
주로 기업들이 주도하는 오픈소스 프로젝트에서 사용하는 라이선스로, BSD 형 GPL형 라이선스와 다르게 처음부터 법률가들이 참여하여 만든 라이선스 입니다.
1. Eclipse License
이클립스사에서 비즈니스 환경에 적합하도록 만든 기업 친화적인 라이선스로, 강력한 카피레프트 조항이 담긴 GPL보다 제약 조건이 완화된 라이선스입니다.
– 적용 사례 : 이클립스
2. Mozilla Public License(MPL)
모질라 공용 허가서는 과거 넷스케이프 웹브라우저의 소스코드를 공개하기 위해 개발된 라이선스입니다. 초기 1.0버전은 넷스케이프 커뮤니케이션의 변호사였던 밋첼 베이커가 작성했고, 1.1과 2.0버전은 모질라재단이 작성했습니다. MPL의 특징은 소스코드와 실행파일의 저작권을 분리했다는 점입니다. 수정한 소스코드는 MPL로 공개하고 원저작자에게 수정한 부분에 대해 알려야 하지만, 실행파일은 독점 라이선스로 배포할 수 있습니다. 즉 사용한 MPL 소프트웨어와 수정한 MPL 소프트웨어에 대한 공개 의무만 가지며, 별도의 소스코드와 실행파일은 독점 라이선스를 가질 수 있습니다.
– 적용 사례 : 모질라 파이어폭스, 모질라 썬더버드
조건표
| 라이선스 | 필수 사항(Required) | 허락 조건(Permitted) | 금지 조건(Forbidden) |
| BSD License 제약조건:하 |
|
|
|
| Apache License 제약조건:하 |
|
|
|
| MIT License 제약조건:하 |
|
|
|
| GPL v2.0/v3.0 제약조건:상 |
|
|
|
| GNU AGPL (Affero GPL) v3.0 제약조건:최상 |
|
|
|
| GNU LGPL (Lesser GPL) v2.1/v3.0 제약조건:중 |
|
|
|
| Artistic License 제약조건:하 |
|
|
|
| Eclipse License 제약조건:중 |
|
|
|
| MPL v2.0 (Mozilla Public License) 제약조건:중 |
|
|
|
'Tech & Development > 개발환경' 카테고리의 다른 글
| Hugging Face Inference API Key 발급 (0) | 2023.03.30 |
|---|---|
| 클라우드 기반 Jupyter Notebook (Cloud Base Notebook) 종류 (0) | 2023.01.19 |
| Mac에서 AWS Windows Server(EC2) 원격제어 (RDP클라이언트) (0) | 2022.09.29 |
| JetBrains Space 시작하기 (0) | 2022.06.27 |
| Flask(플라스크) 설치/시작하기 (0) | 2022.03.07 |