The PHP License, Simplified

I’ve been fascinated with copyright since high school and with open source licensing for most of my career. Yes, I’m a nerd, but I really do find it compelling to think about how humans communicate ideas—through words, songs, photographs, videos, and even code—and claim ownership over these products of the mind. Copyright is how we do that, and licensing is one of the tools we use to share what we create. So, when Matthew Sheahan posted a question to the php-general mailing list in early 2020, just as COVID-19 lockdowns were taking hold, it caught my attention.

Matthew’s team needed to use phpdbg, but their organization required OSI-approved licenses, and “the fact that 3.0 and 3.01 are substantively identical is no use to us at all.” While the PHP website said the PHP License 3.01 was OSI-approved, the OSI’s own said otherwise. Only version 3.0 had been formally approved. 3.01 was a minor version bump, nearly identical to 3.0, but that didn’t matter when company policy required it be listed on the OSI website. Since copyright and licensing is an interest of mine, I figured this was a way I could contribute to the PHP project, so I volunteered. I contacted the OSI to request legacy approval for 3.01, and the OSI Board voted to approve it in May 2020. Problem solved.

I figured this was a way I could contribute to the PHP project, so I volunteered.

But that planted a seed. Looking closely at the PHP License and the Zend Engine License, I saw two well-intentioned licenses that included increasingly awkward provisions; they were showing their age. The PHP project had been using its own custom license since PHP 3, when Rasmus Lerdorf adapted it from the Apache License, version 1.0, with modifications. The Zend Engine License came along with PHP 4, covering sources in the Zend/ directory. Each license contained conditions specific to their respective custodians—restrictions on using the names “PHP” and “Zend,” an advertising acknowledgment clause, and provisions granting only the PHP Group and Zend Technologies the authority to change the licenses.

After 25 years of cohabitation within the same source code repository, [PHP and the Zend Engine] are intertwined in ways in which the Zend Engine can no longer be separated and used as a standalone product. Together, they form the PHP programming language reference implementation.

— PHP License Update RFC

These weren’t bad licenses. Most developers, distributors, and companies accepted their intent and moved on. But gaps between intent and substance have a way of accumulating. The Zend Engine, once imagined as a separable product, had been inextricably bound to PHP for 25 years; the notion that it required its own license had become a historical artifact. Condition 4 of the PHP License—restricting derived products from calling themselves “PHP”—created real ambiguity for Linux distributions like Debian, which patch and redistribute PHP. Neither license was GPL-compatible, and the Zend Engine License had never been OSI-approved. Yet strip away the PHP Group-specific and Zend-specific conditions from both licenses, and what remains is effectively the Modified BSD License, otherwise known as BSD-3-Clause.

So, that is now the PHP License, version 4, and the Zend Engine License, version 3. Not a custom adaptation. Not a derivative. The actual BSD-3-Clause license, with its SPDX identifier, recognized by the OSI, the FSF, and every major piece of licensing tooling in use today. It’s compatible with the GPL. There are no advertising requirements, no restrictions that only a single organization can invoke, no ambiguity for distributors.

The rights granted by contributors have not changed. The rights granted to users have not changed. The new licenses are fully compatible with the old ones. This is a simplification and nothing more.

Getting here required more than writing an RFC. The PHP License gives the PHP Group the authority to change it, which meant tracking down each of the original PHP Group members and getting their written consent. Each approved the proposal. Perforce Software, the successor to Zend Technologies, needed to sign off on the Zend Engine side, as well. They provided a formal letter confirming their full authority and support for the change. I hired an attorney to review the proposal and provide advice on any legal questions that might surface during the discussion period. Speaking of which, I allowed for a six-month community discussion period preceding the vote, which passed unanimously.

Now, if you’re using software licensed under the PHP License 3.01, clause 5 of that license allows you to use the same software under the new version. If you maintain a PECL extension or any other project licensed under PHP License 3.01, clause 5 of that license allows you to adopt the new version. The same permissive spirit that covered your project before still covers it.

Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group.

— The PHP License, version 3.01, clause 5

If your organization has a policy requiring use of OSI-approved licensed open source software, or if you’ve had to explain away the Zend Engine License’s non-approved status to a compliance review, those conversations are over. And if you’ve simply never thought about this because it didn’t affect you, that’s fine too. It’s worth knowing the licenses exist, they’ve been updated, and PHP’s legal foundations now match the spirit of the language and community.

There are many people to thank for seeing this through: the members of the PHP internals community who engaged with the RFC over a long discussion period, the members of the PHP Group—Thies, Stig, Shane, Andi, Rasmus, Sam, Sascha, Zeev, Jim, and Andrei—who each took the time to respond to my messages, Perforce Software—and especially Matthew Weier O’Phinney and Sara Kilian—for their support and cooperation, Zak Greant, the debian-legal and OSI license-discuss mailing lists, the FSF Licensing & Compliance Team, and Pamela Chestek of Chestek Legal. Open source licensing is unglamorous, but it matters, and I’m glad to have had a part in this.