判定ガイド
OSSライセンス早見表
改変を非公開のまま、商用サービス（SaaS）として提供できるか——その一点で主要ライセンスを判定しました。
オープンソースを改良して自分のサービスにする場合、最初の関門はライセンスです。「儲かるか」ではなく「そもそもやっていいか」を、下の早見表で先に確認してください。
→ 実データ：GitHubのライセンス割合を見る01判定一覧
グループの左帯が判定色。上ほど自由、下ほど非公開SaaSには使えません。
改変を非公開のままSaaS化・再配布まで自由。迷ったらここだけ狙えば安全。
サーバー運用に限れば改変を非公開にできる。アプリ配布に広げると公開義務。
触ったファイルや改変ライブラリだけ公開すればよい。付加価値コードは守れる。
権利放棄に近く、実質的に何でもできる。
改変の公開を強制され、非公開SaaSモデルと正面衝突する。候補から除外。
02見落としがちな落とし穴
判定表がクリアでも、ここで足をすくわれます。特に1つ目は最頻出。
「No License」は自由ではなく全面禁止
LICENSEファイルが無ければ法的には全権利留保。使うだけでも侵害になり得る。「ライセンス無し＝一番危険」と覚える。
商標はライセンスと別問題
コードが自由でも、プロジェクト名・ロゴは商標。本家と同じ名前ではサービスを出せない。必ずリブランドする前提で。
依存ライブラリのライセンスまで見る
本体がMITでも、内部の依存にGPLやAGPLが混ざると全体が汚染される。license-checker等で依存ツリー全体をスキャンする。
提供形態でGPLの義務は変わる
同じGPLでも、SaaS運用なら義務は緩く、バイナリ配布した瞬間にソース公開義務。将来の事業形態まで見越して選ぶ。
デュアルライセンスは「お金で解決」できる
GPL＋商用の二本立て（例：Qt, MySQL）なら、商用ライセンスを購入すればクローズド利用が可能。NGに見えて交渉できる場合がある。
03実務の判定フロー
候補OSSを見つけたら、この順で確認すれば地雷を踏みません。
- LICENSEファイルを確認。無ければ即除外（No License＝禁止）。
- パーミッシブ（MIT/Apache/BSD/ISC）なら即GO。表示義務だけ守る。
- AGPL/SSPL/BSL/Elastic/Commons Clauseなら即除外（SaaS封じ層）。
- GPL/LGPL/MPLは提供形態で判断。SaaS限定なら可、将来アプリ配布したいなら避ける。
- 依存関係をスキャン。本体がOKでも依存に地雷が無いか確認。
- 名前・ロゴをリブランドしてから公開。
免責：本ページは調査・意思決定の目安であり法的助言ではありません。実際に事業化する候補が固まったら、そのライセンス原文（特にBSL・デュアルライセンスは版で条項が異なる）を必ず確認してください。
04よくある質問
一番安全なライセンスはどれですか？
MITとApache-2.0です。どちらも改変を非公開にしたままSaaS化・再配布まででき、Apache-2.0は特許条項が付くぶんさらに安心です。
BSLやElastic Licenseはなぜ避けるべきなのですか？
これらは競合となるホスティングやマネージドサービスとしての提供を禁じる条項を持ちます。つまりSaaS化そのものが規約違反になり得るため、非公開SaaSモデルには使えません。
商標は気にしなくてよいですか？
いいえ。ライセンスでコードが自由でも、プロジェクト名やロゴは商標です。本家と同じ名前ではサービスを出せないため、必ずリブランドが必要です。
GPLのOSSは商用サービスにできますか？
サーバーで運用するSaaSに限れば、改変を非公開にしたまま提供できます。ただしユーザーにアプリを配布する形態に広げると、全ソースの公開義務が発生します。