Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128016
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Subject: Re: [PHP-DEV] [RFC] Updating the PHP License
Date: Sat, 12 Jul 2025 14:33:17 -0500
References: <70DC3FB4-C98E-4C79-AB2C-F2B65AE8B9F1@php.net>
 <CAAfnsFVXf_z-srRtYJi1+3tLrAXsY+-Sni-=UND2+Bf3+8Bvqw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <CAAfnsFVXf_z-srRtYJi1+3tLrAXsY+-Sni-=UND2+Bf3+8Bvqw@mail.gmail.com>
Message-ID: <2947B0BE-8A52-4B3C-8AF7-0A57C6D4DAC9@php.net>
From: ramsey@php.net (Ben Ramsey)

> On Jul 12, 2025, at 04:18, Peter Kokot <petk@php.net> wrote:
>=20
> On Thu, 10 Jul 2025 at 05:26, Ben Ramsey <ramsey@php.net> wrote:
>> Hello internals,
>>=20
>> I=E2=80=99m opening discussion on an RFC proposing that we relicense =
PHP under
>> the Modified BSD License (SPDX identifier: BSD-3-Clause), starting =
with
>> PHP 9.0. This change simplifies and modernizes our licensing,
>> addressing long-standing issues while preserving the rights of both
>> contributors and users. Below is a quick summary of what the RFC
>> proposes and what it means for developers.
>>=20
>> - Proposes that PHP 9.0 adopt the Modified BSD License =
(BSD-3-Clause),
>>   replacing the current PHP and Zend Engine licenses.
>> - The Modified BSD License is OSI-approved, GPL-compatible, and =
widely
>>   recognized in the open source community.
>> - Your rights as a developer=E2=80=94use, modification, =
distribution=E2=80=94remain
>>   unchanged.
>> - Extensions and tools may adopt BSD-3-Clause in place of the =
outdated
>>   PHP License.
>> - The update removes confusing legacy clauses tied to branding and
>>   permissions.
>>=20
>> I=E2=80=99ve spoken with all members of the PHP Group, and each has =
voiced their
>> approval of this proposal. The Perforce legal team has also =
informally
>> approved, and I will be working with them to get a formal letter of
>> approval soon.
>>=20
>> The RFC is available at: https://wiki.php.net/rfc/php_license_update
>>=20
>> Discussion will remain open for at least six months to ensure all
>> interested parties have an opportunity to respond.
>>=20
>> Cheers,
>> Ben
>>=20
>> P.S. For legal questions or concerns, I=E2=80=99m working with Pamela =
Chestek
>> of Chestek Legal <https://www.chesteklegal.com> on behalf of the PHP=20=

>> Group. You may be familiar with her work as chair of the license
>> committee for the Open Source Initiative.
>=20
> Sounds great. I'm sure this was a lot of work involved. Thank you.
>=20
> I'd just have two questions here that are popping up to things I've =
encountered lately:
>=20
> 1. TSRM (Thread Safe Resource Manager) also has a separate LICENSE =
file but it is BSD 2 Clause, which is compatible with all of that, I =
assume. That should be also simplified in some way? Perhaps integrating =
TSRM into Zend Engine directly at some point or updating its license to =
3 clause BSD?

The license that applies to TSRM should remain the same. For one, it=E2=80=
=99s already under a widely-accepted and permissive OSI-approved =
license. Secondly, I think changing it would require approval from all =
contributors:

1. The license on TSRM doesn=E2=80=99t explicitly reserve the right for =
anyone to change the license (the PHP License and Zend Engine Licenses =
do), so no one can unilaterally change the license.

2. Changing from BSD-2-Clause to BSD-3-Clause adds more restrictions to =
the terms authors have granted by including the 3rd clause (i.e., =
=E2=80=9CNeither the name of the copyright holder=E2=80=A6=E2=80=9D). =
So, the authors would need to approve of these additional restrictions =
added to the use of their contributions.

There are only about 70 contributors to TSRM, so getting approvals =
wouldn=E2=80=99t be too hard, but I also don=E2=80=99t think it=E2=80=99s =
necessary to change the license on it.

It looks like TSRM was originally written with the intention of being a =
standalone library that could be used apart from PHP, which is why it =
was contributed under a different license.

> 2. To be more clear, the GPL compatibility would probably need to be =
just slightly clarified to make PHP usage simpler in the future for =
cases when GPL-licensed software is involved.
>=20
> PHP currently has option to link to two GPL-3 licensed libraries that =
cause issues when distributing PHP (for example, packaging PHP and =
providing it as a binary via some package and similar):=20
> - GNU readline library for ext/readline (here libedit alternative can =
be used)
> https://github.com/php/php-src/issues/16826
> - GDBM for ext/dba (here other handlers can be used)
> https://github.com/php/php-src/issues/15882
>=20
> So, GPL-compatibility here means that PHP licensed under the Modified =
BSD License could link to GNU Readline library but it should be =
relicensed as GPL-3 then?
>=20
> Because I'm thinking of deprecating linking options with GNU Readline =
and GDBM to make the PHP build process worry-free for packagers.

I=E2=80=99m not sure what you mean by =E2=80=9CGPL compatibility would =
probably need to be just slightly clarified to make PHP usage =
simpler.=E2=80=9D

The FSF considers the Modified BSD License as compatible with the =
GPL.[^1] They elaborate on what they mean by compatibility:

=E2=80=9CIt means that the other license and the GNU GPL are compatible; =
you can combine code released under the other license with code released =
under the GNU GPL in one larger program.

=E2=80=9CAll GNU GPL versions permit such combinations privately; they =
also permit distribution of such combinations provided the combination =
is released under the same GNU GPL version.=E2=80=9D[^2]

Being licensed under the Modified BSD License means that PHP may be =
combined with GPL-licensed software and released together with that =
software, as long as the *combination* is released under the terms of =
the GPL.

For those who are packaging PHP and linking against GPL libraries, the =
current PHP License, version 3.01, presents an incompatibility that =
cannot be resolved because of the additional restrictions it places on =
users.[^3] However, under the Modified BSD License, there is no =
incompatibility, as long as the combined package is released under the =
terms of the GPL.

Example: if I create a PHP package that links against Readline (whether =
statically or dynamically) the GPL considers this a combined work, and I =
must release the combination under the terms of the same version of the =
GPL that covers Readline.[^4]

Does that clear things up?

Cheers
Ben


[^1]: https://www.gnu.org/licenses/license-list.html#ModifiedBSD
[^2]: https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
[^3]: https://www.gnu.org/licenses/license-list.html#PHP-3.01
[^4]: https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic