오픈소스 라이선스는 남의 코드를 어떤 조건으로 쓰고, 고치고, 배포할 수 있는지를 정한 계약이다. 크게 보면 "출처만 밝히면 뭐든 하라"는 허용형(MIT·Apache)과 "고친 것도 같은 조건으로 공개하라"는 카피레프트형(GPL 계열)으로 나뉜다. 이 구분을 모르고 코드를 갖다 쓰면 회사가 위험해질 수 있다.
개발자에게 라이선스는 지루한 주제다. 나도 그랬다. 그런데 "이 라이브러리 우리 상용 제품에 넣어도 돼?"라는 질문에 대답 못 해 프로젝트가 멈춘 걸 본 뒤로 생각이 바뀌었다. 최소한의 구분은 반드시 알아야 한다.
두 갈래로 먼저 나눠라
수십 개 라이선스를 다 외울 필요는 없다. 큰 줄기 두 개만 잡으면 된다.
- 허용형(permissive): MIT, Apache-2.0, BSD. "저작권 고지만 유지하면 상용이든 폐쇄소스든 마음대로." 기업이 가장 편하게 쓰는 쪽이다.
- 카피레프트(copyleft): GPL, AGPL, LGPL. "이 코드를 쓴 결과물도 같은 자유를 보장하라." 즉 파생물의 소스 공개 의무가 따라붙는다.
핵심 질문은 이거다. "내 코드에 이걸 결합하면, 내 코드까지 공개 의무가 전염되는가?" 허용형은 아니오, 카피레프트는 경우에 따라 예다.
주요 라이선스 비교
| 라이선스 | 유형 | 소스 공개 의무 | 특징 |
|---|---|---|---|
| MIT | 허용형 | 없음 | 가장 단순 |
| Apache-2.0 | 허용형 | 없음 | 특허 조항 포함 |
| LGPL | 약한 카피레프트 | 라이브러리 수정분만 | 동적 링크는 완화 |
| GPL-3.0 | 강한 카피레프트 | 배포 시 전체 | 파생물 전염 |
| AGPL-3.0 | 강한 카피레프트 | 네트워크 제공도 | SaaS도 공개 대상 |
표에서 특히 봐야 할 두 줄이 있다. Apache-2.0은 MIT처럼 자유롭지만 명시적 특허 라이선스를 준다. 기여자가 나중에 특허로 사용자를 걸지 못하게 막는 장치라, 기업 환경에서 선호된다. 그리고 AGPL은 함정 조항이 있다. GPL은 "배포"할 때만 소스 공개 의무가 생기는데, AGPL은 서버로 서비스만 해도 의무가 발동한다. SaaS로 몰래 쓰려던 계획을 무너뜨린다.
실무에서 판단하는 법
나는 새 의존성을 넣을 때 세 가지를 확인한다.
- 우리 제품이 폐쇄소스 상용인가? 그렇다면 GPL·AGPL 라이브러리를 코드에 결합하는 건 피한다. MIT·Apache·BSD 위주로 고른다.
- 어떻게 결합하나? 그냥 별도 프로세스로 CLI를 호출하는 것과, 코드에 직접 링크·번들하는 것은 의무가 다르다. 애매하면 법무·오픈소스 정책을 확인한다.
- 라이선스 파일과 고지를 남겼나? 허용형이라도 저작권 고지 유지는 의무다. 이걸 빼먹는 게 가장 흔한 위반이다.
솔직히 처음엔 "MIT면 그냥 다 되는 거 아냐?"라고 뭉뚱그렸다. 하지만 MIT조차 저작권·라이선스 고지를 유지하라는 최소 의무가 있다. "무료"와 "의무 없음"은 다르다. 공짜라고 아무렇게나 쓰면 안 된다.
라이선스 호환성이라는 복병
의존성이 하나면 단순하지만, 수백 개가 얽히면 라이선스끼리 충돌할 수 있다. 대표적으로 GPL과 일부 허용형은 한 배포물 안에서 섞일 때 조건이 부딪힌다. 그래서 규모가 있는 조직은 빌드 파이프라인에 라이선스 스캐너를 넣어, 승인 목록에 없는 라이선스가 딸려 들어오면 CI가 막게 한다. 나는 작은 팀에서도 최소한 license-checker 같은 도구로 전체 의존성 라이선스를 한 번 뽑아 보길 권한다. 손으로 package.json을 훑는 것보다 훨씬 빠르고, GPL·AGPL이 몰래 섞여 들어온 걸 조기에 잡아낼 수 있다.
라이선스가 아예 없는 코드
흔한 오해. GitHub에 공개돼 있고 라이선스 파일이 없으면 "자유롭게 써도 된다"고 여기는데, 정반대다. 라이선스가 없으면 기본 저작권법이 적용되어 원저작자만 권리를 가진다. 즉 복제·수정·배포 권한이 아무에게도 없다. 쓰고 싶으면 저작자에게 허락을 받아야 한다.
자주 묻는 질문
MIT와 Apache-2.0 중 뭘 고를까요?
둘 다 상용에 자유롭게 쓸 수 있는 허용형입니다. 차이는 Apache-2.0에 명시적 특허 라이선스와 기여 조항이 있다는 점입니다. 특허 리스크를 줄이고 싶은 기업 프로젝트라면 Apache-2.0이, 최대한 단순한 조건을 원하면 MIT가 무난합니다.
GPL 라이브러리를 상용 제품에 써도 되나요?
내부에서만 쓰고 배포하지 않으면 문제되지 않을 수 있지만, 제품에 결합해 배포하면 파생물 전체를 GPL로 공개해야 할 수 있습니다. 폐쇄소스 상용 제품이라면 코드 결합은 피하고, 별도 프로세스 호출 등 결합 방식과 정확한 조항을 반드시 검토하세요.
AGPL이 GPL과 다른 점은요?
AGPL은 소스 공개 의무의 발동 조건을 "배포"에서 "네트워크를 통한 서비스 제공"까지 넓힌 라이선스입니다. 즉 서버에서 SaaS로만 제공해도 사용자에게 소스를 공개해야 합니다. 폐쇄형 SaaS를 운영한다면 AGPL 의존성은 특히 주의해야 합니다.
라이선스 파일이 없는 오픈소스는 자유롭게 쓸 수 있나요?
아닙니다. 라이선스가 명시되지 않으면 기본 저작권법에 따라 원저작자만 권리를 가지며, 제3자에게는 복제·수정·배포 권한이 없습니다. 공개돼 있다는 사실이 사용 허가를 뜻하지는 않으므로, 쓰려면 저작자에게 명시적 허락을 받아야 합니다.
댓글 0