오픈소스 라이선스 리스크 지도: MIT부터 AGPL까지, 무엇을 두려워하고 무엇은 두려워하지 않아도 되는가
오픈소스 라이선스는 2천 종이 넘지만, 기업의 법무와 엔지니어링 팀에 정말 필요한 것은 '전염성'으로 층위를 나눈 지도 한 장이다. 두려워할 대상을 잘못 고르면 효율을 잘못 죽이거나(모든 GPL 금지) 리스크를 놓친다(AGPL 컴포넌트를 SaaS에 넣는 것).
1층: 관용형 —— 마음 놓고 쓰되 저작자 표시는 잊지 말 것
MIT, BSD, Apache-2.0은 관용형(Permissive)이다. 상용·수정·클로즈드소스 배포가 모두 허용되고 의무는 사실상 저작권 고지와 라이선스 원문 유지뿐이다. Apache-2.0은 특허 허여 조항까지 있어 기업에는 오히려 보호막이 된다. 이 층의 진짜 리스크는 라이선스가 아니라 실행 디테일이다. NOTICE 파일 하나 없는 '저작자 표시 제로' 납품은 고객 실사에서 똑같이 컴플라이언스 결함으로 기록된다. 감사에서 가장 흔히 발견되는 문제는 관용형 코드의 저작권 헤더까지 벗겨 자체 개발로 취급하는 경우인데, 이는 스니펫 수준 탐지 앞에서 숨을 곳이 없다. 자세한 내용은 SCA 도구 선택 가이드를 참고하라.
2층: 약한 카피레프트 —— 건드려야만 전염된다
LGPL, MPL-2.0, EPL은 약한 카피레프트로, '파일' 또는 '라이브러리'가 경계다. 그 파일을 수정하면 해당 부분을 공개해야 하지만, 경계만 깨끗이 유지하면 자사 코드는 영향받지 않는다. 엔지니어링의 관건은 링크와 격리 방식이다. LGPL 컴포넌트를 동적 링크로 쓰면 대개 안전하지만, 정적 링크는 제품 전체를 오픈소스 의무로 끌고 들어갈 수 있다. 정적 링크가 일상인 임베디드와 C/C++ 프로젝트가 최대 위험 지대다.
3층: 강한 카피레프트 —— 배포하는 순간 발동
GPL-2.0/3.0의 규칙은 단순하고 엄격하다. GPL 코드가 포함된 소프트웨어를 배포하는 순간, 파생 저작물 전체를 GPL로 공개해야 한다. 대외 납품하는 상용 소프트웨어, 기기에 선탑재된 펌웨어, 클라이언트 프로그램 모두 배포에 해당한다. 다만 흔히 오해되는 두 경계가 있다. 첫째, 순수 내부 사용은 배포가 아니다. 자사 서버에서 GPL 소프트웨어를 쓰는 것만으로는 공개 의무가 없다. 둘째, GPL의 '파생 저작물' 경계는 법적으로 여전히 회색지대가 있다. 독립 프로세스 간 통신은 대개 전염되지 않고, 깊은 링크는 리스크가 높다.
4층: 네트워크 전염과 상업 제한 —— SaaS 시대의 새 지뢰밭
AGPL-3.0은 발동 조건을 '배포'에서 '네트워크를 통한 서비스 제공'으로 확장했다. 사용자가 네트워크로 당신의 SaaS를 쓰면 소스를 공개해야 한다. 주요 클라우드 사업자들이 AGPL을 금지 목록에 올린 이유가 바로 이것이다. 더 새로운 '소스 공개형(source-available)' 라이선스들은 한 발 더 나간다. SSPL(MongoDB), BSL(한때 HashiCorp가 사용), Elastic License는 '경쟁 호스팅 서비스 제공'을 직접 제한한다. 이들은 더 이상 OSI 인증 오픈소스 라이선스가 아니지만, 수많은 팀이 여전히 이 컴포넌트들을 일반 오픈소스처럼 들여온다. 최근 유명 프로젝트들의 잇단 라이선스 전환이 증명하듯 라이선스는 정적 속성이 아니다. 버전 업그레이드가 모든 것을 바꿀 수 있으므로, 버전을 고정할 때는 라이선스 버전도 함께 고정해야 한다.
3단계 거버넌스 방법
1단계: 자산 파악. CleanSource SCA로 코드베이스를 전량 스캔한다. 핵심은 의존성 매니페스트에 선언된 것이 아니라 복사-붙여넣기와 개명 재사용으로 들어온 것이다. 라이선스 리스크가 가장 높은 코드는 대개 매니페스트에 보이지 않는 바로 그 부분이다. 가볍게 시작하려면 무료 커뮤니티 에디션이 있다.
2단계: 배포 형태별 정책 수립. 같은 컴포넌트라도 사내 도구·대외 납품·SaaS 세 형태에서 리스크는 완전히 다르다. 정책은 매트릭스(라이선스 유형 × 배포 형태 × 허용/심사/금지)로 작성해 스캔 도구의 도입 게이트로 설정해야지, 법무팀의 Word 문서에 잠들게 해서는 안 된다.
3단계: 의무 이행의 엔지니어링화. 릴리스마다 갱신되는 오픈소스 고지 파일(NOTICE/attribution)을 자동 생성하고, 라이선스 정보를 SBOM에 담아 함께 납품한다. 고객 검수와 수출 인증 때 이 파일의 존재 여부가 컴플라이언스 점검이 10분에 끝날지 10일이 걸릴지를 직접 결정한다.
라이선스 컴플라이언스의 목표는 'GPL 박멸'이었던 적이 없다. 모든 도입을 정보에 근거한 의사결정으로 만드는 것이다. 지도가 분명해졌다면, 어느 길로 갈지는 비즈니스의 자유다.