OSSライセンス入門

目次

• 概要
• ライセンスが必要な理由
• 代表的なライセンス
• permissiveとcopyleft
• 利用形態で変わる確認点
• SPDXで表記する
• NOTICEと著作権表示
• 依存関係の確認
• SBOMとライセンス棚卸し
• 素材・ドキュメント・フォント
• 自分のプロジェクトにライセンスを付ける
• 実務での注意
• ライセンス確認フロー
• READMEに書くこと
• ライセンス選択の実践ガイド
• GNU のライセンス体系
• Creative Commons とドキュメント
• Mozilla Public License (MPL) の特徴
• 依存関係ライセンスの監査
• オープンソース方針の実装
• REUSE ソフトウェアの推奨
• オープンソース財団別の推奨
• ライセンス違反と対応
• ライセンスと特許の相互作用
• ライセンス互換性の実装例
• Creative Commons ライセンスの実務
• SBOM (Software Bill of Materials) とライセンス管理
• ライセンス監査チェックリスト
• 商用利用とライセンスの組み合わせ
• ライセンス選択の実務フロー
• ライセンスと組織的管理
• まとめ
• 参考文献

概要

OSSライセンスは、ソフトウェアを使う、複製する、改変する、再配布する条件を定めるものです。ライブラリを使うだけでも、ライセンス条件を理解しておく必要があります。

ライセンスが必要な理由

著作物は、明示的な許諾がないと自由に使えません。OSSライセンスは、その許諾条件を明文化します。

ライセンスがない公開リポジトリは、自由に使ってよいとは限りません。

公開されていることと、利用許可があることは別です。GitHubに置かれていても、licenseが明示されていなければ、著作権者が明確に許可した範囲は分かりません。

OSSライセンスは、利用者にとっては「何をしてよいか」を示し、作者にとっては「どの条件で使ってほしいか」を示します。

代表的なライセンス

もう少し実務寄りに見ると、次の観点が重要です。

-only と -or-later は違います。GPL-3.0-only はGPLv3だけ、GPL-3.0-or-later はGPLv3以降を選べる、という意味です。

permissiveとcopyleft

大きく分けると、permissiveとcopyleftがあります。

copyleftは悪いものではありません。目的が違うだけです。重要なのは、自分の配布形態や製品方針と合うかを確認することです。

copyleftの範囲はライセンスごとに異なります。

ここで重要なのは「使った瞬間に全部公開」ではなく、「どのような形で結合し、改変し、配布するか」です。静的リンク、動的リンク、改変有無、source配布、SaaS提供、clientへの配布で確認点が変わります。

利用形態で変わる確認点

OSSライセンス確認では、ライセンス名だけでなく利用形態をセットで見ます。

「配布していないから何も不要」と決めつけるのも、「OSSを使ったから全部危険」と決めつけるのも雑です。使い方を分解すると判断しやすくなります。

SPDXで表記する

SPDXは、ライセンスを機械可読に表すための標準的な識別子を提供します。MIT、Apache-2.0、BSD-3-Clause のような短いIDを使うと、ツールで扱いやすくなります。

package metadataの例です。

{
  "license": "MIT"
}

複数licenseや例外を表す場合はSPDX expressionを使います。

source fileに書く例です。

SPDX-License-Identifier: MIT

REUSE specificationのように、各fileへ SPDX-License-Identifier とcopyrightを明記する運用もあります。大きなprojectや企業内では、人間が読む LICENSE だけでなく、機械で検査できる情報があると棚卸しが楽になります。

NOTICEと著作権表示

多くのライセンスでは、著作権表示とライセンス文を残す必要があります。

Apache-2.0では、NOTICEファイルがある場合の扱いも確認します。

配布物に含めるものの例です。

• ライセンス文
• 著作権表示
• NOTICE
• 変更した場合の表示

Apache-2.0では、再配布時にライセンス文を渡す、変更したfileには変更表示を残す、copyright/patent/trademark/attribution noticeを保持する、NOTICEがある場合は扱いを確認する、といった条件があります。

配布物に入れる場所の例です。

NOTICEは「適当に全依存のREADMEを貼る」ものではありません。license文、copyright表示、NOTICEに含めるべきattributionを整理し、重複や無関係なものを減らします。

依存関係の確認

依存ライブラリが増えると、ライセンス確認も難しくなります。

直接依存だけでなく、transitive dependencyも確認対象です。

ツール例です。

npm ls
pip-licenses
cargo deny

言語ごとに見る場所が違います。

transitive dependencyは忘れやすいところです。自分ではMITのライブラリを入れたつもりでも、その依存先に別licenseが含まれることがあります。

依存関係は更新で変わるため、初回確認だけでは不十分です。lockfile更新、major version update、container base image変更のタイミングで再確認します。

SBOMとライセンス棚卸し

SBOM(Software Bill of Materials)は、ソフトウェアに含まれるcomponentを一覧化する考え方です。security脆弱性だけでなく、license棚卸しにも使えます。

代表的な形式にはSPDXとCycloneDXがあります。

SBOMに含めたい情報です。

license確認では、SBOMを作って終わりではありません。許可済みlicense policy、例外申請、NOTICE生成、配布物への同梱までつなげます。

素材・ドキュメント・フォント

OSSライセンスはsource codeだけの話ではありません。README、図、スクリーンショット、アイコン、フォント、データセット、サンプル文章にもlicenseがあります。

Creative Commonsは、文章・画像・教材などでよく使われます。CC BY はcreditが必要、CC BY-SA はadaptationに同条件共有が必要、CC BY-NC は非商用条件、CC BY-ND は改変不可条件です。

ソフトウェアのsource codeには、通常はMITやApache-2.0などのsoftware licenseを使う方が扱いやすいです。CC licenseはコンテンツ向けに使われることが多く、software dependencyとしては注意して扱います。

自分のプロジェクトにライセンスを付ける

自分のprojectを公開するときは、最初にlicense方針を決めます。

repositoryに置くものです。

LICENSE
NOTICE
README.md
THIRD_PARTY_NOTICES.md

source file単位で明記するなら、SPDX headerを使います。

// SPDX-License-Identifier: MIT

共同開発では、contributionの扱いも決めます。CLA(Contributor License Agreement)を使うprojectもあれば、DCO(Developer Certificate of Origin)を使うprojectもあります。小さな個人projectでも、READMEに「contributions are licensed under the same license」といった方針を置くと曖昧さが減ります。

実務での注意

実務では次を確認します。

• 商用利用可能か
• 再配布時の条件は何か
• ソース公開義務があるか
• SaaS提供で条件が変わるか
• 特許条項があるか
• NOTICEが必要か
• 依存関係のlicenseが変わっていないか

ライセンス判断は法務判断を含むため、重要な製品では専門家に確認します。

特に注意したい場面です。

このページは実務の読み方を整理するものです。個別の法的判断が必要な場合は、プロジェクトの配布形態、契約、地域、会社方針を含めて専門家に確認します。

ライセンス確認フロー

OSSを追加するときは、次の順で確認します。

確認対象は直接依存だけではありません。依存の依存にも別ライセンスが含まれます。

追加前に見る観点です。

READMEに書くこと

自分のプロジェクトを公開する場合、READMEとrepositoryにライセンス情報を明示します。

• repository rootに LICENSE を置く
• READMEにライセンス名を書く
• third-party noticeが必要なら別ファイルにまとめる
• サンプルコードと本文のライセンスが違うなら明記する

例です。

## License

This project is licensed under the MIT License.
See [LICENSE](./LICENSE).

ライセンスが曖昧なプロジェクトは、利用者にとって使いにくくなります。公開するなら、最初に方針を決めておく方が親切です。

third-party noticeの例です。

## Third-party licenses

This project includes third-party open source software.
See [THIRD_PARTY_NOTICES.md](./THIRD_PARTY_NOTICES.md).

READMEに「このproject自身のlicense」と「同梱している第三者componentのlicense」を混ぜないようにします。project本体はMITでも、依存componentにはApache-2.0やBSDが含まれることがあります。

zing-your-repository/licensing-a-repository)

• Apache License 2.0
• GNU Licenses
• GNU GPLv3
• GNU AGPLv3
• Mozilla Public License 2.0
• Creative Commons Licenses
• SPDX License List
• REUSE Specification
• CycloneDX Specification Overview
• GitHub Docs: Dependency graph

ライセンス選択の実践ガイド

ChooseALicense.com では、一般的な目的別にライセンスを推奨しています。

目的別推奨ライセンス

ライセンスの互換性マトリクス

MIT ← → Apache 2.0 ✓（互換性あり）
MIT ← → GPL-3.0 ✗（非互換、GPLがより強い）
Apache 2.0 ← → GPL-3.0 ✗（特許条項衝突）
BSD-3-Clause ← → MIT ✓

複数のライセンスを混合使用する際は、最も制限的なライセンスに統一する必要があります。

GNU のライセンス体系

GNU.org で詳細に説明されている GPL の分類です。

GPL バージョン間の差異

GPL-3.0 は GPL-2.0 の改善版であり、より明示的な特許許諾と、ハードウェア制限に対する保護を含みます。

Creative Commons とドキュメント

Creative Commons (creativecommons.org) は、ソフトウェア以外のコンテンツ向けライセンスです。

CC ライセンス体系

CC-BY: 表示のみ必須
CC-BY-SA: 表示+同じライセンスで配布
CC-BY-NC: 表示+非商用のみ
CC-BY-ND: 表示+改変禁止
CC0: パブリックドメイン相当

ドキュメント、画像、データセットには CC ライセンスが適しています。

Mozilla Public License (MPL) の特徴

Mozilla.org の MPL は、GPL と Apache のバランスを取った設計です。

MPL-2.0 の主要特徴

1. ファイル単位でのライセンス選択
   - 異なるファイルで異なるライセンスを適用可能
   - MPL-2.0 と Apache 2.0 の混在使用が可能

2. Weak Copyleft
   - ファイル自体の変更は共有必須（copyleft）
   - リンク元のコードは共有不要（weak）

3. 明示的な特許許諾
   - Apache 2.0 と同じく、特許許諾を含む
   - GPL-3.0 より明示的でない

4. 二重ライセンス容易
   - 複数ライセンスでの配布が設計上容易

依存関係ライセンスの監査

多くのプロジェクトが複数のオープンソースに依存しており、ライセンス互換性の確認が必須です。

ライセンス監査ツール

ライセンス確認の実装

# npm: package.json のライセンス確認
npm list --depth=0

# Python: requirements.txt のライセンス確認
pip install pip-licenses
pip-licenses

# Node.js: license-report ツール
npm install -g license-report
license-report --csv

SPDX ライセンス ID の記述

{
  "name": "my-project",
  "license": "MIT",
  "dependencies": {
    "react": {
      "version": "18.2.0",
      "license": "MIT"
    },
    "lodash": {
      "version": "4.17.21",
      "license": "MIT"
    }
  }
}

SPDX.org では、全ライセンスに統一的な ID を割り当てており、マシンリーダブル化されています。

オープンソース方針の実装

企業や組織でのオープンソース活用には、明確なポリシーが必要です。

チェックリスト

□ ライセンス許可方針
  □ GPL の使用を許可するか
  □ AGPL の使用を許可するか
  □ 商用ライセンス混在の可能性

□ コンプライアンス
  □ NOTICE ファイルの配置
  □ ライセンステキストの包含
  □ ソースコードの配布

□ セキュリティ
  □ 脆弱性スキャン自動化
  □ 依存関係の定期更新
  □ End-of-Life パッケージの排除

□ 貢献
  □ CLA(Contributor License Agreement)の検討
  □ Developer Certificate of Origin (DCO)
  □ コミュニティガイドライン

REUSE ソフトウェアの推奨

REUSE.software はドイツの Free Software Foundation による推奨です。

REUSE コンプライアンス

プロジェクト構造:
my-project/
├── src/
│   ├── main.py
│   └── main.py.license (ライセンスファイル)
├── LICENSES/
│   ├── MIT.txt
│   └── Apache-2.0.txt
├── COPYING
└── .reuse/
    └── dep5  (メタデータ)

REUSE ツールで自動的にコンプライアンス確認できます。

pip install reuse
reuse lint  # ライセンス記述チェック
reuse download --all  # ライセンステキスト自動ダウンロード

オープンソース財団別の推奨

Apache Software Foundation (apache.org)

ASF プロジェクト特性:
- Apache License 2.0 を強制
- Contributor License Agreement (CLA) 必須
- 法務サポート提供
- イネキュベーション制度あり

例: Apache Kafka, Hadoop, Spark, Cassandra

Free Software Foundation (fsf.org)

FSF 推奨:
- GPL-3.0 推奨
- Copyleft を強調
- 自由の尊重
- DRM 批判

例: GNU Emacs, GNU Coreutils, Linux kernel (部分)

Open Source Initiative (opensource.org)

OSI 認定ライセンス:
- 約90個のライセンスを認定
- 仕様: Open Standards
- 非営利組織
- ライセンス中立

例: MIT, Apache 2.0, GPL-3.0, BSD など

ライセンス違反と対応

不適切なライセンス使用時の対応です。

よくある違反パターン

1. ライセンスの無視
   → ソースコード非公開
   → GPL で配布するべきコード隠蔽

2. 帰属表示の欠落
   → MIT や Apache で NOTICE 記載忘れ

3. 改変追跡の失敗
   → GPL で改変部分の明示化なし

4. 商用化に未対応
   → 非商用ライセンスで商売

違反時の対応

1. 検出（監査ツール）
   ↓
2. 通知（著作権保有者から）
   ↓
3. 協議（修正時間の交渉）
   ↓
4. 修正（ソース公開、ライセンス修正）
   ↓
5. 確認（著作権保有者による確認）

多くの場合、誠実な対応（3-5）で解決します。

ライセンスと特許の相互作用

Apache 2.0 の特許条項

Apache 2.0 が MIT などより法務的に強いのは、明示的な特許許諾を含むためです。

Apache 2.0 の3.1条より:
"Each Contributor hereby grants to You a perpetual,
 worldwide, non-exclusive, no-charge, royalty-free,
 irrevocable copyright and patent license..."

つまり、その contributors が保有する特許について、ソフトウェアの利用・改変に関しては無償で使用できます。

GPL の特許条項

GPL-3.0 では、さらに強い保護があります：

"If you convey covered work... you may not terminate
 any recipient's rights under this License for exercising
 any right granted under this License."

もし GPLed コードを特許侵害に使用すると訴えた場合、その者に対しては自動的にライセンスが失効します。これを「patent termination clause」と呼びます。

ライセンス互換性の実装例

複数の OSS を組み合わせた場合の互換性確認：

プロジェクト選定フロー:

1. メインのライセンス決定
   ↓
2. 依存ライブラリをスキャン
   ↓
3. 互換性チェック
   - MIT の依存: OK（すべてと互換）
   - GPL-2.0 の依存: 注意（copyleft 伝播）
   - AGPL-3.0 の依存: 注意（SaaS も対象）
   ↓
4. 非互換があれば、代替 or 組織判断

実装例（Python + pip-licenses）：

pip install pip-licenses
pip-licenses --format=json > licenses.json

# 出力例:
# [
#   {"name": "django", "version": "4.2", "license": "BSD-3-Clause"},
#   {"name": "requests", "version": "2.31.0", "license": "Apache-2.0"}
# ]

Creative Commons ライセンスの実務

ドキュメント、画像、デザインには CC ライセンスが一般的です。

CC バージョンと条件

CC-BY-4.0
  制限: 帰属表示のみ必須
  用途: ブログ記事、チュートリアル

CC-BY-SA-4.0
  制限: 帰属表示 + 同一ライセンスで再配布
  用途: Wikipedia 型の協働資料

CC-BY-ND-4.0
  制限: 帰属表示 + 改変禁止
  用途: 著作物の保護（配布のみOK）

CC-BY-NC-4.0
  制限: 帰属表示 + 非商用のみ
  用途: 教材、学習資料（営利化禁止）

CC ライセンスはソフトウェアに使うべきではありません。ソフトウェア向けは、GPL、MIT、Apache 2.0 などの「コードライセンス」が適切です。

SBOM (Software Bill of Materials) とライセンス管理

SBOM は、ソフトウェアに含まれるすべてのコンポーネント、バージョン、ライセンスをリスト化したものです。

CycloneDX 形式での表現

<?xml version="1.0" ?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.4" version="1">
  <components>
    <component type="library">
      <name>requests</name>
      <version>2.31.0</version>
      <licenses>
        <license>
          <name>Apache-2.0</name>
        </license>
      </licenses>
    </component>
    <component type="library">
      <name>django</name>
      <version>4.2.0</version>
      <licenses>
        <license>
          <name>BSD-3-Clause</name>
        </license>
      </licenses>
    </component>
  </components>
</bom>

SBOM 生成ツール

# Python プロジェクト
pip install cyclonedx-bom
cyclonedx-py -o sbom.json

# Node.js プロジェクト
npm install -g @cyclonedx/npm
cyclonedx-npm -o sbom.json

# Go プロジェクト
go install github.com/CycloneDX/cyclonedx-go/cmd/cyclonedx-go@latest
cyclonedx-go mod -o sbom.json

# コンテナイメージ
syft docker.io/library/python:3.11 -o spdx-json > sbom.json

ライセンス監査チェックリスト

実務での確認項目：

□ 依存関係スキャン
  □ すべての直接依存を列挙
  □ すべての推移依存を列挙
  □ SBOM を生成

□ ライセンス確認
  □ 各ライセンスを OSI 認定か確認
  □ Copyleft ライセンスを識別
  □ AGPL の存在を確認

□ 互換性チェック
  □ プロジェクトライセンスと依存が互換か
  □ Copyleft 伝播の有無
  □ SaaS 利用時の AGPL リスク

□ 法務確認
  □ 組織の使用目的（商用/非商用）
  □ 配布形態（バイナリ/ソース）
  □ 特許関連の懸念

□ ドキュメント化
  □ LICENSE ファイルを作成
  □ NOTICE ファイルで依存関係を記載
  □ README にライセンス方針を記載

商用利用とライセンスの組み合わせ

パターン1: MIT ライセンスの商用利用

ビジネスモデル: 有料 SaaS

ライセンス方針:
  - ソースコード: MIT (非公開で OK)
  - サービス: 利用規約で規定
  - 利用者への提示: MIT ライセンスのテキストと帰属

パターン2: GPL コンポーネントの利用

ビジネスモデル: 有料ソフトウェア + 他社 GPL コンポーネント

選択肢:
  A. ソース全体を GPL で公開 (利益モデルの再検討)
  B. GPL コンポーネントを隔離 (LGPL 等でラップ)
  C. 別製品として配布 (GPL は付属品扱い)
  D. ライセンス購入 (著作権者に許可を得る)

多くの場合、B か D が選ばれます。

パターン3: AGPL リスク対策

ビジネスモデル: クラウドサービス

AGPL の条件:
  - ソース公開義務は配布時だけでなく、SaaS 利用時も発生
  - "ネットワークを通じてユーザーと相互作用する" = 公開対象

対策:
  1. AGPL 依存関係を避ける
  2. 別プロセス化 (LGPL でラップ)
  3. 組織的な AGPL 利用方針の確立

ライセンス選択の実務フロー

プロジェクト開始時のライセンス選択を体系化：

ステップ1: 利用形態を確認
  - 組織内のみ？ → Proprietary または Unlicense
  - オープンソースで公開？ → OSS ライセンス選択へ

ステップ2: OSS の場合、配布形態を確認
  - ソースコード公開？
  - バイナリ配布？
  - SaaS/クラウド利用？

ステップ3: ライセンス選定
  - シンプル重視 → MIT
  - 特許懸念あり → Apache 2.0
  - 自由重視 → GPL-3.0
  - 弱い保護 → LGPL-3.0

ステップ4: 依存関係確認
  - 既存 OSS の依存ライセンスをスキャン
  - 互換性チェック
  - 非互換あれば、依存削除または代替を検討

ステップ5: ドキュメント化
  - LICENSE ファイルを明示
  - NOTICE/AUTHORS ファイルで帰属表示
  - README にライセンス情報を記載

ライセンスと組織的管理

企業内ポリシーの例

大規模組織では、OSS ライセンス方針を定めることが一般的です：

推奨ライセンス（許可）:
  - MIT / BSD-3-Clause (何でも OK)
  - Apache-2.0 (特許懸念対応)
  - LGPL-2.1+ (コンポーネント利用)

条件付き許可：
  - GPL-2.0 (レビュー必須)
  - AGPL-3.0 (法務承認必須)

禁止：
  - SSPL (著作権者による過度な著作権主張)
  - Commons Clause (疑似商用化)

定期的な監査

監査スケジュール:
  四半期ごと:
    - SBOM 再生成
    - 新規依存の追加ライセンス確認
    - CVE スキャン
  
  年1回:
    - 全依存関係の包括的レビュー
    - ポリシー改善の検討
    - 法務の確認

まとめ

オープンソースライセンスの理解と選択は、プロジェクトの長期的な成功に直結します。

• 個人プロジェクト: MIT（シンプル、制約少ない）
• ビジネス向け: Apache 2.0（特許許諾が明示的）
• GPL 互換性必須: LGPL-3.0（弱いCopyleft）
• 企業内ツール: Proprietary（スピード重視時）
• ドキュメント: CC-BY-SA（改変共有）

ライセンスは法的問題だけでなく、コミュニティ形成と信頼構築の基礎です。また、SBOM の生成と監査による継続的なコンプライアンス管理が、大規模プロジェクトでは必須です。

OSSライセンスは、利用条件を明確にするための約束です。MITやApache-2.0のようなpermissive系、GPL系のcopyleft、NOTICEや著作権表示の扱いを理解し、依存関係を継続的に確認することが大切です。実務では、SPDX ID、利用形態、配布有無、transitive dependency、SBOM、素材licenseまで含めて棚卸しすると、後から困りにくくなります。

参考文献

公式・標準

• GitHub Docs: Licensing a repository
• SPDX Specification
• SPDX License List

ライセンス情報

• Choose a License
• Open Source Initiative: Licenses
• GNU: GPL FAQ
• Apache Software Foundation: License

SBOM と監査

• CycloneDX Specification
• Software Composition Analysis (SCA) - NIST Guide
• REUSE Software Initiative
• Syft - SBOM Generator

Creative Commons

• Creative Commons Licenses
• CC-BY-4.0
• CC-BY-SA-4.0