MongoDB 를 "오픈소스라 그냥 써도 된다" 또는 "라이선스가 위험해 못 쓴다"로 뭉뚱그리면 판단이 틀린다. 구성 요소마다 라이선스가 다르다.
| 구성 요소 | 라이선스 | 성격 |
|---|---|---|
| MongoDB Community Server | SSPL v1 | 4.0 부터 적용. OSI 승인 오픈소스 라이선스가 아니다 |
| 공식 드라이버 (Node · Python · Java · Go 등) | Apache License 2.0 | 상용·비상용 모두 제약 없음 |
| MongoDB Enterprise Advanced | 상용 계약 | 별도 구매 |
| MongoDB Atlas | 서비스 이용 계약 | MongoDB Inc 가 운영. 이용자에게 SSPL 의무가 넘어오지 않는다 |
4.0 이전 버전은 AGPLv3 였다. 옛 문서를 근거로 삼고 있다면 지금 쓰는 버전의 LICENSE 파일을 직접 확인한다.
SSPL 은 AGPLv3 를 바탕으로 만들어졌고, 결정적인 차이는 13조다. 요지는 이렇다 — MongoDB 의 기능을 제3자에게 서비스로 제공한다면, 그 서비스를 제공하는 데 쓰인 관리 소프트웨어 일체를 SSPL 로 공개해야 한다. 관리 소프트웨어에는 프로비저닝 · 모니터링 · 백업 · 스토리지 관리 · 사용자 인터페이스까지 들어간다.
현실적으로 이 조항을 지키면서 관리형 MongoDB 서비스를 파는 것은 불가능에 가깝다. 조항의 목적 자체가 그것이다.
다만 13조가 걸리지 않는다고 해서 SSPL 의 나머지 조항이 사라지는 것은 아니다. SSPL 1조부터 12조는 GPL 계열의 배포 조건을 그대로 갖고 있으므로, MongoDB 바이너리를 외부에 배포하는 순간 소스 제공 의무를 비롯한 카피레프트 조건이 따라온다.
| 상황 | 판단 |
|---|---|
| 사내 시스템의 DB 로 설치해 운영 | 문제 없음. 배포도 서비스 제공도 아니다 |
| Kubernetes 에 StatefulSet 이나 Operator 로 올려 사내에서 사용 | 문제 없음. 배포 방식은 라이선스 판단과 무관하다 |
| SaaS 를 만들되 MongoDB 는 내부에서만 쓰고 고객은 접속하지 못함 | 일반적으로 13조 대상이 아니라고 본다. 다만 "MongoDB 의 기능을 서비스로 제공"에 해당하는지는 제품 구조에 달렸다 |
| 고객에게 MongoDB 클러스터 자체를 빌려주거나 관리형 DB 로 판매 | 13조에 걸린다. 사실상 불가능 |
| 자사 패키지 제품에 MongoDB 를 담아 고객사에 설치·배포 | 주의. 13조는 아니지만 배포에 따른 카피레프트 의무가 생긴다. 법무 검토 없이 "문제없다"고 판단하지 않는다 (확인 필요) |
마지막 줄은 인터넷에서 "제품 내장은 괜찮다"고 단정하는 설명이 많은데 근거가 없다. 상용 제품에 담아 배포하는 벤더들이 상용 라이선스를 따로 구매하는 이유가 여기에 있다.
라이선스 조건을 감당하기 어렵다면 선택지는 셋이다.
드라이버만 Apache 2.0 이라는 점도 기억해 둔다. 애플리케이션이 드라이버만 링크하고 서버는 Atlas 같은 외부 서비스를 바라본다면, 애플리케이션 코드에 SSPL 이 전파될 근거가 없다.
한 줄로 줄이면 이렇다. 사내에서 쓰는 것은 자유롭고, DBaaS 로 파는 것은 불가능하며, 제품에 담아 배포하는 것은 법무 검토 대상이다.
라이선스 판단은 최종적으로 조직의 법무가 한다. 이 문서는 기술 담당자가 무엇을 물어봐야 하는지 정리한 것이지 법률 자문이 아니다.