오픈소스 라이선스 호환성, 왜 신경 써야 할까요?
오픈소스 라이선스는 "공개되어 있다"가 곧 "마음대로 써도 된다"를 뜻하지 않습니다. MIT처럼 거의 모든 사용을 허용하는 허용형 라이선스부터, 결합한 모든 코드를 같은 조건으로 공개해야 하는 GPL 같은 강력 카피레프트, 네트워크 서비스로 제공해도 소스 공개 의무가 발생하는 AGPL까지 스펙트럼이 매우 넓습니다. 이 도구는 가장 자주 쓰이는 12종 라이선스 — MIT, Apache 2.0, BSD-2/3-Clause, ISC, MPL 2.0, LGPL 2.1/3.0, GPL 2.0/3.0, AGPL 3.0, Unlicense, CC0 — 를 묶어 4가지 핵심 권한(상업적 사용, 배포, 수정, 사적 사용)과 2가지 의무(라이선스 고지, 변경된 소스 공개)를 한 화면에 정리합니다.
여러 라이선스를 동시에 선택하면 결합 시 어떤 라이선스를 따라야 하는지 결합 결과를 계산합니다. 예를 들어 MIT + GPL-3.0을 결합하면 최종 결과물은 GPL-3.0을 따라야 하고(MIT는 GPL과 호환되지만 GPL이 우세), Apache-2.0 + GPL-2.0은 특허 조항 충돌로 비호환이므로 GPL-3.0으로 이중 라이선스된 버전을 찾아야 한다는 식의 진단을 받을 수 있습니다.
허용형 vs 카피레프트의 핵심 차이
MIT, BSD, Apache 같은 허용형(Permissive) 라이선스는 거의 모든 행위를 허용하지만 "원저작권 고지를 유지하라"는 최소한의 의무만 요구합니다. 반면 GPL 계열은 결합·파생물 전체를 같은 라이선스로 공개해야 합니다. LGPL은 라이브러리로 동적 링크되는 경우 한해 카피레프트가 완화되며, MPL 2.0은 파일 단위 카피레프트로 파일이 다르면 다른 라이선스로 결합할 수 있습니다.
자주 묻는 질문 (FAQ)
Q. 사내에서만 쓰는 코드인데 GPL 라이브러리를 써도 되나요?
A. 일반 GPL은 외부 배포 시점에만 소스 공개 의무가 발생합니다. 사내 내부 사용만 한다면 의무가 트리거되지 않습니다. 다만 AGPL은 네트워크 서비스로 제공하는 것도 "배포"로 간주하므로 SaaS 서비스에서는 매우 주의해야 합니다.
Q. MIT 라이브러리에 패치를 보내면 그 패치는 무슨 라이선스인가요?
A. 별도 명시가 없으면 원 프로젝트의 MIT를 따른다고 봅니다. 대부분의 오픈소스 프로젝트는 CLA/DCO로 이 점을 명문화합니다.
Q. 이 도구의 결과를 그대로 법무에 제출해도 되나요?
A. 이 진단은 일반적인 가이드이며 법적 자문이 아닙니다. 상업 제품·계약·소송 관련 결정은 반드시 변호사 또는 OSPO 담당자와 상의하세요.