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

45件のうち4件

本カタログの45件のうち、OSI承認ライセンスは41件で、残る4件は該当しません。n8n（Sustainable Use License）、Dify（Dify Open Source License）、AutoGen（CC-BY-4.0）、Phoenix（Elastic-2.0）です。

件数では1割弱ですが、注目度で見ると比率は上がります。4件のGitHubスターは合計424,833、全45件の合計3,249,406に対して13.1%です。n8nは200,782で本カタログ3位、Difyは152,550で7位。この2件は、本カタログのビジュアルワークフロービルダー3件のうちの2件です。残る1件がLangflow（153,278）で、3件のうちOSSはこのLangflowだけです。

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

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

プロジェクト	ライセンス	効いてくる条項	それでも可能なこと
n8n	Sustainable Use License	ホスティングサービスとしての再販	社内利用、セルフホスト
Dify	Dify Open Source License	マルチテナント提供とブランディングの変更	それ以外はApache 2.0と同等
AutoGen	CC-BY-4.0	明示的な制限がないこと自体	出典表示を伴う利用
Phoenix	Elastic-2.0	マネージドサービスとしての第三者提供	社内利用、セルフホスト、改変

3件は5分で読み切れ、内容も明快です。Sustainable Use Licenseは社内の業務利用とセルフホストを認め、n8nをホスト型製品として再販する権利だけを留保します。n8n自身もOSI準拠を主張せず「fair-code」と表現しています。DifyのライセンスはApache 2.0にマルチテナント提供とブランディングの追加条件を付けたものです。Elastic License 2.0が禁じるのは3点で、マネージドサービスとしての第三者提供、ライセンスキー機能の回避、ライセンス表示や著作権表示の削除・隠蔽です。

3件が制限しているのは同じ一点、競合するホスティング事業者になることです。自組織のために動かす限りどれも影響せず、多くのチームがこの話題に抱く不安はたいてい的外れです。

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

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

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

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

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

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

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

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

AGPL-3.0は2件、Firecrawl（167,800スター）とSkyvern（22,757スター）です。AGPL-3.0はOSI承認ライセンスで、4件の側ではなく41件の側に入ります。ここに書くのは批判ではありません。

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

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

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

確認する順序

1. ライセンスを読む前に、何に使うのかを決める。ほとんどはこの3問で片が付きます。自社製品の内側で動かすのか隣に置くのか、社外の人がネットワーク越しに触れるのか、改変するのか。答えが「隣に置く」「触れない」「改変しない」であれば、本カタログの45件はいずれも問題なく、例の4件も含まれます。
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は実在する見慣れた識別子で、だからこそ条文なら通らない場面を名前だけで通過してしまいます。

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