セルフホストOSS 1,332件のライセンスを全数調査した

01調べ方（そのまま再現できます）

データ源は awesome-selfhosted-data です。有名な「awesome-selfhosted」リストの機械可読版で、1ソフトウェア＝1つのYAMLファイルとして管理されています。

ありがたいことに、このリポジトリには licenses だけでなく stargazers_count・updated_at・archived・current_release・commit_history まで含まれています。GitHub APIのレート制限に悩まされることなく、健全性の判定まで機械的にできます。

# 1. データを取得（約290KB）
git clone --depth 1 https://github.com/awesome-selfhosted/awesome-selfhosted-data

# 2. software/*.yml の licenses を集計するだけ
ls awesome-selfhosted-data/software/*.yml | wc -l
#=> 1332

02ライセンス分布の全体像

集計結果です。上位25ライセンスを、SaaSとして改変を非公開のまま運用できるかで色分けしました。

いちばん驚いたのは AGPL-3.0 が301件（22.6%）で堂々の2位だったことです。MITに次ぐ規模で、GPL-3.0（226件）より多い。セルフホスト分野に限れば、AGPLはもはや例外的な選択ではなく主要な選択肢のひとつになっています。

03商用SaaSに使えるのは何件か

「改変を非公開のまま、SaaSとしてホスティング提供する」という用途に絞って絞り込みます。

7割近くが通ります。「AGPLだらけで使える球がない」という感覚は、少なくともこのカタログの範囲では成立しませんでした。

ただし最後の行を見てください。健全な577件のうち業務ドメインのタグが付くのは95件（16.5%）だけで、残り83%はゲーム・メディアストリーミング・写真ギャラリー・フィードリーダー・Pastebin・電子書籍管理——つまり個人・趣味用途です。「セルフホストOSSは業務システムの宝庫」というイメージは、数えてみると実態と違いました。

04AGPLの実務的な射程（誤解していました）

我々は当初、社内ガイドに「AGPL＝✕ NG。ネット越し提供でも改変ソース公開義務」と書いていました。これは条文としては正しいが、射程を過大に見積もっていたと分かったので訂正します。

AGPL-3.0 第13条の条文はこうです。

"If you modify the Program, your modified version must prominently
offer all users interacting with it remotely through a computer network
... an opportunity to receive the Corresponding Source of your version ..."

実例として、Hetzner は Nextcloud（AGPL）ベースのマネージドサービスを月額€4.29（税別・1TB）から提供しており、同社は製品FAQで「このソフトウェアは自社で開発したものではないため、機能を追加できない」と明記しています。Mastodonのホスティング事業者 Masto.host も、公開フォークと上流を実際に比較したところ変更ファイルは0件でした（＝改変版が存在しないので第13条が発動していない）。無改変で運用するという道は、現実に成立しています。

※この2点は続編の記事で条文と一次情報から検証し直しました。当初ここには「Masto.host はフォークを公開して第13条に準拠している」と書いていましたが、実際には差分が存在しなかったので訂正しています（2026-07-19）。

05ライセンス表示では見抜けない罠

ここが本記事でいちばんお伝えしたい部分です。 SPDX識別子やGitHubのライセンス表示を信じていると、確実に踏みます。実際に我々が踏みかけた実例です。

06ライセンス変更は「昔の話」ではない

調べていて実感したのは、ライセンス変更は現在進行形で起き続けているということです。今回の調査中だけでこれだけ観測しました。

さらにライセンスとは別軸のリスクもあります。2025年10月、KAGOYA CLOUD VPS が Redmine テンプレートの公開を一時停止しました。理由は Bitnami の Redmine Docker イメージが Legacy リポジトリへ移管されたためです。ライセンスが安全でも、公式配布物の提供が止まればサービスは止まります。

07この調査で、我々が間違えていたこと

最後に自分の失敗を書いておきます。同じ轍を踏む人がいるかもしれないので。

誤り①「AGPLが多すぎて使える球が枯れている」

数える前は本気でそう思っていました。実際は68.8%が通過。有名なOSSばかり見ていたせいで、そう錯覚していました。有名なOSSほどAGPL/BSLで囲われているため、上澄みだけを見ると「枯れている」ように見えるのです。

誤り②「AGPLは即除外すべき」

第13条は改変が発動条件で、無改変運用なら義務は生じません（04章）。「法的に危険だから避ける」ではなく「競争構造上不利だから避ける」が正確な理由でした。

誤り③ ★300以上で絞ったこと

健全性フィルタとして★300以上を課していましたが、これは失敗でした。非エンジニア向けの業種特化ソフト（設備保全・会員管理・予約など）は、そもそもGitHubのスター文化の外側にあり★300に届きません。結果として「エンジニアが星を付けたもの＝エンジニア向け」だけが残る偏りが生まれていました。フィルタが結論を作ってしまっていたわけです。