PHP、ライセンスをBSD 3-Clauseへ変更する提案を議論中

• PHPプロジェクトは、従来の複雑で互換性のないPHP独自ライセンスとZend Engineライセンスを**BSD 3-Clause（修正BSDライセンス）**へ一本化するRFCを議論中
• 新ライセンスの適用時期はPHP 9.0で、ソースコード・ヘッダー・ドキュメント全般にBSD 3-Clauseが反映され、過去の特別条項やブランド関連の制限がなくなる
• OSI・FSF承認、GPL互換など法的明確性が確保され、コントリビューターおよびユーザーの権利は従来どおり保証される
• ライセンス変更には**PHP Group、Perforce Software（旧Zend）**の正式な同意が必要で、コミュニティでの議論後、6か月以上の検討および投票手続きを進める
• この変更はPECL/拡張機能など外部プロジェクトにもBSD 3-Clauseの選択を推奨し、「PHPライセンス」の使用は推奨しない

---

概要

• PHPプロジェクトでは長年、独自のオープンソースライセンスとZend Engine Licenseによって混乱と論争が続いていた
• 特にZendディレクトリのソースに適用されるZend Engine LicenseはOSI承認ライセンスではないため複雑さを増していた
• このRFCは、すべてのPHPコントリビューターの著作権を維持しつつ、ユーザーに従来ライセンスと同等の権利を与える実用的なライセンス簡素化を提案するもの
• **BSD 3-Clause（修正BSDライセンス）**を新たな公式ライセンスとして採用し、権利・利用条件を維持しながら複雑さと誤解を減らすことが目的

提案と主な変更点

• 問題の本質は、新しいバージョンのPHP LicenseとZend Engine Licenseを公開し、**Modified BSD License（BSD-3-Clause、OSI/FSFともに承認）**を正式に採用すること
• 既存のPHP License（version 3.01）とZend Engine License（version 2.00）は、特別条項を除けばModified BSDと実質的に同一であり、権限の本質的な変化はない
• ライセンス更新後:
  • コントリビューターおよびユーザーに付与される権限に変化はない
  • PHP Group、Perforce Softwareと協力して特定グループ固有の条項を削除
  • PHPおよびZend EngineはOSI承認、GPL互換ライセンスの下で提供される
• 旧PHP LicenseおよびZend Engine Licenseの使用はもはや推奨されない
• LICENSEおよびソース内のライセンスヘッダーも新フォーマットへ置き換えられる

ライセンス全文の要約

• BSD 3-Clauseは自由にコピー・改変・配布が可能で、著作権表示と免責条項、名称・ブランドの無断使用禁止条件を含む
• BSD-3-ClauseはOSI（オープンソース・イニシアティブ）、FSFの双方で承認された自由ソフトウェアライセンスであり、GPL互換でもある

変更手続きと承認

• RFCはコミュニティでの公開議論の後、投票で確定され、正式な同意・投票後に適用が進められる
• ライセンス変更にはPHP GroupおよびPerforce Softwareの正式同意が必要
• 過去のソースコードコントリビューターの権利はそのまま維持され、変更が既存の権利を侵害することはない
• コミュニティに6か月以上の議論期間を設けた後、投票で確定する
• 変更はPHP 9.0で正式に反映される予定

背景と歴史的文脈

• 初期のPHP 1・2はGPL、その後ApacheライセンスやカスタムBSDベースのライセンスを経て発展してきた
• Zend Engineは別ライセンスを維持していたが、現在では事実上分離不可能な1つのプロジェクトと見なされている
• 既存のPHPライセンスにおける名称使用制限やブランド保護条項は、他のオープンソースとの互換性や配布において継続的に問題を引き起こしてきた

既存コード、拡張機能、ドキュメントへの影響

• 今回のRFCは**php-src全体（別ライセンスが明記されたコードは除く）**に適用され、PECL/拡張機能などにもBSD 3-Clause採用を推奨する
• 新規/既存のPHPソースリポジトリ内でPHP LicenseまたはZend Engine Licenseが適用されているコード全体に影響する
• 既存ライセンス（z.B. timelibなど別ライセンスのコード）はこの変更の対象ではない
• PHPマニュアルはCreative Commons Attribution 3.0以降のライセンスを継続して維持
• 既存の拡張モジュール/ソフトウェアにはPHP License v4（Modified BSD）適用の選択肢が与えられる
• 今後の拡張機能および新規プロジェクトには最新のBSD/Apacheなど公認ライセンスの使用を推奨

結論

• PHPおよびZend Engineのライセンス構造が3-clause BSDへ簡素化され、オープンソースエコシステム内での明確性、互換性、商用活用、法的安定性が強化される見通し
• 本提案が承認・適用されれば、ユーザーはBSD-3-Clauseを基準としてPHPとZend Engineを自由に利用できる
• プロジェクト内のコントリビューター、コミュニティ、主要企業の同意と投票手続きが完了し次第、正式に適用される予定

[GN⁺]

Hacker Newsの意見

• Metaが使っている言語はPHPではなくHackであることを指摘しつつ、Hackはパッケージング、ドキュメント、可用性がいまひとつだと述べている。その理由として、Meta内部で目に見える部分ではないため人事評価に反映されにくいこと、また内部知識の囲い込みが雇用の安定と結びついていることを挙げている。さらにライセンス面では、Meta、Google、Microsoft、Appleなどの大手IT企業はAGPLソフトウェアの使用を厳格に禁じているとし、AGPLの「Remote Network Interaction」条項の曖昧さによる法的リスクを避けたいからだと説明している。もし大企業や一般的な事業者に自分のコードを絶対に使わせたくないなら、AGPLを選べという提案も添えている。参考: GoogleのAGPLポリシー文書
  • 多くの企業がAGPLソフトウェア（例: Grafana、Mastodon、Mattermostなど）を実際に社内で使っていることを強調している。ただし、外部の有料顧客向けサービスとして使われることは少ないとも述べている。開発者として、自分は巨大企業の過剰な懸念よりも、自分のソフトウェア利用者の自由のほうを重視すると明言している
  • AGPLの影響を受けるのは「すべての事業者」ではなく、「自分のソフトウェアで独占的なネットワークサービスを提供する会社」だけだと指摘している。これこそがAGPLの核心的な意図であり、Googleのポリシー根拠もそのためにネットワーク事業者であることを明記していると説明している。ほとんどの非技術系企業には何の影響もなく、気にする必要もないと付け加えている
  • オープンソース系スタートアップなら、AWSのようなメガクラウドによる囲い込みを防ぐために、AGPL + 商用デュアルライセンス（知的財産権譲渡CLAを含む）を勧めている
  • 多くの大企業がAGPLソフトウェアを使うのは、デュアルライセンスが可能だからだと説明している。つまり、AGPLでオープンソース性を打ち出しつつ、商用ライセンス利用時には顧客企業に課金できるということだ
  • 最近はGoをよく使っている気がする、多くのパッケージがGoで書き直されたように感じた、という印象を述べている
• PHPライセンスに関する内容とその歴史が、マーケティング文やAI生成文なしで一か所に整理されていてとても良い、という感想を述べている
  • AI生成コンテンツは実際には追加情報を与えず、無駄話は昔から存在していたので、本質的に新しいものは何もないという軽妙な意見を添えている
• 25年前にPHP Zend Engineのソースコードを直接読んで学んだとき、人生で初めて三重ポインタ（zval***）に出会った記憶を振り返っている。その後PHPでいろいろなことをやり、高校生のころにはプログラミング大会にもCLI環境でPHPを使って出場したが、当時スタッフがその言語や環境に不慣れだったため失格になったという、笑うに笑えない経験も語っている。そして当時PHPが与えてくれた可能性に感謝を伝えている
  • この話を面白く感じたとし、自分は卒業プロジェクトでPerlを使った経験があると共有している
  • 三重の「むき出し」ポインタについて、論理的に納得できる落としどころを見つけにくいと述べている。性能以前に、暗黙的な間接参照の複雑さを説明するのが難しいという。たとえばstructのメンバーのように明確なものなら理解できるが、わざわざ複雑さを足すのは不合理だとしている。「なぜ単純じゃないんだ？」と知人がよく言っていたことも回想している
• すべてのコントリビューターの同意を得ない場合、悪意あるコントリビューターが問題を起こす可能性があるという懸念がある。米国などでは嫌がらせ目的の訴訟も十分にあり得て、全員が自費で対応しなければならないため、結果として法的防御に過度に気を配る文化が生まれると述べている。そして脇道として、リチャード・ストールマンとPHPのGPL利用、そしてそれによってデュアルライセンスが中断されたという古典的な逸話にも触れている
  • PHP Groupは「or later」条項のおかげで、別途コントリビューターの同意を得なくてもライセンス本文を変更して新バージョンを公開できると説明している
  • ストールマンとのライセンス逸話として挙げられた主資料は、実際にはMySQLのGPL移行とそれによるPHPライセンスへの影響に近いと指摘している。ストールマンが嫌いだからGPLをやめるという理由には納得できないとも述べている
• 関連する背景は PHP Wikiのライセンス変更背景文書 で確認できる
• ソフトウェアライセンスと修正に関する専門知識を身につけたいなら必読のページだと勧めている。そして今回のライセンス変更は、私たちに何らかの変更や再認証を要求するニュースではなく、コントリビューターにも利用者にも影響はないことを強調している
  • 大きな変化なく進むというニュースが、実際には大きな変化を伴っていた787MAXとMCAS問題を例に、現実的な警戒心をユーモラスに表現している
  • 実際の変更点は、PHP/Zendの商標関連文言を削除し、両プロジェクトを1つのライセンスに統合する作業だと詳しく説明している。つまり、「PHP」「Zend」「Zend Engine」という名称の使用には以前はそれぞれ個別の承認が必要だったが、今後は著作権者およびコントリビューター名に対して一括適用されるように変わる。また、表示・改訂・認証・通知条項（4～6項）もあわせて削除されると丁寧に案内している
• なぜライセンス文書では重要な部分をすべて大文字（ALL CAPS）で書くのか、という疑問を呈している
  • 米国法では保証・責任に関する免責条項には「conspicuous（目立つこと）」が求められ、通常文の中で最も簡単にそれを実現する手段が大文字表記だと説明している
  • 大文字・小文字をめぐる論争自体をなくす方法だとも述べている。全部の単語を大文字にすれば、全体が強調されるので混乱が減るということだ
  • 商法（UCC）の条項によれば、合理的な人が必ず認識できるように書かれていなければならず、その一例として見出しが大きな大文字で書かれている場合がある。だから全体を大文字にすれば、裁判所もその重要性を「目立つもの」として認定しやすいと説明している
• 変化についてよく知っている人に、ELI5レベルで説明してほしいと求めている。PHP全体のライセンスが変わるのかが気になっている
  • 「PHP全体」とは正確に何を指すのかと問い返しつつ、今回の変更は言語そのもの、つまりインタプリタとランタイム、標準ライブラリに適用されると説明している
• MITライセンスのほうがずっと簡単なのに、なぜそれを使わないのかと疑問を述べている
  • MITライセンスとBSD 3条項ライセンスの違いが、本当に実質的な意味で感じられるほど単純さに差があるのか、MITライセンス と BSD 3条項ライセンス の間に意味のある違いがあるのかと問いかけている