Re: [PHP-DEV] [RFC] [Discussion] Final anonymous classes

[Daniil Gentili]

Hi,


Pick an approach and put that up for a vote,


Picked the basic option of just adding final anonymous classes & edited 
the RFC accordingly.


Thanks for the feedback!

Regards, Daniil Gentili.

Re: [PHP-DEV] [RFC] [Discussion] Final anonymous classes

[Larry Garfield]

On Fri, Dec 1, 2023, at 6:01 PM, Daniil Gentili wrote:
> Hi all,
>
> Heads up, I'll move this RFC 
> (https://wiki.php.net/rfc/final_anonymous_classes) to voting status 
> tomorrow!
>
> Regards,
>
> Daniil Gentili.

The way the vote is structured there is highly confusing.  Three separate 
primary votes, and then you'd plan a separate runoff RFC?  That... is 
needlessly complicated.

Pick an approach and put that up for a vote, or figure out how to structure it 
as a secondary vote.  Or make it a 4 item RCV vote (with one of the options 
being "do nothing").  There's a couple of ways to handle it, but the way it's 
written now is not it.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Final anonymous classes

[Daniil Gentili]

Hi all,

Heads up, I'll move this RFC 
(https://wiki.php.net/rfc/final_anonymous_classes) to voting status 
tomorrow!


Regards,

Daniil Gentili.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Change how JIT is disabled by default

[Daniil Gentili]

Hi all,

Heads up, I'll move this RFC 
(https://wiki.php.net/rfc/jit_config_defaults) to voting status tomorrow!


Regards,

Daniil Gentili.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Adding a donate link to the PHP website

[Larry Garfield]

On Fri, Dec 1, 2023, at 8:27 AM, Andreas Heigl wrote:
> Hey Ben
>
> On 01.12.23 01:04, Ben Ramsey wrote:
>>> On Nov 30, 2023, at 02:45, Andreas Heigl  wrote:
>>>
>>> On 30.11.23 09:39, James Titcumb wrote:
 On Thu, 30 Nov 2023 at 07:28, Andreas Heigl >>> > wrote:
>>> [...snip...]
 I suppose that is actually nothing that an RFC can do as I imagine that
 everyone from the PHP Group needs to support this and even an RFC
 wouldn't legally be able to change anything in regards to that.
 Surely, everyone who has contributed (i.e. has voting karma) has the 
 opportunity to vote, and therefore, if they choose not to vote, that is 
 surely their choice. I don't know the ins and outs of it, but I'd have 
 thought an RFC, well advertised, with plenty of time to ensure as many 
 people can vote who have rights to.
>>>
>>> What I meant by that is that the members of "The PHP Group" are currently 
>>> the copyright holders. From a legal point of view no RFC can change that. 
>>> The only way to change that would be for the PHP Group to transfer their 
>>> copyright to someone else. What an RFC *can* do though is *propose* that 
>>> the PHP Group transfers their copyright to the PHP Foundation.
>>>
>>> Though I'm lo lawyer, so ¯\_(ツ)_/¯
>> 
>> 
>> I have spoken at length with a lawyer about this, and the TL;DR version is 
>> that every contributor owns the copyright on their specific contributions, 
>> if the contributions are copyrightable. Some contributions (typo fixes, 
>> white space changes, etc.) aren’t copyrightable, but anything more 
>> significant that is the contributor’s own work belongs to them.
>> 
>> In other words, even though the license statement says the copyright belongs 
>> to The PHP Group[^1] or Zend Technologies Ltd.[^2], technically, these 
>> copyrights only apply to the specific code contributed by these 
>> organizations or contributed by people for these organizations (through 
>> work-for-hire or by legally transferring the copyright to them).
>> 
>> Contributing to an open source project is NOT an implicit transfer of your 
>> copyright to the project. To do this, every contributor needs to sign a CLA 
>> that specifies they are transferring their copyright to The PHP Group.
>> 
>> What is implied, however—and I’m told this is how most courts in the US and 
>> outside would view it—is assignment of license. When someone contributes to 
>> an open source project, they own the copyright on their contributions, but 
>> unless they specify a different license that covers their contributions, 
>> it’s implied that they are granting use of their contributions under the 
>> same license as the project. In this way, the contributor can’t later demand 
>> to have their copyrighted code removed; it’s under the terms of the same 
>> license, which can't be revoked.
>> 
>> Once a copyright statement is placed on a source file, there’s a bunch of 
>> legal reasons why you cannot change or remove that copyright statement. In 
>> general, you should keep all copyright statements added to a source file and 
>> never change one that already exists on a source file. Just look at the file 
>> header on any WebKit[^3] source file. WebKit even specifies that you add a 
>> copyright notice to each file where you make “significant” changes.[^4]
>> 
>> With this in mind, it would be more proper to update the general copyright 
>> notice to something like this:
>> 
>>  Copyright (c) 2023 and later, The PHP Foundation and contributors. All 
>> rights reserved.
>>  Copyright (c) 1999-2023, The PHP Group and contributors. All rights 
>> reserved.
>> 
>> Since no reassignment of copyright is taking place, we don’t run into any 
>> major legal issues, and this tells a true and accurate story. The PHP Group 
>> were stewards of the project until 2023, at which point the community 
>> recognized The PHP Foundation as the new stewards of the project, and 
>> through all of this time (since 1999), the various copyrights have been 
>> owned by their respective owners (i.e., contributors).
>> 
>> If you look at the file headers on ICU source code, you can see that 
>> Unicode, Inc. made a similar change in 2016.[^5]
>> 
>> All this said… I am in favor of making this change.
>> 
>> I also have a lot more to say on this, as I’ve been considering opening up 
>> an RFC on just this topic. I had intended to reach out to Zend first 
>> (through Matthew Weier O’Phinney), but I haven’t done that yet, so this is 
>> the first time anyone from Zend has seen these ideas. My apologies. :-)
>> 
>> The PHP source code is interesting in that it is covered by two licenses: 
>> the PHP License[^6] and the Zend Engine License.[^7] This is an historical 
>> artifact of the early days of PHP when it was conceivable that other 
>> companies might develop their own engines for PHP, but we know how this 
>> story ends: for all intents and purposes, the Zend Engine 

Re: [PHP-DEV] Adding a donate link to the PHP website

[Nicolas Grekas]

Hi Ben

> On Nov 30, 2023, at 02:45, Andreas Heigl  wrote:
> >
> > On 30.11.23 09:39, James Titcumb wrote:
> >> On Thu, 30 Nov 2023 at 07:28, Andreas Heigl  andr...@heigl.org>> wrote:
> > [...snip...]
> >>I suppose that is actually nothing that an RFC can do as I imagine
> that
> >>everyone from the PHP Group needs to support this and even an RFC
> >>wouldn't legally be able to change anything in regards to that.
> >> Surely, everyone who has contributed (i.e. has voting karma) has the
> opportunity to vote, and therefore, if they choose not to vote, that is
> surely their choice. I don't know the ins and outs of it, but I'd have
> thought an RFC, well advertised, with plenty of time to ensure as many
> people can vote who have rights to.
> >
> > What I meant by that is that the members of "The PHP Group" are
> currently the copyright holders. From a legal point of view no RFC can
> change that. The only way to change that would be for the PHP Group to
> transfer their copyright to someone else. What an RFC *can* do though is
> *propose* that the PHP Group transfers their copyright to the PHP
> Foundation.
> >
> > Though I'm lo lawyer, so ¯\_(ツ)_/¯
>
>
> I have spoken at length with a lawyer about this, and the TL;DR version is
> that every contributor owns the copyright on their specific contributions,
> if the contributions are copyrightable. Some contributions (typo fixes,
> white space changes, etc.) aren’t copyrightable, but anything more
> significant that is the contributor’s own work belongs to them.
>
> In other words, even though the license statement says the copyright
> belongs to The PHP Group[^1] or Zend Technologies Ltd.[^2], technically,
> these copyrights only apply to the specific code contributed by these
> organizations or contributed by people for these organizations (through
> work-for-hire or by legally transferring the copyright to them).
>
> Contributing to an open source project is NOT an implicit transfer of your
> copyright to the project. To do this, every contributor needs to sign a CLA
> that specifies they are transferring their copyright to The PHP Group.
>
> What is implied, however—and I’m told this is how most courts in the US
> and outside would view it—is assignment of license. When someone
> contributes to an open source project, they own the copyright on their
> contributions, but unless they specify a different license that covers
> their contributions, it’s implied that they are granting use of their
> contributions under the same license as the project. In this way, the
> contributor can’t later demand to have their copyrighted code removed; it’s
> under the terms of the same license, which can't be revoked.
>
> Once a copyright statement is placed on a source file, there’s a bunch of
> legal reasons why you cannot change or remove that copyright statement. In
> general, you should keep all copyright statements added to a source file
> and never change one that already exists on a source file. Just look at the
> file header on any WebKit[^3] source file. WebKit even specifies that you
> add a copyright notice to each file where you make “significant”
> changes.[^4]
>
> With this in mind, it would be more proper to update the general copyright
> notice to something like this:
>
> Copyright (c) 2023 and later, The PHP Foundation and contributors. All
> rights reserved.
> Copyright (c) 1999-2023, The PHP Group and contributors. All rights
> reserved.
>
> Since no reassignment of copyright is taking place, we don’t run into any
> major legal issues, and this tells a true and accurate story. The PHP Group
> were stewards of the project until 2023, at which point the community
> recognized The PHP Foundation as the new stewards of the project, and
> through all of this time (since 1999), the various copyrights have been
> owned by their respective owners (i.e., contributors).
>
> If you look at the file headers on ICU source code, you can see that
> Unicode, Inc. made a similar change in 2016.[^5]
>
> All this said… I am in favor of making this change.
>
> I also have a lot more to say on this, as I’ve been considering opening up
> an RFC on just this topic. I had intended to reach out to Zend first
> (through Matthew Weier O’Phinney), but I haven’t done that yet, so this is
> the first time anyone from Zend has seen these ideas. My apologies. :-)
>
> The PHP source code is interesting in that it is covered by two licenses:
> the PHP License[^6] and the Zend Engine License.[^7] This is an historical
> artifact of the early days of PHP when it was conceivable that other
> companies might develop their own engines for PHP, but we know how this
> story ends: for all intents and purposes, the Zend Engine is PHP and PHP is
> the Zend Engine. Yes, I’m aware of alternatives (with very limited
> adoption), and no, they don’t matter for this discussion.
>
> Both the PHP License and Zend Engine License are based on the BSD 4-clause
> “Original” license,[^8] 

Re: [PHP-DEV] What is the prevailing sentiment about extract() and compact() ?

[Marco Pivetta]

Hey Juliette,

On Wed, 29 Nov 2023 at 03:00, Juliette Reinders Folmer <
php-internals_nos...@adviesenzo.nl> wrote:

>
> For now, I'm just wondering how people feel about these functions.
>

>From my PoV: burn them with fire.
The translation of `compact()` is **trivial** with a CS tool (like the one
you maintain), and the translation of `extract($vars)` is `foreach ($vars
as $k => $v) { $$k = $v; }`, and that's all there is.

Instead, both `compact()` and `extract()` come at additional cognitive load
when reading, scanning, analyzing, debugging and generally understanding
code: a flamethrower helps.

Meanwhile, I'm also wondering if the removal of such functions would help
more in future AOT and JIT improvements: I suppose code using `extract()`
and `compact()` would immediately defeat any JIT, or at least lead to added
code to handle them correctly?

There's a section describing this in HHVM, which is the kind of
problem-space I was thinking of:
https://hhvm.com/blog/713/hhvm-optimization-tips


Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/

Re: [PHP-DEV] [PDO] 2 phase commit

[Eugene Sidelnyk]

One thing I'd like to point out is regarding second phase (commit phase)

It's important to understand that once this phase has started, there's no
way back. After code execution is behind commit point, the transactions
MUST commit no matter what. Data must be committed regardless of network
issues even if such last for minutes.

Let's say we have two databases.

On the first phase we have asked them and received a confirmation of being
ready to commit.


Then second (Commit) phase starts:

1. We have sent commit to the first database and it responded us with OK
(comitted)
2. Next we send commit to the second database, and it may be the case that
in that very moment we lose connection. Hence, if connection is lost before
final commit request, second database won't receive commit, and since It's
not aware of whether transaction should be committed or rolled back, data
is never made persistent.

FWIK, this case is usually handled at the application level using async
commit in message consumers. Meaning commit operation will be retied again,
and again, and again until the connection is restored.

Therefore, commit point is the point of no-return and network issues is the
problem we have to deal with.

Do you have any ideas how to handle this case at the core level in the
regard of php lifecycle?

Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()

[Jakub Zelenka]

On Fri, Nov 24, 2023 at 12:31 AM Saki Takamachi  wrote:

> Hi internals,
>
> I started voting on my RFC "Change the edge case of round()”.
>
> Voting will end December 8th, 00:00 GMT.
>
> https://wiki.php.net/rfc/change_the_edge_case_of_round
>
>
I have been thinking about this one for a bit and I voted no at the end. I
would probably pick the new behaviour if designing a new function like this
but considering that it's been around for long time in this form, I don't
think it's worth to be changed as it introduces slight BC break that might
difficult to figure out. Also the old behaviour might be more intuitive for
users so it does not seem completely wrong to me to keep it.

Cheers

Jakub

Re: [PHP-DEV] Inconsistency mbstring functions

[youkidearitai]

2023年12月1日(金) 18:48 G. P. B. :
>
> On Fri, 1 Dec 2023 at 09:31, Stefan Schiller via internals <
> internals@lists.php.net> wrote:
>
> > Hi,
> >
> > I would like to raise attention to an inconsistency in how mbstring
> > functions handle invalid multibyte sequences. When, for example,
> > mb_strpos encounters a UTF-8 leading byte, it tries to parse the
> > following continuation bytes until the full byte sequence is read. If
> > an invalid byte is encountered, all previously read bytes are
> > considered one character, and the parsing is started over again at the
> > invalid byte. Let's consider the following example:
> >
> > mb_strpos("\xf0\x9fABCD", "B"); // int(2)
> >
> > The leading byte 0xf0 initiates a 4-byte UTF-8 sequence. The following
> > byte (0x9f) is a valid continuation byte. The next byte (0x41) is not
> > a valid continuation byte. Thus, 0xf0 and 0x9f are considered one
> > character, and 0x41 is regarded as another character. Accordingly, the
> > resulting index of "B" is 2.
> >
> > On the other hand, mb_substr, for example, simply skips over
> > continuation bytes when encountering a leading byte. Let's consider
> > the following example, which uses mb_substr to cut the first two
> > characters from the string used in the previous example:
> >
> > mb_substr("\xf0\x9fABCD", 2); // string(1) "D"
> >
> > Again, the leading byte 0xf0 initiates a 4-byte UTF-8 sequence. This
> > time, mb_substr just skips over the next three bytes and considers all
> > 4 bytes one character. Next, it continues to process at byte 0x43
> > ("C"), which is regarded as another character. Thus, the resulting
> > string is "D".
> >
> > This inconsistency in handling invalid multibyte sequences not only
> > exists between different functions but also affects single functions.
> > Let's consider the following example, which uses mb_strstr to
> > determine the first occurrence of the string "B" in the same string:
> >
> > mb_strstr("\xf0\x9fABCD", "B"); // string(1) "D"
> >
> > The principle is the same, just in a single function call.
> >
> > This inconsistency may not only lead to an unexpected behavior but can
> > also have a security impact when the affected functions are used to
> > filter input.
> >
> >
> > Best Regards,
> > Stefan Schiller
> >
> > [1]: https://www.php.net/manual/en/function.mb-strpos.php
> > [2]: https://www.php.net/manual/de/function.mb-substr.php
> > [3]: https://www.php.net/manual/de/function.mb-strstr.php
> >
>
> This might have been better to raise as a bug, but in any case I am CCing
> Alex who's the main maintainer of the mbstring extension so he's aware of
> this and can possibly provide some explanations.
>
> Best regards,
>
> Gina P. Banyard

Hi,

> >
> > I would like to raise attention to an inconsistency in how mbstring
> > functions handle invalid multibyte sequences. When, for example,
> > mb_strpos encounters a UTF-8 leading byte, it tries to parse the
> > following continuation bytes until the full byte sequence is read. If
> > an invalid byte is encountered, all previously read bytes are
> > considered one character, and the parsing is started over again at the
> > invalid byte. Let's consider the following example:
> >
> > mb_strpos("\xf0\x9fABCD", "B"); // int(2)

Yes, that's true. Because mb_strpos is convert to UTF-8 in internal.
However, other mbstring function is temporary convert to UTF-32, then
reconvert to original character encoding.

Anyway, I'll wait Alex's reply.

Regards
Yuya

-- 
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Inconsistency mbstring functions

[G. P. B.]

On Fri, 1 Dec 2023 at 09:31, Stefan Schiller via internals <
internals@lists.php.net> wrote:

> Hi,
>
> I would like to raise attention to an inconsistency in how mbstring
> functions handle invalid multibyte sequences. When, for example,
> mb_strpos encounters a UTF-8 leading byte, it tries to parse the
> following continuation bytes until the full byte sequence is read. If
> an invalid byte is encountered, all previously read bytes are
> considered one character, and the parsing is started over again at the
> invalid byte. Let's consider the following example:
>
> mb_strpos("\xf0\x9fABCD", "B"); // int(2)
>
> The leading byte 0xf0 initiates a 4-byte UTF-8 sequence. The following
> byte (0x9f) is a valid continuation byte. The next byte (0x41) is not
> a valid continuation byte. Thus, 0xf0 and 0x9f are considered one
> character, and 0x41 is regarded as another character. Accordingly, the
> resulting index of "B" is 2.
>
> On the other hand, mb_substr, for example, simply skips over
> continuation bytes when encountering a leading byte. Let's consider
> the following example, which uses mb_substr to cut the first two
> characters from the string used in the previous example:
>
> mb_substr("\xf0\x9fABCD", 2); // string(1) "D"
>
> Again, the leading byte 0xf0 initiates a 4-byte UTF-8 sequence. This
> time, mb_substr just skips over the next three bytes and considers all
> 4 bytes one character. Next, it continues to process at byte 0x43
> ("C"), which is regarded as another character. Thus, the resulting
> string is "D".
>
> This inconsistency in handling invalid multibyte sequences not only
> exists between different functions but also affects single functions.
> Let's consider the following example, which uses mb_strstr to
> determine the first occurrence of the string "B" in the same string:
>
> mb_strstr("\xf0\x9fABCD", "B"); // string(1) "D"
>
> The principle is the same, just in a single function call.
>
> This inconsistency may not only lead to an unexpected behavior but can
> also have a security impact when the affected functions are used to
> filter input.
>
>
> Best Regards,
> Stefan Schiller
>
> [1]: https://www.php.net/manual/en/function.mb-strpos.php
> [2]: https://www.php.net/manual/de/function.mb-substr.php
> [3]: https://www.php.net/manual/de/function.mb-strstr.php
>

This might have been better to raise as a bug, but in any case I am CCing
Alex who's the main maintainer of the mbstring extension so he's aware of
this and can possibly provide some explanations.

Best regards,

Gina P. Banyard

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

[G. P. B.]

On Fri, 1 Dec 2023 at 09:35, Jakub Zelenka  wrote:

> On Fri, Dec 1, 2023 at 9:28 AM G. P. B.  wrote:
>
>> On Thu, 30 Nov 2023 at 23:45, Jakub Zelenka  wrote:
>>
>>> Hi,
>>>
>>> On Thu, Nov 30, 2023 at 10:13 PM Jorg Sowa  wrote:
>>>

 Creating aliases for Intl extension constants has been accepted with 10
 votes yes and 6 votes no.


>>> This means that it is declined as you need 2/3 of votes to pass...
>>>
>>
>> This seems to be a secondary vote which only requires 50% of votes to be
>> accepted.
>>
>>
> Ah I see now. It's a bit strange to have a secondary vote about sort of
> unrelated thing in different extension but no one objected before or during
> the vote so let's keep it accepted.
>

I think so, however, I do agree that this was unclear, and we probably
should make sure future RFCs explicitly state if a vote is primary or not
and what the approval rate for the vote to be accepted should be.

Best regards,

Gina P. Banyard

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

[Jakub Zelenka]

On Fri, Dec 1, 2023 at 9:28 AM G. P. B.  wrote:

> On Thu, 30 Nov 2023 at 23:45, Jakub Zelenka  wrote:
>
>> Hi,
>>
>> On Thu, Nov 30, 2023 at 10:13 PM Jorg Sowa  wrote:
>>
>>>
>>> Creating aliases for Intl extension constants has been accepted with 10
>>> votes yes and 6 votes no.
>>>
>>>
>> This means that it is declined as you need 2/3 of votes to pass...
>>
>
> This seems to be a secondary vote which only requires 50% of votes to be
> accepted.
>
>
Ah I see now. It's a bit strange to have a secondary vote about sort of
unrelated thing in different extension but no one objected before or during
the vote so let's keep it accepted.

Cheers

Jakub

[PHP-DEV] Inconsistency mbstring functions

[Stefan Schiller via internals]

Hi,

I would like to raise attention to an inconsistency in how mbstring
functions handle invalid multibyte sequences. When, for example,
mb_strpos encounters a UTF-8 leading byte, it tries to parse the
following continuation bytes until the full byte sequence is read. If
an invalid byte is encountered, all previously read bytes are
considered one character, and the parsing is started over again at the
invalid byte. Let's consider the following example:

mb_strpos("\xf0\x9fABCD", "B"); // int(2)

The leading byte 0xf0 initiates a 4-byte UTF-8 sequence. The following
byte (0x9f) is a valid continuation byte. The next byte (0x41) is not
a valid continuation byte. Thus, 0xf0 and 0x9f are considered one
character, and 0x41 is regarded as another character. Accordingly, the
resulting index of "B" is 2.

On the other hand, mb_substr, for example, simply skips over
continuation bytes when encountering a leading byte. Let's consider
the following example, which uses mb_substr to cut the first two
characters from the string used in the previous example:

mb_substr("\xf0\x9fABCD", 2); // string(1) "D"

Again, the leading byte 0xf0 initiates a 4-byte UTF-8 sequence. This
time, mb_substr just skips over the next three bytes and considers all
4 bytes one character. Next, it continues to process at byte 0x43
("C"), which is regarded as another character. Thus, the resulting
string is "D".

This inconsistency in handling invalid multibyte sequences not only
exists between different functions but also affects single functions.
Let's consider the following example, which uses mb_strstr to
determine the first occurrence of the string "B" in the same string:

mb_strstr("\xf0\x9fABCD", "B"); // string(1) "D"

The principle is the same, just in a single function call.

This inconsistency may not only lead to an unexpected behavior but can
also have a security impact when the affected functions are used to
filter input.


Best Regards,
Stefan Schiller

[1]: https://www.php.net/manual/en/function.mb-strpos.php
[2]: https://www.php.net/manual/de/function.mb-substr.php
[3]: https://www.php.net/manual/de/function.mb-strstr.php

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function

[G. P. B.]

On Thu, 30 Nov 2023 at 23:45, Jakub Zelenka  wrote:

> Hi,
>
> On Thu, Nov 30, 2023 at 10:13 PM Jorg Sowa  wrote:
>
>>
>> Creating aliases for Intl extension constants has been accepted with 10
>> votes yes and 6 votes no.
>>
>>
> This means that it is declined as you need 2/3 of votes to pass...
>

This seems to be a secondary vote which only requires 50% of votes to be
accepted.

Best regards,

Gina P. Banyard

Re: [PHP-DEV] Adding a donate link to the PHP website

[Andreas Heigl]

Hey Ben

On 01.12.23 01:04, Ben Ramsey wrote:

On Nov 30, 2023, at 02:45, Andreas Heigl  wrote:

On 30.11.23 09:39, James Titcumb wrote:

On Thu, 30 Nov 2023 at 07:28, Andreas Heigl mailto:andr...@heigl.org>> wrote:

[...snip...]

I suppose that is actually nothing that an RFC can do as I imagine that
everyone from the PHP Group needs to support this and even an RFC
wouldn't legally be able to change anything in regards to that.
Surely, everyone who has contributed (i.e. has voting karma) has the 
opportunity to vote, and therefore, if they choose not to vote, that is surely 
their choice. I don't know the ins and outs of it, but I'd have thought an RFC, 
well advertised, with plenty of time to ensure as many people can vote who have 
rights to.


What I meant by that is that the members of "The PHP Group" are currently the 
copyright holders. From a legal point of view no RFC can change that. The only way to 
change that would be for the PHP Group to transfer their copyright to someone else. What 
an RFC *can* do though is *propose* that the PHP Group transfers their copyright to the 
PHP Foundation.

Though I'm lo lawyer, so ¯\_(ツ)_/¯



I have spoken at length with a lawyer about this, and the TL;DR version is that 
every contributor owns the copyright on their specific contributions, if the 
contributions are copyrightable. Some contributions (typo fixes, white space 
changes, etc.) aren’t copyrightable, but anything more significant that is the 
contributor’s own work belongs to them.

In other words, even though the license statement says the copyright belongs to 
The PHP Group[^1] or Zend Technologies Ltd.[^2], technically, these copyrights 
only apply to the specific code contributed by these organizations or 
contributed by people for these organizations (through work-for-hire or by 
legally transferring the copyright to them).

Contributing to an open source project is NOT an implicit transfer of your 
copyright to the project. To do this, every contributor needs to sign a CLA 
that specifies they are transferring their copyright to The PHP Group.

What is implied, however—and I’m told this is how most courts in the US and 
outside would view it—is assignment of license. When someone contributes to an 
open source project, they own the copyright on their contributions, but unless 
they specify a different license that covers their contributions, it’s implied 
that they are granting use of their contributions under the same license as the 
project. In this way, the contributor can’t later demand to have their 
copyrighted code removed; it’s under the terms of the same license, which can't 
be revoked.

Once a copyright statement is placed on a source file, there’s a bunch of legal 
reasons why you cannot change or remove that copyright statement. In general, 
you should keep all copyright statements added to a source file and never 
change one that already exists on a source file. Just look at the file header 
on any WebKit[^3] source file. WebKit even specifies that you add a copyright 
notice to each file where you make “significant” changes.[^4]

With this in mind, it would be more proper to update the general copyright 
notice to something like this:

 Copyright (c) 2023 and later, The PHP Foundation and contributors. All 
rights reserved.
 Copyright (c) 1999-2023, The PHP Group and contributors. All rights 
reserved.

Since no reassignment of copyright is taking place, we don’t run into any major 
legal issues, and this tells a true and accurate story. The PHP Group were 
stewards of the project until 2023, at which point the community recognized The 
PHP Foundation as the new stewards of the project, and through all of this time 
(since 1999), the various copyrights have been owned by their respective owners 
(i.e., contributors).

If you look at the file headers on ICU source code, you can see that Unicode, 
Inc. made a similar change in 2016.[^5]

All this said… I am in favor of making this change.

I also have a lot more to say on this, as I’ve been considering opening up an 
RFC on just this topic. I had intended to reach out to Zend first (through 
Matthew Weier O’Phinney), but I haven’t done that yet, so this is the first 
time anyone from Zend has seen these ideas. My apologies. :-)

The PHP source code is interesting in that it is covered by two licenses: the 
PHP License[^6] and the Zend Engine License.[^7] This is an historical artifact 
of the early days of PHP when it was conceivable that other companies might 
develop their own engines for PHP, but we know how this story ends: for all 
intents and purposes, the Zend Engine is PHP and PHP is the Zend Engine. Yes, 
I’m aware of alternatives (with very limited adoption), and no, they don’t 
matter for this discussion.

Both the PHP License and Zend Engine License are based on the BSD 4-clause 
“Original” license,[^8] and as a result, neither are compatible with the 
GPL.[^9][^10] In fact, the Zend Engine