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.0
GNU・Apache・MPL は公式告知文も推奨していますが、SPDX の2行だけで代替するプロジェクトが増えています。詳しくは SPDX ガイドを参照してください。
5. パッケージのメタデータと README
package.json、Cargo.toml、pyproject.tomlなどの license フィールドに SPDX 識別子を書きます。- README の末尾に「ライセンス」の節を設け、1〜2行で要約します(例: 「This project is licensed under the MIT License — see LICENSE」)。
6. サードパーティのコードの表示
他人のコードを含めて配布するなら、そのライセンスの義務も一緒に守る必要があります。
- コピーして入れたコードは、元の著作権表示とライセンスをそのファイルに維持します。
- バイナリやアプリで配布するなら、使用したオープンソースの一覧とライセンス全文を
THIRD_PARTY_NOTICESファイルやアプリの「オープンソースライセンス」画面にまとめます。 - 依存関係が多い場合は、SBOM ツールやパッケージマネージャーのライセンスレポート機能で一覧を自動生成します。
7. 貢献を受け付けるとき: DCO または CLA
外部からの貢献を受け付けると、著作権が多くの人に分散します。これを管理する方式は2つあります。
- DCO: 貢献者がコミットに
Signed-off-by:を入れ、「このコードをプロジェクトのライセンスで提出する権利がある」ことを確認します。軽量で、Linux カーネルが採用しています。 - CLA: 貢献者がプロジェクトに再ライセンスを含む幅広い権利を与える契約です。商用のデュアルライセンスを行う場合や、後でライセンスを変更する余地を残したい場合に必要です。
貢献のルールは CONTRIBUTING.md に書いておきます。
8. ライセンスを変更するとき
- 著作権者は今後のバージョンに別のライセンスを適用できます。すでに配布したバージョンに対する許諾は通常撤回できません。
- 他の貢献者のコードがあれば、その人たちの同意が必要です(CLA で再ライセンスの権限を得ている場合は例外)。
- 寛容型からコピーレフトへの変更は比較的簡単ですが(寛容型のコードはコピーレフトのプロジェクトに入れられるため)、コピーレフトから寛容型への変更は、すべての著作権者の同意がなければ事実上不可能です。
- 変更の時期、理由、適用バージョンを CHANGELOG と README に明確に残します。
チェックリスト
- LICENSE の原文(プレースホルダーだけを埋める)
- 付属ファイル(NOTICE、COPYING.LESSER など)
- ファイルヘッダー(SPDX の2行)
- パッケージのメタデータと 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/