PHP Relicensing to BSD-3: What You Need to Watch For
VeröffentlichtKategorie: Website-Optimierung
Veröffentlicht am 17.03.2026
Introduction
PHP is cleaning up its licensing—nothing changes technically, but the legal story gets much clearer.
I’ll break down what changes, when it applies, who it affects, and what you must do if you distribute PHP as part of your product.
What exactly is changing?
PHP plans to unify its historically split licensing. Both the PHP license and the Zend Engine license are intended to move to the Modified BSD / BSD-3-Clause model (as new versions of the respective licenses).
This is a licensing and ecosystem clean-up—not a technical migration. I do not expect any changes to runtime behavior, Composer, deployments, or hosting.
Who is affected—and who isn’t?
Most PHP developers (apps, APIs, client projects) will feel nothing. You don’t need to relicense your application code, and you’re not forced to open-source anything.
This matters if you ship PHP itself—meaning you distribute PHP binaries or source as part of a product, image, installer, appliance, or your own builds.
Usually not an issue
- You only run PHP on your servers
- You ship just your application code
- You consume Composer packages as usual
Pay attention here
- Docker images, appliances, on-prem bundles including PHP
- Installers/bundles that contain PHP binaries
- Your own PHP builds/forks, distributions, mirrors
When does it take effect?
The RFC states the change should be fully effective in the next PHP 8.x release. In practice, it becomes relevant as soon as you distribute PHP versions that are shipped under the new license text.
What do you need to watch for? (Checklist)
If you distribute PHP (or parts of it), BSD-3-Clause is straightforward. This is what I follow:
- Ship the license text: Include the license and copyright notices in your package/repo/artifact (e.g.,
LICENSEorNOTICE). - Applies to source and binaries: If you ship only binaries/containers, the notices must still “travel with” the distribution (e.g., inside the image, docs, or an about section).
- No endorsement marketing: Don’t write copy that implies your product is officially endorsed by PHP/Zend/core contributors without explicit permission.
- Third-party stays third-party: Extensions, OS packages, and bundled libraries have their own licenses—keep tracking them separately.
- Your license stays yours: PHP does not impose a license on your application code. You can remain proprietary or choose any license you want.
Exceptions and common pitfalls
In practice, compliance issues usually come from messy distribution, not from BSD itself:
- Containers without license files: The build works, but the artifact lacks a proper license folder or documentation reference.
- Bundles with many components: PHP is only one part; web servers, OS libraries, PECL extensions often create the real blind spots.
- Over-eager marketing lines: “Officially recommended by…” is risky even when you mean well.
What happens if you ignore it?
If you distribute PHP and omit notices, you create compliance risk: customer questions, blockers in legal/security reviews, and potential rework or re-release of artifacts. It’s rarely catastrophic—but it’s always avoidable friction, especially in enterprise settings.
My recommendation
If you don’t distribute PHP: do nothing. Just keep an eye on when the new license text appears in the PHP versions you use.
If you do distribute PHP: add a minimal compliance routine now—license folder in the artifact, a build-time check, and one documentation line. Done.
