はじめに
案件でWordPressのプラグインをいくつか作ってきました。WordPressの拡張機能（Add-onやプラグイン）を販売する際、しばしば以下のようなご指摘やご意見が寄せられることがあります。
WordPressのAPI（add_action, add_filter）を使っているなら、そのコードはGPLのはずだ！
なるほどなるほど。しかし、実はこれは「WordPress財団の願望的なポリシー」の話であり、法律的な義務ではありません。
なぜEULA（商用ライセンス）での配布が可能なのか、そしてなぜ「WordPress APIを使うことがGPL強制」ではないのか思ったことありませんか？
だから商用で使えない、GPLなのでソースコードが公開が義務だから商用で使えない、ソースコードが公開されているからセキュリティホール叩かれて使えない、GPLだからサポート料しか請求できないソース全部持ってかれた、というお客様や同業者ご意見をいただくこともしばしばあります。
GPLだけが独り歩きし続けて、結果WordPressのプラグインやその拡張機能の発展や成長を阻害してるんだなとは個人的に感じています。
ここから先は、個人的な解釈で、GPLがうんぬんかんぬんではなく、
WordPressをプラグインやプラグイン機能拡張を作った際のライセンスの取り扱いについてのメモです。
このブログの免責事項を読んだ上で、見てくださいね。
まず、GPLとはなんぞやは、こちらからどうど。日本国内でGPLの議論はしたくないです(遠い目)。
https://licenses.opensource.jp/GPL-2.0/gpl/gpl.ja.html
よくある誤解：「WordPressのAPIを使ったらGPLになる」
これは、技術的な理解と法律の両面で誤りです。
❌ 誤解
- add_action を1行でも書いたらGPLになる
- WordPressの関数を呼んだら派生物になる
- Add-onは無条件でGPLを継承する
- なんならWordPress使ってブログでコード書いてたら、今日からそのコードGPLだよね。
✔ 実際の事実（法律的な基準）
GPLが継承されるのは、「著作権法でいう派生物（Derivative Work）」だけです。
そして、「派生物」の条件は以下の2つです。
- A. コードをコピーしているか？
- B. コードを改変しているか？
APIを利用しただけでは、著作権法上の派生物には当たりません。
著作権法上、派生物とは“元のソースコードの表現を継承する作品”を指します。
API呼び出しやイベントフックは“機能の利用”であって“表現の継承”ではないため、派生物とは判断されません。
この原則はWordPressだけでなく、以下のようなケースにも当てはまります。
- Linuxカーネル（GPL）の非GPLドライバ
- MySQL（GPL）を利用する商用アプリ
- Windows / macOS のAPI
- Android SDK
これらすべてが同じ原則で成り立っています。「APIを呼んだら派生物扱い」は、著作権法上、成立しないのです。
WordPress財団の主張は“法律”ではない。GPLは“権利”であって“義務”ではない
WordPress財団は以下のように主張しています。
WordPressのプラグインはすべてGPLであるべきだ！
しかし、これはあくまで「願望・思想」であり、法的拘束力はありません。
WordPress財団が他社に対してGPL違反の訴訟を起こした前例はゼロです。逆に、商用プラグインは10年以上市場で問題なく動作し続けています。
あまりGPLについて語りたくない。いろいろな考えと意見があるからね。
GPLとは本来：
- GPL作品の作者が、利用者に与える権利
- 利用者が自由を享受するための権利
であって、
「GPLでなければならないという義務」
ではない。
法律として強制されるのは、
- 元の GPL コードを コピーした場合
- 元の GPL コードを 改変して配布した場合
という 著作権法上の“派生物”の条件を満たしたときだけ。
つまり：
- APIコール
- add_action / add_filter
- WordPress上での動作
- UIのみを追加する Add-on
- 外部APIと通信する拡張
これらは GPLの派生物には該当しない（著作権法の範囲外）。
だから GPLはそこで“義務”としては発生しない。
実務の事実：商用プラグインは普通に存在する
✔ 代表例
- WP Rocket（商用・EULA）
- MemberPress（商用）
- LearnDash（商用）
- Gravity Forms（商用）
これらはすべてadd_actionを使用し、WordPress内で動作するにもかかわらず商用で提供されています。もし本当に「API利用＝派生物」であるなら、これらのプラグインは全滅しているはずです。プラグインのadd-onも全て公開されていないとGPL違反ですが、そのような事態にはなっていません。
ソース開示されていない
追加アドオンも非公開
JS/CSS/画像は完全商用
外部API利用で独自ロジック維持
なぜ商用で成立するのか？
理由はシンプルです。
✔ WordPress（GPL）のコードをコピーしていない
WordPressのクラスや関数を複製したり、コアコードを丸写ししたりしていない限り、著作権法上の派生物とはみなされません。
✔ プラグインは独立した作品（著作物）
WordPress自体は、「プラグインを読み込む機能」しか提供していません。受け皿としてのプラグインフォルダや、呼び出し口としてのフックに過ぎず、Add-onがWordPressの内部コードと一体化していない限り、派生物にはならないのです。
✔ ロジックを外部サーバーに置く方式が確立している
商用プラグインの多くは、以下のような構造を採用しています。
- WordPress側：UI と API リクエスト
- 外部サーバー：中枢ロジック・ライセンス認証
この外部ロジックはWordPressと結合しないため、100% GPLの影響外となります。
「商用Add-onをEULAにする方法」まとめ
結局、以下の条件を守ればEULAで販売しても問題ありません。
- WordPressのコードをコピーしない
コピーしていない限り、「派生物」とはみなされません。 - require/include で WordPressコアを直接読み込まない
- 親プラグインの内部ロジックを直接呼ばない
フック経由の疎結合であれば、派生物とみなされにくいです。 - Add-onはUIと設定だけにして、実処理は外部APIで行う
外部APIは完全に非GPLであり、企業が最もよく採用する構造です。 - JS / CSS / 画像 / モデルデータはGPLの対象外です
これらは完全に商用利用が可能です。 - EULA（利用規約）で「再配布禁止」を明確化する
実務における抑止力は非常に強いです。
まとめ
WordPressのAdd-onをEULA（商用）で販売することは合法であり、商用WordPress企業は実際に10年以上この方式を採用しています。これは、WordPress財団の「ポリシー寄りの解釈」であって、法律的に強制されるものではありません。
WordPressのGPLが適用されるのは「WordPressの派生物」、つまり“WordPressのコードをコピー・改変した作品”だけです。
※WordPress に限らず、GPL が適用されるのは GPL ライセンスされた作品の派生物だけ。
※派生物＝表現の継承
逆に言えば、Add-on が WordPress内部でロジックを持たず、外部APIと疎結合で連携するだけなら、それは派生物ではありません。
APIは単なる通信であり、著作権法上の派生物には該当しません。
実際、世界中の商用プラグイン（WP Rocket、MemberPress等）はすべてこの構造を採用し、長年販売されています。
よって、Add-onを商用EULAとして提供することは法的にも実務的にも成立します。
GPLになりえる構造 vs GPLにならない構造
| 項目 | GPLになりやすい構造 | GPLになりにくい / 対象外の構造（商用OK） |
|---|---|---|
| WordPress内部でPHP実行 | ✔ WordPress本体のコードと同じプロセス上で動く | ▲ UIと設定だけならOK（Add-on構造） |
| WordPressコードのコピー | ❌ コアコードや親プラグインのコードを複製 → 100% GPL派生物 | ✔ コピーしない限り派生物にならない |
| WordPressコードの改変 | ❌ 改変した時点で派生物 → GPL強制 | ✔ 改変しなければ派生物にはならない |
| require / includeでWPコアを読む | ❌ 強結合 → GPLの影響濃厚 | ✔ 使用しない限り結合が発生しない |
| 親プラグインの関数やクラスを直接呼ぶ | ❌ 内部ロジックへの依存度が高い → 派生物扱い | ✔ フック連携だけなら独立性が保てる |
| add_action / add_filter の使い方 | ❌ 内部ロジックを大量呼び出し → 濃結合に見える | ✔ “通知”だけ（疎結合）であれば派生物ではない |
| 管理画面の操作（add_menu_pageなど） | ▲ WordPress内部API依存度が高い（GPL寄り） | ✔ UIのみなら外部API方式で実質問題なし |
| 外部APIへの依存 | ▲ APIを呼ぶだけではGPL外（中身次第） | ✔ ロジックが全部API側なら完全に非GPL |
| ロジックの場所 | ❌ WordPress内 → GPL範囲 | ✔ 外部サーバー → 完全にGPLの外、商用OK |
| ライセンス認証の実装場所 | ❌ WP内部（GPLコード内） | ✔ 外部サーバーで完結させる（100%非GPL） |
| Add-on の役割 | ❌ 機能本体を実行 → GPL派生物 | ✔ UI/設定/通信のみ → 商用Add-onとして成立 |
| 配布形態 | ❌ WP内部PHP＝GPLになりやすい | ✔ Add-on軽量＋外部ロジック完全独立＝GPLの外 |
| JavaScript/CSS/画像 | ✔ これらはGPL強制なし（常に商用OK） | ✔ 完全商用資産として扱える |
| API利用の法律的扱い | ❌ WP側の主張は「APIでもGPL」だが法的根拠なし | ✔ API利用＝派生物ではない（著作権法の原則） |
| 実務上の扱い | ❌ コードが重いとGPL主張が強くなる | ✔ 商用WPプラグイン企業の大半がこの方式で販売中 |
| 外部サーバーが必須か？ | ❌ 不要、でもGPL影響下 | ✔ 必須にすると商用ロジック完全保護 |
GPL強制の有無 比較表
| 条件 | GPLが強制される（影響あり） | GPLが強制されない（影響なし） |
|---|---|---|
| 1. コードを配布しているか？ | ✔ GPLコードの派生物を配布する場合 | ❌ 配布されないコード（外部API・SaaS・クラウド） |
| 2. WordPressのコードをコピーしたか？ | ✔ コアコード・親プラグインのコードをコピーした場合 | ❌ コピーしていない（独自コードのみ） |
| 3. WordPressのコードを改変したか？ | ✔ コアを改変して再配布した場合 | ❌ 改変なし |
| 4. require/include で WP コアを内部取り込み | ✔ 強結合 → 派生物と判断されやすい | ❌ 使用しない（独立動作） |
| 5. 親プラグインの内部クラス・関数を直接呼ぶ | ✔ 内部ロジック使用 → 派生物の可能性 | ❌ フック通知だけ（add_action など） |
| 6. PHPでWP内部処理を実行しているか？ | ✔ WP内部のロジックを実行 → 依存高い | ❌ UIとAPI通信だけ（本体ロジックは外部） |
| 7. add_action / add_filter の使い方 | ▲ WP内部関数を多用し密結合 → GPL寄り | ✔ “通知だけ”の疎結合 → 派生物とは言えない |
| 8. ロジックの場所 | ✔ WordPress内部 → GPLの影響範囲 | ❌ 外部サーバー側 → 完全にGPLの影響外 |
| 9. ライセンス認証の場所 | ✔ WP内部で実装 → GPL対象 | ❌ 外部API側で実装 → 非GPL |
| 10. データ処理の場所 | ✔ WordPress内で処理 | ❌ 外部サーバーで処理（商用OK） |
| 11. JavaScript / CSS / 画像 | ✔ GPLの影響なし（常に自由） | ✔ 100% 商用OK（GPL対象外） |
| 12. プラグインの配布物に“GPLコード”が混ざるか？ | ✔ 混在している場合 → 純粋派生物 | ❌ 混在しない（独立コード） |
| 13. 外部プロセスとの関係 | ✔ 同一プロセス上 → GPL議論対象 | ❌ 別プロセス / 外部API → 影響ゼロ |
| 14. 全コードを同梱配布しているか？ | ✔ 含まれている場合はGPL可能性 | ❌ Add-on軽量、中枢ロジックは外（クラウド） |
| 15. 実務上どう扱われているか？ | ❌ 純粋GPLプラグインのみ | ✔ WP Rocket / MemberPress 等がこの方式で商用成功 |
おわりに
私もWordPressのプラグイン制作や既存プラグインに拡張機能を追加するときは上記表のように対応したり、自作ライセンスサーバー経由でライセンス販売して、拡張機能をライセンス認証して利用してもらっています。GPLに恩返しとWordPressコミュニティと一緒に繁栄していきましょう。