「オープンソース」のAIエージェントツールのうち、実際にはOSSでないもの

147件のうち7件

本カタログの147件のうち、OSI承認ライセンスは140件で、残る7件は該当しません。n8n（Sustainable Use License）、AutoGPT（プラットフォーム部分がPolyForm Shield、それ以外はMIT）、Dify（Dify Open Source License）、AutoGen（CC-BY-4.0）、Crush（FSL-1.1-MIT）、Phoenix（Elastic-2.0）、TEN Framework（Apache-2.0に追加条件）です。

件数では約20件に1件ですが、スター数では約10件に1件の重みを占めます。7件のGitHubスターは合計654,198、全147件の合計6,767,833に対して9.7%です。n8nは202,708で本カタログ3位、AutoGPTは186,963で6位、Difyは153,771で10位。本カタログのビジュアルワークフロービルダー4件のうち3件がこの一覧に入り、入っていないのはLangflow（153,816）だけです。

140件の内訳は退屈です。そして退屈であることが、そのまま安心材料になります。MITが67件、Apache-2.0が65件、AGPL-3.0が3件、BSD-3-Clauseが2件、BSD-2-Clauseが1件、pgvectorが使うPostgreSQL Licenseが1件、そしてコードと仕様本文がApache-2.0でドキュメントがCC-BY-4.0のMCP仕様が1件。全147件のうち132件は単一のMITかApache-2.0で、依存先がそのどちらかならこの先を読む必要はありません。

7件が実際に制限していること

プロジェクト	ライセンス	効いてくる条項	それでも可能なこと
n8n	Sustainable Use License	ホスティングサービスとしての再販	社内利用、セルフホスト
AutoGPT	PolyForm Shield 1.0.0（プラットフォーム側）	競合製品としての提供	社内利用、セルフホスト。それ以外の範囲はMITのまま
Dify	Dify Open Source License	マルチテナント提供とブランディングの変更	それ以外はApache 2.0と同等
AutoGen	CC-BY-4.0	明示的な制限がないこと自体	出典表示を伴う利用
Crush	FSL-1.1-MIT	競合用途。各リリースは2年後にMITへ移行	社内利用、非営利の研究、専門サービスでの利用
Phoenix	Elastic-2.0	マネージドサービスとしての第三者提供	社内利用、セルフホスト、改変
TEN Framework	Apache-2.0に追加条件	エンドユーザー機器上でのホスティング、Agoraとの競合	自社アプリを自社のエンドユーザーへ提供すること

6件は数分で読み切れ、内容も明快です。Sustainable Use Licenseは社内の業務利用とセルフホストを認め、n8nをホスト型製品として再販する権利だけを留保します。n8n自身もOSI準拠を主張せず「fair-code」と表現しています。DifyのライセンスはApache 2.0にマルチテナント提供とブランディングの追加条件を付けたものです。Elastic License 2.0が禁じるのは3点で、マネージドサービスとしての第三者提供、ライセンスキー機能の回避、ライセンス表示や著作権表示の削除・隠蔽です。AutoGPTはリポジトリを分割し、現在の製品本体であるプラットフォーム側にPolyForm Shieldを適用して、その外側はMITのまま残しています。CrushのFunctional Source Licenseは競合用途を禁じたうえで、各リリースの2年後にMITを付与します。

6件が制限しているのは同じ一点の変形、競合する製品やホスティング事業者になることです。自組織のために動かす限り、このうち5件は影響しません。多くのチームがこの話題に抱く不安はたいてい的外れです。

2度読むべきなのはTEN Frameworkです。追加条件がこの表で最も広く、Agoraとの競合禁止に加えて、モバイル端末を明示的に含むエンドユーザー機器上でのホスティングを禁じています。スマートフォンアプリの中で動く音声エージェントは、まさにこの条項が届く配置です。ファイル冒頭の「Apache-2.0」という表記からはそれが読み取れません。

AutoGenだけは事情が違い、しかも厄介です。CC-BY-4.0は記事や写真、データセットなどコンテンツのために書かれたCreative Commonsのライセンスで、出典表示さえすれば商用利用も認められるため、一読すると寛容に見えます。しかしソフトウェアライセンスが担うべき仕事をしていません。特許の許諾がなく、ソース形式とオブジェクト形式の区別もなく、コンパイル済みの派生物を配布する際の許諾構造もありません。Creative Commons自身がソフトウェアへの適用を避けるよう案内しています。正確な言い方は「制限が厳しい」ではなく「出荷する製品にとって条項が何を意味するのか誰も断定できない」です。読めば分かる制限より厄介です。

もっとも、この論点は結論を変えません。AutoGenはメンテナンスモードに入っており、受け付ける変更はバグ修正、セキュリティ修正、ドキュメント改善に限られ、READMEは新規プロジェクトをMicrosoft Agent Frameworkへ案内しています。これから選ぶなら、ライセンスを読む前にその一点で決まります。

GitHubのライセンス表示では足りない理由

リポジトリのページに出るライセンス名は、LICENSEファイルを既知のテンプレートと突き合わせた判定結果です。多くは正しく、そして誤解を招くときは両方向に招きます。本カタログには両方の実例があります。

一方向がAutoGenです。APIはリポジトリの宣言をそのまま報告しており、その宣言がコードリポジトリに置かれたコンテンツ向けライセンスだった、というだけです。APIは嘘をついていません。ただ、選ばれた道具が用途に合っていないことまでは教えてくれません。

もう一方向がOpenClawです。スター数387,929で本カタログ最多ですが、GitHubの表示はNOASSERTION、テンプレート照合に失敗したときの値です。ファイルを開くと中身はMITライセンスの原文そのままで、末尾にTHIRD_PARTY_NOTICES.mdを参照する1行が足されているだけです。この1文で照合は崩れます。本カタログがMITと記録しているのは、人が開いて読んだからです。

どちらの誤りも起こすのは簡単で、引き継いだ側の負担は大きくなります。APIの値だけで組んだリストなら、AutoGenを問題なしとして扱い、OpenClawをライセンス不明として外していたはずです。

この分野で最も導入されているスキル群は、そもそもOSSではありません

ライセンス表示が誤解を招く3つ目の方向があり、影響範囲はこれが最も広いものです。何も表示されず、それを読んだ人が「気にしなくてよい」と受け取る、という方向です。

anthropics/skillsはAgent Skillsの参照リポジトリで、スター数はおよそ172k、この種のコレクションでは最多です。そして導入されることを前提とした構造をしています。ルートにプラグインマーケットプレイスの定義ファイルがあり、その下に19個のスキルディレクトリが並びます。GitHubはこのリポジトリのライセンスを何も表示しません。ルートにLICENSEファイルが無いからです。19個のうち18個のスキルディレクトリにはLICENSEファイルがあり、その中身はオープンソースライセンスではありません。

© 2025 Anthropic, PBC. All rights reserved. […] users may not: extract these materials from the Services or retain copies of these materials outside the Services […] reproduce or copy these materials […] create derivative works based on these materials […] distribute, sublicense, or transfer these materials to any third party.

これは、前掲の7件が使っているような「競合サービス化を禁じる」タイプのsource-availableライセンスではありません。複製・改変・再配布そのものを認めず、許諾される利用範囲をAnthropic自身のサービス内に限定しています。ソースは公開されていますが、持ち出す権利は与えられていません。

隠されているわけでも不当なわけでもありません。Anthropicはこれらのスキルを自社製品の中で提供しており、条項はその形をそのまま記述しています。問題は、リポジトリの見え方とファイルの記述の間にある落差です。見え方は他のスキルリポジトリと変わりません。公開されていて、閲覧でき、導入向けに構造化されていて、各ディレクトリには複製の対象になるものとまったく同じSKILL.mdが置かれています。サイドバーを見てライセンス表示が無いことを確認し「ライセンス未設定、たぶん問題ない」と結論づけた読者は、事実を逆に受け取っています。

対照はカタログの中にあります。GoogleのskillsリポジトリはGoogle Cloud・広告・アナリティクスに対して同じ仕事をし、同じくディレクトリの集まりで、ライセンスはApache-2.0です。複製し、改変し、自社製品に載せられます。外から見た形はよく似た2つのリポジトリで、違いはGitHubのサイドバーが読まないファイルの中にだけ現れます。

これは後述のチェック項目3、モノレポではパッケージ単位で確認するが実費を伴って現れた例です。ここではルートが何も教えず、その下のすべてのディレクトリが、知っておくべきことを教えています。

AGPLはオープンソースです。それでも判断は必要です

AGPL-3.0は3件、Firecrawl（173,614スター）、SearXNG（36,209スター）、Skyvern（22,873スター）です。AGPL-3.0はOSI承認ライセンスで、7件の側ではなく140件の側に入ります。ここに書くのは批判ではありません。

AGPLがGPLに加えているのはネットワーク条項です。改変版にユーザーがネットワーク越しに接する形で提供するなら、そのユーザーは改変後のソースを受け取る権利を持ちます。利用の制限ではなくコピーレフトの義務であり、引き金は自分の改変がユーザーに届くことで、スタックに含まれていること自体ではありません。

ここから導かれるのは設計上の判断で、私なら毎回同じ選び方をします。この2つは独立したサービスとして立て、改変せずHTTP経由で呼び出します。どちらもセルフホスト可能なサーバーとして配布され、そう使われる前提で作られています。面倒になるのはソースを自分のツリーへ取り込んで手を入れる進め方で、相手のコードとの境界が後から議論の的になります。

組織としてAGPLを一律禁止しているなら——大企業では珍しくなく、例外申請の窓口もないのが普通です——争わず前提として受け入れるほうが早く済みます。同じ仕事をこなす寛容な選択肢があるからです。クロールとMarkdown化にはCrawl4AI（Apache-2.0）が代替になり、その代わりプロキシ管理とレート制限は自分で持ちます（両者の比較）。ブラウザ自動化ならBrowser UseとStagehandがいずれもMITです。LangfuseとPhoenixの比較も、ほぼ同じ用途に対するMITとElastic-2.0の対比になっています。

確認する順序

1. ライセンスを読む前に、何に使うのかを決める。ほとんどはこの3問で片が付きます。自社製品の内側で動かすのか隣に置くのか、社外の人がネットワーク越しに触れるのか、改変するのか。答えが「隣に置く」「触れない」「改変しない」であれば、本カタログの147件はいずれも問題なく、例の7件も含まれます。
2. サイドバーではなくLICENSEファイルを開く。10秒で済み、前節の内容はすべてここに帰着します。
3. モノレポではパッケージ単位で確認する。ルートのLICENSEは、配下の各公開パッケージが同じ条件である保証になりません。
4. 本文を「service」と「hosting」で検索する。効いてくるのは第三者への提供形態に関する条項です。これらの語が出てこないなら、計画を制限している可能性は低いといえます。
5. 独自ライセンスはきちんと読む。Sustainable Use LicenseとElastic License 2.0はそれぞれ1ページ程度、DifyのものはApache 2.0に追加条件が2つ、冒頭に置かれているだけです。5分で推測がなくなります。
6. 判断と日付を残す。ライセンスは変わり、しかも緩む方向より締まる方向が多く起きます。本サイトが全エントリに最終確認日を表示しているのも同じ理由で、扱いは掲載基準に書いてあります。

制限は妥当です。問題なのは名前のほうです

ソース公開型ライセンスの背景には、繰り返し起きてきた出来事があります。ある企業が何年も開発費を負担し、より大きな企業がその成果をマネージドサービスとして包み直し、負担した側には保守の重さだけが残る、という流れです。Sustainable Use LicenseとElastic License 2.0はそれに対する狭くて読みやすい回答で、禁じる範囲より許す範囲のほうがはるかに広いものです。

条文そのものは誠実です。n8nはOSI準拠を名乗らず「fair-code」と表現し、ArizeがPhoenixに付けたライセンスは全文で1ページに収まります。Difyも追加条件を本文の冒頭、番号付きの第1項と第2項——マルチテナント提供、続いてブランディング——に置いており、ファイルを開けば数行で何が留保されているか分かります。

問題はそのファイルに付いた名前のほうです。見出しは「Open Source License」とだけあり、プロジェクトが付けたその名前——本カタログもライセンス名は「Dify Open Source License」と記録するほかありません——が、すぐ下の条件で否定されているはずの地位を主張しています。本文まで読んだ人は正しく理解できますが、名前だけ見て本文を飛ばした人は、何も調べなかった場合より悪い状態に置かれます。AutoGenの欠陥も向きが逆なだけで同じ形です。CC-BY-4.0は実在する見慣れた識別子で、だからこそ条文なら通らない場面を名前だけで通過してしまいます。

本カタログが各エントリにライセンス名だけでなくライセンス種別を記録しているのは、この一点のためです。名前は何とでも名乗れますが、種別は3つのうちどれかでなければなりません。基準は公開しています。OSI承認ライセンス、条件が明示されたソース公開型ライセンス、そして独占的ライセンスの3つです。掲載するのは前の2つで、独占的ライセンスは掲載せず、ライセンスを確認できないものも掲載しません。ただし、この分野の全員が導入元にしているリポジトリが独占的ライセンスである場合、黙って外すより書く価値があります。anthropics/skillsが本文には出てカタログには無いのはそのためです。第三者が作ったリスト、カンファレンスのスライド、企画会議で口にされる「オープンソースだから自社でホストすればいい」——言葉が緩く使われる場面はどれも、ファイルではなく名前を読んだところから始まっています。