PHP internals opened a vote to replace the PHP License 3.01 and Zend Engine License 2.0 with the 3-Clause BSD License beginning with PHP 9.0. The change addresses a legal mismatch that has survived for roughly 25 years.
The current PHP license is recognized as open source by OSI, while the Zend Engine license is not. The two bodies of code now live together so closely that treating them as separable components is impractical. That ambiguity creates recurring questions during compliance reviews, especially around compatibility with GPL-licensed work.
BSD-3 is recognized by OSI and FSF and is GPL-compatible. The PHP Group, Zend/Perforce, and legal counsel had signed off before the community vote, which runs through April 4. Ordinary rights to use, modify, and distribute PHP remain. The main change is that organizations receive one widely understood license instead of explaining a historical split.
Audits want a known SPDX identifier
The problem the RFC describes is recognition. PHP License 3.01 received OSI approval through a legacy process: the text was already in wide use when the committee reviewed it. Zend Engine License 2.00 is not OSI Approved. Neither is GPL-compatible according to the FSF. After 25 years in the same repository, treating Zend/ as a detachable product stopped being realistic. Together they form the language's reference implementation.
BSD-3-Clause, SPDX identifier BSD-3-Clause, is recognized by OSI and FSF and is GPL-compatible. The RFC argues that the extra clauses in the current licenses are specific to the PHP Group and Zend/Perforce: the "PHP" name restriction, the right to republish the license, the mandatory acknowledgement, Zend advertising. Strip those clauses and the text matches BSD-3. Rights to use, modify, and distribute remain. Each contributor's copyright stays with the contributor.
For a compliance team, the question stops being "explain the PHP License and the Zend Engine License, and why the engine has its own text" and becomes "the runtime declares BSD-3-Clause". That shortens vendor questionnaires, SBOMs, and reviews of use next to GPL code.
The RFC also deprecates the PHP License and the Zend Engine License for new projects. Publishing an internal library "under PHP License 3.01" after the change means choosing a text the project itself asks people not to use.
Application PHP does not change behavior
There is no change to semantics, opcodes, or API. composer update on your code does not have to wait for the license. Extensions, SAPIs, and ABI follow the normal version cycle. Application regression tests are the wrong place for this decision. The right place is the legal package: LICENSE in the tarball, headers in php-src files, removal of Zend/LICENSE, the text of php --version.
Teams that copy PHP's LICENSE into an internal package need to copy the new file, not the old one. Teams that cite "PHP License 3.01" in an approved-software policy need to update the list when the new runtime version arrives. Without that step, engineering updates the image and legal keeps answering the questionnaire with the previous formula.
Third-party code inside php-src with its own license, such as timelib in ext/date/lib/, is outside the swap. The manual stays under Creative Commons. The cut is repository software that today sits under the PHP License or the Zend Engine License.
I would treat this as a release-notes item for legal and for whoever generates the SBOM, not as a refactor item. If the team has no SBOM for the runtime, the license swap is a decent reason to start one. The SPDX identifier fits on one line. The two-license history does not.
PECL, vendor, and opting into version 4
Many PECL extensions still declare PHP License 3.01. Clause 5 of 3.01 already lets a user treat covered code under a later version published by the PHP Group. If version 4 is BSD-3, consumers of the extension may choose those terms. The maintainer may migrate the header and composer.json. The SPDX the RFC recommends is BSD-3-Clause, not a new name "PHP License 4", precisely to avoid proliferating another text.
A useful inventory, on a short spreadsheet:
- PHP runtime in production, CLI, FPM, and job images;
- PECL extensions and the
licenseeach one declares; - internal packages that copied the PHP License;
- company policy that lists "PHP License" as an approved or blocked option.
Legal updates the list. Engineering points at the versions. Without both, the team keeps filling questionnaires with the old answer and finds the mismatch in a due diligence.
The RFC recommends, for new software, Apache-2.0, BSD-2, BSD-3, LGPLv3, MIT, MPL-2.0, or Unlicense, among others. GPL on a PHP extension remains a confusing state for distributors, because the FSF treats extension and engine as one combined program. That recommendation already held before the vote. The core swap only makes it stranger to insist on the PHP License for a new package.
The legal calendar is not PHP 9
This note's title talks about PHP 9 because that was the public frame. The RFC text, already before the March vote, had shifted to taking effect in the next 8.x. Waiting for a major to "clean the license" mixes two projects: the platform migration and the legal-text swap. The second does not ask for a feature freeze or a downtime window.
The internals vote ran through 4 April 2026, 00:00 UTC, with a two-thirds bar. The PHP Group and Perforce had already consented in writing, according to the RFC. The community vote was still required to record the project's will and to request execution in the repositories.
If it passes, the internal work is mundane: update the SBOM when the new runtime version arrives, notify legal, review extension templates, copy the new LICENSE wherever it was vendored. If it fails, the grey zone remains and the questionnaire stays long. In neither outcome does the application need a code epic.
There is one point where engineering and legal actually meet: the date the production image starts shipping the new text. Until then, the old runtime stays under the old licenses. Planning "when we go to 9" leaves that date without an owner.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
