ハクソク

世界を動かす技術を、日本語で。

RFC: PHPライセンスの更新

315日前原文(wiki.php.net)

概要

  • PHP License および Zend Engine License の複雑さと混乱を解消する提案
  • Modified BSD License（3-clause BSD） への移行で権利関係の明確化
  • GPL互換性 と OSI承認 の確保
  • 特定団体向けの特別条項を削除し、よりシンプルなライセンス体系へ
  • 新しいライセンス文書やファイルヘッダーの導入計画

PHP ライセンス更新提案の概要

  • PHP と Zend Engine の現在のライセンスは、独自条項やOSI非承認部分があり、長年にわたり混乱の原因
  • Modified BSD License（BSD-3-Clause） を新たな共通ライセンスとして採用する提案
  • 既存の貢献者・ユーザーへの権利は維持しつつ、特定団体向けの特別条項を廃止
  • GPL互換性 および OSI承認 を得ることで、オープンソースコミュニティの要望に応える
  • PHP GroupやPerforce Softwareと連携し、ライセンス文書・ファイルヘッダー・公式ドキュメントの全面的な更新を実施

提案内容の詳細

  • Modified BSD License をPHP License（バージョン4）とZend Engine License（バージョン3）として採用

    • SPDX識別子： BSD-3-Clause
    • OSIとFSFによる承認済み

  • 既存のPHP License 3.01やZend Engine License 2.00の特別条項を削除し、内容をModified BSD Licenseに統一

  • 新規および既存プロジェクトでは、従来のPHP LicenseやZend Engine Licenseの使用を非推奨とする

  • LICENSEファイル や ファイルヘッダー を新形式に差し替え

  • 公式サイトや関連ドキュメントも新ライセンスに合わせて改訂

    • PHP Groupと協力し、PHP License 4への移行
    • Perforce Softwareと協力し、Zend Engine License 3への移行
    • 旧ライセンスの廃止と利用抑制
    • 新しいLICENSEファイル・ファイルヘッダー例の導入
    • 公式ウェブサイト（https://www.php.net/license/）等の内容更新

Modified BSD License（3-clause BSD）の全文

  • ソースコードおよびバイナリ形式での再配布・利用を許可
    • ソース再配布時：著作権表示、条件リスト、免責事項の保持が必須
    • バイナリ再配布時：同様の情報をドキュメント等に記載
    • 著作権者や貢献者の名称を無断で宣伝・推奨に使用不可
  • ソフトウェアは「現状有姿」で提供
    • 明示的・黙示的な保証を否認
    • いかなる損害に対しても責任を負わない

新しいLICENSEファイル例

  • Copyright © 1999–2025, The PHP Group and Contributors.
  • Copyright © 1999–2025, Zend by Perforce.
  • Modified BSD Licenseの条件を明記
  • 著作権者・貢献者名の保持例を提示

新しいファイルヘッダー例

  • PHP GroupおよびZend by Perforceの著作権表示
  • Modified BSD LicenseへのリンクとSPDX識別子
  • 各ファイルごとに既存著者名を保持

背景・歴史的経緯

  • 従来のPHP LicenseやZend Engine LicenseはGPL非互換・OSI非承認の課題

  • 初期のPHPはGNU GPL v2で公開、その後商用利用の懸念から独自ライセンスへ移行

  • デュアルライセンスや独自条項の複雑さが、法的対応や企業利用の障壁となっていた

  • 25年にわたりPHPとZend Engineは密接に統合され、分離利用は現実的でなくなった

  • オープンソース運動と商用利用の歴史的対立背景

    • Rasmus LerdorfによるGPL公開と、その後のApacheライセンスベース独自条項
    • 商用利用制限や法的対応の困難さ
    • コミュニティ内での自由度・権利範囲の議論

まとめ

  • Modified BSD License への移行で、PHPとZend Engineのライセンス体系を国際標準かつ明確に統一
  • GPL互換性 と OSI承認 の獲得により、企業・開発者双方にとって扱いやすいオープンソースソフトウェアとなる
  • 今後の新規開発・利用における法的リスクや混乱の大幅な低減

Hackerたちの意見

ソフトウェアのライセンスや改変について専門家になりたいなら、これを読むべきだね。ニュースじゃないって売り出されてるけど、それはいいことだよ。寄稿者にもエンドユーザーにも、権利的には変化なし。

└

最後に聞いたニュースじゃないアップデートで、変更や再認証が不要だったのは、787MAXとMCASのことだったかな。

└

削除されてる条項は、PHPとZendの商標を守るものだけみたいだね。それ以外は、二つのプロジェクトを一つのライセンスの下に統一してるだけ。 基本的に、これらの二つの条項（最初はPHPから、次はZendから）が削除されてる： 「PHP」という名前は、このソフトウェアから派生した製品を支持または宣伝するために、事前の書面による許可なしに使用してはならない。許可が必要な場合は、group@php.netに連絡してください。 「Zend」と「Zend Engine」という名前は、このソフトウェアから派生した製品を支持または宣伝するために、Zend Technologies Ltd.からの事前の許可なしに使用してはならない。許可が必要な場合は、license@zend.comに連絡してください。 そして、以下のように置き換えられてる： 著作権者の名前や寄稿者の名前は、このソフトウェアから派生した製品を支持または宣伝するために、特定の事前の書面による許可なしに使用してはならない。 その後、以下の三つの条項（4-6）がPHPから削除されてる： 4. このソフトウェアから派生した製品は「PHP」と呼ばれることはできず、「PHP」がその名前に含まれることもできない。事前の書面による許可が必要です。あなたのソフトウェアがPHPと連携していることを示すには、「Foo for PHP」と言うことができます。 5. PHPグループは、ライセンスの改訂版や新しいバージョンを随時公開することができます。各バージョンには識別番号が付けられます。特定のライセンスの下で公開されたコードは、そのバージョンの条件の下で使用し続けることができます。また、PHPグループが公開した次のバージョンの条件の下でそのコードを使用することもできます。このライセンスの下で作成されたコードに適用される条件を変更できるのはPHPグループだけです。 6. いかなる形態の再配布も、次の確認を保持しなければなりません：「この製品にはPHPソフトウェアが含まれており、http://www.php.net/software/から自由に入手できます」。 そして、以下の三つの条項（4-6）がZendから削除されてる： 4. Zend Technologies Ltd.は、ライセンスの改訂版や新しいバージョンを随時公開することができます。各バージョンには識別番号が付けられます。特定のライセンスの下で公開されたコードは、そのバージョンの条件の下で使用し続けることができます。また、Zend Technologies Ltd.が公開した次のバージョンの条件の下でそのコードを使用することもできます。このライセンスの下で作成されたコードに適用される条件を変更できるのはZend Technologies Ltd.だけです。 5. いかなる形態の再配布も、次の確認を保持しなければなりません：「この製品にはZend Engineが含まれており、http://www.zend.comから自由に入手できます」。 6. このソフトウェアの機能や使用を言及するすべての広告資料には、次の確認を表示しなければなりません：「Zend Engineはhttp://www.zend.comから自由に入手できます」。

背景: https://wiki.php.net/rfc/php_license_update#background

こういう法的な変更って面白いよね。OSIがPHPライセンスを承認するまで圧力が必要だったってのは、彼らの「オープンソース」に対する「管理」のズレを示してる。彼らの「オープンソースAI」の定義も変だし、権利を侵害してる。

提案されたライセンスは、ユーザーの権利を減らしたり、以前のPHPライセンスバージョン3.01の下でライセンスされたコードの使用に新しい制限を追加したりしません。 確かに、そうじゃないよ。修正されたBSD条項3（以下にコピー）を見てみて。 3. 著作権者の名前や寄稿者の名前は、このソフトウェアから派生した製品を支持または宣伝するために、特定の事前の書面による許可なしに使用してはならない。 ちょっと細かいこと言ってるかもしれないけど、これは権利の狭まりだよ。 すべての寄稿者から許可が必要ですか？ 短い答えは「いいえ」。元のライセンスが派生物の権利を狭めることを禁じてないから、彼らはこの変更をやってのけると思う。もし寄稿者がこの追加の負担や面倒に抗議したら面白いね。

└

つまり、PHPライセンスの条項3と4はすでにこう言ってるみたいだね： 3. 「PHP」という名前は、このソフトウェアから派生した製品を支持または宣伝するために、事前の書面による許可なしに使用してはならない。許可が必要な場合は、group@php.netに連絡してください。 4. このソフトウェアから派生した製品は「PHP」と呼ばれることはできず、「PHP」がその名前に含まれることもできない。事前の書面による許可が必要です。あなたのソフトウェアがPHPと連携していることを示すには、「PHP Foo」とか「phpfoo」と呼ぶのではなく、「Foo for PHP」と言うことができます。 編集：思ったよりも文脈があるかも。

└

自分は法律の専門家じゃないけど、新しいライセンスは新しいPHPバージョンにのみ適用されるから、遡って変更するには承認が必要だよ。新しいライセンスの下で寄稿しないなら、影響はないはず。

└

この条項は、人があなたに連絡することを許可するものではなく、書面での許可なしに行動することを防ぐものなんだ。それがデフォルトなんだよ。商標法や個人を保護する法律も、元々こういう風に機能してる。BSDライセンスにこの条項が本当に必要かどうかは微妙だと思う。弁護士と慎重にこの変更を評価したんだろうけどね。

└

私は細かいことを言っているのは分かってるけど、これは権利の制限だよ。 いや、違うよ。どの権利を与えないかを明示的に示すことは、暗黙的に与えないことよりも狭くはない。ただ、より明確なだけだよ。著作権と商標権は別物だからね。

すごい、PHPのライセンスやその歴史が一つの場所にまとまってる。マーケティングやAI生成のクソみたいなものも見当たらないし、最高だね ;)

└

AIが生成したくだらないものは、新しいものを何も加えないよ。実際、くだらないものは昔からあったし！だから、特に見るべきものはないね :)

すべての貢献者から許可を得ないことに対する懸念は、悪意のある貢献者が厄介なことをする可能性があるからなんだ。例えば、あのストライプのあるSマークとか、ただの嫌がらせでね。良くも悪くも、アメリカのようなシステムでは誰でも誰にでも理由をつけて訴えられるし、みんな自分のコストを負担することが求められるから、みんなすごく神経質になって、金属でガチガチに守ってるんだよ。余談だけど、「一方、GPLの著者でFSFの創設者であるリチャード・ストールマンは、PHPプロジェクトがGPLを使用することについて大きな意見の相違があったため、PHPプロジェクトはデュアルライセンスのアプローチを中止し、GPLライセンスを選択肢から外した」って、ほんと、ストールマンらしいよね。

└

PHPグループは「または後のバージョン」条項のおかげで、貢献者の承認なしに新しいライセンスのバージョンをリリースできるから、何でも好きなことができるよ。

変更を理解している人、私のためにELI5してくれない？これはPHP全体のライセンスを変更するの？

└

「PHP全体」ってどういう意味？これは言語のライセンスを変更するんだよ。それはインタープリター、ランタイム、標準ライブラリを含むよ。

参考までに、誰かが気になっているかもしれないけど：MetaはPHPではなくHackを使ってるよ。（Hackのパッケージング、ドキュメント、利用可能性はひどい。なぜなら、Metaの内部で誰も見ない改善に対するパフォーマンスレビューの「影響」がないから。しかも、知識を独占することで職の安定があるしね。）ライセンスについて：MetaとGoogle[1]、おそらくMicrosoft、Apple、そしてほとんどの他の大企業は、AGPLソフトウェアの使用を明示的に禁止してる。なぜなら、「リモートネットワークインタラクション」条項の曖昧さにより、呼び出しを防ぐことができるとは証明できないから。だから、もしあなたのコードを大企業やビジネスを運営している誰にも使われたくないなら、AGPLを選んでね。

  1. https://opensource.google/documentation/reference/using/agpl...
└

つまり、オープンソースのスタートアップでAWSにやられたくないなら、デュアルAGPL + 商業ライセンス（IP譲渡CLA付き）を選ぶべきだね。

└

Metaには確かにいくつかのPHPアプリがあるよ。WordPressを使っているサイトのコレクションがあるんだ。

└

だから、もしメガコープやビジネスを運営している誰かに自分のコードを使ってほしくないなら、AGPLを選べばいい。単に「ビジネスを運営している誰か」ではなく、「あなたのソフトウェアを使って独自のネットワークサービスを提供するビジネスの中の誰か」ってことだ。それがAGPLの全てのポイントなんだ！ あなたのリンクの中でGoogleの理由は、彼らがネットワークサービスの提供者であることが問題だってことがはっきりしてる。ほとんどの非テクノロジー系のビジネスはこれらの問題に全く影響されないし、気にする理由もないんだ。

25年前にPHPのZend Engineのソースコードを勉強したことを思い出すよ。初めてトリプルCポインタを見たとき（確かzval***だったかな？）は衝撃だった。その後の数年間、たくさんPHPを使ったよ。高校のプログラミングコンテストでもPHPを使ったけど、提出したものが却下されたんだ。スタッフがPHPやスタンドアロンのCLIでの使い方に不慣れだったからね。その時代にできたことには感謝してる。

└

それを考えると面白いね、俺は卒業プロジェクトをPerlでやったから。

これは実際、10年以上前に話し合われていたこととほぼ同じだね。その頃は「LOLPHPライセンス」って呼んでた。これが再再実装されてるのを見たとき、コーヒーをこぼしちゃったよ。なんて混乱だ。

なんでもっとシンプルなMITじゃないのか、ちょっと気になるな。