Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121898
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1178-geeaf0069a7-fm-20231114.001-geeaf0069
MIME-Version: 1.0
Message-ID: <5d79bde4-52bb-4ae1-96c0-33236a21ae7b@app.fastmail.com>
In-Reply-To: <6441b82b-95f2-4be8-a1c9-96bb94965f95@heigl.org>
References: <e763ad7e-26aa-4f34-9387-6dfa2a3823b6@app.fastmail.com>
 <8e77ac89-b8dd-4991-b859-943d34592f5d@app.fastmail.com>
 <fff6af56-f888-4263-b6a5-b8718e4614ae@heigl.org>
 <CAOD_yv1hxVzF_N5TTvCVeBZ+G5z=Guy2xL3QnrRNK9gm_r=gmA@mail.gmail.com>
 <06261716-9557-4944-8bad-14cd77cfbbb0@heigl.org>
 <DA56D46C-87C0-4F1C-BEB5-A1727C6C8AC7@benramsey.com>
 <6441b82b-95f2-4be8-a1c9-96bb94965f95@heigl.org>
Date: Fri, 01 Dec 2023 17:03:32 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Adding a donate link to the PHP website
From: larry@garfieldtech.com ("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 <andreas@heigl.org> wrote:
>>>
>>> On 30.11.23 09:39, James Titcumb wrote:
>>>> On Thu, 30 Nov 2023 at 07:28, Andreas Heigl <andreas@heigl.org <mai=
lto:andreas@heigl.org>> wrote:
>>> [...snip...]
>>>>     I suppose that is actually nothing that an RFC can do as I imag=
ine that
>>>>     everyone from the PHP Group needs to support this and even an R=
FC
>>>>     wouldn't legally be able to change anything in regards to that.
>>>> Surely, everyone who has contributed (i.e. has voting karma) has th=
e opportunity to vote, and therefore, if they choose not to vote, that i=
s 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 curr=
ently the copyright holders. From a legal point of view no RFC can chang=
e that. The only way to change that would be for the PHP Group to transf=
er their copyright to someone else. What an RFC *can* do though is *prop=
ose* that the PHP Group transfers their copyright to the PHP Foundation.
>>>
>>> Though I'm lo lawyer, so =C2=AF\_(=E3=83=84)_/=C2=AF
>>=20
>>=20
>> I have spoken at length with a lawyer about this, and the TL;DR versi=
on is that every contributor owns the copyright on their specific contri=
butions, if the contributions are copyrightable. Some contributions (typ=
o fixes, white space changes, etc.) aren=E2=80=99t copyrightable, but an=
ything more significant that is the contributor=E2=80=99s own work belon=
gs to them.
>>=20
>> 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 o=
rganizations or contributed by people for these organizations (through w=
ork-for-hire or by legally transferring the copyright to them).
>>=20
>> Contributing to an open source project is NOT an implicit transfer of=
 your copyright to the project. To do this, every contributor needs to s=
ign a CLA that specifies they are transferring their copyright to The PH=
P Group.
>>=20
>> What is implied, however=E2=80=94and I=E2=80=99m told this is how mos=
t courts in the US and outside would view it=E2=80=94is assignment of li=
cense. When someone contributes to an open source project, they own the =
copyright on their contributions, but unless they specify a different li=
cense that covers their contributions, it=E2=80=99s implied that they ar=
e granting use of their contributions under the same license as the proj=
ect. In this way, the contributor can=E2=80=99t later demand to have the=
ir copyrighted code removed; it=E2=80=99s under the terms of the same li=
cense, which can't be revoked.
>>=20
>> Once a copyright statement is placed on a source file, there=E2=80=99=
s a bunch of legal reasons why you cannot change or remove that copyrigh=
t statement. In general, you should keep all copyright statements added =
to a source file and never change one that already exists on a source fi=
le. Just look at the file header on any WebKit[^3] source file. WebKit e=
ven specifies that you add a copyright notice to each file where you mak=
e =E2=80=9Csignificant=E2=80=9D changes.[^4]
>>=20
>> With this in mind, it would be more proper to update the general copy=
right notice to something like this:
>>=20
>>      Copyright (c) 2023 and later, The PHP Foundation and contributor=
s. All rights reserved.
>>      Copyright (c) 1999-2023, The PHP Group and contributors. All rig=
hts reserved.
>>=20
>> Since no reassignment of copyright is taking place, we don=E2=80=99t =
run into any major legal issues, and this tells a true and accurate stor=
y. 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 copyrigh=
ts have been owned by their respective owners (i.e., contributors).
>>=20
>> If you look at the file headers on ICU source code, you can see that =
Unicode, Inc. made a similar change in 2016.[^5]
>>=20
>> All this said=E2=80=A6 I am in favor of making this change.
>>=20
>> I also have a lot more to say on this, as I=E2=80=99ve been consideri=
ng opening up an RFC on just this topic. I had intended to reach out to =
Zend first (through Matthew Weier O=E2=80=99Phinney), but I haven=E2=80=99=
t done that yet, so this is the first time anyone from Zend has seen the=
se ideas. My apologies. :-)
>>=20
>> The PHP source code is interesting in that it is covered by two licen=
ses: the PHP License[^6] and the Zend Engine License.[^7] This is an his=
torical artifact of the early days of PHP when it was conceivable that o=
ther 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 an=
d PHP is the Zend Engine. Yes, I=E2=80=99m aware of alternatives (with v=
ery limited adoption), and no, they don=E2=80=99t matter for this discus=
sion.
>>=20
>> Both the PHP License and Zend Engine License are based on the BSD 4-c=
lause =E2=80=9COriginal=E2=80=9D license,[^8] and as a result, neither a=
re compatible with the GPL.[^9][^10] In fact, the Zend Engine License is=
n=E2=80=99t an OSI Approved License, while the PHP License is,[^11] and =
this can cause problems, especially with companies that require SBOMs li=
sting the licenses of all third-party software used and these licenses m=
ust be OSI Approved. I=E2=80=99m not sure why no one has raised this as =
an issue yet, and I=E2=80=99ve been quiet about it (until now) to avoid =
it becoming an issue.
>>=20
>> The BSD 4-clause license is the one that includes the =E2=80=9Cobnoxi=
ous=E2=80=9D (in the words of the FSF) advertising clause, and the Zend =
license includes this. Both the PHP and Zend licenses include a statemen=
t that says The PHP Group and Zend Technologies Ltd. have the exclusive =
right to publish revised versions of the license, and both state that re=
distributions must include a specific =E2=80=9Cthis product includes=E2=80=
=A6=E2=80=9D statement. The PHP License also includes the restrictions a=
gainst using the name =E2=80=9CPHP=E2=80=9D in the name of any derivativ=
es. If all of these statements are removed, the licenses become identica=
l to the BSD 3-clause license.
>>=20
>> So, a few points about this:
>>=20
>> * In general, when changing a project=E2=80=99s license, you need eve=
ry contributor to approve of the changes because they own the copyrights=
 on their contributions and the license terms of their copyrighted contr=
ibutions are changing.
>> * The PHP and Zend licenses are essentially the BSD 3-clause license =
with additional stuff.
>> * The additional stuff isn=E2=80=99t related to any rights a contribu=
tor (i.e., copyright holder), other than The PHP Group and Zend, would h=
ave on the source code.
>> * The PHP Group has already specified it has the right to modify its =
license.
>> * Zend has already specified it has the right to modify its license.
>> * The additional stuff is largely unimportant and unenforceable.
>> * If both licenses are modified to change them to the BSD 3-clause li=
cense, this does not change any of the terms the contributors (i.e., the=
 copyright holders) have granted to users, so we don=E2=80=99t need expl=
icit approval from all contributors (though an advance notice of several=
 months to allow comments on the changes is a nice gesture).
>>=20
>> Obviously, IANAL, but I=E2=80=99ve spoken with Pamela Chestek about t=
hese changes. She is a member of the Board and Chair of the License Comm=
ittee for the Open Source Initiative, though I must make it clear (for l=
egal reasons) that she was not acting in an official capacity of her rol=
e with the OSI when we spoke.
>>=20
>> MY PROPOSAL:
>>=20
>> 1. Retire the PHP License and Zend Engine License.
>> 2. Drop the Zend/LICENSE file and replace the text of the LICENSE fil=
e with the exact text of the BSD 3-clause license.
>> 3. Replace the copyright notice in the file headers and LICENSE with =
the following:
>>=20
>>      Copyright (c) 2023 and later, The PHP Foundation and contributor=
s.
>>      Copyright (c) 1999-2023, The PHP Group and contributors.
>>      Copyright (c) 1999-2023, Zend Technologies USA, Inc. ("Zend=E2=80=
=9D),
>>        a subsidiary of Perforce Software, Inc.
>>=20
>> Here is an example diff of the proposed changes to the LICENSE file: =
https://gist.github.com/ramsey/96026cda9da33cb95e49357dc074cdb5
>>=20
>> We would allow contributors (i.e., copyright holders) at least 3 mont=
hs to make comments on the proposal, after which their approval is impli=
ed.
>>=20
>>=20
>> An ALTERNATE PROPOSAL, if others feel strongly about keeping the =E2=80=
=9Cadditional stuff=E2=80=9D in the LICENSE:
>>=20
>> 1. Retire the Zend Engine License, effectively folding it into the PH=
P License.
>> 2. Make some light edits to the PHP License to bring it to parity wit=
h the exact text of the BSD 3-clause license, while keeping the aforemen=
tioned =E2=80=9Cadditional stuff.=E2=80=9D
>> 3. Replace the copyright notice in the file headers and LICENSE, as n=
oted above.
>> 4. Bump the PHP License version number to 3.2.
>>=20
>> Here is an example diff of the alternate proposed changes to the LICE=
NSE file: https://gist.github.com/ramsey/b6bd0339a027b182f91133d912515d44
>>=20
>> Again, we would allow contributors (i.e., copyright holders) at least=
 3 months to make comments on the proposal, after which their approval i=
s implied.
>>=20
>> It=E2=80=99s important to note that The PHP Group (or PHP Association=
) did exist at one time as a formal business entity in the US,[^12] and =
Zend drafted a formal agreement with the PHP Association for its use of =
the Zend Engine.[^13] So, there is some precedence here for members of T=
he PHP Group to step forward and =E2=80=9Cbless=E2=80=9D or approve of t=
his proposal. Additionally, it=E2=80=99s important for Zend to also =E2=80=
=9Cbless=E2=80=9D or approve of this.
>>=20
>> So, this is a lot for a message in a thread about adding a donation l=
ink to the PHP website, but if others are interested, I can take this in=
to a new thread and work on a separate RFC, or perhaps we use the same R=
FC for both and use it as an opportunity to formalize the project=E2=80=99=
s relationship with The PHP Foundation, as the successor to The PHP Grou=
p.
>>=20
>
> Thank you for this in depth explanation!
>
> To me that already before that email sounded more than just an add on =
to=20
> the donation link question.
>
> The reason I brought it up was that both seemed to have something to d=
o=20
> with the PHP Group.
>
> After digesting these information I would definitely
>
> a: want to go the path to change the license following one of your=20
> proposals but
> b: separate that from the question regarding the donation link!
>
> I would happily help in drafting an RFC based on your proposals. My=20
> first idea would be to not change the license in the middle of the=20
> PHP8.3 lifecycle but have PHP8.4 or even PHP9 (as it kinda is a BC bre=
ak=20
> =F0=9F=99=88) released with the new license.
>
> As this would be a special RFC we'd definitely need a longer discussio=
n=20
> period than the required minimum of 2 weeks but we can explain those=20
> details in the RFC itself.
>
> Cheers
>
> Andreas

I would agree that linking to the Foundation for donations and fully swi=
tching up the license/copyright are separate issues and should be separa=
te proposals/RFCs.  That said, I in principle support both.

A license switch sounds like something that should be part of PHP 9; tha=
t's also ample time for discussion.

--Larry Garfield