AI・オープンソースソフトウェアライセンス完全解説：MIT・Apache・GPL・AGPL・プロプライエタリの違い

クイックファクト

• MITは最も短く一般的なpermissiveライセンス — 約170語、特許条項なし。
• Apache-2.0にはMITにない明示的な特許許諾条項があり、企業発プロジェクトで好まれる理由の一つです。
• GPLはソフトウェアを配布する場合にのみソースコード開示を要求し、AGPL-3.0はこの要求をネットワークサービスとしての運用にも拡張します。
• OSI承認の「オープンソース」はOpen Source Initiativeによる具体的な認証であり、「source-available」「fair-code」はこの定義を満たさないライセンスを指すマーケティング用語です。
• AIモデルライセンスはコードライセンスとは別カテゴリです。 ツールのコードはApache-2.0でも、ダウンロードするモデルの重みはまったく異なる、より制限の強い条件を持つ場合があります。

Permissiveライセンスとは？MIT・Apache-2.0・BSD

• MITライセンスはマサチューセッツ工科大学（MIT）で誕生し、大学発ソフトウェアを最小限の制限で公開する手段として使われました。約170語という短さで、ほぼ無制限の権利を付与し、再配布するコピーや実質的な部分に元の著作権・ライセンス文を残すことのみを求めます。
• Apache License 2.0はApache Software Foundationに由来し、企業やコミュニティの貢献者が大規模な協業プロジェクトで共有できる法的枠組みとして生まれました。MITと異なり明示的な特許許諾条項を含み、貢献者はコードに関する特許権をユーザーにライセンスします — これが特許ポートフォリオを持つ企業に好まれる理由です。
• BSDライセンス（2条項・3条項）は、カリフォルニア大学バークレー校がBerkeley Software Distributionオペレーティングシステム向けに生み出したものです。3条項版には、無許可でオリジナル作者の名前を派生製品の宣伝に使うことを禁じる非推奨条項が追加されています。
• 利用者にとっての実務的な効果：permissiveライセンスのツールをフォーク・改変・組み込み・クローズド製品の一部として販売しても、自社のソースコードを公開する必要は一切ありません — 実際のリスクは、配布物から必須の著作権/ライセンス表記を落としてしまうことだけです。
• このサイトのレビューにおける実例：Ollamaとllama.cppはいずれもMIT、vLLMはApache-2.0です — 3つともソース開示義務を発生させずに商用製品へ組み込めます。

Copyleftとは？GPL・LGPLファミリー

• GNU General Public License（GPL）はリチャード・ストールマンとFree Software FoundationがGNUプロジェクトのライセンスとして書いたもので、「ソフトウェアの自由は下流に保存されるべき」という考えに基づいています — 改変版を受け取った人は、元の作者と同じ権利を持つべきという発想です。
• GPL v2とGPL v3は主に特許に関する文言と互換性規定で異なります。v3では特許報復条項と反ティボ条項（法的に実行する権利がある改変済みソフトウェアの実行をブロックするハードウェアを防ぐ条項）が明示的に追加されました。
• GNU Lesser General Public License（LGPL）は、ライブラリに限定してGPLを緩和したものです — ライブラリコンポーネントが差し替え可能で、その独自のソースコードが入手可能である限り、LGPLライブラリをプロプライエタリなアプリケーションにリンクしても、アプリケーション自体をオープンソース化する必要はありません。
• 義務を実際に発生させるもの：GPL対象コードの改変版を配布することです。単に社内で未改変のGPLソフトウェアを使う、あるいはGPLライセンスのOSの上でプロプライエタリなソフトウェアを動かすだけでは、自社コードが自動的にGPL下に置かれることはありません。
• 注意すべき対象：GPLツールをフォークして商用製品の中核として改変する予定のスタートアップは、その変更を公開するか、フォークを避けるかの計画が必要です。未改変のGPLツールを社内でのみ利用する企業には、この義務は発生しません。

AGPL-3.0がSaaSの抜け道を塞ぐ仕組み

• 塞がれた抜け道：純粋なGPLの下では、改変版をホスティングされたWebサービスとして運用することは、ライセンスが発動する法的な意味での「配布」に該当しません — 企業はGPLコードを取得し、改変し、SaaS製品としてのみ提供し、その変更を公開する必要が一切ないという状況が生まれ得ました。これは非公式に「ASPの抜け道」（application service provider）や「SaaSの抜け道」と呼ばれるようになりました。
• AGPL-3.0はこの抜け道を塞ぐために特別に書かれました。ネットワーク相互作用条項を追加することで、改変されたソフトウェアの機能をネットワーク経由でユーザーに提供することが、物理的なコピーを配布するのと同じソース開示義務を発生させるようにしています。
• ホスティングや再販にとって重要な理由：AGPLライセンスのツールを取得し、改変し、ホスティングサービスとしてクライアントに提供する代理店やホスティングプロバイダーは、そのユーザーに改変後のソースコードを提供しなければなりません — 未改変のまま運用する場合、この義務は発生しません。
• このサイトのレビューにおける実例：Jan、KoboldCpp、SillyTavern、text-generation-webuiはAGPL-3.0で提供されています — 個人利用や社内利用として未改変のまま自己ホスティングする分には問題ありませんが、それを改変してホスティングアクセスを再販する時点で法的な状況は大きく変わります。
• これはライセンスの仕組みに関する一般的な説明であり、法的助言ではありません。具体的な導入がAGPL-3.0の正確な文言における「ネットワーク経由で提供する」に該当するかどうかは、あなたの特定のアーキテクチャを確認する弁護士に相談すべき事項です。

Source-Available・「フェアコード」ライセンスとは？

• Business Source License（BSL、BUSLとも呼ばれる）は、当初からソースコードへのアクセスと広範な利用権を付与し、将来のある特定の日付でライセンスが真のオープンソースライセンス（多くの場合Apache-2.0や類似のpermissiveライセンス）に転換するという構造を持ちます — その転換までは、通常は競合するホスティング提供を防ぐ目的の商用利用制限が適用されます。
• Server Side Public License（SSPL）はMongoDBが作成したもので、ソフトウェアをサービスとして提供する者に対し、その周囲に構築されたサービススタック全体もオープンソース化することを要求します — AGPL-3.0よりはるかに広範な義務であり、競合するクラウドプロバイダーによる商用ホスティングを実質的に不可能にする意図で書かれています。
• Commons Clauseは、それ以外は許容的またはcopyleftのベースライセンスに追加される制限で、自由な利用・改変は認めつつ、ソフトウェアの販売や有料ホスティングサービスとしての提供を特に禁止します。
• プロジェクトがこうしたライセンスへ移行する理由：完全にオープンなライセンスで始まったプロジェクトが後にsource-availableライセンスを採用するのは、多くの場合、大手クラウドプロバイダーが開発への貢献なしにそのプロジェクトをホスティングサービスとして提供していることへの対応です。source-availableライセンスへの移行により、メンテナーはオープン性の大部分を保ちつつ、この特定の競合利用を阻止できます。
• 利用者にとっての実務的な効果：通常、社内利用目的でsource-availableソフトウェアを読み、自己ホスティングし、改変することに問題はありません。制限が発動するのは、ライセンス保有者自身の提供物と競合するホスティング製品として再販しようとする時です — 文言はプロジェクトごとに大きく異なるため、具体的な商用利用条項を必ず読んでください。

プロプライエタリ・Freemium「無料」ライセンスとは？

• 比較表の「無料（クローズド）」は無償のプロプライエタリソフトウェアを意味します。コンパイル済みアプリケーションをベンダーの利用規約の下で使用できますが、ソースコードへのアクセス権はなく、改変・監査・フォークする権利もありません。
• オープンソース代替との主なトレードオフ：単一ベンダーがユーザー体験全体をコントロールするため、プロプライエタリな無料アプリはしばしば洗練されておりインストールも簡単です — しかし、そのベンダーが今後も無料・安全・メンテナンス済みの状態を保つ意思を持ち続けるかどうかに完全に依存することになります。
• ベンダーロックインのリスク：ソースコードへのアクセスがないため、改変版を自己ホスティングすること、アプリケーションがデータをどう扱っているか正確に監査すること、ベンダーがメンテナンスを止めたり価格モデルを変更したり閉鎖したりした場合に開発を継続することができません。
• 特に注意すべき対象：プロプライエタリな無料ツールを中心にワークフローや業務プロセスを構築する場合は、文書化された代替計画を持つべきです — どのベンダー依存にも適用すべきなのと同じデューデリジェンスです。「無料」は「永続的」でも「保証された」ものでもありません。
• Source-Availableとは異なる点：Source-Availableライセンス（BSL、SSPL）は商用利用が制限されていても少なくともコードを読み監査することを許しますが、完全にプロプライエタリなツールは、そのコードも保証も提供しません。

AIモデルライセンスの仕組み：Open Weights、RAIL、利用制限条項

• 完全にpermissiveな重み：一部のモデルファミリーは、標準的なpermissiveソフトウェアライセンス（多くの場合Apache-2.0）で重みを公開し、コードに与えるのと同じ広範な利用権 — 用途制限のない商用利用を含む — を付与します。
• RAILおよびOpenRAILライセンス（Responsible AI License）は、BigScienceによるBLOOMモデルの公開に伴って誕生し、法律研究者と共同で設計され、オープンアクセスと具体的な禁止用途のリストを組み合わせています — 一般的に偽情報の生成、差別的な意思決定、法律違反となるコンテンツを禁じる一方、それ以外の広範な商用利用は認めます。
• 独自の「コミュニティ」または「open-weight」ライセンス：複数の主要モデル提供元は、オープンライセンスのように見えつつ用途条件を追加する独自ライセンスで重みを公開しています。最もよく引用される例は、Metaがオープン公開しているモデルの重みに付与するコミュニティライセンスです — 広範な無料利用を認めつつ、一定の利用規模のしきい値を超えると別途商用契約が必要になる条件と、許容利用制限を追加しています。
• 具体的に確認すべき点：商用利用がそもそも許可されているか、条件が変わる利用規模や収益のしきい値があるか、許容利用ポリシーが何を禁止しているか、そしてモデルの出力を使って競合モデルを学習することをライセンスが制限しているか — この最後の制限は複数のモデル固有ライセンスに見られ、標準的なソフトウェアライセンスには相当する項目がありません。
• これは法的助言ではありません。モデルのライセンス条件は同じ提供元のリリース間でも変わるため、同じ組織の以前のリリースとの継続性を前提とせず、実際に導入予定の特定のモデルの重みに付随する正確なライセンス文を確認してください。

誰がどのライセンスを気にすべきか

導入前ライセンスチェックリスト：ツール導入前に確認すべき7項目

1. 1
   リポジトリ内の実際のLICENSEファイルを読む
   Why it matters: ランディングページの「オープンソース」という主張は法的な事実ではなくマーケティングである場合があります — ソースリポジトリ内のLICENSE（またはNOTICE/COPYING）ファイルこそが正式な文書であり、バッジや価格ページではありません。
2. 2
   ライセンスが最近変更されていないか確認する
   Why it matters: 商用的な牽引力を得た後、permissiveまたはcopyleftライセンスからsource-availableライセンスへ移行するプロジェクトがあります — この動きは、クラウドプロバイダーが人気オープンソースプロジェクトを貢献なしにホスティングし始めて以来、ソフトウェア業界で繰り返されてきました。現在のファイルだけでなく、リポジトリのライセンス履歴を確認してください。
3. 3
   重要であれば、そのライセンスが実際にOSI承認かどうかを確認する
   Why it matters: BSLやSSPLのようなsource-availableライセンスは一般にオープンソースとして宣伝されますが、Open Source Initiativeの承認リストには載っていません — OSI承認がユースケース上の要件であれば、プロジェクト自身の説明を鵜呑みにせず直接リストを確認してください。
4. 4
   AIモデルに特有の商用利用条項・用途制限条項を読む
   Why it matters: モデルのライセンスは、商用利用を広く許可することも、利用規模のしきい値を超えると制限することも、特定の用途を完全に禁止することもあります — これらの条項は標準的なソフトウェアライセンスの文言の外にあり、コードライセンスだけを確認していると見落としやすい部分です。
5. 5
   自己ホスティングかSaaSホスティングかで義務が変わるかを確認する
   Why it matters: AGPL-3.0の下では、改変ソフトウェアをネットワーク経由で提供することが、GPLの下でコピーを配布するのと同じ開示義務を発生させます — コードを改変する前に、予定している導入がどちらのカテゴリに該当するかを確認してください。
6. 6
   コード貢献を予定している場合はContributor License Agreement（CLA）を確認する
   Why it matters: CLAは、プロジェクトのライセンス自体がユーザーに与える以上の広範な権利を、あなたの貢献に対してプロジェクトメンテナーに与える場合があります — これはプロジェクトへコードを送り返す予定がある場合に主に関係し、単に利用するだけであれば関係ありません。
7. 7
   商標に関する制限をコードライセンスとは別に確認する
   Why it matters: permissiveまたはcopyleftのコードライセンスは、自動的にプロジェクトの名称やロゴに対する権利を付与するものではありません — コードライセンス上はフォークが許可されていても、商標法によってツールのフォーク・リブランディングがブロックされる場合があります。

よくある間違い

• リポジトリ内の実際のLICENSEファイルを読まず、マーケティングページの「オープンソース」という主張を鵜呑みにする。
• AGPL-3.0はソフトウェアのコピーを配布する場合だけ関係すると思い込む — 改変コードをホスティングサービスとして提供する場合にも適用される。
• モデルのコードライセンスと重みのライセンスを同じ文書として扱う — 実際には別物であることが多い。
• コードライセンスとは別の商標制限を確認せずに、ツールをフォークしてリブランディングする。
• プロジェクト開始時にpermissiveだったライセンスが、その後の再ライセンス後も同じままだと思い込む — 記憶ではなく現在のライセンスを確認する。
• 「無料だから」という理由でcopyleftやsource-availableツールの法務レビューを省略する — 無料で使えることと義務がないことは同じではない。

出典

• Open Source Initiative — The Open Source Definition — OSI承認のオープンソースとして認定されるためにライセンスが満たすべき正式な定義。
• GNUプロジェクト — Free Software Licenses — GPL、LGPL、AGPLについてのFree Software Foundation自身による解説。
• Apache Software Foundation — Apache License 2.0 — ライセンス全文。
• MITライセンス全文（Open Source Initiative） — ライセンス全文。
• MongoDB — Server Side Public License — SSPL自身の条件と根拠。
• Business Source License FAQ — このライセンスの著名な採用元によるBSL/BUSL転換の仕組みの解説。

よくある質問

関連記事

• ローカルLLMソフトウェア完全ディレクトリ — 160以上のローカルLLMツールと、各項目に記載されたライセンス。
• Dify AI Workflow Builderレビュー — ライセンスを明記したレビュー。そのライセンスが自分の導入案件にとって何を意味するか、本ガイドで理解できます。
• AI生成コンテンツとIPリスク — AI生成出力を商用利用する際にライセンスと並んで検討すべき知的財産権の論点。
• エージェンティックAIのセキュリティ：ID・アクセス管理 — 自己ホスティングAI導入におけるセキュリティ・ガバナンスの検討事項。ライセンスコンプライアンスと並ぶ論点。
• 機密文書向けGDPR準拠のローカルRAG — ライセンスリスクとデータレジデンシー/コンプライアンスリスクは別々のチェックリスト。本記事はコンプライアンス側を扱います。