> On May 21, 2024, at 16:32, Francesco Poli <invernomuto@paranoici.org> wrote: > > On Sun, 19 May 2024 14:53:48 -0500 Ben Ramsey wrote: > >> On May 19, 2024, at 11:42, Francesco Poli <invernomuto@paranoici.org> wrote: > [...] >>> If the PHP Group decides to elect the 3-clause BSD license as the next >>> version (4.0) of the PHP License, then clause 5 of the PHP License version >>> 3.01 will kick in and any piece of software currently licensed under >>> the terms of the PHP License version 3.01 will *instantly* be also >>> available under the terms of the 3-clause BSD license, at the >>> recipient's choice. >>> >>> A similar reasoning should hold for the Zend Engine License, as well… >> >> I want to be clear that this RFC does not exert any control over other >> projects that use the PHP License. > > I would not call it "control". > > Nobody will be forced to stop copying/modifying/redistributing other > projects under the terms of the PHP License version 3.01 . > > It's just a license-upgrade clause that can be triggered by the license > steward, which decides to publish a new version of the license. > > People who released their own projects under the terms of the PHP > License version 3.01 were (or should have been...) aware of the > existence of that license-upgrade clause: they decided to trust the PHP > Group as license steward. > They should not be surprised, if, at some point in time, that > license-upgrade clause is actually triggered. > > [...] >> One of my goals with the RFC is to get rid of the idea of a “PHP License,” > > I agree with this goal. > >> so it deprecates the PHP License and *replaces* it with the >> BSD 3-Clause License. I don’t want there to be a “PHP License, >> version 4.0.” I think that will continue to cause confusion >> in the community. > > If the PHP Group decides to adopt the 3-clause BSD license as the new > PHP License, version 4.0, there will be no obligation, I think, to > mention the term "PHP License, version 4.0" in each PHP source code > file. > It will be possible to mention the 3-clause BSD license in each source > file and to state that PHP will be released under the terms of the > 3-clause BSD license. > > At the same time, somewhere on the php.net website, there will be a > page that explicitly says that the PHP Group has adopted the 3-clause > BSD license as the PHP License, version 4.0. After thinking this over, I like your suggestions and approach. I’ll start working on updating the relevant sections of the RFC to call attention to this and to also mention this as the “PHP License, version 4.0,” even if we don’t put that name in any of the source files, etc. >> Is there a reading of clause 5 (specifically “You may also choose >> to use such covered code under the terms of any subsequent version >> of the license published by the PHP Group.”) that would allow >> projects using the PHP License to switch to the BSD 3-Clause License, >> even if a subsequent version 4.0 of the PHP License is not published? > > First off, and I should have stated this more explicitly from the > beginning, IANAL, TINLA. Understood. :-) > That being said, I personally don't see how the license-upgrade clause > could be triggered, without actually publishing a new version of the > license. This is how I understand it, as well. > AFAICT, the strategy to "adopt" the 3-clause BSD license as the new > version 4.0 of the PHP License would trigger the license-upgrade > clause, while at the same time deprecating the use of the PHP License. > The web page on the php.net website could even explicitly say that the > PHP License is now deprecated and that the PHP Group has designated the > 3-clause BSD license as its successor (PHP License, version 4.0). +1. I like this approach. > In addition, triggering the license-upgrade mechanism would make it > much clearer that there's no need to ask for permission to all the > external contributors and that the license change can be performed just > with a vote within the PHP Group. I think this was my biggest concern: I didn’t want to advise others that they could update their licenses, only to piss off a bunch of contributors, but if we adopt the 3-clause BSD as the next version of the PHP License, then I agree with you that it would trigger the license-upgrade mechanism and allow other projects to seamlessly upgrade the license, which doesn’t affect any of the terms or rights their contributors granted anyway. This is something that didn’t cross my mind while I was putting together the RFC, so I’m glad I posted to this list. Thank you for the suggestions! I’ll update the RFC and will reply here when I’ve made the changes. > To a layman like me, the reasoning that no contributors, other than > representatives of the PHP Group, are able to grant or assert clauses > 4, 5, and 6, looks convincing. But I don't know whether it would > actually hold water in a court. > So, maybe, it's better, if the license-upgrade mechanism is also > triggered. > > Or at least, this is how I personally see it. > > Bye!
Attachment:
signature.asc
Description: Message signed with OpenPGP