The php.internals vote closed on April 4, and PHP 9.0 will ship under the 3-clause BSD license. The RFC, driven by Ben Ramsey, replaces both the PHP License v3.01 and the Zend Engine License v2.0 with a single, OSI-recognized, FSF-recognized, GPL-compatible permissive license that has been sitting on the shelf for thirty-five years. This is a good decision, and the only mildly interesting question is why it took this long.

What PHP was actually shipping

PHP has been distributed under two licenses since the Zend Engine landed in PHP 4. The bulk of the source — the runtime, extensions, the interpreter scaffolding — lives under the PHP License v3.01. The Zend/ directory lives under the Zend Engine License v2.0. The OSI recognizes the first one. It does not recognize the second. That means PHP, the canonical implementation of one of the most-deployed languages on the planet, has been shipping a substantial chunk of its own source code under a license that is not, by the OSI’s own definition, open source.

The PHP License itself is also a custom job. It contains a no-endorsement clause, a name-restriction clause (“Products derived from this software may not be called ‘PHP’…”), and a fair-use clause that gestures vaguely at “PHP” appearing in derivative names. Most of this exists for entirely defensible historical reasons — the project did not want a fork called PHP++ confusing everyone in 2002 — but it also means downstream packagers have spent two decades doing license-compatibility math against a license that almost nobody else uses. Distributions handle it. Lawyers don’t love it.

Why 3-clause BSD is the right pick

The 3-clause BSD license — sometimes called the Modified BSD License or New BSD License — is a permissive license that grants use, modification, and redistribution, requires that attribution be preserved in source and binary distributions, and prohibits using the names of contributors or the project to endorse derivative works without permission. That last clause does most of the work that PHP’s name-restriction clause was trying to do, only it does it in twenty-eight words that every IP lawyer on Earth has read before.

The 4-clause version, which famously included the obnoxious advertising clause (“All advertising materials mentioning features or use of this software must display the following acknowledgement…”), was retired by Berkeley itself in 1999 because nobody could keep track of all the names that had to appear in the acknowledgement. The 2-clause version drops the no-endorsement clause entirely. 3-clause splits the difference: short, permissive, attributive, with a sensible trademark-adjacent guardrail. It is the license you pick when you want to be done thinking about licenses.

That is what PHP just did. They are done thinking about licenses.

A digression about PostgreSQL

PostgreSQL ships under the PostgreSQL License, which is yet another custom permissive license — a couple of paragraphs derived from the BSD family that grants use, modification, distribution, and a no-warranty disclaimer, with no advertising clause, no name-restriction clause, and no endorsement clause. Functionally it is the 2-clause BSD with friendlier prose.

You might reasonably ask why we did not just use 2-clause BSD. The answer is that the license is older than that distinction settling out, predates a meaningful chunk of the OSI’s existence, and at this point the PostgreSQL Global Development Group is not going to relitigate something that has worked fine for thirty years. The license is well-understood by every distribution, every cloud vendor, and every legal department that has ever looked at it. It is not OSI-recognized as a named license, but the OSI considers it functionally equivalent to a permissive BSD/MIT-style license, and nobody has ever made a serious compliance argument otherwise.

PHP could have done what PostgreSQL did: keep the custom license, fix the broken parts, and rely on community goodwill plus three decades of consistent practice. They didn’t, and they were right not to. PostgreSQL got away with it because the license was always coherent, was always written by adults, and was always functionally a permissive BSD-style license. The PHP License plus the Zend License never had any of that going for it, and the moment a corporate legal team had to ask whether the Zend Engine License v2.0 was OSI-approved was the moment the whole arrangement was on borrowed time.

Why it matters

The trend across 2024–2026 has mostly been the other direction: projects abandoning OSI-approved licenses for source-available ones — Redis, HashiCorp, Elastic, MongoDB before them. PHP going the other way is a useful reminder that the gravitational pull of standard licenses works in both directions. If you are writing your own license today, in 2026, you almost certainly should not be. If you are still shipping software under a license written specifically for your project before the OSI was a going concern, the PHP RFC is a template. Find the closest standard license that does what your custom one does. Adopt it. Move on.

The PHP people just removed an entire category of licensing question from their packagers’ lives, in exchange for nothing more painful than a vote and a commit. If you maintain a project still on a custom license, the math is exactly the same.