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 <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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
