ISC 라이선스, 왜 지금 알아야 하는가
GitHub에서 오픈소스 프로젝트를 클론하거나 npm 패키지를 설치할 때, 라이선스 파일을 아무 생각 없이 지나친 경험이 있을 것이다. 그런데 사용 중인 라이브러리가 어떤 라이선스 조건을 담고 있는지 모른 채 상용 서비스에 적용했다가 법적 분쟁에 휘말린 사례는 국내외를 막론하고 꾸준히 발생한다. ISC 라이선스는 바로 그런 상황에서 개발자가 가장 자주 마주치는 라이선스 중 하나다.
npm 생태계 통계에 따르면 자바스크립트 패키지 라이선스 분포에서 MIT가 약 53%로 1위를 차지하고 ISC가 약 10.48%로 3위권에 위치할 만큼, ISC 라이선스는 현대 프론트엔드·백엔드 개발 환경에서 사실상 표준처럼 통용된다. 특히 npm init 명령어를 실행할 때 자동으로 제안되는 기본 라이선스가 ISC일 정도로 Node.js 생태계에 깊숙이 자리 잡고 있다.
이 글에서는 ISC 라이선스의 역사적 배경부터 실제 라이선스 조문의 의미, MIT·BSD·GPL 등 다른 라이선스와의 차이점, 그리고 실무에서 ISC 라이선스 코드를 사용할 때 반드시 지켜야 할 조건까지 구체적으로 다룬다.
ISC 라이선스의 정의와 역사적 배경
ISC 라이선스(ISC License)는 인터넷 소프트웨어 컨소시엄(Internet Software Consortium), 현재 명칭으로는 인터넷 시스템 컨소시엄(Internet Systems Consortium)이 발행한 퍼미시브(Permissive) 자유 소프트웨어 라이선스다. OSI(오픈 소스 이니셔티브), FSF(자유 소프트웨어 재단), DFSG(데비안 자유 소프트웨어 지침) 모두에서 공식적으로 승인된 라이선스로, 법적 유효성과 신뢰성이 충분히 검증된 표준 라이선스다.
ISC의 대표 프로젝트인 BIND(Berkeley Internet Name Domain)와 dig 유틸리티에 처음 적용되었다. BIND는 1980년대 초 UC 버클리에서 탄생한 DNS 소프트웨어로, 이후 ISC가 개발과 유지보수를 이어받아 인터넷 인프라의 핵심 기술로 자리매김했다. 1990년대 중반, ISC는 이 소프트웨어의 라이선스를 정비하면서 당시 BSD 라이선스의 복잡한 조문을 정리한 ISC 라이선스를 탄생시켰다.
ISC 라이선스는 베른 협약(Berne Convention for the Protection of Literary and Artistic Works)에 따라 이미 불필요하다고 간주되는 문구들을 2항 BSD 라이선스에서 제거함으로써 탄생했다. 베른 협약은 1886년 체결된 저작권 국제 조약으로, 저작물은 별도의 등록 없이 창작과 동시에 자동으로 보호받는다는 원칙을 담고 있다. 이 원칙 덕분에 구 BSD 라이선스에 있던 광고 조항 같은 군더더기 문구가 불필요해졌고, ISC 라이선스는 이를 깔끔하게 제거한 버전으로 완성됐다.
2003년 OpenBSD 프로젝트가 새로 기여되는 코드에 ISC 라이선스를 공식 채택하면서 오픈소스 커뮤니티 전반으로 확산되었다. 이후 2014년 npm이 npm init 명령어의 기본 라이선스로 ISC를 지정하면서 자바스크립트 생태계 전반의 표준 라이선스로 자리 잡는 결정적 계기가 만들어졌다. 퀄컴 아테로스(Qualcomm Atheros)가 기여한 리눅스 무선 드라이버, LV2 플러그인 시스템 등 다양한 인프라 소프트웨어에도 활발히 적용되어 있다.
ISC 라이선스 전문 해석
라이선스 전문을 구성하는 각 항목의 실질적 의미는 다음과 같다.
1항 - 허가 조건: 본 소프트웨어의 사용, 복사, 수정 및/또는 배포에 대한 허가는 수수료 유무에 관계없이 부여되며, 모든 복사본에 위의 저작권 고지 및 본 허가 고지가 표시되어야 한다는 내용이다. 이 문장 하나가 ISC 라이선스의 핵심 허가 범위 전체를 담고 있다. 유료·무료, 개인·상업용, 소스·바이너리 배포 모두 허용되며, 단 하나의 조건은 저작권 고지문을 모든 복사본에 유지하는 것이다.
2항 - 보증 부인: 소프트웨어는 있는 그대로 제공되며, 저자는 상품성 및 특정 목적에의 적합성에 대한 모든 묵시적 보증을 포함하여 모든 보증을 부인한다는 내용이다. 소프트웨어에 결함이 있거나 목적에 맞지 않더라도 원작자가 책임지지 않는다는 뜻이며, 상용 서비스에 적용할 때 자체적인 품질 검증이 필수적인 이유가 여기에 있다.
3항 - 책임 제한: 직접·간접·결과적 손해 전반에 걸쳐 원작자의 법적 책임을 면제한다. 계약 위반이든 과실이든 불법 행위든 관계없이 소프트웨어 사용 또는 성능 관련 손해에 대해 저자는 배상 의무를 지지 않는다.
| ISC 라이선스 주요 항목 | 내용 요약 |
|---|---|
| 허가 범위 | 사용, 복사, 수정, 배포 — 유상·무상 모두 가능 |
| 유일한 의무 조건 | 모든 복사본에 저작권 고지 및 허가 고지 포함 |
| 소스코드 공개 의무 | 없음 |
| 보증 여부 | 없음 (있는 그대로 제공) |
| 저자 법적 책임 | 모든 직접·간접·결과적 손해에서 면제 |
| GPL 호환성 | 있음 (GPLv2, GPLv3 모두) |
| OSI 승인 여부 | 승인됨 |
| SPDX 식별자 | ISC |
ISC vs MIT vs BSD vs GPL — 퍼미시브 라이선스 비교
소프트웨어 라이선스는 크게 두 계열로 나뉜다. 소스코드 공개 의무를 부과하지 않는 퍼미시브(허용적) 라이선스와, 파생 저작물도 동일한 조건으로 공개해야 하는 카피레프트(Copyleft) 라이선스다. ISC 라이선스는 퍼미시브 계열에 속하며, 같은 계열 중에서도 가장 간결한 축에 속한다.
퍼미시브 라이선스는 자유롭게 써도 되지만 내 이름은 남겨라 원칙이고, 카피레프트 라이선스는 자유롭게 써도 되지만 네가 만든 것도 똑같이 공개해라 원칙이다. 기업 입장에서 독점 소프트웨어를 개발하려면 퍼미시브 계열 라이선스가 훨씬 유리하다.
ISC 라이선스와 MIT 라이선스의 차이
ISC와 MIT는 실질적으로 동일한 권리와 의무를 부여한다. 다만 표현 방식에 차이가 있다. MIT 라이선스는 복사, 수정, 병합, 게시, 배포, 서브라이선스 부여, 판매할 수 있는 권리를 명시적으로 열거한 반면, ISC 라이선스는 베른 협약에 의해 불필요해진 조항들을 제거하고 사용, 복사, 수정, 배포 4가지로 간략히 표현한다. 유럽 연합 출판사무국은 라이선스 범람(license proliferation)을 방지하기 위해 ISC 라이선스 대신 MIT 라이선스 사용을 권장하기도 한다. 개발자 커뮤니티에서 MIT 선호도가 ISC보다 높은 이유 중 하나도 이런 표준화 권고 영향이 있다.
BSD 라이선스와의 비교
BSD 라이선스는 크게 4항 BSD(원본), 3항 BSD, 2항 BSD로 나뉜다. ISC 라이선스는 기능적으로 2항 BSD와 동일하다. 3항 BSD에는 저자나 기여자의 이름을 광고에 사용하지 말 것이라는 비광고 조항이 추가되어 있다. 4항 BSD(원본)에는 이 소프트웨어가 포함된 모든 광고물에 UC 버클리의 작업에 기반하고 있음을 명시해야 한다는 광고 조항이 있어 GPL과 호환되지 않는 문제가 있었다. ISC는 이를 완전히 제거했다.
| 라이선스 | 조항 수 | 소스 공개 의무 | GPL 호환 | 광고 제한 | 특허 보호 | 상업적 이용 |
|---|---|---|---|---|---|---|
| ISC | 2항 | 없음 | 있음 | 없음 | 없음 | 가능 |
| MIT | 2항 | 없음 | 있음 | 없음 | 없음 | 가능 |
| BSD 2항 | 2항 | 없음 | 있음 | 없음 | 없음 | 가능 |
| BSD 3항 | 3항 | 없음 | 있음 | 비광고 조항 있음 | 없음 | 가능 |
| Apache 2.0 | 상세 | 없음 | GPLv3만 | 없음 | 명시적 보호 | 가능 |
| GPL v2/v3 | 상세 | 있음 | 해당 버전만 | 없음 | v3에서 보호 | 가능 |
| LGPL | 상세 | 일부 있음 | 있음 | 없음 | v3에서 보호 | 가능 |
Apache 2.0은 ISC·MIT와 달리 명시적인 특허 라이선스 조항을 포함하고 있어 특허 분쟁 관련 법적 보호 수준이 다르다. 특허 위험이 존재하는 기술 영역에서는 ISC나 MIT 대신 Apache 2.0 사용을 고려해야 한다.
ISC 라이선스의 실무 적용 — 의무사항과 주의점
ISC 라이선스가 적용된 코드를 사용할 때 개발자가 반드시 이행해야 할 의무는 단 하나, 저작권 고지문과 라이선스 고지문을 모든 복사본에 유지하는 것이다. 이 단순한 규칙 안에도 실무에서 놓치기 쉬운 세부 사항이 있다.
- 저작권 고지 유지: 소스코드 배포 시 원본 라이선스 파일(LICENSE, LICENSE.md 등)을 제거하거나 수정하면 안 된다. 바이너리 배포의 경우에도 문서 또는 소프트웨어 내 저작권 고지를 포함해야 한다.
- 소스코드 공개 의무 없음: ISC 라이선스 코드를 수정·사용하더라도 자신의 소스코드를 공개할 의무가 없다. 클로즈드 소스(상용 독점 소프트웨어)에 자유롭게 통합할 수 있다.
- 라이선스 변경 가능: ISC 라이선스 코드를 포함한 프로젝트는 다른 라이선스(예: MIT, Apache 2.0)로 출시해도 된다. GPL 계열로 전환 시 GPLv2·GPLv3와 ISC는 호환되므로 법적 문제가 없다.
- 파생 저작물에 ISC 적용 강제 없음: ISC 라이선스는 카피레프트가 아니므로, 해당 코드를 기반으로 개발한 파생 저작물을 반드시 ISC 라이선스로 배포해야 하는 의무가 없다.
- 특허 보호 조항 없음: ISC 라이선스에는 Apache 2.0처럼 기여자가 보유한 특허에 대한 명시적 라이선스 부여 조항이 없다. 특허 집약 분야에서는 이 점을 유의해야 한다.
npm 패키지를 개발할 때 npm init 명령어로 프로젝트를 초기화하면 package.json의 license 필드가 자동으로 ISC로 설정된다. 이를 인지하지 못한 채 배포하면 의도치 않게 ISC 라이선스를 적용한 프로젝트가 되므로, 원하는 라이선스가 따로 있다면 반드시 수동으로 변경해야 한다.
npm 생태계에서의 ISC 라이선스
npm은 2014년 ISC를 기본 라이선스로 채택하면서 자바스크립트 개발자들이 가장 자주 접하는 라이선스가 됐다. 이미지 속 jjlabsio의 라이선스 파일도 ISC 표준 조문을 사용하고 있으며, 저작권 연도는 2025년으로 명시되어 있다. GitHub 저장소에서 ISC 라이선스 탭이 표시될 때의 조문 구조는 다음 형태를 따른다.
저작권자 명시, 소프트웨어의 사용·복사·수정·배포 허가, 보증 부인, 책임 제한 이 세 가지 블록으로 구성되며 이 구조는 전 세계 수만 개의 npm 패키지에서 동일하게 반복된다. 실제로 프로젝트 하나를 구성하는 수백 개의 의존성 패키지 중 ISC가 섞여 있는 경우가 매우 흔하다.
ISC 라이선스의 2007년 개정판은 기존 and를 and/or로 변경했다. GNU 프로젝트는 이 and/or 표현이 수정된 버전의 배포를 금지하는 것으로 해석될 여지가 있다고 지적한 바 있다. OpenBSD는 이 때문에 원래 문구(and 사용)를 그대로 유지한 별도 버전을 사용하고 있다. 실무에서 ISC 라이선스 코드를 받을 때 어떤 버전인지 확인하는 습관이 도움이 된다.
ISC 라이선스의 현재와 한계
ISC 라이선스는 간결함과 유연성이 강점이지만, 아이러니하게도 이를 만든 ISC 자체는 2015년-2017년 사이에 자사 소프트웨어를 점진적으로 모질라 공중 허가서(MPL 2.0)로 재라이선스했다. ISC는 당시 회사가 소프트웨어를 사용하면서 개선하는 경우, 그 개선 사항이 다시 프로젝트로 돌아오기를 원한다고 밝히며 카피레프트 방식을 채택한 것이다. BIND 9, Kea DHCP, ISC DHCP 서버 모두 현재는 MPL 2.0 하에 배포된다.
이 흐름은 오픈소스 라이선스 전략에 중요한 시사점을 준다. ISC 라이선스처럼 완전히 허용적인 라이선스는 기여자에게 기여가 다시 돌아온다는 보장이 없다. 대형 기술 기업이 오픈소스 프로젝트를 활용해 수익을 창출하면서도 개선 사항을 공개하지 않는 사례가 많아지면서, 많은 프로젝트가 ISC·MIT에서 AGPL·MPL 계열로 이동하는 추세가 관찰된다.
개발자가 자신의 프로젝트에 ISC 라이선스를 적용하기로 결정했다면, 그것은 코드를 최대한 폭넓게 공유하고 어떤 용도로도 활용되도록 허용하겠다는 의사 표시다. 기여의 환류를 기대하기 어렵다는 점은 감수해야 한다. 반면 ISC 라이선스가 적용된 코드를 활용하는 입장이라면, 저작권 고지를 제거하지 않는 것 외에 어떤 제약도 없이 자유롭게 사용·수정·배포할 수 있다는 사실을 명확히 인식해야 한다.
오픈소스 라이선스 준수는 단순한 법적 형식이 아니다. 코드를 공개한 개발자에 대한 최소한의 존중이며, 건강한 오픈소스 생태계를 유지하는 기반이다. ISC 라이선스의 단 하나뿐인 조건, 즉 저작권 고지문을 유지하는 것은 그 정신을 실천하는 가장 간단한 방법이다. 지금 사용 중인 프로젝트의 의존성 라이선스를 license-checker 같은 도구로 점검하고, ISC 라이선스 코드가 포함된 배포물에 고지문이 제대로 포함되어 있는지 확인해보길 권한다.