Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129866
Precedence: list
MIME-Version: 1.0
References: <CAOWwgp=JtbTSVCv9z=QGx9yS=8G72L-hcAjcOj33eEMLB0zfvg@mail.gmail.com>
 <cd6a8892-3f86-d664-c4bf-75d1dcf47c28@php.net>
In-Reply-To: <cd6a8892-3f86-d664-c4bf-75d1dcf47c28@php.net>
Date: Thu, 22 Jan 2026 13:38:17 -0300
Message-ID: <CADK1yXLa9y74+Xij19M-tFTdCX=Cz1rg6urVEV1u2Fcf5R1o6Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Allow Reassignment of Promoted Readonly
 Properties in Constructor
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001aedc90648fcade3"
From: deleugyn@gmail.com (Deleu)

--0000000000001aedc90648fcade3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 22, 2026 at 1:02=E2=80=AFPM Derick Rethans <derick@php.net> wro=
te:

> On Thu, 22 Jan 2026, Nicolas Grekas wrote:
>
> > Here is a new RFC for you to consider:
> > https://wiki.php.net/rfc/promoted_readonly_constructor_reassign
>
> I read in the linked PR:
>
>         "Team work with Claude Code opus 4.5 =F0=9F=92=AA"
>
> This makes me instantly want to vote no to this.
>

I *assume* it was *not* your intention, but the stated message here then
is: if you use an LLM to contribute to PHP, keep that information private /
do not disclose that information, otherwise you run the risk of getting
your contribution rejected due to personal subjective opinion beyond the
merits of your contribution.


> Code LLMs have been trained on all kinds of open source (and perhaps
> proprietary?) software. Open Source nearly always *atleast* has an
> "Attribution Required" license. But, these "tools" do not follow these
> licenses and the required.
>
> Therefore, there is no legally possible way to allow AI/LLM
> contributions into the PHP source code.
>
> cheers,
> Derick


I understand you have a point from the legal perspective, but as a thought
experiment we can consider any human-produced contribution potentially
tainted with lack of attribution under the same scrutiny, but it wouldn't
ever matter.

I definitely don't want to be debating in favor of AI use, the accelerated
method of burning down the planet or even how OSS is being bombarded by
extremely low quality AI-driven contributions. However, I don't think it's
in the spirit of OSS, the RFC nor PHP's best interest to debate AI like
that on a specific RFC from an author that is known for high quality OSS
contributions. Make an RFC and ban any use of AI on the PHP project for all
I care, but let's aim to be fair with the RFC being proposed as any other
RFC while such a rule/guideline doesn't exist.

--=20
Marco Deleu

--0000000000001aedc90648fcade3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jan 22,=
 2026 at 1:02=E2=80=AFPM Derick Rethans &lt;<a href=3D"mailto:derick@php.ne=
t">derick@php.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">On Thu, 22 Jan 2026, Nicolas Grekas wrote:<br>
<br>
&gt; Here is a new RFC for you to consider: <br>
&gt; <a href=3D"https://wiki.php.net/rfc/promoted_readonly_constructor_reas=
sign" rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/promote=
d_readonly_constructor_reassign</a><br>
<br>
I read in the linked PR:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &quot;Team work with Claude Code opus 4.5 =F0=
=9F=92=AA&quot;<br>
<br>
This makes me instantly want to vote no to this.<br></blockquote><div><br><=
/div><div>I *assume* it was *not* your intention, but the stated message he=
re then is: if you use an LLM to contribute to PHP, keep that information p=
rivate / do not disclose that information, otherwise you run the risk of ge=
tting your contribution rejected due to personal subjective opinion beyond =
the merits of your contribution.</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
Code LLMs have been trained on all kinds of open source (and perhaps <br>
proprietary?) software. Open Source nearly always *atleast* has an <br>
&quot;Attribution Required&quot; license. But, these &quot;tools&quot; do n=
ot follow these <br>
licenses and the required.<br>
<br>
Therefore, there is no legally possible way to allow AI/LLM <br>
contributions into the PHP source code.<br>
<br>
cheers,<br>
Derick</blockquote></div><div><br clear=3D"all"></div><div>I understand you=
 have a point from the legal perspective, but as a thought experiment we ca=
n consider any human-produced contribution potentially tainted with lack of=
 attribution under the same scrutiny, but it wouldn&#39;t ever matter.</div=
><div><br></div><div>I definitely don&#39;t want to be debating in favor of=
 AI use, the accelerated method of burning down the planet or even how OSS =
is being bombarded by extremely low quality AI-driven contributions. Howeve=
r, I don&#39;t think it&#39;s in the spirit of OSS, the RFC nor PHP&#39;s b=
est interest to debate AI like that on a specific RFC from an author that i=
s known for high quality OSS contributions. Make an RFC and ban any use of =
AI on the PHP project for all I care, but let&#39;s aim to be fair with the=
 RFC being proposed as any other RFC while such a rule/guideline doesn&#39;=
t exist.</div><div><br></div><span class=3D"gmail_signature_prefix">-- </sp=
an><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div dir=
=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr=
"><div dir=3D"ltr">Marco Deleu</div></div></div></div></div></div></div></d=
iv></div>

--0000000000001aedc90648fcade3--