It Was BSD All Along: Relicensing PHP After 30 Years
MCLD 2012 | Fri 07 Aug 11:45 a.m.–12:30 p.m.
Presented by
-
Ben Ramsey
@ramsey@phpc.social
https://ben.ramsey.dev
Ben is a seasoned software engineer with 25+ years of experience in web applications. As a Senior Staff Software Engineer at Intuit Mailchimp, he leads the API Core team managing the Mailchimp public API. A passionate advocate for open source, Ben is a PHP release manager, creator of the ramsey/uuid library, and an active community contributor. A prolific writer and speaker, he has contributed to books, articles, and conferences. Connect with him on the web at ben.ramsey.dev or on the Fediverse at @ramsey@phpc.social.
Ben Ramsey
@ramsey@phpc.social
https://ben.ramsey.dev
Ben is a seasoned software engineer with 25+ years of experience in web applications. As a Senior Staff Software Engineer at Intuit Mailchimp, he leads the API Core team managing the Mailchimp public API. A passionate advocate for open source, Ben is a PHP release manager, creator of the ramsey/uuid library, and an active community contributor. A prolific writer and speaker, he has contributed to books, articles, and conferences. Connect with him on the web at ben.ramsey.dev or on the Fediverse at @ramsey@phpc.social.
Abstract
In early 2020, someone asked a question on a PHP mailing list that I couldn't stop thinking about. Their employer only allowed OSI-approved licenses, and while php.net claimed the PHP License 3.01 was approved, the OSI's own website showed approval only for version 3.0. I volunteered to sort it out, and a few months later the OSI granted legacy approval for 3.01. But the question stuck with me, and the closer I looked, the stranger PHP's licensing history got.
PHP didn't always have its own license. It began under the GPL, became dual-licensed, then settled into the custom PHP and Zend Engine licenses it kept for over two decades. Neither was GPL-compatible; one was never OSI-approved. Yet strip away the conditions specific to the PHP Group and Zend, and what remains is, almost word for word, BSD-3-Clause. Making it official meant answering a question with no obvious answer: who has the authority to relicense a 30-year-old language whose contributors never signed an agreement?
This is the story of how I answered that question and steered the new license through, and what it taught me about copyright, license stewardship, and the distance between what a license intends and what it says. It's one project's story, not a how-to guide—every situation is different, and I'm not a lawyer—but PHP's is a strange and instructive one, and a window into how tangled software licensing can be.
In early 2020, someone asked a question on a PHP mailing list that I couldn't stop thinking about. Their employer only allowed OSI-approved licenses, and while php.net claimed the PHP License 3.01 was approved, the OSI's own website showed approval only for version 3.0. I volunteered to sort it out, and a few months later the OSI granted legacy approval for 3.01. But the question stuck with me, and the closer I looked, the stranger PHP's licensing history got.
PHP didn't always have its own license. It began under the GPL, became dual-licensed, then settled into the custom PHP and Zend Engine licenses it kept for over two decades. Neither was GPL-compatible; one was never OSI-approved. Yet strip away the conditions specific to the PHP Group and Zend, and what remains is, almost word for word, BSD-3-Clause. Making it official meant answering a question with no obvious answer: who has the authority to relicense a 30-year-old language whose contributors never signed an agreement?
This is the story of how I answered that question and steered the new license through, and what it taught me about copyright, license stewardship, and the distance between what a license intends and what it says. It's one project's story, not a how-to guide—every situation is different, and I'm not a lawyer—but PHP's is a strange and instructive one, and a window into how tangled software licensing can be.