Re: Adding a donate link to the PHP website

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 >>>> <mailto:andreas@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 >> License isn’t an OSI Approved License, while the PHP License is,[^11] and this can cause problems, >> especially with companies that require SBOMs listing the licenses of all third-party software used >> and these licenses must be OSI Approved. I’m not sure why no one has raised this as an issue yet, >> and I’ve been quiet about it (until now) to avoid it becoming an issue. >> >> The BSD 4-clause license is the one that includes the “obnoxious” (in the words of the >> FSF) advertising clause, and the Zend license includes this. Both the PHP and Zend licenses include >> a statement that says The PHP Group and Zend Technologies Ltd. have the exclusive right to publish >> revised versions of the license, and both state that redistributions must include a specific “this >> product includes…” statement. The PHP License also includes the restrictions against using the >> name “PHP” in the name of any derivatives. If all of these statements are removed, the licenses >> become identical to the BSD 3-clause license. >> >> So, a few points about this: >> >> * In general, when changing a project’s license, you need every contributor to approve of >> the changes because they own the copyrights on their contributions and the license terms of their >> copyrighted contributions are changing. >> * The PHP and Zend licenses are essentially the BSD 3-clause license with additional stuff. >> * The additional stuff isn’t related to any rights a contributor (i.e., copyright >> holder), other than The PHP Group and Zend, would have 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 license, this does not >> change any of the terms the contributors (i.e., the copyright holders) have granted to users, so we >> don’t need explicit approval from all contributors (though an advance notice of several months to >> allow comments on the changes is a nice gesture). >> >> Obviously, IANAL, but I’ve spoken with Pamela Chestek about these changes. She is a >> member of the Board and Chair of the License Committee for the Open Source Initiative, though I must >> make it clear (for legal reasons) that she was not acting in an official capacity of her role with >> the OSI when we spoke. >> >> MY PROPOSAL: >> >> 1. Retire the PHP License and Zend Engine License. >> 2. Drop the Zend/LICENSE file and replace the text of the LICENSE file with the exact text >> of the BSD 3-clause license. >> 3. Replace the copyright notice in the file headers and LICENSE with the following: >> >> Copyright (c) 2023 and later, The PHP Foundation and contributors. >> Copyright (c) 1999-2023, The PHP Group and contributors. >> Copyright (c) 1999-2023, Zend Technologies USA, Inc. ("Zend”), >> a subsidiary of Perforce Software, Inc. >> >> Here is an example diff of the proposed changes to the LICENSE file: >> https://gist.github.com/ramsey/96026cda9da33cb95e49357dc074cdb5 >> >> We would allow contributors (i.e., copyright holders) at least 3 months to make comments on >> the proposal, after which their approval is implied. >> >> >> An ALTERNATE PROPOSAL, if others feel strongly about keeping the “additional stuff” in >> the LICENSE: >> >> 1. Retire the Zend Engine License, effectively folding it into the PHP License. >> 2. Make some light edits to the PHP License to bring it to parity with the exact text of >> the BSD 3-clause license, while keeping the aforementioned “additional stuff.” >> 3. Replace the copyright notice in the file headers and LICENSE, as noted above. >> 4. Bump the PHP License version number to 3.2. >> >> Here is an example diff of the alternate proposed changes to the LICENSE file: >> https://gist.github.com/ramsey/b6bd0339a027b182f91133d912515d44 >> >> Again, we would allow contributors (i.e., copyright holders) at least 3 months to make >> comments on the proposal, after which their approval is implied. >> >> It’s 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 The PHP Group >> to step forward and “bless” or approve of this proposal. Additionally, it’s important for Zend >> to also “bless” or approve of this. >> >> So, this is a lot for a message in a thread about adding a donation link to the PHP >> website, but if others are interested, I can take this into a new thread and work on a separate RFC, >> or perhaps we use the same RFC for both and use it as an opportunity to formalize the project’s >> relationship with The PHP Foundation, as the successor to The PHP Group. >> > > Thank you for this in depth explanation! > > To me that already before that email sounded more than just an add on to > the donation link question. > > The reason I brought it up was that both seemed to have something to do > 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 > 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 > first idea would be to not change the license in the middle of the > PHP8.3 lifecycle but have PHP8.4 or even PHP9 (as it kinda is a BC break > 🙈) released with the new license. > > As this would be a special RFC we'd definitely need a longer discussion > period than the required minimum of 2 weeks but we can explain those > details in the RFC itself. > > Cheers > > Andreas I would agree that linking to the Foundation for donations and fully switching up the license/copyright are separate issues and should be separate proposals/RFCs. That said, I in principle support both. A license switch sounds like something that should be part of PHP 9; that's also ample time for discussion. --Larry Garfield