본 글은 일반 정보이며 개별 사업의 법률 자문을 대체하지 않는다. 실제 도입 결정 전에는 사내 법무 또는 외부 IP 전문 변호사의 검토를 권한다.
라이선스를 모르면 사업이 위험한 이유
오픈소스는 무료가 아니다. 정확히 말하면 돈 대신 라이선스 조건을 지불하는 자산이다. 조건을 어기면 라이선스가 자동 종료되고, 종료된 시점부터 그 코드를 포함한 제품 배포는 저작권 침해가 된다.
Black Duck의 2026 OSSRA에 따르면 상업 코드베이스의 68%에서 오픈소스 라이선스 충돌이 발견됐다. 역대 최고치다. 보고서는 AI 코드 어시스턴트가 라이선스 메타데이터 없이 코드 조각을 학습·재생산하면서 일종의 “라이선스 세탁”이 늘어난 것을 주된 원인으로 꼽는다. Copilot이 뱉어 준 30줄짜리 함수가 GPL 프로젝트에서 온 것이라면, 그 사실을 모른 채 클로즈드 SaaS에 그대로 넣은 순간 위반이 시작된다.
법적 위험이 추상적이지도 않다. 2026년 1월 SFC v. Vizio 판결은 소비자가 GPL의 제3자 수익자로서 직접 소를 제기할 수 있다고 인정했다. 즉 GPL 위반을 추적하는 주체가 원저작자뿐 아니라 그 소프트웨어를 산 일반 사용자까지 확장된 셈이다. GPL은 더 이상 “젠틀맨의 약속”이 아니라 법원이 집행하는 계약이다.
주요 오픈소스 라이선스 한눈에 비교
| 라이선스 | 상업 이용 | 수정본 소스 공개 | 특허 보호 조항 | 네트워크 사용 시 공개 | OSI 승인 |
|---|---|---|---|---|---|
| MIT | 가능 | 불필요 | 없음 | 불필요 | 승인 |
| Apache 2.0 | 가능 | 불필요 | 명시적 부여 | 불필요 | 승인 |
| LGPL 2.1 | 가능 | 라이브러리 수정 시만 | 약함 | 불필요 | 승인 |
| GPL v2 | 가능 | 결합 배포 시 필요 | 묵시적 | 불필요 | 승인 |
| GPL v3 | 가능 | 결합 배포 시 필요 | 명시적 + Tivoization 금지 | 불필요 | 승인 |
| AGPL v3 | 가능 | 네트워크 제공 시도 필요 | 명시적 | 필요 | 승인 |
| BUSL 1.1 | 제한적(경쟁 금지) | 소스 공개됨 | 별도 | 별도 | 미승인 |
표에서 핵심은 두 축이다. (1) 코드 공개 의무가 어디까지 전파되는가(copyleft 강도), (2) 그 의무가 SaaS처럼 “배포가 아닌 호스팅” 환경에도 적용되는가. MIT/Apache는 둘 다 약하고, AGPL은 둘 다 강하다.
MIT · Apache 2.0: 상업 이용이 가장 자유로운 두 라이선스
스타트업의 클로즈드 SaaS에 가장 안전한 두 라이선스다. 둘 다 수정본을 공개할 의무가 없고, 사내 포크해서 비공개로 운영해도 된다. 의무는 사실상 저작권 고지 보존 하나뿐이다.
차이는 한 가지에서 갈린다. 특허다. MIT는 특허에 대해 침묵한다. 반면 Apache 2.0은 기여자가 자신이 보유한 특허에 대한 사용권을 라이선시에게 명시적으로 부여하고, 라이선시가 그 특허로 소를 걸면 라이선스가 자동 종료된다(특허 보복 조항). B2B SaaS·인프라 소프트웨어처럼 특허 분쟁 가능성이 있는 영역이라면 MIT보다 Apache 2.0을 골라 받는 게 낫다. Kubernetes, Terraform(전환 전), TensorFlow가 Apache를 쓴 이유다.
실무 팁: package.json이나 pyproject.toml 의존성을 SBOM 도구로 한 번 훑으면 MIT/Apache 비율이 80%를 넘는 경우가 많다. 이 영역은 라이선스 검토가 거의 자동화 가능하다. 진짜 시간을 들일 곳은 나머지 20%다.
GPL · LGPL: 코드 공개 의무가 ‘전파’되는 범위
GPL의 핵심은 “결합 저작물(derivative work)을 배포할 때 전체 소스를 같은 라이선스로 공개해야 한다”는 점이다. 정적 링크든 동적 링크든, 한 바이너리에 GPL 코드가 들어가면 그 바이너리 전체가 GPL이 된다. 사내에서만 쓰는 한 의무는 발생하지 않는다 — GPL은 “배포(distribution)“를 트리거로 하기 때문이다.
LGPL은 라이브러리 한정으로 완화된 버전이다. LGPL 라이브러리를 동적 링크해서 호출하는 클로즈드 앱은 자기 소스를 공개할 필요가 없다. 다만 LGPL 라이브러리 자체를 수정하면 그 수정분은 공개해야 한다.
GPL v2와 v3의 실무 차이는 Tivoization 금지 조항에서 가장 또렷하다. v3는 사용자가 수정 펌웨어를 디바이스에 설치할 수 있도록 서명키 등을 함께 제공하라고 요구한다. v2는 그렇지 않다. SFC v. Vizio의 2025년 12월 결정이 이 차이를 명확히 했다 — Vizio가 사용한 GPLv2/LGPLv2.1 코드에 대해 서명키 제공 의무는 없다고 판단했다. 임베디드·하드웨어 제품을 만든다면 v2와 v3 의존성을 분리해서 추적해야 한다.
가장 흔한 함정 하나. “백엔드에만 GPL 라이브러리를 쓰고 클라이언트에 보내지 않으니 안전하다”는 가정은 맞다. 하지만 그 백엔드 바이너리를 온프레미스로 고객사에 납품하는 순간 “배포”가 발생하고 GPL이 전파된다. B2B 온프레미스 사업이라면 GPL은 사실상 사용 불가라고 보는 편이 안전하다.
AGPL: SaaS 서비스도 소스 공개 의무가 생기는 이유
AGPL은 GPL의 “배포가 트리거” 가정이 클라우드 시대에 무력해진 것을 막으려고 만들어졌다. 네트워크 너머의 사용자에게 서비스를 제공하는 행위 자체를 트리거로 추가했다. 즉 AGPL 코드를 수정해서 SaaS로 운영하면, 그 사용자가 요청할 때 수정된 소스를 받을 수 있어야 한다.
실무에서 AGPL은 두 가지 방식으로 다룬다. 첫째, 아예 의존성으로 들이지 않는다 — 구글·아마존 등 대형 회사들의 사내 정책이 그렇다. 둘째, 듀얼 라이선스로 풀린 프로젝트(MongoDB SSPL 이전 시절, Grafana Enterprise 등)에서 상업 라이선스를 별도 구매한다.
MongoDB·Elastic·Redis가 줄줄이 AGPL이나 그 변형을 거쳐 결국 source-available 라이선스로 옮겨간 흐름은 우연이 아니다. AGPL조차 하이퍼스케일러의 “관리형 서비스” 비즈니스를 막지 못했기 때문이다. 그래서 등장한 게 BUSL이다.
Terraform 사례: 라이선스 전환과 source-available의 함정
HashiCorp는 2023년 8월 Terraform을 MPL 2.0에서 BUSL 1.1로 전환했고 2026년 현재도 그 정책을 유지한다. BUSL의 핵심은 소스는 공개하되, 라이선서와 경쟁하는 상업 서비스에는 쓸 수 없다는 조건이다. 4년 후 Apache 2.0으로 자동 전환되는 시한 조항도 붙는다.
여기서 두 가지를 구분해야 한다. 소스가 공개돼 있다는 사실과 그 코드가 오픈소스라는 사실은 다르다. BUSL은 OSI(Open Source Initiative) 승인 라이선스가 아니다. OSI의 오픈소스 정의는 “이용 분야 차별 금지”를 포함하고, 경쟁 금지 조항은 이를 위반한다. 즉 BUSL 코드는 “source-available”이지 “open source”가 아니다.
실무 영향은 직접적이다. 최신 Terraform을 IaC 관리형 SaaS로 다시 팔겠다면 HashiCorp의 별도 상업 라이선스가 필요하다. 반면 Linux Foundation으로 포크된 OpenTofu는 MPL 2.0 오픈소스를 유지하고 있다. 사내 인프라 관리 용도라면 BUSL은 사실상 무료지만, 컨설팅·재판매 수익 모델로 다루는 순간 게임이 바뀐다. 단일 기업이 통제하는 오픈소스 프로젝트는 그 기업의 비즈니스 모델이 바뀌면 라이선스도 따라 바뀐다 — Terraform이 선례가 됐다.
실전 체크리스트: 오픈소스 도입 전 확인할 것
라이브러리 하나를 새로 들이기 전에 다음 7가지를 확인한다. 분량이 많아 보이지만 SBOM 도구로 5분이면 끝나는 항목이 대부분이다.
- 라이선스 식별 —
package.json/pyproject.toml/go.mod만 보지 말고 transitive dependency까지 SBOM(syft,cyclonedx)으로 펼쳐 본다 - OSI 승인 여부 — 미승인이면 별도 검토. BUSL·SSPL·Commons Clause 부착 라이선스는 모두 여기 해당
- copyleft 강도 — MIT/Apache(약함) → MPL/LGPL(파일/라이브러리 단위) → GPL(결합 단위) → AGPL(네트워크) 순으로 위험 증가
- 배포 모델 vs 라이선스 매칭 — SaaS만 한다면 AGPL을 차단, 온프레미스 납품도 한다면 GPL까지 차단
- 수정 여부 — 포크해서 고치면 패치를 사내 fork에 보관하되, 라이선스에 따라 공개 의무 발생 여부 재검토
- 저작권 고지 보존 —
LICENSE/NOTICE파일을 빌드 산출물에 포함시키는 자동화. Apache의NOTICE누락이 가장 흔한 실제 위반 사례 - AI 코드 어시스턴트 정책 — 사내 가이드라인에 “라이선스 불명 코드 생성 금지”, PR 리뷰에 라이선스 스캐너(FOSSA, Black Duck, ScanCode) 통합
법무 검토 범위가 라이선스만 있는 것도 아니다. 데이터 처리 측면에서는 한국 개인정보보호법 개정 대응과 묶어서 한 번에 정리해 두는 편이 효율적이다. 라이선스·개인정보·보안 인증은 같은 회의에서 다뤄질 때가 많기 때문이다.
자주 묻는 질문
Q. MIT 라이브러리를 수정해서 우리 SaaS에 쓰면 그 수정분도 공개해야 하나요?
아니다. MIT는 수정본 공개 의무가 없다. 사내에서 포크하고 임의로 수정해 비공개로 운영해도 된다. 다만 원본의 저작권 고지와 라이선스 텍스트는 보존해야 한다. 보통 앱 안에 “Open Source Licenses” 화면이나 빌드 산출물에 THIRD_PARTY_LICENSES 파일을 포함시키는 방식으로 처리한다.
Q. GPL 라이브러리를 사내 백엔드에서만 쓰면 안전한가요?
GPL의 의무는 “배포(distribution)“를 트리거로 한다. 사내에서 운영하고 외부로 바이너리를 내보내지 않는다면 의무가 발생하지 않는다는 것이 다수 해석이다. 단 두 가지 경계가 있다. 첫째, 자회사·합작사로의 코드 이전이 “배포”인지 모호하다. 둘째, 온프레미스 납품으로 사업이 확장되는 순간 즉시 트리거된다. 사내 한정 사용은 GPL 회피 수단으로 시작은 가능해도 유지는 어렵다.
Q. AGPL과 GPL의 차이가 SaaS에서 정말 그렇게 큰가요?
크다. GPL은 사용자가 바이너리를 받지 않으면 트리거되지 않으므로 SaaS는 GPL의 사각지대다. AGPL은 그 사각지대를 메우려고 “네트워크 제공도 배포로 본다”는 조항을 추가했다. 즉 AGPL 코드를 수정해서 운영하는 SaaS는 사용자에게 수정 소스를 받을 방법을 제공해야 한다. 듀얼 라이선스 상업판이 없다면 AGPL은 클로즈드 SaaS와 양립하지 않는다.
Q. BUSL 코드는 오픈소스로 봐도 되나요?
OSI 정의 기준으로는 오픈소스가 아니다. 경쟁 금지 같은 이용 분야 제한이 OSI 정의를 위반하기 때문이다. “source-available”이라는 별도 분류가 더 정확하다. 사내 사용은 보통 무료지만, 그 코드를 기반으로 관리형 서비스를 팔거나 컨설팅 산출물에 포함시킬 계획이라면 별도 상업 라이선스 협상이 필요하다. Terraform·MongoDB·Redis가 모두 이 모델로 옮겨갔으므로 IaC·DB·캐시 영역 의존성 변경 시 라이선스 히스토리를 한 번 더 확인하는 것이 좋다.