MIT도 지킬 의무가 있습니다

npm install 한 번에 수백 개 패키지가 딸려 들어옵니다. 그중 라이선스를 확인해본 게 몇 개나 될까요. 저는 솔직히 거의 없습니다.

20일차에 AI가 추천한 패키지를 설치하는 보안 위험을 다뤘는데, 법적 위험도 비슷한 구조로 쌓입니다. 확인하지 않은 채 쌓이다가 배포 시점에 터지는 식이죠.

오픈소스는 "조건부 허용"이다

가장 흔한 오해부터 짚으면, 오픈소스는 "마음대로 써도 되는 코드"가 아닙니다. 저작권자가 특정 조건을 지키면 쓰라고 허락한 것이고, 조건을 어기면 무단 사용이 됩니다.

MIT는 가장 자유롭습니다. 수정, 재배포, 상업적 사용, 사유화까지 다 됩니다. 그런데 의무가 없는 건 아닙니다. 저작권 고지와 라이선스 전문을 사본에 포함해야 합니다.

여기서 실무적으로 자주 놓치는 지점이 있습니다. 바이너리 배포에도 적용된다는 것. 앱스토어에 올리는 앱, 도커 이미지, npm 패키지 전부 해당합니다. 소스를 공개할 필요는 없지만 고지는 넣어야 합니다. 앱에 "오픈소스 라이선스" 메뉴가 있는 게 이 때문인데, 이걸 빠뜨린 앱이 생각보다 많습니다.

MIT의 함정은 특허입니다. 특허 관련 조항이 없어서, 코드를 공개한 회사가 그 알고리즘 특허를 별도로 보유하고 있으면 나중에 특허 문제를 제기할 여지가 남습니다.

Apache 2.0은 그 지점을 보완합니다. 기여자가 특허권을 행사하지 않겠다는 조항이 들어 있어서 기업이 선호합니다.

GPL 계열은 copyleft입니다. 가져다 쓴 코드를 배포하면 내 코드도 같은 조건으로 공개해야 합니다. 여기서 핵심은 "배포"라는 조건인데, 사내에서만 쓰고 배포하지 않으면 공개 의무가 발생하지 않습니다.

소스 공개 대신 약정서를 제공하는 방법도 있습니다. 최소 3년간 소스코드를 제공하겠다는 서면을 실행물과 함께 배포하고, 요청 시 제공하는 방식입니다.

참고로 GPL-3.0과 LGPL-3.0은 사용자 제품에 대해 설치 정보까지 제공해야 하는 조항이 있어서, 기업이 준수하기 어렵다는 이유로 임베디드 제품에서는 사용을 피하는 경우가 많습니다.

AGPL이 진짜 함정이다

AGPL은 GPL의 "배포" 개념을 네트워크로 확장합니다. 서버에서 실행해 서비스를 제공하는 것만으로도 배포로 간주합니다.

즉 바이너리를 아무에게도 안 뿌려도, SaaS나 API로 서비스하면 소스 공개 의무가 생깁니다. 웹 서비스를 만드는 입장에서는 이게 결정적입니다. 실제로 많은 기업의 오픈소스 정책에서 AGPL은 네트워크 서비스 개발 시 사용 금지 목록에 올라 있습니다.

실제 분쟁 사례들

추상적으로 들리지만 실제 소송이 계속 있었습니다.

2008년 시스코는 GPL 코드가 포함된 Linksys 라우터 펌웨어를 의무 이행 없이 배포해 소송을 당했습니다. 한컴은 Ghostscript를 상용 제품에 포함하면서 라이선스 비용을 내지 않아 미국 법원에서 패소했고요.

프랑스 통신사 오랑주는 오픈소스 라이브러리를 쓰면서 GPL을 준수하지 않아 약 9억 4천만원 손해배상 판결을 받았습니다. 이 사건이 주목받은 이유는 GPL 분쟁이 주로 임베디드 기기에서 나오는데, 이건 B2B 웹서비스 구축 사례였다는 점입니다. 서버 쪽도 안전지대가 아니라는 뜻이죠.

최근에는 2025~2026년 Rockchip과 FFmpeg의 라이선스 분쟁이 임베디드 업계에서 화제가 됐습니다.

국내 동영상 플레이어들의 FFmpeg 사용도 오래된 이슈입니다. FFmpeg가 GPL과 LGPL 이중 라이선스인데, GPL이 적용되는 부분까지 쓰면서 소스를 공개하지 않는다는 지적이 반복됐습니다. 일부는 FFmpeg를 본체에서 분리해 별도 코덱 설치 파일로 배포하는 방식으로 대응했고요.

확인 방법

거창한 도구 없이도 기본 점검은 가능합니다.

Node 프로젝트라면 license-checker 같은 도구로 의존성 라이선스를 한 번에 볼 수 있습니다. 중요한 건 간접 의존성까지 봐야 한다는 점입니다. 내가 직접 넣은 패키지는 MIT인데 그게 끌어오는 하위 패키지가 GPL인 경우가 실제로 있습니다.

그리고 SBOM(Software Bill of Materials)을 빌드 파이프라인에 넣어두면 나중에 문의가 왔을 때 대응이 쉬워집니다. 20일차에서 공급망 보안 관점으로 같은 얘기를 했는데, 라이선스 관점에서도 "무엇이 들어 있는지 아는 것"이 출발점입니다.

Source Available도 구분해야 합니다. 소스가 공개돼 있어도 OSI 승인 라이선스가 아니면 오픈소스가 아닙니다. 상업적 SaaS 제공에 제한을 거는 경우가 많아서, 코드가 깃허브에 있다고 자유롭게 쓸 수 있다고 판단하면 위험합니다.

정리

오픈소스 라이선스 분쟁은 대부분 악의가 아니라 확인하지 않은 데서 시작됩니다. 급하게 라이브러리를 넣고 배포까지 가버리는 흐름이 흔하니까요.

실무적으로는 두 가지만 챙겨도 대부분 막힙니다. 배포물에 라이선스 고지를 포함하는 것, 그리고 AGPL과 GPL 계열이 의존성에 들어 있는지 한 번 확인하는 것. 프로젝트 초기에 하면 몇 분이고, 나중에 발견하면 아키텍처를 바꿔야 할 수도 있습니다.