1. LICENSE 파일을 저장소 최상위에
가장 먼저 할 일은 라이선스 원문을 LICENSE(또는 LICENSE.txt, LICENSE.md) 파일로 저장소 최상위에 두는 것입니다. GitHub·GitLab 과 패키지 관리자는 이 파일을 찾아 라이선스를 인식합니다. 생성기에서 라이선스를 고르고 연도·저작권자를 넣으면 바로 받을 수 있습니다.
- 원문을 고치지 않는다: MIT·BSD·ISC 의
[year]·[fullname]같은 자리표시자만 채우고 나머지 문장은 그대로 둡니다. 문장을 바꾸면 표준 라이선스로 인식되지 않고, 해석 문제가 생길 수 있습니다. - GNU 라이선스는 전문 그대로: GPL·LGPL·AGPL 원문에는 채울 자리가 없습니다. 저작권자와 버전 조항은 파일 고지문으로 밝힙니다.
2. 연도와 저작권자 표기
- 연도: 처음 공개한 해를 적는 것이 일반적입니다.
2019-2026처럼 범위를 쓰기도 합니다. 매년 갱신할 법적 의무는 없습니다. - 저작권자: 개인이 쓴 코드라면 본인 이름, 업무로 작성한 코드라면 보통 고용주가 저작권자입니다(국가·계약에 따라 다름). 여러 사람이 기여하는 프로젝트는
The Example Project Authors처럼 적고AUTHORS파일로 목록을 관리하기도 합니다. - 저작권 표시는 권리를 발생시키는 것이 아니라 알리는 것입니다. 표시가 없어도 저작권은 있습니다.
3. 라이선스별 부속 파일
| 라이선스 | 관례 |
|---|---|
| Apache-2.0 | LICENSE + 필요하면 NOTICE(귀속 고지만 짧게) |
| GPL-3.0 / GPL-2.0 | COPYING 또는 LICENSE 에 원문 |
| LGPL-3.0 | COPYING(GPL-3.0 원문) + COPYING.LESSER(LGPL-3.0 원문) |
| MIT OR Apache-2.0 | LICENSE-MIT + LICENSE-APACHE |
| BSL-1.0 | LICENSE_1_0.txt |
Apache-2.0 의 NOTICE 는 필수가 아니지만, 한번 NOTICE 가 있는 코드를 재배포하는 사람은 그 내용을 유지해야 합니다. ASF 는 NOTICE 에 법적으로 필요한 귀속 고지만 넣고 감사 인사나 라이선스 전문은 넣지 말라고 권합니다.
4. 소스 파일 헤더
파일마다 짧은 헤더를 두면 파일이 따로 복사돼도 라이선스 정보가 따라갑니다.
# SPDX-FileCopyrightText: 2026 Example Inc.
# SPDX-License-Identifier: Apache-2.0GNU·Apache·MPL 은 공식 고지문도 권장하지만, SPDX 두 줄만으로 대체하는 프로젝트가 늘었습니다. 자세한 내용은 SPDX 가이드를 참고하세요.
5. 패키지 메타데이터와 README
package.json,Cargo.toml,pyproject.toml등의 license 필드에 SPDX 식별자를 적습니다.- README 끝에 '라이선스' 절을 두고 한두 줄로 요약합니다(예: 'This project is licensed under the MIT License — see LICENSE').
6. 서드파티 코드 고지
다른 사람의 코드를 포함해 배포한다면 그 라이선스 의무도 함께 지켜야 합니다.
- 복사해 넣은 코드는 원래의 저작권 표시와 라이선스를 해당 파일에 유지합니다.
- 바이너리·앱으로 배포한다면 사용한 오픈소스 목록과 라이선스 전문을
THIRD_PARTY_NOTICES파일이나 앱의 '오픈소스 라이선스' 화면에 모읍니다. - 의존성이 많다면 SBOM 도구나 패키지 관리자의 라이선스 보고 기능으로 목록을 자동 생성합니다.
7. 기여를 받을 때: DCO 또는 CLA
외부 기여를 받으면 저작권이 여러 사람에게 나뉩니다. 이를 관리하는 두 방식이 있습니다.
- DCO: 기여자가 커밋에
Signed-off-by:를 넣어 '이 코드를 프로젝트 라이선스로 제출할 권리가 있다'고 확인합니다. 가볍고 리눅스 커널이 씁니다. - CLA: 기여자가 프로젝트에 재라이선스를 포함한 폭넓은 권리를 주는 계약입니다. 상용 듀얼 라이선스를 하거나 나중에 라이선스를 바꿀 여지를 두려면 필요합니다.
기여 규칙은 CONTRIBUTING.md 에 적어 둡니다.
8. 라이선스를 바꿀 때
- 저작권자는 앞으로의 버전에 다른 라이선스를 적용할 수 있습니다. 이미 배포된 버전에 대한 허락은 보통 철회되지 않습니다.
- 다른 기여자의 코드가 있다면 그들의 동의가 필요합니다(CLA 로 재라이선스 권한을 받았다면 예외).
- 허용형 → 카피레프트 변경은 비교적 쉽지만(허용형 코드는 카피레프트 프로젝트에 들어갈 수 있으므로), 카피레프트 → 허용형은 모든 저작권자의 동의 없이는 사실상 불가능합니다.
- 변경 시점, 이유, 적용 버전을 CHANGELOG 와 README 에 분명히 남깁니다.
체크리스트
- LICENSE 원문(자리표시자만 채움)
- 부속 파일(NOTICE, COPYING.LESSER 등)
- 파일 헤더(SPDX 두 줄)
- 패키지 메타데이터와 README
- 서드파티 고지
- 기여 규칙(DCO 또는 CLA)
이 글은 일반 정보이며 법률 자문이 아닙니다. 중요한 결정은 전문가와 상의하세요.
참고 출처
- GitHub Docs, Adding a license to a repository — https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository
- Apache, Applying the Apache License · Assembling LICENSE and NOTICE — https://www.apache.org/legal/apply-license.html
- GNU, How to Use GNU Licenses for Your Own Software — https://www.gnu.org/licenses/gpl-howto.html
- REUSE Specification — https://reuse.software/spec/
- Developer Certificate of Origin — https://developercertificate.org/