오픈소스 라이선스 도우미 완벽 가이드
오픈소스 소프트웨어 프로젝트를 시작할 때 가장 중요하면서도 많은 개발자가 간과하는 부분이 바로 라이선스 선택입니다. 적절한 라이선스를 선택하지 않으면 저작권 분쟁, 법적 문제, 커뮤니티 참여 저하 등 다양한 문제가 발생할 수 있습니다. 이 도구는 개발자가 프로젝트의 성격과 목적에 맞는 라이선스를 쉽게 비교하고 선택할 수 있도록 도와줍니다.
라이선스 선택이 중요한 이유
소프트웨어 라이선스는 해당 소프트웨어를 다른 사람이 어떻게 사용, 수정, 배포할 수 있는지를 법적으로 정의합니다. 라이선스가 없는 코드는 기본적으로 저작권법에 의해 보호되므로, 다른 사람이 사용할 수 없습니다. 따라서 오픈소스로 공개하려면 반드시 적절한 라이선스를 명시해야 합니다. GitHub에 공개된 프로젝트 중 라이선스가 없는 경우, 법적으로는 해당 코드를 포크하거나 수정하는 것이 저작권 침해가 될 수 있습니다.
주요 라이선스별 특징
MIT License는 가장 널리 사용되는 허용적(permissive) 라이선스로, 저작권 고지만 유지하면 상업적 사용, 수정, 배포가 모두 자유롭습니다. React, jQuery, Node.js 등 수많은 유명 프로젝트가 MIT 라이선스를 채택하고 있습니다. 단순하고 제약이 적어 초보 개발자에게 가장 추천되는 라이선스입니다.
Apache License 2.0은 MIT와 유사하게 허용적이지만, 특허 사용권을 명시적으로 부여하고 변경 사항을 표시해야 한다는 점이 다릅니다. 기업 환경에서 특허 관련 보호가 필요한 경우 적합합니다. Android, Kubernetes, Swift 등이 Apache 2.0을 사용합니다.
BSD 2-Clause와 3-Clause는 MIT와 매우 유사한 허용적 라이선스입니다. 3-Clause 버전은 저작권자의 이름을 홍보 목적으로 사용할 수 없다는 조항이 추가되어 있어, 브랜드 보호가 필요한 프로젝트에 적합합니다.
MPL 2.0 (Mozilla Public License)은 약한 카피레프트(weak copyleft) 라이선스로, 수정된 파일은 동일한 라이선스로 공개해야 하지만 새로 추가된 파일은 다른 라이선스를 적용할 수 있습니다. Firefox와 Thunderbird가 대표적인 MPL 프로젝트입니다.
The Unlicense는 저작권을 완전히 포기하고 퍼블릭 도메인으로 공개하는 라이선스입니다. 아무런 조건 없이 자유롭게 사용할 수 있지만, 일부 법적 관할권에서는 저작권 포기가 인정되지 않을 수 있으므로 주의가 필요합니다.
프로젝트 유형별 추천 라이선스
- 라이브러리/프레임워크: MIT 또는 Apache 2.0 (최대한 많은 채택을 원할 때)
- 기업용 프로젝트: Apache 2.0 (특허 보호 필요 시)
- 커뮤니티 기여 중심: MPL 2.0 (수정된 파일의 공개를 보장)
- 완전한 자유 공개: Unlicense 또는 MIT
- 학술/연구용: BSD 3-Clause (이름 사용 보호)
자주 묻는 질문 (FAQ)
Q. MIT 라이선스와 BSD 라이선스의 차이점은 무엇인가요?
A. MIT와 BSD 2-Clause는 실질적으로 거의 동일한 수준의 허용적 라이선스입니다. 가장 큰 차이는 문구의 표현 방식입니다. BSD 3-Clause는 저작권자의 이름을 파생 제품의 홍보에 사용할 수 없다는 조항이 추가되어 있어, 브랜드 보호 측면에서 약간 더 제한적입니다. 일반적으로 특별한 이유가 없다면 MIT 라이선스가 더 간결하고 널리 이해되어 있어 추천됩니다.
Q. GPL과 여기에 있는 라이선스들의 가장 큰 차이는 무엇인가요?
A. GPL은 강한 카피레프트(copyleft) 라이선스로, GPL 코드를 포함한 파생 작품 전체를 GPL로 공개해야 합니다. 반면 MIT, Apache 2.0, BSD 등은 허용적(permissive) 라이선스로, 파생 작품에 다른 라이선스를 적용하거나 비공개로 유지할 수 있습니다. MPL 2.0은 그 중간에 위치하여 수정된 파일만 공개하면 됩니다. 이 도구에서는 가장 많이 사용되는 허용적 라이선스와 MPL을 중심으로 제공합니다.
Q. 이미 배포한 프로젝트의 라이선스를 변경할 수 있나요?
A. 저작권자가 본인 한 명이라면 언제든지 라이선스를 변경할 수 있습니다. 다만 이미 이전 라이선스로 배포된 버전은 기존 라이선스가 계속 적용됩니다. 여러 기여자가 있는 프로젝트의 경우, 모든 기여자의 동의가 필요하므로 프로젝트 초기에 CLA(Contributor License Agreement)를 설정하는 것이 좋습니다. 라이선스 변경 시에는 CHANGELOG에 명확히 기록하고, 새 버전부터 적용되는 것임을 명시해야 합니다.
Q. 라이선스 파일은 프로젝트 어디에 위치해야 하나요?
A. 프로젝트 루트 디렉토리에 LICENSE 또는 LICENSE.txt라는 이름으로 저장하는 것이 표준 관행입니다. GitHub, GitLab 등 대부분의 코드 호스팅 플랫폼은 이 위치의 라이선스 파일을 자동으로 인식하여 프로젝트 페이지에 라이선스 정보를 표시합니다. 추가로 각 소스 파일 상단에 짧은 라이선스 헤더를 포함하는 것도 좋은 관행입니다.