On Sun, Sep 15, 2019 at 2:37 PM Peter Bowyer <phpmailingli...@gmail.com> wrote:
> On Sun, 15 Sep 2019 at 06:48, Joe Watkins <krak...@php.net> wrote: > > > The Wikipedia states that PHP is developed by the PHP Group, in saying > this > > it is (must be) referring to internals as a whole, but our own > > documentation names members of the group - who aren't even around mostly. > > > > I think we need to clarify what exactly is the purpose of the PHP Group > > today, does anyone want to attempt to do that ? > > > > Joe, I applaud this move. > > As a non-American and so used to a different legal system, I have a further > point I would like clarified: the PHP website and PHP license say > "Copyright the PHP Group" (https://www.php.net/copyright.php, > https://www.php.net/license/3_01.txt). > > How can an undefined group have copyright vested in it? It's very much well-defined. And certainly not by Wikipedia, but in the PHP source code and the php.net website itself. Right at the top of the Credit page: https://www.php.net/credits.php > And more > importantly, how would it defend or deal with a copyright infringement if > "The PHP Group" is not a recognised group or legal entity? > Thankfully, copyright infringements are practically irrelevant as far as the PHP license is concerned. License violations are also pretty much irrelevant, with the only practical exception being someone breaking the clause that requires them not to use the name 'PHP' to promote a derivative product. But we've been able to deal with this gracefully for the past ~20 years, and I don't see a reason that should change. To the suggested proposal - it's quite obvious that you can't use a mechanism to widen its own scope. Changing the Voting RFC (either unilaterally or by using the Voting RFC itself) to extend its jurisdiction is meaningless. It was never, ever designed to be a mechanism to radically alter the language (which nobody even considered as an option at the time of its introduction) - but as a way to extend it. There are several references in the text - both of the Voting RFC itself, the RFC template and the RFC howto that make the scope of this mechanism quite clear. Note that I'm not at all advocating that we defer deprecation/radical changes to Group. That's impractical and more importantly - makes no sense. But so is using the same threshold for adding a feature and removing it - that too makes absolutely no sense at all. The negative end-user impact from taking away a feature that they've grown to rely on is virtually always far greater than adding it in the first place. In 20+ years of the project, there were 3 proactive major compatibility breakages that we decided to go for - namely, register_globals, magic_quotes and safe_mode. The first two had super simple one liner workarounds, and were disabled by default for many years before they were deprecated and subsequently removed. The 3rd was so inherently unsafe and complex to maintain that we decided that the price of removing it was worth the impact - which was limited almost exclusively to shared hosters (and there were much more reliable alternatives emerging at the time). We didn't have a voting mechanism back then, these decisions passed in near-consensus (not 66/33, but an overwhelming support and very little opposition, IIRC a lot closer to 10 to 1 vs. 2/3). We a new mechanism for deprecations/radical changes - i.e., things that break existing code (as opposed to make new code possible). It can reuse much of the process of the Voting RFC, but the threshold has to correlate to the expect breakage impact (and we need to be able to measure that in a reasonable way). Simple things with limited impact can stick with 2/3, which is still too low but has become a standard. Things with far-reaching impact should have a much higher, near-consensus bar. Yes, it means that proposals with a far-reaching effect on end users will need to be almost unanimously agreed upon before they clear, much like they did in the past when we've made similar decisions. They'll have to have a super convincing case and not one that's deemed controversial by a sizable number of voters. Which means they'll be uncommon, and when they do take place - it'll be for very good reasons. Zeev
