OSS ライセンス社内ポリシーの作り方【申請書・禁止リスト雛形付き】

規程の雛形だけ欲しい方は「3 段階で即決する」「調達申請テンプレ」へ、再ライセンスの監視だけ知りたい方は「ライセンス変更を見逃さない」へ、背景から読みたい方はこのまま次の見出しへ進んでください。

執筆時点: 2026-06-13 / 対象法域: 日本(海外動向は背景として米・EU を参照)

この記事は、ソフトウェアの権利・ライセンスを扱うシリーズの一本です。前提となるライセンスの読み方は OSS ライセンス に、構成表(SBOM◆)の作り方は SBOM ツール に、SaaS◆ の利用規約面は AI サービスを使う前に読む利用規約 にまとめています。

用語ミニ解説(はじめての方へ):

• OSS(Open Source Software): ソースコードが公開され、ライセンス条件の範囲で自由に利用・改変・再配布できるソフトウェア。
• SaaS(Software as a Service): インストールせずブラウザ等から利用するクラウド型ソフトウェア。
• SBOM(Software Bill of Materials): 製品が含むソフトウェア部品とそのライセンス・バージョンの一覧表。「ソフトウェアの原材料表」。
• コピーレフト: 改変・再配布物にも同じライセンスでのソース公開を求める性質(GPL / AGPL など)。
• ソースアベイラブル: ソースは見えるが OSS の定義は満たさないライセンス(BSL / SSPL / FSL など)。多くは内部利用は可で、顧客向けに提供する段階で制限がかかる。挙動はライセンスごとに異なり、とくに SSPL は「外販禁止」ではなく、サービスとして提供するならサービススタック全体のソース公開を求める強コピーレフト(SSPL §13)。BSL は提供元が定める範囲を超える本番利用を制限し、期限後にオープン化する型。
• GitHub: ソースコードのホスティングと共同開発のためのプラットフォーム。多くの OSS がここで公開・配布されます。
• Issue(イシュー): GitHub などで課題・依頼・申請を 1 件ずつ起票・管理する単位。本記事では調達申請フォームの貼り先として使います。
• PoC(Proof of Concept / 概念実証): 本格導入の前に、技術的に成立するかを小さく試して確かめる検証。
• CI(Continuous Integration / 継続的インテグレーション): コード変更のたびに自動でビルド・テストを走らせるしくみ。本記事では SBOM 生成の組み込み先。

OSS◆ や SaaS の導入は、もはや「個人がライブラリを選ぶ」話では収まりません。昨日まで自由に使えた OSS が、ある日ライセンス変更で「条件付き」や「外販不可」に変わることが、ここ数年で何度も起きています。とはいえ、毎回すべてを法務に投げていては開発が止まります。この記事では、開発チームが自分で素早く判断でき、リスクの高いものだけ法務に上げやすくなる状態を、コピーして使える雛形として組み立てていきます。

なぜ今、社内の「調達規程」が必要なのか

調達規程が必要な理由は、大きく 2 つあります。ライセンスは動くこと、そしてそれを管理する制度が国際的に整いつつあることです。

ライセンスは予告なく変わる

ここ数年、広く使われていた OSS が相次いでライセンスを変更しました。代表例は次のとおりです（日付・変更内容は本記事末尾の公式ソースに基づきますが、最新状況は各公式をご確認ください）。

※ MinIO はライセンス文言を切り替えた「再ライセンス」ではなく、開発体制を縮小・終了した「開発終了型」のケースです。ライセンス自体は AGPLv3 のままですが、メンテナンスが止まったソフトを使い続けるリスクという点で、調達規程が監視すべき対象に含まれます。

ポイントは、これらが「悪いソフト」だったわけではないことです。優れたソフトほど、提供元が事業を守るためにライセンスを変えるインセンティブを持ちます。つまり「採用時に一度確認すれば終わり」ではなく、使い続ける限り変更を監視する必要がある、というのが第一の理由です。

管理を求める制度が国際的に整ってきた

第二の理由は、ソフトウェア構成の管理（SBOM・脆弱性対応・ライセンスコンプライアンス）を、各国の制度が求め始めていることです。本記事は日本の実務が主題なので深入りはしませんが、調達規程の「背骨」として知っておくべき動きを 3 つだけ挙げます。

• EU（CRA）: サイバーレジリエンス法（Regulation (EU) 2024/2847、2024-12-10 発効、主要義務の全面適用は 2027-12-11）が、SBOM 作成・脆弱性対応を法的義務として課します。ただし名宛人は「EU 市場に出すデジタル製品の製造者」であり、SaaS やモデルを利用するだけの一般的な調達を直接規律するものではありません（自社が EU に製品を出す場合に関わります）。ただし、自社製品の機能に不可欠なリモートデータ処理を SaaS 形態で提供する場合などは対象になりうるため、EU 展開時は個別に確認してください。
• 米国（EO 14028）: 大統領令 14028（2021-05-12 署名）と NTIA の「SBOM 最小要素」（2021-07）が政府調達向けに SBOM を後押ししました。ただし自己証明の共通様式を求めた OMB メモは 2026-01 に撤回され（M-26-05）、現在はリスクベース・各機関裁量へ転換しています。なお SBOM の最小要素自体も、CISA が 2025-08 に改訂版（2025 Minimum Elements）を公開コメント用ドラフトとして公表しており（コメント締切 2025-10-03、本稿時点で最終版は未確定）、求められる構成要素は今後変わる可能性があります。
• 国際標準（OpenChain）: OSS ライセンスコンプライアンス管理の国際規格 ISO/IEC 5230、SBOM 記述標準の SPDX◆（ISO/IEC 5962）/ CycloneDX。社内規程を「管理システム」として裏づける準拠先になります。

これらが共通して示すのは、「成熟した OSS ポリシーには、判定基準・申請手順・SBOM・監視が含まれているべき」という方向性です。次の章から、それを実物の雛形として組み立てていきます。

許可・警告・禁止の 3 段階で即決する

規程の心臓部は、ソフトウェア・SaaS・AI モデルを 3 段階に振り分ける判定基準です。これがあると、開発者が多くのケースを自分で判断しやすくなり、迷うものだけを法務に上げる運用にしやすくなります。

「警告」をどう扱うかが肝心

実務でいちばん判断が要るのは🟡警告です。とくに BSL◆ / SSPL◆ のようなソースアベイラブル系は、「ソースが公開されている＝自由に使える」と誤解されがちですが、挙動はライセンスごとに異なります。SSPL は「外販禁止」ではなく、サービスとして提供するならサービススタック全体のソース公開を求める強コピーレフトで、BSL は提供元が定める範囲を超える本番利用を制限します。いずれも社内ツールに使う分には問題ないことが多くても、顧客向け SaaS に転用した瞬間に条件（ソース公開義務や利用制限）に触れえます。だから禁止ではなく「警告（用途を確認してから使う）」に置きます。

判定の例を挙げます。

• MIT ライセンスで規模条件なし → 🟢 そのまま使える
• Llama 系（Llama 3.1 コミュニティライセンス §2 で月間アクティブユーザー 7 億超なら Meta への別途ライセンス要請が必要） → 🟡（中堅企業では超えないので実質🟢、ただし OEM 提供時は再判定）
• Non-Production License の AI モデルを本番投入 → 🔴 違反になりうる（評価のみ可とされる例が多い。ただし「評価」の範囲もライセンスごとに異なり、営利組織内での評価利用は条件を要確認。本番化する場合は、Apache / MIT 系など商用利用が明確なライセンスへの差し替えを検討します）

リストは「型」を配り、自社で埋める

ここで重要なのは、他社の許可リストをそのままコピーしないことです。許可・警告・禁止のどこに線を引くかは、自社が「社内ツールだけ作るのか」「顧客向け SaaS を外販するのか」で変わります。そこで本記事は、判定基準（上の 3 段階）と空欄付きの型を配り、中身（具体的なソフト名）は自社で棚卸しして埋める前提にします。最初は「いま使っている主要ソフト 20〜30 個」を 3 段階に分類するだけでも、まず運用を始められます。

調達申請テンプレート（そのまま GitHub Issue に貼る）

判定基準があっても、🟡警告・🔴禁止に当たったときに「誰が何を確認して承認するか」が決まっていなければ運用は回りません。そこで、GitHub◆ の Issue◆ テンプレートとして使える申請フォームを用意します。下のコードブロックを .github/ISSUE_TEMPLATE/ に置くか、申請時にそのまま貼り付けてください。

## 申請対象
- 名称 / バージョン:
- 公式 LICENSE / モデルカードの URL:

## 用途
- [ ] 社内ツール（従業員のみ）
- [ ] 顧客向け SaaS / 配布製品
- [ ] PoC・評価のみ
- [ ] 学習・勉強会のみ

## ライセンス分類（社内規程の許可/警告/禁止に基づく）
- [ ] 🟢 許可リスト掲載 → 参考まで（申請不要）
- [ ] 🟡 警告リスト → 該当する条件:
  - [ ] 規模条件（従業員数 / 売上 / MAU）
  - [ ] 地理制限（EU など）
  - [ ] 用途制限（SaaS 外販禁止 など）
  - [ ] コピーレフト（GPL / AGPL）
- [ ] 🔴 禁止リスト → PoC・評価のみ（本番利用は不可）

## 条件への対応
- 規模超過時の有償プラン / 価格:
- 地理制限時の代替:
- AGPL 対応:
  - 改変の有無:
  - ネットワーク越しにユーザーへ提供するか（AGPL の肝）:
  - ソース提供方法（リポジトリ URL / 配布物同梱 など）:

## SBOM
- 生成ツール（Syft / Trivy / OSV-Scanner など）:
- ライセンス検出結果:

## 承認
- [ ] 開発リード
- [ ] セキュリティ
- [ ] 法務（🟡警告・🔴禁止のときのみ必須）

## 確認 URL（取得日: YYYY-MM-DD）
- 公式 LICENSE:
- 利用規約 / Use Policy:
- 価格ページ:

このフォームの狙いは、🟢許可なら申請ゼロ・🟡警告と🔴禁止だけ法務を巻き込むという流れを、チェックボックスで強制することです。「全部を法務に確認する」運用は現実には回らないので、判定で絞ってから人を呼ぶのがコツです。

あわせて、ライセンス変更が起きたときの 検知レポートも Issue 化しておくと、後述の監視が機能します。

## 検知対象
- 名称 / 旧ライセンス → 新ライセンス / 変更日 / 公式アナウンス URL:

## 影響範囲
- 社内利用: あり / なし
- 顧客向け: あり / なし
- 既存リリース: 継続可 / 差し替え必要

## 対応方針
- [ ] 旧バージョンで固定
- [ ] フォークへ移行（OpenTofu / Valkey / OpenSearch など）
- [ ] 商用ライセンス購入
- [ ] 機能を差し替え

ガイドライン雛形と運用フロー

判定基準と申請フォームができたら、それをいつ・誰が・どう回すかを 1 ページのガイドラインにまとめます。OSPO（オープンソースを専門に管理する部署）がない中堅企業でも回る、最小構成の共通ルールがこちらです。

【社内 OSS/SaaS 利用ガイドライン（最小5条）】
□ 1. 採用前に、社内規程の許可/警告/禁止リストで分類を確認する
□ 2. 🟡警告・🔴禁止に該当したら、Issue テンプレートで法務レビューを依頼する
□ 3. SBOM ツール（Syft / Trivy / OSV-Scanner）を CI に組み込み、四半期に全件棚卸しする
□ 4. Apache 2.0 など NOTICE が必要なライセンスは、配布物に NOTICE を同梱する
□ 5. AI モデルのライセンスは、呼び出すライブラリとは別物。モデルカードで個別に確認する

用途で変わる判断（シナリオ別）

同じソフトでも、どう使うかで必要な確認が変わります。

• 社内ツール（顧客に配布しない）: 🟢許可は自由。🟡警告は規模条件だけ確認すればよいことが多い。🔴禁止は評価のみ。
• 顧客向け SaaS / 配布製品: 🟡警告はすべての条件（地理・用途・コピーレフト）を確認。とくに AGPL◆ 系、SaaS 外販禁止系、AI モデルの利用規約継承に注意。🔴禁止は使用不可（商用 API / 商用ライセンスへ切り替え）。
• 社内研究・PoC のみ: 研究範囲なら広く許容できるが、将来本番化する見込みがあるなら、ライセンスを切り替える計画を Issue に残す。

運用フローと役割分担

採用検討から監視までを 1 本の流れにすると、こうなります。

採用検討 → ①許可リストなら即採用 → ②警告なら Issue で法務レビュー（条件クリアで採用、不可なら代替検討）→ ③禁止なら PoC のみ → 採用後は CI◆ に SBOM を組み込み → 四半期で棚卸し → ライセンス変更を検知したら検知レポートを発行。

役割は次のように分けます。

四半期ごとの棚卸しは、次のチェックリストをそのまま貼って使えます。

【四半期棚卸しチェックリスト】
□ SBOM を全件再生成した（Syft + Trivy など）
□ 新規導入したソフト・モデルが許可/警告/禁止のどこかに分類されている
□ 既存ソフトのライセンス変更がないか確認した（次章の監視で）
□ 規模条件（従業員数・MAU・売上）の超過がないか確認した
□ 警告リスト該当ソフトの法務レビュー期限が切れていないか確認した
□ 禁止リストのソフトが PoC のまま本番に残っていないか確認した

ライセンス変更を見逃さない（規程に組み込む監視条項）

ここが、多くの解説記事が触れていない部分です。再ライセンスの「解説」はよく見かけますが、変更をどう検知し、検知したら規程上どう動くかまで書いたものはほとんどありません。冒頭で見たとおりライセンス変更は今後も起きるので、監視を規程の一部として明文化しておきます。

監視リスト（直近で変更があったもの＝四半期で確認）

まずは「過去に変更したソフト」を監視対象にします。一度変えた提供元は再び変える可能性が相対的に高いからです。

監視チャネル

「公式の一次情報を、自動で手元に届く形にする」のが基本方針です。

• GitHub Watch: 各リポジトリを Watch し、通知カテゴリで releases を有効にする（再ライセンスに気づく手がかりの一つ。ただし LICENSE 変更が release ノートに必ず載るとは限らない）。Watch は リポジトリ単位で、特定の LICENSE ファイル変更を直接 Watch する機能はない。LICENSE 自体の差分監視は、後述の API / 定期ジョブ（ファイルのハッシュ比較）で補う
• 公式 RSS / ブログ: Redis・Elastic・HashiCorp などの提供元ブログを購読
• OSI◆ / 業界ニュース: opensource.org のニュースレター、LWN.net、Hacker News の licensing タグ
• deps.dev: 依存パッケージのライセンス情報も確認できる（Google 提供）。SBOM ツールでの定期スキャンと組み合わせると、依存の中のライセンス変化に気づきやすい

検知を自動化する（監視条項の実装例）

四半期ごとに人手で全リポジトリを見るのは現実的ではありません。LICENSE ファイルのハッシュ値を定期的に比較し、変わっていたら Issue を立てる、という最小の自動化を入れておきます。GitHub リポジトリが 1 つあれば動かせます。

どこに何のファイルを置くか:

• .github/workflows/license-watch.yml … 下のワークフロー本体。このパス・ファイル名で保存すると GitHub Actions が自動で認識します。
• watched-repos.txt … リポジトリ直下に置く監視対象リスト。1 行に 1 つ、owner/repo 形式で書きます(例: redis/redis、hashicorp/terraform)。

# .github/workflows/license-watch.yml
# 監視対象リポジトリの LICENSE のハッシュを毎月チェックし、
# 前回から変わっていたら Issue を自動作成する。
name: License Change Detection

on:
  schedule:
    - cron: "0 0 1 * *" # 毎月 1 日 00:00 UTC に自動実行
  workflow_dispatch: # 画面の「Run workflow」で手動実行も可能

permissions:
  contents: write # 比較用スナップショットをリポジトリへ書き戻すため
  issues: write # 変更検知時に Issue を作るため

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: Compare LICENSE hashes
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} # 自動で入る。事前設定は不要
        run: |
          # watched-repos.txt の各 "owner/repo" の LICENSE の SHA を集める
          : > license-shas.txt
          while read -r repo; do
            [ -z "$repo" ] && continue
            sha=$(curl -s -H "Authorization: Bearer $GH_TOKEN" \
              "https://api.github.com/repos/$repo/contents/LICENSE" | jq -r '.sha')
            echo "$repo $sha" >> license-shas.txt
          done < watched-repos.txt

          # 前回の記録(license-shas.prev)と比較し、差があれば Issue を作る
          if [ -f license-shas.prev ] && ! diff -q license-shas.prev license-shas.txt; then
            gh issue create --title "License change detected" \
              --body "$(diff license-shas.prev license-shas.txt || true)"
          fi

          # 今回の結果を次回比較用に保存(リポジトリへコミット)
          mv license-shas.txt license-shas.prev
          git config user.name  "license-watch-bot"
          git config user.email "[email protected]"
          git add license-shas.prev
          git commit -m "chore: update license hash snapshot" || echo "変更なし"
          git push

使い方の要点:

• gh(GitHub CLI)も jq も GitHub の ubuntu-latest ランナーに最初から入っているため、追加インストールは不要です。
• 初回実行は比較対象(license-shas.prev)が無いので Issue は作らず、基準スナップショットを保存するだけです。2 回目以降、ハッシュが変わったリポジトリがあれば Issue が立ちます。
• LICENSE というファイル名が無いリポジトリ(LICENSE.md や COPYING など)は API が 404 になります。その場合は URL のファイル名を対象に合わせて変えてください。

これを「規程の監視条項」として一文で書くなら、こうなります。

監視条項（例）: 当社が利用する OSS のうち、別表「監視リスト」に掲げるものは、四半期ごとに最新のライセンスを確認する。ライセンス変更を検知した場合は、検知レポート（Issue）を発行し、影響範囲の評価と対応方針の決定を 2 週間以内に行う。

この一文と、前章までの判定基準・申請テンプレ・棚卸しがそろえば、「採用して終わり」ではなく「使い続ける限り守られる」調達規程になります。

まとめ

社内の OSS/SaaS 調達規程は、立派な文書を一から書くものではありません。判定・申請・監視の最小セットをコピーして、自社向けに調整しながら回すのが現実的です。導入は次のチェックリストから始めてください。

【調達規程 導入チェックリスト】
□ いま使っている主要ソフト 20〜30 個を 許可/警告/禁止 に分類した
□ 調達申請の Issue テンプレートを設置した（🟢は申請ゼロ、🟡🔴だけ法務）
□ ライセンス変更の監視リストと監視条項を規程に入れた
□ SBOM ツールを CI に入れ、四半期棚卸しを予定に組み込んだ
□ 雛形を自社の事業内容に合わせて法務・OSS コンプライアンス担当と調整した

「組織の規程はまだ大げさ」という個人開発者・小規模チームの方は、まずこの 3 点だけでも、再ライセンス事故の大半は防げます。

【個人・小規模向け 最小セット】
□ 採用する前に、公式 LICENSE と SPDX 識別子を 1 行だけ確認する
□ BSL / SSPL / 非商用は「外販・本番で要注意」とだけ覚えておく
□ よく使う OSS 5〜10 個を GitHub Watch して、ライセンス変更に気づける状態にする

個別ライセンスの読み方は OSS ライセンス、構成表の作り方は SBOM ツール、SaaS の利用規約面は AI サービスを使う前に読む利用規約 で詳しく扱っています。

References

• HashiCorp ライセンス変更（2023-08、BSL 1.1）: https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license
• Redis ライセンス変更（2024-03、RSAL/SSPL）: https://redis.io/blog/redis-adopts-dual-source-available-licensing/
• Redis AGPLv3 追加（2025-05-01、Redis 8 から）: https://redis.io/blog/agplv3/
• Elastic ライセンス変更（2021-01、SSPL/ELv2）: https://www.elastic.co/blog/licensing-change
• Elastic、AGPL 追加（2024-08）: https://www.elastic.co/blog/elasticsearch-is-open-source-again
• MinIO（GitHub リポジトリ / アーカイブ表記）: https://github.com/minio/minio
• MinIO メンテモード移行コミット 27742d4（2025-12-03）: https://github.com/minio/minio/commit/27742d4
• 大統領令 EO 14028（2021-05-12）: https://bidenwhitehouse.archives.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
• NTIA「The Minimum Elements for an SBOM」（2021-07）: https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
• CISA「2025 Minimum Elements for an SBOM」（2025-08、公開コメント用ドラフト、docket CISA-2025-0007）: https://www.federalregister.gov/documents/2025/08/22/2025-16147/request-for-comment-on-2025-minimum-elements-for-a-software-bill-of-materials
• OMB M-26-05（2026-01、リスクベース転換）: https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf
• EU CRA（Regulation (EU) 2024/2847）: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
• OpenChain / ISO/IEC 5230: https://openchainproject.org/license-compliance
• 経済産業省「ソフトウェア管理に向けた SBOM 導入の手引」v2.0（2024-08）: https://www.meti.go.jp/policy/netsecurity/wg1/SBOMv2.pdf
• Redis ライセンスページ（RSALv2/SSPLv1/AGPLv3 の三択、Redis 8 以降）: https://redis.io/legal/licenses/
• Server Side Public License（SSPL）§13: https://www.mongodb.com/legal/licensing/server-side-public-license
• Llama 3.1 Community License §2（Additional Commercial Terms、700M MAU）: https://github.com/meta-llama/llama-models/blob/main/models/llama3_1/LICENSE
• GitHub Docs「Configuring notifications」（Watch は repo 単位）: https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications