MIT, GPL 오픈소스 라이센스를 잘못 쓰면 회사가 망한다

 

출처: Snyk

 

2024년 3월에 Redis가 갑자기 라이센스를 바꿔서 개발자 커뮤니티 전체가 뒤집어진 사건을 기억하는가. BSD에서 RSALv2/SGPLv1로 전환하자마자 Linux Foundation이 Valkey라는 포크를 만들었고, AWS와 구글도 여기에 합류했다. 이런 사태는 Redis 하나로 끝나지 않는다. HashiCorp Terraform도 2023년에 라이센스를 바꿨고, Elasticsearch는 2021년에 이미 갈아엎었다.

 

다만 이런 뉴스들이 남의 일이 아니라는 점이 문제다. 지금 이 글을 읽고 있는 개발자 중에 "오픈소스 = 공짜"라고 생각하고 GitHub에서 코드를 긁어다 쓴 사람이 많을 텐데, 오픈소스 라이센스는 무료 허락이 아니라 조건부 허락이다. MIT와 GPL이 무엇이 다른지 모르고 쓰다가 소스코드 전부를 공개하라는 소송을 당한 회사들이 실제로 존재한다. 이 글에서는 MIT와 GPL이 구체적으로 무엇이 다른지, 실무에서 무엇을 주의해야 하는지 한국 사례를 포함해 정리했다.

 

오픈소스 라이센스란 무엇이며 왜 이렇게 신경 써야 하는가

 

"오픈소스 = 공짜"라고 생각하면 큰일이 난다

 

오픈소스라는 말 때문에 착각하는 사람이 많지만, 오픈소스는 "코드를 볼 수 있음 + 조건을 지키면 쓸 수 있음"이지 "아무렇게나 써도 된다"가 절대 아니다. 라이센스마다 조건이 다르다. 어떤 것은 그저 "저작권 표시만 해달라"로 끝나고, 어떤 것은 "수정한 코드도 전부 공개해야 한다"로 끝난다.

 

Synopsys가 2024년에 발표한 OSSRA 리포트에 따르면 감사한 코드베이스의 96%가 오픈소스를 포함하고 있다. 평균적으로 프로젝트 하나당 526개의 오픈소스 구성 요소가 들어가 있고, 약 53%의 코드베이스에서 고위험 라이센스 충돌이 발견됐다. 즉 10개 프로젝트 중 5개는 라이센스 문제가 있는데 정작 본인들은 모르고 있다는 뜻이다.

 

라이센스를 지키지 않으면 실제로 소송을 당한다

 

"설마 소송까지 가겠는가" 싶겠지만 실제로 일어난다.

 

• 한컴 리눅스 vs Ghostscript 사건: 한국에서 유명한 GPL 위반 사례다. Ghostscript가 GPL인데 한컴 제품에 묶어서 판매하면서 소스 공개를 하지 않았고, Artifex가 문제를 제기했다.
• VMware vs Christoph Hellwig: 리눅스 커널 개발자가 VMware를 GPL 위반으로 독일 법원에 제소했다. 2016년부터 2021년까지 질질 끌린 소송이다. VMware가 리눅스 커널 코드를 자체 제품에 가져다 쓰면서 GPL 의무를 지키지 않았다는 주장이었다.
• Cisco vs FSF: 링크시스 공유기에 리눅스 커널 코드를 썼는데 GPL 조건을 지키지 않아 FSF가 소송을 제기했다. 결국 합의로 마무리됐다.

 

소송까지 가지 않더라도 경고장을 받는 순간 회사 분위기가 엉망이 된다. 법무팀이 출동하고, 제품 판매를 중단하며, 소스 공개 여부를 판단하느라 개발 일정이 전부 무너진다.

 

최근 1년간 라이센스 전환 사태 정리

 

2021년부터 지금까지 라이센스를 바꾸는 회사들이 줄줄이 나오고 있다. 공통점은 "AWS 같은 하이퍼스케일러가 우리 오픈소스를 공짜로 써서 돈을 버는데 우리는 망해가는 중이라 더는 참을 수 없다"는 것이다.

 

• 2021년 1월 — Elastic이 Elasticsearch를 Apache 2.0에서 SSPL + Elastic License로 전환했다. AWS가 즉시 OpenSearch 포크를 만들었다.
• 2023년 8월 — HashiCorp가 Terraform을 MPL에서 BUSL(Business Source License)로 전환했다. Linux Foundation이 OpenTofu 포크를 만들었다.
• 2024년 3월 — Redis가 BSD 3-Clause에서 RSALv2/SGPLv1으로 전환했다. Linux Foundation과 AWS, Google이 Valkey 포크를 출범시켰다.
• 2024년 — MongoDB는 이미 2018년에 SSPL로 바꿔놓았고, 최근에도 추가 제약을 검토 중이다.

 

이런 사실을 모르고 "Redis는 오픈소스니까 괜찮다"는 식으로 사내 서비스에 썼다가는 다음 버전부터 법무팀의 호출을 받을 수 있다.

 

MIT 라이센스의 특징과 장단점

 

MIT 라이센스 한 줄 요약

 

"저작권만 표시해주면 무엇이든 해도 된다, 심지어 상업적 이용도 허용한다" 이것이 MIT 라이센스다. 1988년 MIT 대학에서 만든 것인데 지금까지도 가장 널리 쓰이는 퍼미시브(permissive) 라이센스다. 원문이 A4 한 장도 되지 않는다. 그만큼 단순하다.

 

핵심 조건은 단 2개다.

 

1. 소스에 원저작권 표시를 그대로 유지할 것
2. 라이센스 전문을 배포본에 포함할 것

 

그 외에는 수정, 재배포, 상업적 이용, 비공개 사용이 모두 허용된다. 심지어 수정한 부분을 공개할 의무조차 없다.

 

MIT 라이센스를 쓰기에 적합한 상황은 무엇인가

 

React, Node.js, Vue.js, Rails, jQuery, Angular — 요즘 잘나가는 프레임워크는 대부분 MIT다. 이유가 명확하다. 기업이 가져다 쓰기에 가장 편하다. 법무팀이 "이것을 써도 되는가" 물으면 "된다"로 끝난다.

 

오픈소스 프로젝트를 만드는 입장이라면 다음과 같은 상황에서 MIT를 고려할 만하다.

 

• 최대한 많은 개발자가 쓰게 하고 싶을 때
• 기업에서도 부담 없이 가져다 쓸 수 있기를 원할 때
• 라이브러리/SDK/프레임워크처럼 넓게 퍼져야 의미 있는 프로젝트일 때
• 특허 조항 같은 복잡한 것을 신경 쓰고 싶지 않을 때

 

반대로 "내 코드를 가져다가 돈을 벌면 너도 오픈소스로 풀어라" 같은 철학을 강요하고 싶다면 MIT는 절대 답이 아니다. 그것은 GPL 계열의 영역이다.

 

MIT 라이센스를 쓸 때 주의할 점

 

대충 써도 된다고 생각해서는 안 된다. 저작권 표시 누락은 엄연한 위반이다.

 

• 배포본에 LICENSE 파일이 빠지면 위반
• 소스 주석의 저작권 표시를 지우면 위반
• 저작자의 이름을 허락 없이 마케팅에 사용하면 별도의 문제가 생길 수 있다 (MIT 본문에는 이 조항이 없지만 상표법 차원의 이슈)

 

그리고 한 가지 더 있다. MIT 라이센스 코드를 가져다 써도 원저작자가 나중에 라이센스를 바꿀 수 있다. 다만, 이미 MIT로 배포된 버전을 쓰는 것은 영원히 MIT다. 이는 Redis가 라이센스를 바꿨을 때에도 똑같이 적용됐다. 7.2.4까지는 BSD였기 때문에 Valkey가 그 버전을 기반으로 포크할 수 있었던 것이다.

 

GPL 라이센스의 특징과 악명 높은 이유

 

GPL = 전염성 라이센스라는 말의 진짜 의미

 

 

출처: ravesli.com

 

GPL 이야기가 나오면 "전염성"이라는 단어가 항상 따라붙는다. 개발자들이 농담처럼 "GPL 바이러스"라고 부르기도 한다. 왜일까?

 

GPL은 카피레프트(Copyleft) 라이센스다. 카피라이트(저작권)의 반대 의미로 만든 말인데, 핵심 조건은 이것이다.

 

"내 코드를 쓰고 싶다면 너도 네 코드를 공개해야 한다"

 

즉, GPL 코드를 단 한 줄이라도 프로젝트에 합치는 순간, 그 프로젝트 전체가 GPL이 된다. 상용 제품을 팔려고 해도 소스를 공개해야 한다. 비공개 상용 소프트웨어를 만들려는 회사에는 거의 재앙 수준이다.

 

예시를 들면, 사내 시스템에 GPL 라이브러리를 정적 링크로 넣으면 → 그 사내 시스템 전체가 GPL 의무를 지게 되고 → 고객이 소스를 요구하면 넘겨줘야 한다.

 

GPL v2 vs GPL v3의 차이

 

GPL에도 버전이 있다. v2는 1991년, v3는 2007년에 나왔다.

 

항목	GPL v2	GPL v3
특허 조항	약함	강함 (명시적 라이센스 부여)
Tivoization 방지	없음	있음 (하드웨어 잠금 금지)
DRM 사용	언급 없음	금지
다른 라이센스 호환	제한적	Apache 2.0 등과 호환 확대
특허 반격 조항	없음	있음

 

Tivoization은 TiVo라는 회사가 GPL 코드를 쓰면서 하드웨어 잠금으로 수정이 불가능하게 만든 사건에서 유래했다. v3는 이를 명시적으로 금지한다. 리눅스 커널이 지금도 v2에 머물러 있는 이유 중 하나가 이것이다. Linus Torvalds가 v3로 가지 않겠다고 못 박았다.

 

LGPL과 AGPL은 무엇이 다른가

 

GPL은 세 종류로 나뉜다. 이것을 헷갈리면 큰일이 난다.

 

• GPL (일반): 가장 엄격하다. 정적 링크든 동적 링크든 전부 전염된다.
• LGPL (Lesser GPL): 동적 링크는 전염되지 않는다. 라이브러리를 수정한 부분만 공개하면 된다. 그래서 상용 소프트웨어가 LGPL 라이브러리를 .dll/.so로 동적 링크해서 쓰는 것은 가능하다.
• AGPL (Affero GPL): SaaS 업계의 악몽이다. GPL은 "배포"할 때만 소스 공개 의무가 발생하는데, AGPL은 네트워크를 통해 서비스를 제공하는 것도 배포로 간주한다. 즉, AGPL 코드를 서버에 올려 웹서비스로 제공하면, 사용자가 소스를 요청할 권리가 생긴다.

 

MongoDB가 원래 AGPL이었는데 이것이 너무 독해서 AWS 같은 클라우드 업체가 피하는 분위기가 됐고, 결국 MongoDB가 SSPL로 다시 바꾸기에 이르렀다. AGPL은 피하든지, 쓸 것이라면 정말 각오하고 써야 한다.

 

MIT와 GPL 외에도 알아야 할 주요 오픈소스 라이센스

 

Apache 2.0 — 기업이 선호하는 이유

 

Apache 2.0은 MIT와 비슷한 퍼미시브 계열이지만 한 가지 큰 차이가 있다. 명시적 특허 라이센스 조항이 들어있다는 점이다.

 

이것이 왜 중요한가? MIT는 특허에 대해 아무 말도 하지 않는다. 그래서 A회사가 MIT 코드를 공개한 뒤, 나중에 "이 코드에 우리 특허가 들어있으니 로열티를 내라" 식으로 공격할 여지가 이론적으로 존재한다. Apache 2.0은 기여자가 본인의 특허도 라이센스에 함께 걸도록 강제한다. 그래서 Kubernetes, Android, Kafka, Spark, TensorFlow 같은 대기업 주도 프로젝트가 Apache 2.0을 선택한다.

 

BSD — MIT와 거의 비슷하지만 미묘하게 다르다

 

BSD는 3-Clause와 2-Clause 두 종류가 있다. 2-Clause는 MIT와 거의 동일하다. 3-Clause는 "저작자 이름을 마케팅에 쓰지 말라"는 조항이 추가된다. FreeBSD, Nginx(초기), PostgreSQL이 BSD다.

 

MPL — 파일 단위 카피레프트

 

Mozilla Public License는 GPL의 전염성과 MIT의 자유로움 사이의 절충안이다. 수정한 파일만 공개하면 된다. 새로 추가한 파일은 원하는 라이센스로 걸 수 있다. Firefox, Rust, Cassandra가 MPL이다.

 

BUSL, SSPL — '오픈소스 아닌 오픈소스'

 

요즘 부각되고 있는 카테고리다. 엄밀히 말하면 OSI가 인증한 오픈소스가 아니다. "소스는 공개하지만 특정 사용은 금지한다"는 방식이다.

 

• BUSL (Business Source License): 일정 기간(보통 4년) 동안은 상업적 경쟁 용도로 쓸 수 없다. 그 이후에 Apache 2.0 같은 오픈소스로 전환된다. HashiCorp Terraform이 대표적이다.
• SSPL (Server Side Public License): AGPL보다 더 독하다. "우리 소프트웨어를 서비스로 제공하려면 서비스 전체 인프라 소스를 공개하라"는 내용이다. MongoDB와 Elasticsearch가 사용한다.

 

이 둘은 OSI 기준 오픈소스가 아니기 때문에 "오픈소스"라고 마케팅할 수 없다. source-available이라고 부른다.

 

라이센스 한눈에 비교 테이블

 

라이센스	상용 가능	소스 공개 의무	수정본 공개 의무	특허 조항	전염성
MIT	O	X	X	없음	없음
BSD 3-Clause	O	X	X	없음	없음
Apache 2.0	O	X	X	있음(강함)	없음
MPL 2.0	O	수정 파일만	수정 파일만	있음	약함(파일 단위)
LGPL	O	라이브러리만	라이브러리만	없음(v2)/있음(v3)	동적링크 제외
GPL v2	O(조건부)	있음	있음	암묵적	강함
GPL v3	O(조건부)	있음	있음	명시적	강함
AGPL	O(조건부)	있음(네트워크 포함)	있음	있음	매우 강함
BUSL	조건부(4년 제한)	소스 공개	공개	있음	없음(상업 제한)
SSPL	조건부	있음(인프라까지)	있음	있음	매우 강함

 

실무에서 오픈소스 라이센스를 주의해야 하는 상황들

 

GPL 코드를 상용 제품에 썼을 때 벌어지는 일

 

실제 시나리오를 보자. 스타트업 A가 결제 시스템을 만드는데 GitHub에서 "결제 SDK"를 검색해 마음에 드는 것을 가져다 썼다. LICENSE 파일은 보지 않은 채 그냥 썼다. 알고 보니 GPL v3였다. 6개월 후 회사가 커지고 SI 사업도 하며 코드를 납품하게 됐다. 고객사가 감사를 요청한다. "이 코드는 GPL이네요, 전체 소스를 넘겨주세요." 회사 전체의 비즈니스 로직이 GPL로 묶여버린다.

 

이것은 실제로 일어나는 일이다. 그래서 GitHub에서 코드를 복사하기 전에 LICENSE 파일 확인은 필수다. CC-BY-SA도 비슷한 위험이 있다(문서/콘텐츠 쪽).

 

npm/pip 의존성에 GPL이 섞여 들어오는 경우

 

직접 쓰는 것은 MIT라 해도, 그 패키지가 GPL 의존성을 가지고 있다면 어떻게 되는가? 간접 의존성까지 라이센스를 체크해야 한다. npm 레지스트리에는 260만 개 이상의 패키지가 있고, 평균 의존성 트리는 수백 개 단계까지 뻗어있다. 사람이 전부 볼 수는 없다.

 

그래서 자동 스캔 도구가 필수다. 대표적인 것을 소개한다.

 

• FOSSology: 오픈소스 라이센스 스캐너. Linux Foundation이 관리한다.
• ScanCode Toolkit: nexB에서 만든 정밀 스캐너다.
• Snyk License Compliance: 상용이지만 의존성 체크에 유용하다.
• GitHub Dependency Graph: 무료이며 기본 정보를 제공한다.

 

사내 시스템에만 쓰는데도 공개해야 하는가

 

GPL FAQ의 해석에 따르면 "사내 사용"은 배포(distribution)로 보지 않기 때문에 소스 공개 의무가 없다. 즉, 회사 안에서만 쓰는 툴에 GPL 라이브러리를 쓰는 것은 이론적으로 문제가 없다.

 

다만 조심해야 할 지점이 있다.

 

• 자회사나 계열사로 넘기는 것은 "배포"로 볼 수 있다 (법인이 다르기 때문)
• 그 사내 시스템을 나중에 외부 고객에게 납품하는 순간 배포가 시작된다
• AGPL이라면 사내 직원이 웹으로 접근하는 것도 배포로 볼 여지가 있다

 

"일단 사내니까 괜찮다"고 방심하면 나중에 사업 모델을 바꿀 때 발목을 잡힐 수 있다.

 

AGPL은 SaaS 회사라면 진짜로 조심해야 한다

 

SaaS 업체라면 AGPL은 거의 손대면 안 된다. 코드를 배포하지 않고 서버에서만 돌려도, 사용자에게 소스 청구권이 발생한다. 회사 전체 서버 코드를 공개해야 할 수도 있다. MongoDB나 Grafana가 AGPL이었거나 지금도 부분적으로 그런 이유가 이것이다. 경쟁사 AWS 같은 곳이 공짜로 못 쓰게 막으려는 의도다.

 

오픈소스 라이센스 위반을 막기 위해 체크할 것들

 

SBOM(소프트웨어 명세서)을 만들어 관리하기

 

SBOM은 Software Bill of Materials의 약자다. 프로젝트에 어떤 오픈소스 구성 요소가 어떤 라이센스로 들어있는지 정리한 문서다. 미국에서는 2021년 행정명령(EO 14028)으로 정부 납품 소프트웨어에 SBOM 제출이 의무화됐다. SPDX, CycloneDX 같은 표준 포맷이 존재한다.

 

syft 같은 오픈소스 툴로 SBOM을 자동 생성할 수 있다. CI/CD 파이프라인에 넣어두면 빌드마다 최신 상태가 유지된다.

 

자동 스캔 도구로 의존성 트리 체크하기

 

앞서 언급한 FOSSology, ScanCode 외에도 CI에 바로 꽂을 수 있는 도구가 많다. GitHub Advanced Security, Dependabot, Snyk 등이다. "무료니까 일단 AGPL을 넣고 나중에 생각하자" 같은 접근은 지양하고 빌드 단계에서 차단해야 한다.

 

회사에서 오픈소스를 쓸 때의 승인 프로세스 제안

 

팀이 작을 때는 승인 프로세스가 과해 보일 수 있지만, 일정 규모를 넘어가면 없을 경우 사고가 난다. 최소한 다음과 같은 단계를 만들어두기를 권장한다.

 

1. 개발자가 라이브러리 도입을 요청 — 용도, 대체 가능성, 라이센스를 명시
2. 자동 스캐너로 의존성까지 검증
3. 라이센스 분류 (퍼미시브 / 약한 카피레프트 / 강한 카피레프트 / 상업 제한)
4. 분류별로 승인 주체를 차등화 (MIT/Apache는 팀 리드, GPL/AGPL은 법무 필수)
5. 승인 기록을 SBOM에 누적

 

오픈소스 도입 전 점검해야 할 10가지 체크리스트

 

• [ ] LICENSE 파일을 직접 확인했는가?
• [ ] SPDX 식별자로 라이센스 종류를 확정했는가?
• [ ] 간접 의존성까지 스캐너로 훑었는가?
• [ ] GPL/AGPL/SSPL/BUSL이 있는지 체크했는가?
• [ ] 제품 배포 방식(바이너리/SaaS/사내)과 맞는지 확인했는가?
• [ ] 정적 링크 vs 동적 링크 방식을 체크했는가? (LGPL 관련)
• [ ] 저작권 표시와 라이센스 전문 포함이 자동화돼 있는가?
• [ ] 최근 1년 내 라이센스가 바뀐 프로젝트 리스트를 업데이트했는가? (Redis, HashiCorp 등)
• [ ] AI 모델/데이터를 쓰는 경우 해당 라이센스도 확인했는가?
• [ ] 연 1회 SBOM 기반 라이센스 감사 계획이 있는가?

 

핵심 정리

 

오픈소스 라이센스를 지키지 않으면 소송이든 평판이든 서비스 중단이든 무엇이든 터질 수 있다. 개발자가 알아야 할 최소 지식은 단 네 가지다.

 

• MIT/BSD: 저작권 표시만 하면 끝이다. 상용 가능. 대부분의 경우 안전하다.
• Apache 2.0: MIT에 특허 조항을 더한 것이다. 기업 환경에서 가장 안전한 선택지다.
• GPL/LGPL: 카피레프트가 전염된다. 상용 제품에 섞으면 본인의 코드도 공개해야 한다. 동적 링크로 LGPL을 쓰는 것은 예외적으로 가능하다.
• AGPL: SaaS 회사라면 반드시 피해야 한다. 네트워크로 서비스만 해도 소스 공개 의무가 발생한다.

 

Redis, HashiCorp, Elasticsearch 사례에서 보듯 오픈소스 라이센스는 한 번 고르면 영원히 가는 것이 아니다. 지금 쓰는 라이브러리가 다음 버전에서 갑자기 상업 제한을 걸 수도 있다. 그러니 SBOM을 만들어 정기적으로 업데이트하고, 의존성 스캐너를 CI에 붙여두고, 회사 내부 승인 프로세스를 한번 정비해두기를 권장한다. "라이센스는 법무의 문제"라며 미뤄두면 결국 본인의 코드가 망가진다. 라이센스는 법무의 문제가 아니라 개발자의 문제다.

 

각설하고, 지금 당장 할 수 있는 것 하나만 꼽는다면 프로젝트 루트에서 syft를 돌려 SBOM을 뽑아보는 것이다. 라이센스 리스트가 나오면 그것을 기반으로 GPL/AGPL이 있는지부터 확인하면 된다. 그다음에 팀 내 오픈소스 라이센스 도입 가이드를 만들어두면 1년 후의 내가 고마워할 것이다.

 

참고 자료

 

• OSI 공식 라이센스 목록
• FSF GPL FAQ
• SPDX License List
• OLIS 공개SW 라이센스 종합정보
• Synopsys Black Duck 2024 OSSRA Report