PHP's licensing changed in 2026: starting with PHP 8.6, the language moved from the vendor-specific PHP License 3.01 to the plain Modified BSD (PHP License v4), dropping name restrictions and the special authority the PHP Group and Zend held over the license. Zend simultaneously simplified the Zend Engine License. The piece argues that these governance and sustainability facts, not language feature checklists, are what actually drive architecture decisions to adopt or keep PHP, covering ownership, release cadence, scaling, tooling maturity, and the makeup of the PHP developer pool, while also naming the real costs behind each: a shrinking pool of Foundation sponsors, an electorate of roughly 140 active RFC voters, unresolved in-request concurrency, and an aging population of experienced PHP developers with limited pipeline behind them.

14m read timeFrom phpunit.expert
Post cover image
Table of contents
Ownership: who can change the terms?Sustainability: the upgrade as a scheduled eventScale: the floor, not the achievementDelivery: fast is easy, sustainable is the requirementPractitioners: staffing as a non-functional requirementWhere this leaves us

Questions this post answers

What license does PHP use starting with PHP 8.6?

PHP 8.6 and later are distributed under PHP License version 4, which is the Modified BSD License (BSD-3-Clause) with nothing else attached. This drops the old PHP License 3.01's restrictions on using the names 'PHP' and 'Zend', its advertising acknowledgment clause, and the provision that only the PHP Group and Zend Technologies could publish a new license version. Zend Technologies made the equivalent change to the Zend Engine License at the same time. Teams weighing a decade-long bet on PHP can follow licensing and governance shifts like this on daily.dev.

How many people actually vote on PHP language change RFCs?

Roughly 140 people have voted on any PHP RFC in the preceding three years, out of about 1,650 accounts nominally eligible to vote, according to the draft Who Can Vote (2024) RFC. Every language change still requires a public RFC with a two-thirds majority vote, but the effective electorate deciding PHP's direction is a small, self-selected group of volunteers. Architects sizing up how community-governed languages evolve can track RFC and governance details via daily.dev.

What is the PHP version support and end-of-life schedule?

PHP ships one feature release per year in November, with each branch receiving two years of active support followed by two years of security fixes, a window extended from three years to four total in March 2024, with end-of-support dates aligned to December 31. For example, PHP 8.2 reaches end of life on December 31, 2026, a date that can be planned around years in advance. Planning PHP upgrade timelines gets easier when you follow version support changes on daily.dev.

7.3K Impressions