Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107106 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42754 invoked from network); 15 Sep 2019 15:40:07 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 15 Sep 2019 15:40:07 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 4F8642CFDDF for ; Sun, 15 Sep 2019 06:16:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_05,DKIM_INVALID, DKIM_SIGNED,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS36351 199.187.172.0/22 X-Spam-Virus: No Received: from tbjjbihbhebb.turbo-smtp.net (tbjjbihbhebb.turbo-smtp.net [199.187.174.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Sun, 15 Sep 2019 06:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1569158206; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=yUnV+VcxE4MFmdPd4vpl0E Guif+DRgSTT+qQUc1qfTg=; b=faaK8udGvYY2qkQPQ0U/eraR5FxTz6KDwgWVeg 69qLhWVIoyTlDgyghdwOJsJm/0+0eBD5Askj0zm1W97CcCCvxHeWZCbGzDbGVj78 HsZrx4N1c3uD123tSCqR50y/m70W1Aud1MK0IoR5zwnGbE1BZ9ROWsC1wqLRNFFL jS7MI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=turbo-smtp; d=php.net; h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type; b=q8WTbUaoV6OnczMOuvJlIQASHw2UbJW45290biXGjryb9+60EObwKBLm6JrF6n DmDqCrouiBKEEWrJRXnRbe6WBErcY3td1FxjjyPmE1f5nsjZy6bq4C5nugrIFGbB TRnh/GSUGqxp5yuyS/sKmla5sMPdqKUn59UY9UslJRgxI=; Received: (qmail 2089 invoked from network); 15 Sep 2019 13:16:45 -0000 Received: X-TurboSMTP-Tracking: 5283147736 X-Gm-Message-State: APjAAAX5RA1F73Ee608sjLLVfGiA6xJyfG0U4/coKv/L6pFwwHSm7SK3 yMhxFLk3aeQ0xbN8WusYn7Sw3iR9IscVKcCc6MM= X-Google-Smtp-Source: APXvYqztz8dqIB2nuC6pJPYB78upx/Wkdh8/qkTgac7Ogk0WkQL/TV8k1wdR6nxPo9O4D/eACc5NHy664zV3o9s2QiQ= X-Received: by 2002:ad4:4712:: with SMTP id k18mr38348536qvz.97.1568553404663; Sun, 15 Sep 2019 06:16:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 15 Sep 2019 16:16:34 +0300 X-Gmail-Original-Message-Id: Message-ID: To: Peter Bowyer Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000007f0f1b0592974c43" X-Envelope-From: Subject: Re: [PHP-DEV] Defining the PHP Group From: zeev@php.net (Zeev Suraski) --0000000000007f0f1b0592974c43 Content-Type: text/plain; charset="UTF-8" On Sun, Sep 15, 2019 at 2:37 PM Peter Bowyer wrote: > On Sun, 15 Sep 2019 at 06:48, Joe Watkins 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 --0000000000007f0f1b0592974c43--