Hey Ben On 01.12.23 01:04, Ben Ramsey wrote:
On Nov 30, 2023, at 02:45, Andreas Heigl <andr...@heigl.org> wrote:On 30.11.23 09:39, James Titcumb wrote:On Thu, 30 Nov 2023 at 07:28, Andreas Heigl <andr...@heigl.org <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 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 definitelya: 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
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
OpenPGP_signature.asc
Description: OpenPGP digital signature
