Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125868
Precedence: bulk
MIME-Version: 1.0
References: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
 <ecfa4bda-9c73-43f0-9d10-61d64da0c9ca@app.fastmail.com> <d7a20849-dfc6-4e48-bc6f-078b447028c1@app.fastmail.com>
In-Reply-To: <d7a20849-dfc6-4e48-bc6f-078b447028c1@app.fastmail.com>
Date: Sun, 27 Oct 2024 12:37:40 +0700
Message-ID: <CAEZPtU6FEi9yUY=cTEZQ_E=y02kpFYyC=o+zP71koBh795T59Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code
To: Jim Winstead <jimw@trainedmonkey.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: pierre.php@gmail.com (Pierre Joye)

Hello :)

On Sun, Oct 27, 2024 at 3:28=E2=80=AFAM Jim Winstead <jimw@trainedmonkey.co=
m> wrote:
>
> There were more existing 3rd-party dependencies that should probably be a=
dded to the policy text:
>
> https://news-web.php.net/php.internals/125769
>
> Two I missed were JpGraph and Parsedown which are used by web-doc. (Curre=
ntly by side-loading JpGraph and having an old copy of Parsedown committed =
to web-doc, I would hope to move those out as Composer dependencies if we d=
ecide to allow that.)
>
> Jim

First, I want to extend my gratitude to all who keep this effort
running, your efforts are truly appreciated and much needed! :)

I've been following this thread and, while I understand the historical
context and some of the off-topic discussions, I find myself a bit
puzzled.

Historically, the restrictions on what could be used for the php-web,
php-doc, and other codebases were primarily about ensuring that
mirrors could operate using a stock PHP setup without additional
dependencies like database servers. Over time, some services couldn't
adhere to these restrictions, leading to various exceptions. It is
important to note that php.net no longer has an official mirror
program (see https://www.php.net/mirroring.php).

Historically, the restrictions on what can be used for the php-web,
php-doc, etc code base at large was about the mirrors (, for any of
these services, could use it by using a stock PHP without anything
else, be database  servers etc. Some services obviously could not do
it with these restrictions and 'exceptions' have appeared along the
way. php.net does not have an official mirror program anymore (see
https://www.php.net/mirroring.php), though mirrors still advertise
themselves at https://www.php.net/mirror.php

The principle that "php.net does not do promotional content" was, and
still is, about avoiding explicit promotions of specific companies,
products, or individuals. For example, all mirrors were listed in one
place, and links/ads/etc from our homepage were never allowed. This is
the context behind the stance of not promoting non-php.net entities.

Regarding the tools we use in php.net projects, we already leverage a
wide range of tools, services, and libraries, both PHP-based and
otherwise. These can be seen in our repositories and elsewhere. Given
that we no longer rely on a mirror network program per se, I don't see
the issue with relaxing some of these strict rules. Doing so could
make life easier and more enjoyable for maintainers, and likely
improve the codebase by reducing the "Not Invented Here" syndrome or
making things easier to maintain.

Composer, for instance, has always wanted to remain independent from
php.net, which is perfectly understandable. However, does this mean we
can't use it? That seems like an overreaction in today's PHP
development ecosystem. While it's true that anything can be done using
a stock PHP setup without dependencies, this approach has not been
ideal for many areas for quite some time. It is most certainly valid
as well for many other tools or libraries.

Last but not least, it might be a good thing (tm) to maintain a simple
list of the tools we use and their purposes. This wouldn't be
promotional but rather informative, helping everyone understand the
current state of our toolset, improving transparency.

best,
--=20
Pierre

@pierrejoye | http://www.libgd.org