# [RFC] Updating the PHP License - Thread: https://externals.io/message/127984 - Original archive: https://news-web.php.net/php.internals/127984 - Started by Ben Ramsey on 2025-07-10T03:22:58+00:00 - Messages: 22 - RFC: PHP License Update (Accepted) — https://externals.io/rfc/php_license_update.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #127984 — Ben Ramsey — 2025-07-10T03:22:58+00:00 URL: https://externals.io/message/127984#127984 Hello internals, I’m opening discussion on an RFC proposing that we relicense PHP under the Modified BSD License (SPDX identifier: BSD-3-Clause), starting with PHP 9.0. This change simplifies and modernizes our licensing, addressing long-standing issues while preserving the rights of both contributors and users. Below is a quick summary of what the RFC proposes and what it means for developers. - Proposes that PHP 9.0 adopt the Modified BSD License (BSD-3-Clause), replacing the current PHP and Zend Engine licenses. - The Modified BSD License is OSI-approved, GPL-compatible, and widely recognized in the open source community. - Your rights as a developer—use, modification, distribution—remain unchanged. - Extensions and tools may adopt BSD-3-Clause in place of the outdated PHP License. - The update removes confusing legacy clauses tied to branding and permissions. I’ve spoken with all members of the PHP Group, and each has voiced their approval of this proposal. The Perforce legal team has also informally approved, and I will be working with them to get a formal letter of approval soon. The RFC is available at: https://wiki.php.net/rfc/php_license_update Discussion will remain open for at least six months to ensure all interested parties have an opportunity to respond. Cheers, Ben P.S. For legal questions or concerns, I’m working with Pamela Chestek of Chestek Legal on behalf of the PHP Group. You may be familiar with her work as chair of the license committee for the Open Source Initiative. --- ## #127990 — Gina P. Banyard — 2025-07-10T11:08:07+00:00 URL: https://externals.io/message/127984#127990 · In reply to: #127984 > Hello internals, > > I’m opening discussion on an RFC proposing that we relicense PHP under > the Modified BSD License (SPDX identifier: BSD-3-Clause), starting with > PHP 9.0. Hello Ben, Thank you for tackling this thorny issue, I sincerely appreciate the work you've put into this over the years. Even if you don't need individual contributors to grant permission, I will still say that: I fully accept the relicensing of all of my code contributions to php-src to the BSD-3-Clause. Best regards, Gina P. Banyard --- ## #127996 — Larry Garfield — 2025-07-10T14:01:02+00:00 URL: https://externals.io/message/127984#127996 · In reply to: #127984 > Hello internals, > > I’m opening discussion on an RFC proposing that we relicense PHP under > the Modified BSD License (SPDX identifier: BSD-3-Clause), starting with > PHP 9.0. This change simplifies and modernizes our licensing, > addressing long-standing issues while preserving the rights of both > contributors and users. Below is a quick summary of what the RFC > proposes and what it means for developers. > > - Proposes that PHP 9.0 adopt the Modified BSD License (BSD-3-Clause), > replacing the current PHP and Zend Engine licenses. > - The Modified BSD License is OSI-approved, GPL-compatible, and widely > recognized in the open source community. > - Your rights as a developer—use, modification, distribution—remain > unchanged. > - Extensions and tools may adopt BSD-3-Clause in place of the outdated > PHP License. > - The update removes confusing legacy clauses tied to branding and > permissions. > > I’ve spoken with all members of the PHP Group, and each has voiced their > approval of this proposal. The Perforce legal team has also informally > approved, and I will be working with them to get a formal letter of > approval soon. > > The RFC is available at: https://wiki.php.net/rfc/php_license_update > > Discussion will remain open for at least six months to ensure all > interested parties have an opportunity to respond. > > Cheers, > Ben > > P.S. For legal questions or concerns, I’m working with Pamela Chestek > of Chestek Legal on behalf of the PHP > Group. You may be familiar with her work as chair of the license > committee for the Open Source Initiative. This is long overdue and very welcome. Thank you, Ben! --Larry Garfield --- ## #128015 — Peter Kokot — 2025-07-12T09:18:56+00:00 URL: https://externals.io/message/127984#128015 · In reply to: #127984 > Hello internals, > > I’m opening discussion on an RFC proposing that we relicense PHP under > the Modified BSD License (SPDX identifier: BSD-3-Clause), starting with > PHP 9.0. This change simplifies and modernizes our licensing, > addressing long-standing issues while preserving the rights of both > contributors and users. Below is a quick summary of what the RFC > proposes and what it means for developers. > > - Proposes that PHP 9.0 adopt the Modified BSD License (BSD-3-Clause), > replacing the current PHP and Zend Engine licenses. > - The Modified BSD License is OSI-approved, GPL-compatible, and widely > recognized in the open source community. > - Your rights as a developer—use, modification, distribution—remain > unchanged. > - Extensions and tools may adopt BSD-3-Clause in place of the outdated > PHP License. > - The update removes confusing legacy clauses tied to branding and > permissions. > > I’ve spoken with all members of the PHP Group, and each has voiced their > approval of this proposal. The Perforce legal team has also informally > approved, and I will be working with them to get a formal letter of > approval soon. > > The RFC is available at: https://wiki.php.net/rfc/php_license_update > > Discussion will remain open for at least six months to ensure all > interested parties have an opportunity to respond. > > Cheers, > Ben > > P.S. For legal questions or concerns, I’m working with Pamela Chestek > of Chestek Legal on behalf of the PHP > Group. You may be familiar with her work as chair of the license > committee for the Open Source Initiative. > Sounds great. I'm sure this was a lot of work involved. Thank you. I'd just have two questions here that are popping up to things I've encountered lately: 1. TSRM (Thread Safe Resource Manager) also has a separate LICENSE file but it is BSD 2 Clause, which is compatible with all of that, I assume. That should be also simplified in some way? Perhaps integrating TSRM into Zend Engine directly at some point or updating its license to 3 clause BSD? 2. To be more clear, the GPL compatibility would probably need to be just slightly clarified to make PHP usage simpler in the future for cases when GPL-licensed software is involved. PHP currently has option to link to two GPL-3 licensed libraries that cause issues when distributing PHP (for example, packaging PHP and providing it as a binary via some package and similar): - GNU readline library for ext/readline (here libedit alternative can be used) https://github.com/php/php-src/issues/16826 - GDBM for ext/dba (here other handlers can be used) https://github.com/php/php-src/issues/15882 So, GPL-compatibility here means that PHP licensed under the Modified BSD License could link to GNU Readline library but it should be relicensed as GPL-3 then? Because I'm thinking of deprecating linking options with GNU Readline and GDBM to make the PHP build process worry-free for packagers. --- ## #128016 — Ben Ramsey — 2025-07-12T19:33:17+00:00 URL: https://externals.io/message/127984#128016 · In reply to: #128015 > > > > > […] > > Sounds great. I'm sure this was a lot of work involved. Thank you. > > I'd just have two questions here that are popping up to things I've encountered lately: > > 1. TSRM (Thread Safe Resource Manager) also has a separate LICENSE file but it is BSD 2 Clause, which is compatible with all of that, I assume. That should be also simplified in some way? Perhaps integrating TSRM into Zend Engine directly at some point or updating its license to 3 clause BSD? The license that applies to TSRM should remain the same. For one, it’s already under a widely-accepted and permissive OSI-approved license. Secondly, I think changing it would require approval from all contributors: 1. The license on TSRM doesn’t explicitly reserve the right for anyone to change the license (the PHP License and Zend Engine Licenses do), so no one can unilaterally change the license. 2. Changing from BSD-2-Clause to BSD-3-Clause adds more restrictions to the terms authors have granted by including the 3rd clause (i.e., “Neither the name of the copyright holder…”). So, the authors would need to approve of these additional restrictions added to the use of their contributions. There are only about 70 contributors to TSRM, so getting approvals wouldn’t be too hard, but I also don’t think it’s necessary to change the license on it. It looks like TSRM was originally written with the intention of being a standalone library that could be used apart from PHP, which is why it was contributed under a different license. > 2. To be more clear, the GPL compatibility would probably need to be just slightly clarified to make PHP usage simpler in the future for cases when GPL-licensed software is involved. > > PHP currently has option to link to two GPL-3 licensed libraries that cause issues when distributing PHP (for example, packaging PHP and providing it as a binary via some package and similar): > - GNU readline library for ext/readline (here libedit alternative can be used) > https://github.com/php/php-src/issues/16826 > - GDBM for ext/dba (here other handlers can be used) > https://github.com/php/php-src/issues/15882 > > So, GPL-compatibility here means that PHP licensed under the Modified BSD License could link to GNU Readline library but it should be relicensed as GPL-3 then? > > Because I'm thinking of deprecating linking options with GNU Readline and GDBM to make the PHP build process worry-free for packagers. I’m not sure what you mean by “GPL compatibility would probably need to be just slightly clarified to make PHP usage simpler.” The FSF considers the Modified BSD License as compatible with the GPL.[^1] They elaborate on what they mean by compatibility: “It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program. “All GNU GPL versions permit such combinations privately; they also permit distribution of such combinations provided the combination is released under the same GNU GPL version.”[^2] Being licensed under the Modified BSD License means that PHP may be combined with GPL-licensed software and released together with that software, as long as the *combination* is released under the terms of the GPL. For those who are packaging PHP and linking against GPL libraries, the current PHP License, version 3.01, presents an incompatibility that cannot be resolved because of the additional restrictions it places on users.[^3] However, under the Modified BSD License, there is no incompatibility, as long as the combined package is released under the terms of the GPL. Example: if I create a PHP package that links against Readline (whether statically or dynamically) the GPL considers this a combined work, and I must release the combination under the terms of the same version of the GPL that covers Readline.[^4] Does that clear things up? Cheers Ben [^1]: https://www.gnu.org/licenses/license-list.html#ModifiedBSD [^2]: https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean [^3]: https://www.gnu.org/licenses/license-list.html#PHP-3.01 [^4]: https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic --- ## #128036 — Derick Rethans — 2025-07-14T13:13:43+00:00 URL: https://externals.io/message/127984#128036 · In reply to: #127984 > The RFC is available at: https://wiki.php.net/rfc/php_license_update > > Discussion will remain open for at least six months to ensure all > interested parties have an opportunity to respond. Thanks for tackling this. Licensing issues can be thorny. I only really have one comment — why wait until (specifically) PHP 9, and not PHP-next (the one after 8.5)? cheers, Derick --- ## #128041 — Ben Ramsey — 2025-07-14T17:41:42+00:00 URL: https://externals.io/message/127984#128041 · In reply to: #128036 > > > > > > […] > > Thanks for tackling this. Licensing issues can be thorny. > > I only really have one comment — why wait until (specifically) PHP 9, > and not PHP-next (the one after 8.5)? > > cheers, > Derick I don’t think there are any technical or legal reasons for this. When I began discussing this with others a few years ago, the next major version (PHP 9) seemed like the right time to make a major licensing change. If others think PHP-next (i.e., either 8.6 or 9.0, whichever comes first) is the right version for this change, then I’m okay with that. Cheers, Ben --- ## #129421 — tim@bastelstu.be — 2025-11-23T23:10:50+00:00 URL: https://externals.io/message/127984#129421 · In reply to: #127984 Hi > The RFC is available at: https://wiki.php.net/rfc/php_license_update > > Discussion will remain open for at least six months to ensure all > interested parties have an opportunity to respond. With the new policy in https://wiki.php.net/rfc/rfc_discussion_and_vote, RFCs are considered inactive after 42 days to ensure that the discussion is fresh. The long discussion period on this RFC will not help anyone if the thread is already buried my several other RFCs and folks already forgot about it. I'm thus using the opportunity to bump this discussion to the top of the inbox and to also note that the new policy very strongly encourages that the final voting widgets are added early to an RFC (since the addition of a voting widget is considered a Major Change). Don't forget to include the “Abstain” option. Best regards Tim Düsterhus --- ## #129445 — Ben Ramsey — 2025-11-25T02:00:14+00:00 URL: https://externals.io/message/127984#129445 · In reply to: #129421 > Hi > > > > […] > > With the new policy in https://wiki.php.net/rfc/rfc_discussion_and_vote, > RFCs are considered inactive after 42 days to ensure that the discussion > is fresh. The long discussion period on this RFC will not help anyone if > the thread is already buried my several other RFCs and folks already > forgot about it. > > I'm thus using the opportunity to bump this discussion to the top of the > inbox and to also note that the new policy very strongly encourages that > the final voting widgets are added early to an RFC (since the addition > of a voting widget is considered a Major Change). Don't forget to > include the “Abstain” option. > > Best regards > Tim Düsterhus Thanks, Tim, for bumping this thread. I've updated the RFC to include the voting widget, including the Abstain option. So far, I think the only substantial bit of feedback comes from Derick: > I only really have one comment — why wait until (specifically) PHP 9, > and not PHP-next (the one after 8.5)? My response was: > I don't think there are any technical or legal reasons for for this. > When I began discussing this with others a few years ago, the next > major version (PHP 9) seemed like the right time to make a major > licensing change. > > If others think PHP-next (i.e., either 8.6 or 9.0, whichever comes > first) is the right version for this change, then I'm okay with that. What do others think? Should this be for PHP 8.6, or should it wait until PHP 9.0? According to the original timeline for this, I plan to open voting for this in early January, and according to the new RFC policy, I'll ensure the discussion is active with the proper cool-down period before I open voting. Cheers, Ben --- ## #129446 — Andreas Heigl — 2025-11-25T08:10:30+00:00 URL: https://externals.io/message/127984#129446 · In reply to: #129445 Hey all > > > […] > > > Thanks, Tim, for bumping this thread. > > I've updated the RFC to include the voting widget, including the Abstain > option. > > So far, I think the only substantial bit of feedback comes from Derick: > > > […] > > My response was: > > > […] > > What do others think? Should this be for PHP 8.6, or should it wait > until PHP 9.0? IMO a licence change is a BC break and should therefore wait until PHP9. Besides that personally I have no issue in moving to the new licence with PHP.next as the new licence is essentially the old one. The people that will get caught with the nitty-gritty details of the licence-changes will probably not care and for everyone else it provides a cleaner licence. So from my side: PHP.next Cheers Andreas -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +---------------------------------------------------------------------+ --- ## #129457 — tim@bastelstu.be — 2025-11-25T22:09:45+00:00 URL: https://externals.io/message/127984#129457 · In reply to: #129445 Hi > According to the original timeline for this, I plan to open voting for > this in early January, and according to the new RFC policy, I'll ensure > the discussion is active with the proper cool-down period before I open > voting. Please note the end-of-year holiday period that ends January 10th. It would therefore more likely be “middle of January” at the earliest. As for the RFC itself, I'm intentionally abstaining from having an opinion (and will also Abstain in the vote itself), as this is a legal matter not a technical matter with the latter being where my main expertise lies :-) Best regards Tim Düsterhus --- ## #129469 — Ben Ramsey — 2025-11-28T20:18:25+00:00 URL: https://externals.io/message/127984#129469 · In reply to: #129457 > Hi > > > > […] > > Please note the end-of-year holiday period that ends January 10th. It > would therefore more likely be “middle of January” at the earliest. > > As for the RFC itself, I'm intentionally abstaining from having an > opinion (and will also Abstain in the vote itself), as this is a legal > matter not a technical matter with the latter being where my main > expertise lies :-) > > Best regards > Tim Düsterhus Sorry for not being specific. I tend to think of January 10 as part of "early January." I'll open voting at some point _after_ January 10. Cheers, Ben --- ## #129470 — Ben Ramsey — 2025-11-28T20:24:02+00:00 URL: https://externals.io/message/127984#129470 · In reply to: #127984 > Hello internals, > > I’m opening discussion on an RFC proposing that we relicense PHP under > the Modified BSD License (SPDX identifier: BSD-3-Clause), starting with > PHP 9.0. This change simplifies and modernizes our licensing, > addressing long-standing issues while preserving the rights of both > contributors and users. Below is a quick summary of what the RFC > proposes and what it means for developers. > > - Proposes that PHP 9.0 adopt the Modified BSD License (BSD-3-Clause), > replacing the current PHP and Zend Engine licenses. > - The Modified BSD License is OSI-approved, GPL-compatible, and widely > recognized in the open source community. > - Your rights as a developer—use, modification, distribution—remain > unchanged. > - Extensions and tools may adopt BSD-3-Clause in place of the outdated > PHP License. > - The update removes confusing legacy clauses tied to branding and > permissions. > > I’ve spoken with all members of the PHP Group, and each has voiced their > approval of this proposal. The Perforce legal team has also informally > approved, and I will be working with them to get a formal letter of > approval soon. > > The RFC is available at: https://wiki.php.net/rfc/php_license_update > > Discussion will remain open for at least six months to ensure all > interested parties have an opportunity to respond. > > Cheers, > Ben > > P.S. For legal questions or concerns, I’m working with Pamela Chestek > of Chestek Legal on behalf of the PHP > Group. You may be familiar with her work as chair of the license > committee for the Open Source Initiative. The only feedback I've received thus far regards the proposed PHP version. After thinking on it a bit, I agree with changing the proposed PHP version from 9.0 to the next version of PHP, whether that's 8.6 or 9.0. I've updated the RFC to reflect this. Additionally, the RFC includes links to patches for php-src and web-php, in case anyone would like to review the changes and help catch areas I might have missed. ;-) * php-src: https://github.com/php/php-src/compare/master...ramsey:php-src:php-license-update * web-php: https://github.com/php/web-php/compare/master...ramsey:web-php:php-license-update Cheers, Ben --- ## #129471 — Jakub Zelenka — 2025-11-28T21:38:07+00:00 URL: https://externals.io/message/127984#129471 · In reply to: #129470 Hi, > > > […] I read it through and it's really nice! +1 on this. I already started using BSD License for some of the new stream changes - we are not required to use PHP license and other licenses are already contained in it - mainly BSD (e.g. FPM) and Apache. FPM is actually 2-Clause BSD: https://github.com/php/php-src/blob/php-8.5.0/sapi/fpm/LICENSE . It might make sense to cover it in the RFC and update it to 3-Clause as well maybe? Also we should add headers with SPDX tag to its files where it's missing completely - see https://github.com/php/php-src/blob/php-8.5.0/sapi/fpm/fpm/fpm.c#L1 for example. Assuming that it's fine to change it because the project is under that license..? > > > […] It would be good to get this stored somewhere so we have got proof of it. It can be done privately but the point is that more people would have access in case it is ever needed and you are not available. It could be slightly clearer in the RFC that you have already all approvals from PHP Group members - it just talks about how many of them might be needed and then list them as approved without saying that it is all covered. I guess the vote can start without the formal approval from Perforce but the actual change should wait for it. > > […] > > The only feedback I've received thus far regards the proposed PHP > version. After thinking on it a bit, I agree with changing the proposed > PHP version from 9.0 to the next version of PHP, whether that's 8.6 or > 9.0. I've updated the RFC to reflect this. > > You should just target just PHP 8.6 which is the automatic next version unless there is an RFC that would change it to 9.0. Kind regards, Jakub --- ## #129472 — Ben Ramsey — 2025-11-29T00:19:29+00:00 URL: https://externals.io/message/127984#129472 · In reply to: #129471 > I read it through and it's really nice! +1 on this. I already > started using BSD License for some of the new stream changes - we > are not required to use PHP license and other licenses are already > contained in it - mainly BSD (e.g. FPM) and Apache. This is true, if you contribute code to php-src, you can place your contributions under the terms of a different license, if you like. Even parts of files can be licensed differently, as long as they don't conflict. Typically, this isn't a problem if using any of the BSD-style or MIT-style licenses together, since they all amount to about the same (at least, in intent). For the sake of consistency and to alleviate confusion, it makes most sense to stick with the 3-Clause BSD for new PHP source code, though, unless we're borrowing the code from another project, where it already has it's own licensing terms. > FPM is actually 2-Clause BSD: https://github.com/php/php-src/blob/ > php-8.5.0/sapi/fpm/LICENSE . It might make sense to cover it in the > RFC and update it to 3-Clause as well maybe? Peter asked the same about TSRM, and I don't think it makes sense to update the code under these licenses to the 3-Clause BSD. For one, the 3-Clause BSD adds a new restriction, which any copyright-holding authors might object to, so you'd need their approval. As I've gone at length to show in the RFC, the 3.01 version of the PHP License doesn't have this problem, since the statements being removed aren't rights any contributors (other than The PHP Group or Zend) can enforce, so we're not adding to or taking away from any of terms copyright authors can assert. > Also we should add headers with SPDX tag to its files where it's > missing completely - see https://github.com/php/php-src/blob/ > php-8.5.0/sapi/fpm/fpm/fpm.c#L1 for example. Assuming that it's fine > to change it because the project is under that license..? I'll have a follow up PR to add SPDX tags and SBOM information and codes to the rest of the code base, once this is passed and merged. There's quite a bit of work involved for that, and I didn't want it to get all jumbled together with the license change. > > […] > > > It would be good to get this stored somewhere so we have got proof > of it. It can be done privately but the point is that more people > would have access in case it is ever needed and you are not > available. > > It could be slightly clearer in the RFC that you have already all > approvals from PHP Group members - it just talks about how many of > them might be needed and then list them as approved without saying > that it is all covered. > > I guess the vote can start without the formal approval from Perforce > but the actual change should wait for it. Good points. I'll put together the email threads with relevant headers, etc. in a format that's sharable. Cheers, Ben --- ## #129750 — Ben Ramsey — 2026-01-11T05:04:20+00:00 URL: https://externals.io/message/127984#129750 · In reply to: #127984 > Hello internals, > > I’m opening discussion on an RFC proposing that we relicense PHP under > the Modified BSD License (SPDX identifier: BSD-3-Clause), starting with > PHP 9.0. This change simplifies and modernizes our licensing, > addressing long-standing issues while preserving the rights of both > contributors and users. Below is a quick summary of what the RFC > proposes and what it means for developers. > > - Proposes that PHP 9.0 adopt the Modified BSD License (BSD-3-Clause), > replacing the current PHP and Zend Engine licenses. > - The Modified BSD License is OSI-approved, GPL-compatible, and widely > recognized in the open source community. > - Your rights as a developer—use, modification, distribution—remain > unchanged. > - Extensions and tools may adopt BSD-3-Clause in place of the outdated > PHP License. > - The update removes confusing legacy clauses tied to branding and > permissions. > > I’ve spoken with all members of the PHP Group, and each has voiced their > approval of this proposal. The Perforce legal team has also informally > approved, and I will be working with them to get a formal letter of > approval soon. > > The RFC is available at: https://wiki.php.net/rfc/php_license_update > > Discussion will remain open for at least six months to ensure all > interested parties have an opportunity to respond. > > Cheers, > Ben > > P.S. For legal questions or concerns, I’m working with Pamela Chestek > of Chestek Legal on behalf of the PHP > Group. You may be familiar with her work as chair of the license > committee for the Open Source Initiative. I'm following up with a reminder that this RFC is still under discussion. I've just made the following changes to the text of the RFC: - As requested, I've compiled an email thread all members of the PHP Group participated in to voice approval of the proposal. I've linked to this document under the "Do We Require Permission From the PHP Group?" section, but for convenience, it is available here: https://static.ben.ramsey.dev/php/rfc/license-update/php-license-update-php-group-correspondence.pdf - I've opened pull requests to php-src and web-php that includes the patches that implement the proposed license changes. I've updated the links under the References > Patches section: - https://github.com/php/php-src/pull/20904 - https://github.com/php/web-php/pull/1762 - I changed the year "2025" to "2026" in the license text in the section "New LICENSE File." I've requested a formal document from Perforce agreeing to the license changes for the Zend Engine License, and I'm waiting to hear back from them. Once I have that, I'll update the RFC to include a link to that document. I won't announce a vote before then (and, of course, I'll follow the cooldown rules for feature proposals). Cheers, Ben --- ## #130184 — Ben Ramsey — 2026-02-27T04:47:30+00:00 URL: https://externals.io/message/127984#130184 · In reply to: #127984 > > > […] > > > I'm following up with a reminder that this RFC is still under > discussion. I've just made the following changes to the text of the RFC: > > - As requested, I've compiled an email thread all members of the PHP >   Group participated in to voice approval of the proposal. I've linked >   to this document under the "Do We Require Permission From the PHP >   Group?" section, but for convenience, it is available here: > > https://static.ben.ramsey.dev/php/rfc/license-update/php-license-update- > php-group-correspondence.pdf > > - I've opened pull requests to php-src and web-php that includes the >   patches that implement the proposed license changes. I've updated the >   links under the References > Patches section: > >   - https://github.com/php/php-src/pull/20904 >   - https://github.com/php/web-php/pull/1762 > > - I changed the year "2025" to "2026" in the license text in the section >   "New LICENSE File." > > I've requested a formal document from Perforce agreeing to the license > changes for the Zend Engine License, and I'm waiting to hear back from > them. Once I have that, I'll update the RFC to include a link to that > document. I won't announce a vote before then (and, of course, I'll > follow the cooldown rules for feature proposals). > > Cheers, > Ben > Hi all! I've made the following updates to the PHP License Update RFC: - The copyright name for Zend is now listed as "Zend Technologies Ltd., a subsidiary of Perforce Software, Inc.," except in cases where a shorter variant is warranted (e.g., the version output), where it is listed as "Zend by Perforce." - I've added an example of what the `php --version` output will look like following the license/copyright changes. - I've updated the RFC to include a link to the consent letter from Zend Technologies legal counsel. The important thing in this message is the link to the Zend consent letter: https://static.ben.ramsey.dev/php/rfc/license-update/zend-technologies-php-license-consent.pdf With this formal consent from Zend/Perforce, we are ready to proceed! Discussion has been formally open since July 10, 2025. You may find the full thread here: https://news-web.php.net/php.internals/127984 The last message posted to the mailing list was on January 11, which means 46 days have elapsed, and according to our policy, we must have a cool down period of at least 7 days prior to opening a vote, but due to the nature of this RFC, I'm allowing 14 days for any further questions, concerns, or general discussion before opening a vote. Unless there are significant issues raised in the meantime, I plan to open the vote on or shortly after March 13; I'll send an "intent to vote" message closer to that date. As a reminder, the RFC is available at https://wiki.php.net/rfc/php_license_update Cheers, Ben --- ## #130186 — tim@bastelstu.be — 2026-02-27T12:20:32+00:00 URL: https://externals.io/message/127984#130186 · In reply to: #130184 Hi Am 2026-02-27 05:47, schrieb Ben Ramsey: > The important thing in this message is the link to the Zend consent > letter: > > https://static.ben.ramsey.dev/php/rfc/license-update/zend-technologies-php-license-consent.pdf Thank you, this is great news. As for the two consent letters: Would it make sense to push the two PDFs (Perforce and PHP Group) to the policies repository at https://github.com/php/policies/ to make them permanently available to the PHP project (i.e. independent of your personal web host)? The policies repository is probably the most appropriate location to store them. Possibly in a “license” subdirectory that also contains a `license.rst` with instructions on how to correctly apply the license to newly created files (i.e. the “New X Source File Header” snippets from the RFC). Best regards Tim Düsterhus --- ## #130202 — Ben Ramsey — 2026-02-27T22:29:13+00:00 URL: https://externals.io/message/127984#130202 · In reply to: #130186 > Hi > > Am 2026-02-27 05:47, schrieb Ben Ramsey: > > […] > > Thank you, this is great news. > > As for the two consent letters: Would it make sense to push the two PDFs > (Perforce and PHP Group) to the policies repository at https:// > github.com/php/policies/ to make them permanently available to the PHP > project (i.e. independent of your personal web host)? The policies > repository is probably the most appropriate location to store them. > Possibly in a “license” subdirectory that also contains a `license.rst` > with instructions on how to correctly apply the license to newly created > files (i.e. the “New X Source File Header” snippets from the RFC). > > Best regards > Tim Düsterhus I planned to add the PDFs to the website, similar to how we keep an artifact of the original Zend Grant there: https://www.php.net/license/ZendGrant/index.php If you think the policies repo is a better place for these artifacts, then we can put them there instead. Cheers, Ben --- ## #130206 — tim@bastelstu.be — 2026-03-01T12:26:10+00:00 URL: https://externals.io/message/127984#130206 · In reply to: #130202 Hi Am 2026-02-27 23:29, schrieb Ben Ramsey: > I planned to add the PDFs to the website, similar to how we keep an > artifact of the original Zend Grant there: > > https://www.php.net/license/ZendGrant/index.php > > If you think the policies repo is a better place for these artifacts, > then we can put them there instead. No strong opinion either way, as long as the PDFs are permanently available in a location under the PHP project's control. I have a slight preference for the policies repository, though. Because I wasn't aware that the pages in the website were a thing and it would never have occurred me to look there rather than php-src itself or the policies repo. Best regards Tim Düsterhus --- ## #130274 — Ben Ramsey — 2026-03-08T20:17:17+00:00 URL: https://externals.io/message/127984#130274 · In reply to: #130206 > Hi > > Am 2026-02-27 23:29, schrieb Ben Ramsey: > > […] > > No strong opinion either way, as long as the PDFs are permanently > available in a location under the PHP project's control. I have a slight > preference for the policies repository, though. Because I wasn't aware > that the pages in the website were a thing and it would never have > occurred me to look there rather than php-src itself or the policies repo. > > Best regards > Tim Düsterhus Sounds good. Once accepted, I'll open a PR to the policies repository to add these PDFs, as well as the Zend Grant PDF. That will be a good, central place to keep track of them. Cheers, Ben --- ## #130275 — Ben Ramsey — 2026-03-08T20:23:26+00:00 URL: https://externals.io/message/127984#130275 · In reply to: #127984 > Hello internals, > > I’m opening discussion on an RFC proposing that we relicense PHP under > the Modified BSD License (SPDX identifier: BSD-3-Clause), starting with > PHP 9.0. This change simplifies and modernizes our licensing, > addressing long-standing issues while preserving the rights of both > contributors and users. Below is a quick summary of what the RFC > proposes and what it means for developers. > > - Proposes that PHP 9.0 adopt the Modified BSD License (BSD-3-Clause), > replacing the current PHP and Zend Engine licenses. > - The Modified BSD License is OSI-approved, GPL-compatible, and widely > recognized in the open source community. > - Your rights as a developer—use, modification, distribution—remain > unchanged. > - Extensions and tools may adopt BSD-3-Clause in place of the outdated > PHP License. > - The update removes confusing legacy clauses tied to branding and > permissions. > > I’ve spoken with all members of the PHP Group, and each has voiced their > approval of this proposal. The Perforce legal team has also informally > approved, and I will be working with them to get a formal letter of > approval soon. > > The RFC is available at: https://wiki.php.net/rfc/php_license_update > > Discussion will remain open for at least six months to ensure all > interested parties have an opportunity to respond. > > Cheers, > Ben > > P.S. For legal questions or concerns, I’m working with Pamela Chestek > of Chestek Legal on behalf of the PHP > Group. You may be familiar with her work as chair of the license > committee for the Open Source Initiative. Hi all! I intend to open the voting for the PHP License Update RFC on Friday, March 13. This serves as the "Intent to Vote" message. If there are any questions or concerns regarding the RFC, please raise them at this time, so I can clarify or make any changes, as needed. Cheers, Ben