PHP 項目擬棄用自訂許可證 統一轉用 Modified BSD

PHP 項目多年來在許可證問題上一直屬於「歷史包袱」較重的項目，如今正準備進行一次重要而徹底的清理：由社群成員 Ben Ramsey 牽頭的提案，計劃廢棄目前使用的兩套自訂許可證——涵蓋大部分代碼的 PHP License 3.01 以及用於 Zend 目錄代碼的 Zend License 2.0——轉而在未來版本中統一採用 BSD 三條款（Modified BSD）許可證。

目前，PHP 社群正在就這一「PHP 許可證更新」RFC 進行投票，投票將持續至 2026 年 4 月 4 日。

PHP 早期許可證變遷歷史

在 PHP 的早期發展階段，項目在許可證上的變更頻率頗高：自 1995 年至 2006 年間，PHP 共進行了七次許可證變更或條款調整。最初，PHP 是在 GPLv2 下發佈的；1998 年發佈的 PHP 3 則採用了 GPLv2 與新 PHP License 的雙重授權方式，這一新許可證以 Apache License 1.0 為基礎，由 PHP 創始人 Rasmus Lerdorf 制定，目的是讓 PHP 對商業用戶更「友好」，同時仍保持自由軟件屬性。

Lerdorf 當時表示，希望在確保 PHP 始終免費的前提下，讓商業公司可以在不讓主要貢獻者感覺「被占便宜」的條件下嘗試商業化版本。 不過，最初版本的自訂 PHP 許可證包含一條需要獲得 PHP 開發團隊書面許可才能進行商業再分發的條款，這在實踐中被證明難以操作，最終在 PHP 3.0.14 版本中被刪除。該版本附帶的 LICENSE 文件甚至沒有標明許可證版本號。

2000 年 5 月發佈的 PHP 4.0 是一次重大重構，引入了由 Zeev Suraski 和 Andi Gutmans 編寫的 Zend 引擎，這兩人隨後創辦了 Zend Technologies，希望在獨立於 PHP 的路徑上商業化 Zend 引擎。Zend 向 PHP 項目提供授權，使其可以将 Zend 引擎集成進 PHP，並承諾相關代碼將保持在 Zend 許可證或符合開源定義（OSD）的其他許可證之下，儘管 Zend License 本身並未獲得開源促進會（OSI）正式批准。

此後，PHP 源碼樹中 Zend 目錄下的代碼便採用 Zend 許可證；PHP 4.0 同時完全放棄了 GPLv2，轉而採用 PHP License 2.02。 在隨後的幾年中，PHP License 繼續被微調：PHP 3.0 版本的許可證曾獲得 OSI 批准，但之後又做了一次小幅修改，形成 PHP License 3.01。該次修改僅調整了版權年份以及對 PHP 和 Zend 致謝文字的表述方式，並未改變授權權利本身。

然而，這個新版本從未再經過 OSI 審核。更麻煩的是，許可證文本表面上只適用於由「PHP Group」發佈的軟件，而這一「PHP Group」本身並非實際的法律實體，而是十名早期 PHP 開發者的列表。這一模糊性讓部分人認為，其他主體發佈的軟件並不能合法地採用 PHP License 作為授權文本，從而對如 Debian 等項目造成了實際困擾。Ramsey 在 RFC 中專門梳理了這段歷史背景。

在當前的 RFC 中，Ramsey 提出，自下一個主要版本起（最初寫的是 PHP 9.0，後更新為「下一版本的 PHP」），用 BSD 三條款許可證統一替換目前的 PHP License 和 Zend License。他表示，在撰寫這一提案時，自己已與 OSI 許可證委員會主席 Pamela Chestek 合作，處理相關法律問題與疑問。Ramsey 稱，他已經與所有 PHP Group 成員溝通過，每位成員都已表示支持這一變更。

同時，他還獲得了 Perforce Software 的許可——Perforce 於 2019 年通過收購 Rogue Wave 將 Zend 納入旗下，而 Rogue Wave 在 2015 年收購了 Zend。 有人可能會疑問：既然多年來有如此眾多個人向 PHP 提交代碼，是否需要每一位貢獻者都同意才能更改許可證？在 RFC 中，Ramsey 的觀點是：不需要。

PHP 並未要求貢獻者簽署將版權轉移給項目的 CLA，因此貢獻者保留其貢獻代碼的版權；但在他們未明確聲明其他授權條款的前提下，可以視為他們以項目目前的許可證向項目授予使用其貢獻的權利。換言之，貢獻者對自己所提交代碼享有版權，但在未指定其他許可證的情況下，其貢獻是按項目所採用的許可證授權給項目使用的。Ramsey 進一步指出，通常在變更開源項目許可證時，需要取得所有版權方的同意，因為新許可證可能會改變授予用戶的權利範圍。

但在此案例中，改用 BSD 三條款許可證並不會改變除 PHP Group 和 Perforce Software 外其他貢獻者所授予的權利。因此，他認為項目並不需要逐一徵求所有貢獻者的明確許可。 儘管 RFC 指出從法律上並不強制要求逐一徵得同意，但出於「禮貌」考慮，Ramsey 提議將討論期至少維持六個月，以確保所有利益相關方有充分機會表達意見。自 2025 年 7 月提出 RFC 以來，他多次發佈更新並提醒社群該議題仍在討論中；截至目前，尚未出現實質性反對意見。

討論中也出現了一些具體問題。例如，Derick Rethans 詢問為何必須等到 PHP 9，而不是在 8.5 之後的「下一版本」就進行變更。Ramsey 回應稱，這並無技術或法律上的硬性理由，只是出於版本節奏的直覺判斷，如果社群認為在 PHP 8.6 中完成變更更合適，他也不反對。此後，RFC 便將實施時間從「PHP 9」調整為「下一版本」。 另一位開發者 Peter Kokot 則建議，應對與 GPL 的兼容性進行更清晰的說明，以便在未來與 GPL 授權軟件協作時減少疑慮。

他指出，PHP 在構建時可以選擇鏈接兩個 GPLv3 許可證的庫：GNU Readline 和 GNU dbm (GDBM)。他希望逐步廢棄在構建階段鏈接這些 GPL 庫的選項，以便讓打包者不再為潛在的不兼容問題擔憂，最終徹底移除對 GDBM 和 Readline 的鏈接可能性。Ramsey 回應稱，在現有 PHP License 3.01 下，由於對用戶附加了一些額外限制，該許可證與 GPL 不兼容，這種不兼容目前無法消除；然而若改用 Modified BSD 許可證，只要最終組合包整體以 G

PL 條款發佈，就不存在此類兼容性問題，這也將顯著簡化發行版打包工作。 2026 年 3 月 14 日，Ramsey 宣布對該 RFC 正式開啟投票。投票結果以公開方式記錄在 PHP Wiki 的 RFC 頁面上。目前尚不確定擁有投票權的總人數——2019 年統計顯示當時共有 180 名具有投票資格的開發者。投票開始後不久，已有 47 人投下贊成票，2 人選擇棄權。

從早期結果看，社群對該提議的態度高度正面，但在投票程序結束前，結果仍不能視為板上釘釘。無論最終結果如何，這次許可證清理和簡化工作顯然離不開 Ramsey 過去數年在幕後進行的溝通、協調與推進。