Github에서 사용되는 주요 라이선스 종류 및 허용, 제약 사항
작성일:
오픈 소스 프로젝트를 시작하거나 기여할 때 가장 먼저 고려해야 할 것 중 하나는 라이선스(License)입니다. Github에는 수많은 프로젝트가 존재하며, 각 프로젝트는 코드 사용에 대한 권리와 의무를 규정하는 라이선스를 가지고 있습니다.
라이선스를 제대로 이해하지 못하고 코드를 사용하면 법적 분쟁에 휘말릴 수 있습니다. 이 글에서는 Github에서 가장 널리 사용되는 주요 오픈 소스 라이선스들의 특징과 허용 범위, 제약 사항을 정리해 봅니다.
1. MIT 라이선스 (MIT License)
MIT 라이선스는 가장 단순하고 제한이 적은 라이선스 중 하나로, Github에서 가장 많이 사용되는 라이선스입니다.
1-1. 특징
- 매우 관대함: 사용자가 코드를 자유롭게 사용, 수정, 배포할 수 있으며, 상업적 이용도 가능합니다.
- 단순함: 라이선스 문구가 짧고 명확합니다.
1-2. 요구 사항
- 저작권 고지 및 라이선스 사본 포함: 소스 코드나 소프트웨어를 배포할 때 원본의 저작권 표시와 MIT 라이선스 문구를 포함해야 합니다.
1-3. 제약 사항
- 책임 부인: 저작권자는 소프트웨어 사용으로 인한 어떠한 책임도 지지 않습니다.
한 줄 요약: “저작권 문구만 남겨주면 마음대로 써도 됨. 대신 책임은 안 짐.”
2. Apache 라이선스 2.0 (Apache License 2.0)
Apache 소프트웨어 재단에서 만든 라이선스로, MIT와 비슷하게 관대하지만 특허권에 대한 명시적인 조항이 포함되어 있습니다.
2-1. 특징
- 특허 권리 부여: 기여자가 자신의 특허 기술을 프로젝트에 포함시킨 경우, 사용자에게 해당 특허의 사용 권한을 자동으로 부여합니다.
- 상표권 보호: 저작권자의 상표(이름, 로고 등)를 허락 없이 사용할 수 없습니다.
2-2. 요구 사항
- 저작권, 라이선스, 보증 부인 고지 포함: 배포 시 관련 문서를 포함해야 합니다.
- 수정 사항 명시: 코드를 수정하여 배포할 경우, 수정된 파일에 수정 사실을 명시해야 합니다.
2-3. 제약 사항
- 비슷하게 책임 부인 조항이 있습니다.
- 특허 소송 제기 시 라이선스가 종료될 수 있는 ‘특허 보복 조항’이 포함되어 있습니다.
한 줄 요약: “마음대로 써도 되고 특허 문제도 해결해 줌. 대신 수정했으면 티를 내고 설명서(NOTICE)는 챙겨 줘.”
3. GNU 일반 공중 라이선스 (GNU GPL v3)
자유 소프트웨어 재단(FSF)에서 만든 강력한 Copyleft 라이선스입니다. 코드의 공개와 자유로운 공유를 강제하는 성격이 강합니다.
3-1. 특징
- 전염성 (Viral Effect): GPL 라이선스 코드를 사용하여 만든 파생 소프트웨어도 반드시 GPL로 배포해야 합니다.
- 소스 코드 공개 의무: 실행 파일(바이너리)을 배포할 경우, 반드시 소스 코드도 함께 제공해야 합니다.
3-2. 요구 사항
- 동일 라이선스 배포: 수정된 코드는 GPL v3 하에 배포되어야 합니다.
- 저작권 고지, 라이선스 사본 포함.
3-3. 제약 사항
- 독점 소프트웨어와 결합 제한: GPL 코드를 정적/동적 링크하여 사용하는 독점(비공개) 소프트웨어 개발이 어렵습니다. (이 경우 전체 코드를 공개해야 할 수 있음)
- 상업적 판매 자체는 가능하지만, 소스 코드를 구매자에게 제공해야 하므로 사실상 독점적 판매가 어렵습니다.
한 줄 요약: “자유롭게 써도 되지만, 수정해서 배포하면 너의 코드도 무조건 공개해야 해.”
4. GNU Affero 일반 공중 라이선스 (GNU AGPL v3)
GPL과 거의 동일하지만, 네트워크를 통해 서비스를 제공하는 경우(SaaS)에 대한 규정이 추가된 더욱 강력한 라이선스입니다.
4-1. 특징
- 네트워크 서비스도 배포로 간주: 일반적인 GPL은 실행 파일을 ‘배포’할 때만 소스 공개 의무가 생깁니다. 하지만 AGPL은 서버에서 실행되고 사용자가 네트워크로 접속해 사용하는 경우에도 ‘서비스 제공’을 배포와 유사하게 보아 소스 공개 의무를 부과합니다.
4-2. 요구 사항
- 네트워크 사용자에게 소스 공개: 프로그램을 네트워크를 통해 사용하는 모든 사용자에게 소스 코드(수정된 부분 포함)를 다운로드할 수 있는 방법을 제공해야 합니다.
- GPL v3의 모든 요구 사항을 포함합니다.
4-3. 제약 사항
- 가장 강력한 제약: 클라우드 서비스나 웹 서비스로 수익을 창출하려는 기업에게는 매우 까다로운 라이선스입니다. (예: MongoDB가 과거 AGPL을 사용했으나, 클라우드 사업자들과의 이슈로 SSPL로 변경함)
한 줄 요약: “GPL이랑 똑같은데, 이걸로 웹 사이트 만들어서 서비스만 해도 소스 다 공개해야 함.”
5. BSD 라이선스 (BSD 2-Clause / 3-Clause)
버클리 캘리포니아 대학(UC Berkeley)에서 배포한 라이선스로, MIT와 매우 유사하게 관대합니다. 주로 2-Clause(Simplified)와 3-Clause(New) 버전이 사용됩니다.
5-1. 특징
- 2-Clause: MIT 라이선스와 거의 동일합니다.
- 3-Clause: 2-Clause에 “저작권자의 이름을 홍보 목적으로 사용할 수 없다”는 조항이 추가된 버전입니다.
5-2. 요구 사항
- 저작권 고지 및 라이선스 사본 포함.
5-3. 제약 사항
- (3-Clause의 경우) 저작권자나 기여자의 이름을 제품 홍보나 보증에 사용할 수 없습니다.
한 줄 요약: “MIT랑 거의 비슷한데, 내 이름 팔아서 홍보하지 마. (3-Clause)”
6. 라이선스 비교 요약표
| 구분 | MIT | Apache 2.0 | GPL v3 | AGPL v3 | BSD (3-Clause) |
|---|---|---|---|---|---|
| 상업적 이용 | 허용 | 허용 | 허용 | 허용 | 허용 |
| 배포 허용 | 허용 | 허용 | 허용 | 허용 | 허용 |
| 수정 허용 | 허용 | 허용 | 허용 | 허용 | 허용 |
| 소스 코드 공개 의무 | 없음 | 없음 | 필수 (전염성) | 필수 (강력한 전염성) | 없음 |
| 특허 권리 부여 | 명시 없음 | 포함 | 포함 | 포함 | 명시 없음 |
| 라이선스 및 저작권 고지 | 필수 | 필수 | 필수 | 필수 | 필수 |
| 주요 사용 사례 | React, Vue | Android, Spark | Linux Kernel | Grafana(과거), MinIO | Nginx, Go |
6-1. 어떤 라이선스를 선택해야 할까?
- 최대한 널리 쓰이게 하고 싶다 (가장 관대): MIT
- 특허권 문제까지 깔끔하게 하고 싶다: Apache 2.0
- 내 코드를 가져다 쓴 사람이 소스를 비공개로 하는 꼴을 못 보겠다: GPL v3
- 웹 서비스 형태로만 얌체같이 쓰는 것도 용납 못 한다: AGPL v3
- 관대하지만 내 이름을 홍보에 이용하는 건 싫다: BSD 3-Clause
주의: 이 글은 일반적인 정보를 제공하기 위함이며 법적 자문이 아닙니다. 중요한 프로젝트나 법적 분쟁 소지가 있는 경우 전문 변호사의 상담을 받는 것이 좋습니다.
댓글남기기