허용·조건·제한 한눈에 보기
조건
- 저작권·라이선스 고지배포할 때 라이선스 사본과 저작권 표시를 함께 넣어야 한다.
제한
- 책임 제한손해에 대한 책임을 지지 않는다고 명시한다.
- 보증 없음어떤 보증도 하지 않는다고 명시한다.
권한·조건·제한 분류 출처: choosealicense.com (GitHub, MIT 라이선스) 데이터.
어떤 라이선스인가
ISC 라이선스는 인터넷 시스템스 컨소시엄(ISC)이 BIND 같은 소프트웨어에 쓰던 라이선스입니다. 베른 협약 이후 불필요해진 표현을 걷어 내 MIT·BSD 2-Clause 와 같은 효과를 더 짧은 문장으로 적었습니다. OpenBSD 프로젝트가 새 코드에 권장하는 라이선스이고, npm 의 npm init 명령이 오랫동안 기본값으로 ISC 를 넣어서 JavaScript 패키지에서도 흔합니다.
조건
허가 문구는 '위 저작권 표시와 이 허가 문구가 모든 사본에 나타난다면' 사용·복제·수정·배포를 허락한다는 한 문장입니다. 즉 MIT 와 마찬가지로 고지 유지가 유일한 조건이며, 나머지는 보증·책임 부인입니다.
자주 하는 오해
- "ISC 는 잘 모르는 라이선스라 기업이 못 쓴다" — OSI 승인 라이선스이며 효과가 MIT 와 같아 대부분의 기업 정책에서 허용형으로 분류됩니다.
- "npm 기본값이니 아무 뜻 없다" — ISC 도 법적 효력이 있는 라이선스입니다. 의도와 다르다면
package.json의license필드와 LICENSE 파일을 원하는 것으로 바꿔야 합니다. - "고지 의무도 없는 버전이 ISC 다" — 고지 의무까지 없앤 것은 ISC 문구를 바탕으로 한 0BSD 입니다.
적용 방법
LICENSE 에 원문을 넣고 [year], [fullname] 을 채웁니다. SPDX 식별자는 ISC 입니다.
이런 경우에 어울린다
MIT 를 쓰려는 상황과 같습니다. 문장이 짧은 것을 선호하거나 OpenBSD·npm 관례를 따르고 싶을 때 선택합니다. 다만 MIT 가 더 널리 알려져 있어, 사용자 입장에서의 익숙함은 MIT 쪽이 낫습니다.
ISC 코드를 다른 프로젝트에 넣을 수 있을까?
이 라이선스로 공개된 코드를 가져와 아래 라이선스의 프로젝트에 합쳐 배포할 때의 일반적인 판정입니다. 호환성 검사기에서 다른 조합 보기 →
| 넣으려는 프로젝트 | 판정 | 메모 |
|---|---|---|
| 비공개(상용) 소프트웨어 | 가능 | 원래 저작권 표시와 라이선스 문구를 함께 넣어야 합니다. |
| MIT | 가능 | 원래 저작권 표시와 라이선스 문구를 함께 넣어야 합니다. |
| Apache-2.0 | 가능 | 원래 저작권 표시와 라이선스 문구를 함께 넣어야 합니다. |
| MPL-2.0 | 가능 | 원래 저작권 표시와 라이선스 문구를 함께 넣어야 합니다. |
| LGPL-2.1 | 가능 | 원래 저작권 표시와 라이선스 문구를 함께 넣어야 합니다. |
| LGPL-3.0 | 가능 | 원래 저작권 표시와 라이선스 문구를 함께 넣어야 합니다. |
| GPL-2.0 | 가능 | 원래 저작권 표시와 라이선스 문구를 함께 넣어야 합니다. |
| GPL-3.0 | 가능 | 원래 저작권 표시와 라이선스 문구를 함께 넣어야 합니다. |
| AGPL-3.0 | 가능 | 원래 저작권 표시와 라이선스 문구를 함께 넣어야 합니다. |
이 사이트의 내용은 일반 정보이며 법률 자문이 아닙니다. 실제 배포·계약·분쟁 판단은 변호사 등 전문가와 상의하세요.