외주로 만든 시스템을 몇 달 잘 쓰다가, 투자 실사나 고객사 보안 점검에서 처음 질문을 받는 경우가 많습니다. 이 프로그램에 들어간 오픈소스 목록을 달라는 요구입니다. 개발사에 연락하면 "라이브러리 몇 개 썼습니다" 정도의 답이 돌아옵니다.
여기서 발주사가 가장 당황하는 지점은 따로 있습니다. 개발비를 전액 지불했고 계약서에 저작권은 발주사 소유라고 적혀 있는데, 소스를 공개해야 할 수도 있다는 말이 나오기 때문입니다. 돈을 낸 것과 배포 조건은 서로 다른 층위의 문제입니다.
돈을 냈다는 사실이 라이선스 조건을 덮지는 못합니다
외주 계약으로 발주사에 넘어오는 것은 개발사가 새로 작성한 코드의 저작권입니다. 개발사가 끌어다 쓴 오픈소스는 애초에 개발사 것이 아니었으므로 넘길 수가 없습니다. 계약서에 "모든 권리는 갑에게 귀속한다"고 적어도 결과는 같습니다.
오픈소스는 원저작자가 정한 조건을 지키는 대가로 무료로 쓰는 코드입니다. 그 조건 중 일부가 "너도 소스를 공개하라"입니다. 개발비를 얼마나 냈든 이 조건은 프로그램을 따라 발주사에게 그대로 옵니다.
발주사가 산 것은 프로그램 전체의 소유권이 아니라, 개발사가 만든 부분의 권리와 남의 코드를 조건부로 쓸 자격입니다.
MIT와 Apache 2.0은 고지만 지키면 소스를 열지 않아도 됩니다
MIT는 조건이 사실상 한 줄입니다. 저작권 표시와 허가 문구를 사본이나 상당 부분에 포함하라는 것이 전부입니다. 소스를 공개할 의무도, 수정한 사실을 알릴 의무도 없습니다.
Apache 2.0은 제4조에서 세 가지를 더 요구합니다. 라이선스 사본을 함께 주고, 수정한 파일에는 변경 사실을 눈에 띄게 표시하고, 원본에 NOTICE 파일이 있으면 그 내용을 읽을 수 있는 형태로 전달해야 합니다. 제3조는 기여자의 특허 사용권까지 주되, 특허 소송을 제기하면 그 권리가 소송 제기일자로 끝난다고 정해 두었습니다.
실무에서는 앱 설정 화면이나 웹사이트 하단에 오픈소스 고지 페이지를 두는 것으로 충족합니다. 다만 아파치 재단 공식 문서는 Apache 2.0이 GPLv2와 호환된 적이 없다고 밝히고 있습니다. 특허 종료와 면책 조항 때문이며, GPLv3와는 한 방향으로만 호환됩니다.
GPL은 파일이 회사 밖으로 나갈 때 의무가 생깁니다
GPLv3는 전달(convey)을 다른 사람이 사본을 만들거나 받게 하는 행위로 정의합니다. 그리고 네트워크를 통한 단순한 상호작용은 전달이 아니라고 명시합니다. 그래서 GPL 코드로 만든 웹서비스를 운영만 하는 동안에는 공개 의무가 생기지 않습니다.
파일이 나가는 순간 걸리는 조건은 두 가지입니다. 제5조는 결합한 저작물 전체를 사본을 받는 누구에게나 GPL 조건으로 허락하라고 요구합니다. 제6조는 실행 파일을 줄 때 대응 소스도 함께 제공하라고 요구합니다.
외주 납품은 그 자체로 배포이고, 재판매에서 문제가 커집니다
GNU 공식 FAQ는 한 조직이 내부에서만 복제해 쓰는 것은 배포가 아니라고 답합니다. 그러면서 사외 계약자에게 사본을 주는 것은 배포라고 못 박습니다. 외주사가 발주사에 프로그램을 넘기는 행위가 여기에 해당합니다.
같은 FAQ는 개발사가 계약에 따라 수정본을 만들고 고객이 허락할 때까지 외부에 공개하지 않는 것도 가능하다고 답합니다. 대신 사본을 받은 고객은 GPL 권리를 그대로 얻습니다. 발주사가 납품 시점에 GPL 부분의 소스를 요구하는 것은 정당한 권리 행사입니다.
진짜 위험은 그다음입니다. 발주사가 그 프로그램을 대리점이나 고객사에 다시 넘기는 순간, GPL 조건을 지킬 당사자가 발주사로 바뀝니다. 사내에서만 쓸 계획이었던 시스템을 나중에 상품으로 파는 결정이 여기서 걸립니다.
LGPL은 링크 방식에 따라 결과가 갈립니다
LGPL 3.0 제4조는 결합 저작물을 배포할 때 라이브러리 사용 사실을 눈에 띄게 알리고 라이선스 문서를 첨부하라고 요구합니다. 여기까지는 부담이 크지 않습니다.
문제는 나머지 요건입니다. 사용자가 라이브러리를 수정본으로 바꿔 다시 결합할 수 있어야 합니다. 별도 파일로 분리된 공유 라이브러리 방식이면 대체로 충족되지만, 하나의 실행 파일로 정적 링크했다면 재결합에 필요한 자료까지 내줘야 합니다. 납품물이 단일 실행 파일이라면 이 부분을 반드시 확인하세요.
AGPL은 화면을 보여주는 것만으로 소스를 요구할 수 있게 합니다
AGPL 3.0 제13조는 GPL이 빼놓은 구멍을 정확히 겨냥합니다. 프로그램을 수정했다면, 네트워크로 원격 접속해 사용하는 모든 사용자에게 그 버전의 대응 소스를 네트워크 서버에서 무상으로 받을 기회를 눈에 띄게 제공하라고 요구합니다.
GPL과의 차이는 이 한 조항뿐입니다. GPL은 네트워크 상호작용을 전달에서 제외했고, AGPL은 그것을 다시 끌어들였습니다. 파일을 아무에게도 주지 않고 서버에서 돌리기만 해도 의무가 발생한다는 뜻입니다.
외부에 서비스하는 웹서비스에서 AGPL이 특히 위험합니다
사내용 시스템이라면 원격 사용자가 직원뿐이라 소스를 회사 안에서 열어 주면 끝납니다. 반면 일반 가입자에게 여는 웹서비스는 접속하는 모든 이용자가 요구 대상이 됩니다. 같은 코드라도 서비스 대상이 달라지면 결과가 완전히 달라집니다.
고스트스크립트를 만드는 Artifex는 이 상황을 라이선스 안내 페이지에 직접 적어 두었습니다. "서버 기반 애플리케이션이나 서비스의 일부로 우리 오픈소스를 배포하면서, 상호작용하는 사용자에게 당신 애플리케이션의 전체 소스를 AGPL로 공개하지 않을 수는 없습니다."
범위가 라이브러리가 아니라 애플리케이션 전체라는 점이 핵심입니다. 정산 로직이나 백오피스까지 딸려 나갈 수 있습니다. 같은 제품군 안에서도 갈리는데, Grafana는 2021년 4월 20일 발표로 Grafana 8.0, Loki 2.3, Tempo 1.0부터 AGPLv3로 바꾸면서 플러그인과 일부 라이브러리는 Apache 2.0으로 남겼습니다.
상용 유료 라이선스는 인원수가 아니라 배포 방식으로 갈립니다
AGPL 컴포넌트는 대부분 유료 상용 라이선스를 함께 팝니다. Artifex는 AGPL 요건을 지킬 수 없으면 상용 라이선스가 필요하고, 상용 계약에서는 소스 공개 의무가 없다고 명시합니다. 돈으로 공개 의무를 사서 없애는 구조입니다.
상용 라이브러리에서 확인할 항목은 금액이 아니라 조건입니다. 개발자 좌석 수, 서버·배포 단위 과금, 재배포와 OEM 허용 여부, SaaS 형태 제공 허용 여부, 갱신 만료 후 사용 가능 여부가 실제 분쟁이 나는 지점입니다. 금액과 조건은 판매사 공식 페이지에서 직접 확인하세요.
외주에서 자주 터지는 사고는 명의 문제입니다. 개발사가 자기 회사 좌석으로 산 라이브러리를 납품물에 넣으면, 발주사에는 그 라이브러리를 계속 쓰거나 재배포할 권리가 없습니다. 계약이 끝난 뒤에야 드러납니다.
계약서에 넣을 오픈소스 목록(BOM) 요구 문구입니다
이름만 적힌 목록은 쓸모가 없습니다. MongoDB Community Edition은 2018년 10월 16일 이전 버전이 AGPL v3, 그 이후 버전이 SSPL 1.0입니다. 같은 제품이라도 버전에 따라 의무가 달라지므로 목록에는 버전이 반드시 있어야 합니다.
아래 다섯 항목을 납품 조건 조항에 그대로 넣으세요. 검수 완료의 전제 조건으로 걸어야 실제로 받을 수 있습니다.
- "을"은 납품물에 포함된 모든 오픈소스 및 상용 라이브러리의 이름, 버전, 라이선스 식별자, 원본 배포처 URL을 목록으로 제출합니다.
- 목록은 SPDX 또는 CycloneDX 형식의 기계 판독 파일과 사람이 읽을 수 있는 표로 함께 제출합니다.
- "을"은 GPL, LGPL, AGPL, SSPL 등 소스 공개 의무가 있는 구성요소의 포함 여부를 명시하고, 포함된 경우 "갑"의 코드와 결합된 방식을 기술합니다.
- 상용 라이브러리는 라이선스 명의자, 허용 배포 형태(사내 사용·재배포·SaaS 제공), 사용자 수 제한, 갱신 만료일을 함께 기재합니다.
- 하자보수 및 유지보수 과정에서 구성요소가 추가·변경된 경우 "을"은 변경분을 반영한 목록을 다시 제출합니다.
형식을 지정하는 이유는 검증 도구를 쓰기 위해서입니다. SPDX는 ISO/IEC 5962:2021 국제표준이고, CycloneDX는 ECMA-424로 표준화되어 있습니다. 둘 중 하나를 고르면 나중에 고객사가 SBOM을 요구할 때 그대로 제출할 수 있습니다.
이 문구로도 막지 못하는 것이 있습니다
목록은 제출 시점의 사진일 뿐입니다. 유지보수로 라이브러리를 갈아 끼우면 그 순간 낡은 문서가 됩니다. 5번 항목을 넣는 이유가 이것이고, 유지보수 계약에도 같은 조항을 반복해 넣어야 합니다.
작은 사내용 도구에까지 SPDX 파일을 요구하면 견적과 일정이 올라갑니다. 외부에 서비스하지 않고 재판매 계획도 없는 프로젝트라면 라이선스 이름과 버전이 적힌 표 한 장으로 충분합니다. 반대로 외부 웹서비스나 재판매가 걸린 납품이라면 이 조항 없이 검수하지 마세요.
여기 적은 내용은 라이선스 조항 원문과 배포자 공식 안내를 기준으로 정리한 것이며, 개별 결합 방식이 파생저작물에 해당하는지는 법률 검토가 필요합니다. 조항 원문은 GNU 라이선스 FAQ에서 확인할 수 있고, 납품 검수와 계약 문구는 실무 가이드 카테고리에 이어서 다룹니다. 외주 납품물의 구성요소 점검이 필요하면 Codeforest로 문의하세요.
결론: 공개 의무는 결제 시점이 아니라 배포 시점에 정해집니다
돈을 냈는데 소스를 공개하게 되는 이유는 간단합니다. 라이선스는 누가 돈을 냈는지가 아니라 프로그램이 누구에게 어떻게 전달되는지를 봅니다. MIT와 Apache 2.0은 고지로 끝나고, GPL과 LGPL은 파일이 밖으로 나갈 때 걸리며, AGPL은 서버에서 돌리기만 해도 걸립니다.
그래서 판단 기준은 하나입니다. 이 프로그램을 사내에서만 쓸 것인지, 외부 이용자에게 서비스할 것인지, 나중에 남에게 넘길 것인지를 먼저 정하고 그에 맞는 목록을 납품 전에 받으세요. 검수 도장을 찍은 뒤에는 협상 카드가 없습니다.
