On 11/28/25 15:38, Jakub Zelenka wrote:
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.
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.
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.
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
Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc