PHP RFC: PHP License Update

• Version: 0.5
• Date: 2024-05-24
• Author: Ben Ramsey, ramsey@php.net
• Proposed Version: PHP 9.0
• Status: Draft
• First Published at: http://wiki.php.net/rfc/php_license_update

PHP has a long history of confusion, concerns, and disagreements regarding its custom open source license, and the Zend Engine License, which covers the sources in the Zend/ directory, adds to this confusion and additionally complicates matters, since it is not an Open Source Initiative Approved License. This RFC proposes a pragmatic simplification to the PHP license that alleviates this confusion, preserves the copyrights owned by all PHP contributors, and grants users the same rights as the original licenses. The proposed license to accomplish this is the BSD 3-Clause "New" or "Revised" License.

This proposal addresses a longstanding issue within the open source community by publishing new versions of the PHP License and the Zend Engine License. The BSD 3-Clause License is adopted as the PHP License, version 4, and as the Zend Engine License, version 3.

The BSD 3-Clause License is sometimes referred to as the “New,” “Revised,” or “Modified” BSD License. Its SPDX identifier is BSD-3-Clause.¹⁾ It is recognized as a free software license by both the Open Source Initiative (OSI) and the Free Software Foundation (FSF).^2) 3) The FSF has designated it as compatible with the GNU General Public License (GPL), and it is an OSI Approved License.

The PHP License, version 3.01, and Zend Engine License, version 2.00, combine the BSD 3-Clause License with special terms specific only to the PHP Group and Zend Technologies (now a subsidiary of Perforce Software). After removing these special terms, the licenses are identical to the BSD 3-Clause License, and there is no change to the rights granted by contributors or to users.

By adopting the BSD 3-Clause License:

• The rights granted by contributors do not change.
• The rights granted to users do not change.
• We will work with the PHP Group and Perforce Software to remove the terms that are specific to them.
• PHP software and the Zend Engine will be licensed under terms that are both OSI Approved and compatible with the GPL.

Proposed, the PHP project will:

1. Work with the PHP Group to adopt the BSD 3-Clause License as the PHP License, version 4.
2. Work with Perforce Software to adopt the BSD 3-Clause License as the Zend Engine License, version 3.
3. Deprecate the PHP License and the Zend Engine License. Use of these licenses for new projects, inside or outside the PHP project, is strongly discouraged.
4. Delete the contents of the LICENSE file from the PHP software, and replace them with the contents indicated in the New LICENSE File section below.
5. Remove the Zend/LICENSE file from the Zend Engine.
6. Replace the file headers for all PHP source files in the PHP software with the contents indicated in the New PHP Source File Header section below.
7. Replace the file headers for all Zend Engine source files with the contents indicated in the New Zend Engine Source File Header section below.
8. Update other applicable documentation and web pages to reflect these changes, such as https://www.php.net/license/.

The Background, Change Authority, and Additional Context sections of this document provide further context and legal justification for this change.

Following is the full text of the BSD 3-Clause License.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Copyright (c) 1999-2024, The PHP Group and contributors.
Copyright (c) 1999-2024, Zend Technologies USA, Inc.,
    a subsidiary of Perforce Software, Inc.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its
   contributors may be used to endorse or promote products derived from
   this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The author names provided are examples to show that we retain the existing author names in each file header.

/*
   +----------------------------------------------------------------------+
   | Copyright (c) The PHP Group and contributors.                        |
   +----------------------------------------------------------------------+
   | This source file is subject to the BSD 3-Clause License that is      |
   | bundled with this package in the file LICENSE, and is available      |
   | through the World Wide Web at <https://www.php.net/license/>.        |
   +----------------------------------------------------------------------+
   | Authors: John Smith <john@example.com>                               |
   |          Kira Torres <kira@example.com>                              |
   +----------------------------------------------------------------------+
*/

The author names provided are examples to show that we retain the existing author names in each file header.

/*
   +----------------------------------------------------------------------+
   | Zend Engine                                                          |
   +----------------------------------------------------------------------+
   | Copyright (c) Zend Technologies USA, Inc.,                           |
   |     a subsidiary of Perforce Software, Inc., and contributors.       |
   +----------------------------------------------------------------------+
   | This source file is subject to the BSD 3-Clause License that is      |
   | bundled with this package in the file LICENSE, and is available      |
   | through the World Wide Web at <https://www.php.net/license/>.        |
   +----------------------------------------------------------------------+
   | Authors: John Smith <john@example.com>                               |
   |          Kira Torres <kira@example.com>                              |
   +----------------------------------------------------------------------+
*/

The PHP License and Zend Engine License are not compatible with the GPL,⁴⁾ and the Zend Engine License is not OSI Approved. While the OSI license approval committee voted to approve versions 3.0 and 3.01 of the PHP License, each followed the “legacy approval” process, meaning the licenses had already been in wide use for many years before the OSI approved them. As a result, the OSI approved the PHP License based more on its intent, rather than its content. If the OSI license approval committee were not considering the legacy use of the PHP License, it is unlikely they would have approved it based solely on its content.

In the beginning, while the Zend Engine was bundled with PHP in the Zend/ directory, it was thought of as a completely separate product that could be unbundled and used apart from PHP. Indeed, that was the intent, and it is the reason PHP and the Zend Engine have separate licenses. However, after 25 years of cohabitation within the same source code repository, the two are intertwined in ways in which the Zend Engine can no longer be separated and used as a standalone product. Together, they form the PHP programming language reference implementation.

Rasmus Lerdorf created PHP at a time when a faction within the free software movement was growing dissatisfied with the politics and philosophy of the movement and splintered off, crystallizing around a more permissive set of licenses viewed as friendlier to commercial use—this became the open source movement.

The frame dispute, consequent transformation, and creation of the open source movement can be viewed as a spin-off movement that not only had a different diagnosis and more elastic reach, but that strove to avoid what they saw as “mistakes” made by the founding movement that inhibited commercial growth.⁵⁾

In his original release announcement, Lerdorf wrote, “The tools are in the public domain distributed under the GNU Public License. Yes, that means they are free!”^6) 7) Lerdorf chose to release PHP version 1 and PHP/FI (version 2) under the terms of the GNU GPL, version 2 (GPLv2), but he recognized the growing concerns among the open source movement that commercial interests were scared of or even forbade the use of GPL software in their organizations—indeed, many continue this practice today. In a 1997 mailing list post discussing licensing, Lerdof said, “PHP, if I can help it, will always be free. But, I am not against letting commercial entities take a shot at a commercial version as long as the terms are such that the major contributors don't feel cheated.”⁸⁾

This led to a dual-licensing model in PHP 3, allowing users the choice to use PHP under the terms of the GPLv2 or a custom license based on the Apache License, version 1.0. “Our license is identical to the Apache license (since that's where we copied it from) except for that first clause,” wrote Lerdforf in a 1999 mailing list post.⁹⁾ That first clause restricted commercial use:

Commercial redistribution of larger works derived from, or works which bundle PHP, requires written permission from the PHP Development Team. You may charge a fee for the physical act of transferring a copy, and must make it clear that the fee being charged is for the distribution, and not for the software itself. You may, at your option, offer warranty protection in exchange for a fee.¹⁰⁾

The dual-licensing model presented a number of challenges to a group that was ill-equipped to handle legal questions. In the same thread, Lerdorf discussed having received requests from companies for signed, hardcopy documents granting permission to use PHP and being unable to respond to them appropriately.¹¹⁾ Free and open source software was not well-understood by companies, and there was significant disagreement within the PHP project about what level of freedom users should have. At the time, Zeev Suraski wrote, “people should not be given the legal right to do whatever they wish with PHP.”¹²⁾ Nevertheless, with Lerdorf having referred to the first clause as “that troublesome clause which we can't enforce,”¹³⁾ the team finally removed it in PHP 3.0.14.¹⁴⁾

Meanwhile, Richard Stallman, author of the GPL and founder of the FSF, had significant disagreements with the PHP project over their use of the GPL,^15) 16) so the PHP project discontinued the dual-licensing approach, removing the GPL license as an option, and PHP 4.0.0 shipped with the PHP License, version 2.02 and the Zend License, version 0.92,¹⁷⁾ for sources within the Zend/ directory.

Suraski and Andi Gutmans originally intended the Zend/ directory to be read-only, with all the source code owned by the two, so they could “sell the Zend engine for uses other than PHP.”¹⁸⁾ It's clear they—and other early members of the PHP project—saw the Zend Engine as wholly separate from PHP. In a 1999 interview, Lerdorf clarified licensing concerns surrounding the separate licenses:

PHP 4 is not synonymous with Zend. And when it comes to licensing, the only time the [Zend License] kicks in is if you unbundle Zend from PHP and try to embed the Zend engine into something else.¹⁹⁾

Andrei Zmievski elaborated on this separation:

I think there is still some confusion about what role exactly Zend plays in the PHP infrastructure. The host language (PHP) uses the base services provided by the engine (Zend)—services such as memory allocation, persistent resources, compilation, and execution. PHP itself then provides the function libraries, interfaces to the Web servers, .ini file support, etc.²⁰⁾

Gutmans hinted at a possible future use of the Zend Engine, which explained the need for a separate license:

I'd very much like to see the Zend engine embedded in MySQL at some point. I think it would be great to be able to write the stored procedure code of the DB in the same language as the scripting engine used to access the DB. […]

The Zend engine was written in a way where it can be used in other products besides PHP. The [Zend License] allows us (the Zend company) to reserve the right to use it elsewhere commercially. However, Zend as part of PHP can be used freely and falls under the PHP license.²¹⁾

Later, Gutmans explained why he thought the separate license for the Zend Engine did not present any problems for contributors:

No one really contributes to the scripting engine but extends PHP with additional modules and functions. There are constantly developers (besides us) extending PHP's functions.²²⁾

Since then, the licenses underwent only one series of major changes, which produced the Zend Engine License, version 2.00, first distributed with PHP 4.2.0 (April 22, 2002), and the PHP License, version 3.0, first distributed with PHP 4.2.3 (September 6, 2002).

In May 2003, Lerdorf petitioned the OSI for approval of version 3.0 of the PHP License, closing with a statement that implied he wished to switch PHP to the Apache License, Version 2.0, once it gained approval from the OSI.

Hopefully the new Apache license whenever that gets finalized will be OSI-approved and has the big advantage of being project-agnostic, so projects such as PHP that are closely tied to Apache can use it verbatim without having to massage it and we won't need all these individual Apache-like licenses.²³⁾

A few years later, a very slight change in the wording of the PHP License resulted in changing the version number to 3.01.²⁴⁾ This new version, while almost identical, never received OSI approval, a problem that presented itself 14 years later, when Matthew Sheahan asked on the php-general mailing list regarding the OSI approval status of version 3.01.

My team's ability to use the phpdbg utility hinges on OSI approval of its license. Language at https://www.php.net/license/ indicates that the PHP 3.01 license is OSI approved, but OSI disagrees; https://opensource.org/licenses/alphabetical shows approval only of the PHP 3.0 license. (The fact that 3.0 and 3.01 are substantively identical is no use to us at all.)²⁵⁾

Andreas Heigl asked on the php-internals mailing list, “Does anyone here remember why the changes to the license where [sic] done in the first place?”²⁶⁾ In response, Johannes Schlüter referenced the Debian debate.

My memory could fail me, but I believe there were debates coming from Debian community around especially PECL extensions being Licensed under PHP Licens [sic] 3.0 and the wording being sub-optimal. The new wording (and website link) should make it clear that PECL (and PEAR) is “PHP Software” while not being “PHP”.²⁷⁾

At that time, Ben Ramsey volunteered to contact the OSI to formally request legacy approval for the PHP License.²⁸⁾ The legacy approval designation allowed the license steward or any interested licensee to request “retroactive approval of historic/legacy licenses that have already been extensively used by an existing community, but have not previously been approved.”²⁹⁾ So, on March 4, 2020, Ramsey submitted a request for legacy approval to the OSI license-review list,³⁰⁾ and on May 13, 2020, the OSI Board voted to approve the PHP License, version 3.01.³¹⁾

The PHP Association was a public benefit corporation incorporated in the State of Nebraska in the United States in February 2000.³²⁾ Each of the directors of the PHP Association were also members of the PHP Group.^33) 34) We can infer from this that the PHP Group created the PHP Association to represent the group in legal and business matters.

On May 22, 2000, the same day the PHP team released PHP version 4.0.0, including Zend Engine version 1.0.0, Zend Technologies and the PHP Association entered into an agreement to ensure the continued availability of the Zend Engine as an open source product.

In particular, the agreement stated:³⁵⁾

Since Zend Engine is a crucial component of PHP, Zend hereby makes the following commitments and assurances to The PHP Association:

• Zend will continue to make Zend Engine available as an open source product under the Zend Open Source License. If Zend changes the terms of the Zend Open Source License, the new license will be consistent with the Open Source Definition of the Open Source Initiative.

• The PHP Association is hereby authorized to market, distribute and sublicense Zend Engine, in source and object code forms, as an integrated component of PHP, to end users who agree to be bound by the PHP open-source license, version 2.02. […] However, if Zend Engine is either modified or separated from the rest of PHP, the use of the modified or separated Zend Engine shall not be governed by the PHP Open Source License, but instead shall be governed by the Zend Open Source License.

The PHP Association agreed to the terms of the agreement, which included the following conditions:

• “The Association will not delete or alter any intellectual property rights or license notices appearing on the Zend Engine and will reproduce and display such notices on each copy it makes of the Zend Engine.”
• “The Association may not assign this Letter, by operation of law or otherwise in whole or in part, without Zend's written consent. Any attempt to assign this Letter without such consent will be null and void. This Letter will bind and inure to the benefit of each party's permitted successors and assigns.”

Given how corporation law works in most US states, the PHP Association is likely still legally bound to this contract, even if they are no longer an active entity, and the terms of the contract followed Zend as it was acquired by Rogue Wave in 2015 and Perforce Software in 2019.

PHP 1.0 and 2.0 (a. k. a. PHP/FI) were both licensed under the GNU GPL, version 2.^36) 37)

PHP 3.0 was dual-licensed under the GPL, version 2, and a custom, BSD-style license that eventually became known as “The PHP License.” This BSD-style license was the Apache License, version 1.0, with two major differences:

1. PHP added a new condition requiring written permission for commercial redistribution.
2. PHP omitted the fifth condition as it appears in the original Apache License.

This license had no version identifier, and the copyright holder was listed as “The PHP Development Team.”

In PHP 3.0.1, the PHP team added the following additional statements to the 5th condition of the PHP License:

This does not apply to add-on libraries or tools that work in conjunction with PHP. In such a case the PHP name may be used to indicate that the product supports PHP.

In PHP 3.0.14, the PHP team removed the 1st condition that required written permission for commercial redistribution.

At this point, the license was nearly identical to the Apache License, except for the addition of the statements mentioned in Revision 1 and the omission of the 5th condition as it appeared in the Apache License, version 1.0.

PHP 4.0.0 included the PHP License, version 2.02,³⁸⁾ which represented several revisions applied to the license during the beta and release candidate phases of PHP 4.0. In addition to a new and separate license for the Zend Engine (which was new in PHP 4), this version of the PHP License included the following changes:

1. The “advertising materials” condition was removed.
2. A new condition was added granting the PHP Group the right to modify the license “at any time and without prior notice, as long as the changes keep the free and open source nature of PHP.”
3. A new condition was added granting permission to distribute the Zend Engine under the terms of the PHP License, as long as it is bundled with PHP. When separated from PHP, the use of the Zend Engine is governed by the Zend Engine License.

This license listed “2.02” as its version identifier and named the copyright holder as “The PHP Group.”

The Zend Engine License began as a copy of the Q Public License (QPL)³⁹⁾, and this was included in PHP 4.0.0 as the Zend Engine License, version 0.92.⁴⁰⁾ However, PHP 4.2.0 included a brand new version of the Zend Engine License, version 2.00, which was nearly identical to the terms of the PHP License, version 2.02. The primary difference was the addition of the “advertising clause” as condition 6, rather than the Zend Engine clause that appeared in the PHP License, version 2.02.⁴¹⁾

PHP 4.2.3 updated the PHP License to version 3.0.⁴²⁾ This version included the following changes:

1. The “does not apply to add-on libraries or tools” clause was dropped from the 3rd condition.
2. A new 4th condition was added restricting any derived product from calling itself “PHP.”
3. The 6th condition of version 2.02 of the license was dropped, implying the Zend Engine was no longer licensed under the terms of the PHP License when bundled with PHP, but rather, the Zend Engine License always applies to the source in the Zend/ directory.

PHP 5.1.2 and 4.4.2 updated the PHP License to version 3.01, with very minor changes to the PHP License.^{43) 44) 45)}

The PHP License and Zend Engine License are BSD-style licenses. As mentioned earlier, Lerdorf pointed to the Apache License, version 1.0, as the model for the original PHP license,⁴⁶⁾ and the Apache License, version 1.0, is derived from the original, or 4-clause, BSD license.⁴⁷⁾ In fact, the two are identical, except the Apache License added conditions 5 and 6:

5. Products derived from this software may not be called “Apache” nor may “Apache” appear in their names without prior written permission of the Apache Group.

6. Redistributions of any form whatsoever must retain the following acknowledgment: “This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/).”⁴⁸⁾

By extension, the PHP License is a derivative of the BSD 4-Clause License.

The BSD 4-Clause License is not an OSI-approved license,⁴⁹⁾ while the FSF considers it free but problematic.⁵⁰⁾ Both positions are in response to the BSD advertising clause:

All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the organization.

For the PHP License, version 3.01, conditions 1 and 2 are identical to conditions 1 and 2 of the BSD 4-Clause License. Condition 3 of the PHP License is similar in function to condition 4 of the BSD. Condition 6 of the PHP License is similar in function to condition 3 of the BSD 4-Clause License. PHP added new conditions 4 and 5.

For the Zend Engine License, version 2.00, conditions 1 and 2 are identical to conditions 1 and 2 of the BSD 4-Clause License. Condition 3 of the Zend Engine License is similar in function to condition 4 of the BSD 4-Clause License. Conditions 5 and 6 of the Zend Engine License are similar in function to condition 3 of the BSD 4-Clause License. Zend added a new condition 4.

Every contributor owns the copyright on their specific contributions to an open source project, if the contributions are copyrightable. Some contributions (e.g., typo fixes, white space changes, etc.) aren't copyrightable, but anything more significant belongs to the contributor, provided it is their own work.

In other words, even though the license statement says the copyright belongs to The PHP Group⁵¹⁾ or Zend Technologies⁵²⁾, technically, these copyright statements only apply to the specific code contributed by these organizations or by people contributing on behalf of these organizations.

Contributing to an open source project is NOT an implicit transfer of your copyright to the project. To do this, every contributor must sign a contributor license agreement that explictly states they are transferring their copyright to whomever owns the code. No one has signed any agreements of this sort for the PHP software, so every contributor retains copyright ownership over the code they have contributed to PHP.

What is implied, however, is assignment of license. When someone contributes to an open source project, they own the copyright on their contributions, but unless they specify a different license covering their contributions (which is wholly valid, with examples including Derick Rethans's timelib, which is bundled within the PHP source code), it is implied they are granting use of their contributions under the same license terms as the project. In this way, the contributor cannot later demand to remove all their copyrighted code; it's under the terms of the same license, which can't be revoked. However, if the project decides to change its license terms, a contributor may then request removal of their copyrighted code because they may not wish to grant the terms of the new license to their copyrighted work.

Additionally, common convention dictates that, once a copyright statement is placed on a source file, it should remain on that source file, complete with any years listed, though the years do not require updating. For an example, look at the file header on any WebKit source file.⁵³⁾ WebKit even specifies that you add a copyright notice to each file where you make “significant” changes.⁵⁴⁾

Who has the authority to make these changes?

We've established that each contributor owns the copyright on their individual contributions to an open source project and, unless stated otherwise, they grant the same rights to users as the license covering the source file(s) they modified. Typically, when changing the license on an open source project, one must gain approval from all copyright owners, since the rights granted might change under the terms of the new license. However, as described in this section and in other places in this document, changing to the BSD 3-Clause License does not change any of the rights granted by contributors who are not the PHP Group or Perforce Software.

The short answer is, “No.” As a courtesy, however, we will keep discussion on this topic open for a period of no less than six months before calling a vote on the proposal.

Earlier, we established that every contributor owns the copyright for their specific contributions, and unless they specified a different license covering their contributions, it is implied they have granted use of their contributions under the same license terms as the project. We have also established, at length, the PHP License, version 3.01, and Zend Engine License, version 2.00, are identical to the BSD 3-Clause License if conditions 4, 5, and 6 are removed from each license.⁵⁵⁾

There is no doubt contributors have the authority to grant users license to use their code with respect to conditions 1 and 2. These are the same for the PHP License, Zend Engine License, and BSD 3-Clause License. This proposal does not change the wording of any part of these conditions:

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Condition 3 does have differences across each license. However, when viewed at face-value, the intent of this condition in the PHP and Zend Engine licenses is the same as the 3rd condition of the BSD 3-Clause License. Additionally, as worded in the PHP and Zend Engine licenses, contributors have no authority to assert these terms for their own contributions, since the terms are specific to the PHP Group and Perforce Software, respectively, but they do have the authority to assert the terms of condition 3 from the BSD 3-Clause License.

PHP License

The name “PHP” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact group@php.net.

Zend Engine License

The names “Zend” and “Zend Engine” must not be used to endorse or promote products derived from this software without prior permission from Zend Technologies Ltd. For written permission, please contact license@zend.com.

BSD 3-Clause License

Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

When we look closer at conditions 4, 5, and 6 for both the PHP License and the Zend Engine License, it appears no contributors, other than representatives of the PHP Group and Perforce Software, are able to grant or assert these conditions for their contributions. Removing them from the license does not change any of the rights granted or restricted by contributors (other than the PHP Group and Perforce Software; see below).

For these reasons, we do not need to gain permission from all contributors to make these changes.

Yes.

This proposal removes the following conditions, which the PHP Group is uniquely able to claim over the PHP source code:

4. Products derived from this software may not be called “PHP”, nor may “PHP” appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying “Foo for PHP” instead of calling it “PHP Foo” or “phpfoo”

5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.

6. Redistributions of any form whatsoever must retain the following acknowledgment: “This product includes PHP software, freely available from http://www.php.net/software/”.

The good news is that condition 5 grants the PHP Group the authority to make changes to the PHP License, without approval from any contributors.

Depending on the bylaws adopted by the PHP Association (as discussed earlier in Zend and the PHP Association), we may require approval from one or more representatives of the PHP Group to accept this proposal. There is no public record of the association's bylaws, so unless the bylaws specify a quorum, we will need approval from each of:

• Thies C. Arntzen
• Stig Bakken
• Shane Caraveo
• Andi Gutmans
• Rasmus Lerdorf
• Sam Ruby
• Sascha Schumann
• Zeev Suraski
• Jim Winstead
• Andrei Zmievski

Note: Legal representatives of Perforce Software have informally approved this proposal. The next step is a formal approval, in writing.

Yes.

As the successor of Zend Technologies, Perforce Software is party to the Zend Grant and owner of the Zend Engine License. This proposal removes the following conditions, which Perforce Software is uniquely able to claim over the Zend Engine source code:

4. Zend Technologies Ltd. may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by Zend Technologies Ltd. No one other than Zend Technologies Ltd. has the right to modify the terms applicable to covered code created under this License.

5. Redistributions of any form whatsoever must retain the following acknowledgment: “This product includes the Zend Engine, freely available at http://www.zend.com”

6. All advertising materials mentioning features or use of this software must display the following acknowledgment: “The Zend Engine is freely available at http://www.zend.com”

Just as the PHP License grants the PHP Group the authority to make changes to the PHP License, the Zend Engine License grants Perforce Software the sole authority to make changes to the Zend Engine License, without approval from its contributors.

To make the changes proposed in this RFC, the PHP project will require that a representative (or representatives) from the PHP Group work with representatives from Perforce Software to agree to this proposal.

Yes.

While the PHP License and Zend Engine License include provisions that allow the PHP Group and Perforce Software to change the licenses at their leisure, in practice, the PHP project community manages both the primary reference version of the PHP programming language and the Zend Engine. Therefore, a vote by the PHP project community is important and crucial to make this change.

Accepting this RFC through a PHP project community vote will:

1. Communicate that it is the will of the PHP project community to make these changes.
2. Indicate to the PHP Group and Perforce Software that we wish to make these changes and request their aid in working with us to make them.

We will open discussion for a period of no less than six months before calling a vote on this RFC.

This RFC does not introduce any backward incompatible changes.

The terms of the PHP License, version 3.01, and the Zend Engine License, version 2.00, are fully compatible with the terms of the BSD 3-Clause License. The proposed license does not reduce any user rights or add any new restrictions on the use of code previously licensed under the PHP License, version 3.01, or the Zend Engine License, version 2.00. The proposed license does not increase or diminish any rights granted by contributors.

This RFC proposes PHP 9.0.0 as the version in which these license changes will take full effect.

This proposal affects all source code within the PHP software repository at https://github.com/php/php-src that is currently licensed under the PHP License or the Zend Engine License. Any source code within the PHP software repository that has separate licensing terms (e.g., timelib in ext/date/lib/) is not affected by this proposal.

The proposed changes for the PHP software repository will not affect the PHP Manual. The PHP Manual will remain licensed under the Creative Commons Attribution 3.0 License or later.⁵⁶⁾

This proposal publishes a new version of the PHP License, triggering clause 5 of the PHP License, version 3.01, which states (emphasis added):

The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.

Users of any PHP extension or other software published under the terms of the PHP License, version 3.01, may choose to use that software under the terms of the PHP License, version 4 (i.e., the BSD 3-Clause License).

Maintainers of PHP extensions and other software published under the terms of the PHP License, version 3.01, may choose to upgrade the software license to the PHP License, version 4 (i.e., the BSD 3-Clause License). In an effort to reduce license proliferation, you are discouraged from using the name “PHP License, version 4” as the license name. If you need an SPDX identifier, use BSD-3-Clause.

Historically, many extensions uploaded to PECL were licensed under the PHP License, version 3.01. Indeed, one of the suggestions for publishing a PECL package is: “We strongly encourage contributors to choose the PHP License 3.01 for their extensions, in order to avoid possible troubles for end-users of the extension. Other solid options are BSD and Apache type licenses.”⁵⁷⁾

The “potential troubles” mentioned here almost always arise from use of a copyleft license like the GPL. The FSF considers the combination of PHP extensions and the PHP software a single combined program.⁵⁸⁾ As a result, licensing a PHP extension with the GPL leads to a confusing state that is especially problematic for distributors.

New PHP extensions and other software should not use the PHP License. Recommended licenses include, but are not limited to (in alphabetical order):

1. Apache License, Version 2.0
2. BSD 2-Clause "Simplified" License
3. BSD 3-Clause "New" or "Revised" License
4. GNU Lesser General Public License version 3
5. MIT License
6. Mozilla Public License 2.0
7. Unlicense

To be updated during discussion.

Publish the PHP License, version 4, and Zend Engine License, version 3, by adopting the BSD 3-Clause License as the new version of both, and deprecate the PHP License and Zend Engine License, as proposed in the Proposal section?

Yes/No

Ben Ramsey will coordinate creation of a patch that will apply the proposed changes.

To be updated after implementation.

1. debian-legal: Updating the PHP License
2. OSI license-discuss: Updating the PHP License

To be updated during discussion.

There are many instances of discussion and disagreements over the PHP License. This section highlights a few of the more substantial discussions not included earlier in this document.

Did RMS come to terms with the PHP/Zend licensing structure?^59) 60)

This indicates there was a disagreement between the PHP maintainers and Richard Stallman (a. k. a. RMS) at some point prior to May 2001. However, the full nature of this disagreement is unknown, as there is no record of it on public mailing lists or forums.

In an article published in 2004, Sean Michael Kerner quoted Gutmans, who referenced past exchanges with RMS, concerning the PHP license.

Gutmans said he has exchanged e-mails with FSF founder Richard Stallman in the past on such issues. “We definitely don't see eye to eye on the issue of licensing. He [Richard Stallman] doesn't like our licensing and we know that,” Gutmans said. “We're aware of each other, but the PHP project has no intention of moving to some sort of GPL license.”⁶¹⁾

In this same interview, Gutmans expounded on his philosophy regarding users' rights when using PHP: “We like the fact that it (PHP) is very open. It's a long discussion about what Free really means. When I think of free, my users can do whatever they want.” He continued, “Most of PHP's user base are people that are using PHP to make a living and they wouldn't care less [about the GPL]. They are just happy that it's a PHP license and they can do whatever they want with it and can ship it with their commercial products”

Debian creates patches for PHP and distributes a modified version of PHP for their distributions, using those patches. In a sense, they violate condition 4 of the PHP License.

Since Debian is (or at least may be) distributing patches in their packages that are not part of upstream, we are distributing a derived product and hence must not name it PHP.

This does not only affect Debian but also other distributions of PHP that are trying to enhance or fix PHP in some ways.⁶²⁾

Schulze sent an email asking for clarification to the PHP Group, and he posted Gutmans's reply to the debian-legal mailing list, saying:

Andi Gutmans answered and told me that he speaks for the PHP Group:

As per your problem, having such a clause in the BSD-like license is the way both Apache and PHP have been enforcing and protecting their brand for a long time. Minor build changes and backported security fixes are fine and if that's all you're doing there is no need to rename the package. The problems arise when you start making significant changes to the actual functionality of the

The license clause and intent is identical in the Apache license which we believe you are also shipping.

So as soon as our maintainer or security team adds more than onlyh [sic] “build changes and backported security fixes”, we'll have to rename the PHP (and Apache) packages.⁶³⁾

Later that year, Joerg Jaspert was working on the Debian “NEW queue” and noticed some PHP extensions listed that used the PHP license.

But a big thing against using a PHP license is that it always only talks about “PHP”, “Software provided by PHP Development Team”, “software made by many individuals in behalf of PHP group”, and “This software includes the Zend Engine”. Im [sic] sure that none of the php-* modules contain the zend engine. :)

So, looking at such packages in NEW - what do you guys suggest to do? *I* tend to go and kick them out. Go get upstream to use a sane license…⁶⁴⁾

Indeed, none of the PHP modules (also known as extensions) contained the PHP source code or the Zend Engine source code. Jaspert's inclination was to kick these packages out of the Debian repositories and request the upstream project maintainers to “use a sane license.”

Years later, the Debian debate over the PHP License continued. In 2014, Jake Edge wrote a summary of a then-new debate that arose on the debian-legal mailing list. From Debian's perspective, he reported, the PHP License renders PHP and any extensions or other code that used the license, non-distributable.⁶⁵⁾

On the debian-devel mailing list, Matthias Urlichs exclaimed:

It is quite obvious that PHP/Zend does not give a flying **** about the way the license is (mis)used by third parties. Also quite obviously, these selfsame third parties think the license to be perfectly applicable, will not change it, and consider us quite strange for even mentioning this.⁶⁶⁾

Urlichs listed three options for the Debian team, the last of which was:

Bite the bullet and admit that when everybody else calls a color “light blue” which we consider to be “cyan”, we might as well docuent [sic] that fact instead of trying to convince everybody else that they're wrong, even if they are, from our PoV. After all, the color stays the same, no matter what people call it.

By the same token, this license is valid by force of everybody under the sun considering it to be valid (taking intent and all that into account). The chance of an author of / contributor to one of these packages (nobody else has any legal standing to do so) suing us for distributing this code is … well … I suspect that if you want to get a lawyer to laugh, you might as well ask them.

Around this time, Pierre Joye prompted the pecl-dev mailing list to discuss these issues, saying, “Debian began to send requests to change PHP license for the PHP Extension arguing that the PHP License is only valid for PHP itself.”⁶⁷⁾

This full thread is available on MARC: https://marc.info/?t=140378209800001

James Wade brought the discussion to the php-qa mailing list, saying, “There seems to be some confusion over the PHP License.”⁶⁸⁾ He then asked:

1. Is 'The PHP License, version 3.01' an Open Source license, certified by the Open Source Initiative? Their website only lists 'PHP License 3.0 (PHP-3.0)'.
2. When was 'The PHP License, version 3.01' released?
3. Can 'The PHP License, version 3.01' be used for anything other than PHP itself?
4. Are there any legal implications of changing a project from 'The PHP License, version 3.01' to LGPL or BSD?
5. Is the PHP license clear enough to ensure that it is correctly applied to extensions?
6. Why would the (Apache-style) PHP License be listed by Debian as a 'serious violation' yet the Apache license is not?

This discussion continued on the pecl-dev mailing list, which may be found on MARC: https://marc.info/?w=2&r=1&s=Debian+and+the+PHP+license&q=t

At one point in the thread, Walter Landry exclaimed in response to Ángel González:⁶⁹⁾

Ángel González wrote:

Trying to keep the spirit of the PHP License and at the same time solve that strict interpretation, I propose the following change to the PHP License 3.01, which will hopefully please both parties:

Stop. Please just stop. Please pick an existing, well known license so that we do not have to argue *again* over whether this really solves all of the problems.

The lengthy discussion resulted in no change to the PHP License, and the Debian team wrote an official position on software licensed under the PHP License, which states:⁷⁰⁾

The PHP license is a copyright license that attempts to go beyond the rights afforded by copyright law - it attempts to control the use of the term PHP.

[…]

The license requires us to make this statement: “This product includes PHP software, freely available from http://www.php.net/software/”, the veracity of which cannot be verified by us, nor can we be held responsible for the maintenance of the link. The license also makes warranty disclaimers that may be inaccurate in certain circumstances but all these inconsistencies owe to its drafting design.

In 2020, the question of whether the PHP License version 3.01 is OSI approved came up again on the php-general mailing list, and the PHP project settled this question by going through the formal license approval process with the OSI.

In May 2003, Lerdorf submitted a formal request for approval of the PHP License, version 3.0.⁷¹⁾ While the mailing list was quiet regarding his request, he responded on June 3, 2003, and indicated he had received a response requesting use of another license.⁷²⁾

So far no responses other than one suggesting we use another license. Using another license is not an option as this is the license the code has been released under for years and it is the already released code I need an OSI-approved license for. I can't go back in time and release that code under a different license.

David Johnson wrote back on June 4:⁷³⁾

The only problems I have with it is the wording (but not intent) of condition 4, and well known problems of section 6. But neither of these would disqualify it as Open Source. Since you have already released code under this license, it does no good suggesting changes.

When Ramsey sought OSI approval of the PHP License, version 3.01 in 2020,⁷⁴⁾ similar concerns were once again raised:

• “Does this license, and it's predecessor PHP License 3.0, satisfy the OSD, specifically OSD 3?”⁷⁵⁾
• “Note the restriction is not limited to their mark, common law or otherwise. It attempts to preclude a much broader scope of designation of origin than that, and put limits on how those designations may be articulated. And it's a limitation on the scope of the copyright grant, meaning they could conceivably make a claim for copyright infringement for using a naming convention to which they may not be entitled to enforce under trademark law. I'm specifically referring to the part of the license restriction that says 'nor may “PHP” appear in their name, without prior written permission.'”⁷⁶⁾
• “Sec 6 to me is badge-ware-ish, although what the dividing line is between badgeware and acceptable author acknowledgements is perhaps a bit murky. Perhaps because it does not require the location or manner of the display of that message (cf., BSD 4-Clause), it falls on the non-badgeware side of the divide.”⁷⁷⁾
• “Or, suppose the Ceph project creates some sort of Kubernetes-related project called”cephpod“ and suppose for some bizarre reason it uses a copyrightable snippet of PHP-licensed code. I think this was the sort of scenario that the FSF was concerned about, as causing the naming restriction to be unreasonable, when judging the license to be GPL incompatible, though I can't immediately find support for this.”⁷⁸⁾
• “The good news is you already have upgrade clause. You could exercise that clause and create the PHP License 3.02 without the naming restrictions.”⁷⁹⁾
• “One radical idea you might consider is upgrading the license out of existence. You could exercise clause 5 and revise it as the PHP License 3.02, being identical to the BSD-3 license. A clever lawyer probably knows the best way to do this. Other projects get on without the naming clause or seemingly redundant attribution clause.”⁸⁰⁾
• “Does this mean that any author of a PHP extension using the PHP license – or indeed some software completely unrelated to PHP using the PHP license – can treat a trademark use of PHP as a breach of the license, and is that appropriate, compared to the situation that I think was contemplated by such licenses where the licensor is also presumably the trademark owner?”⁸¹⁾
• “There is a similar clause is in the Apache Software License 1.1 and the OpenSSL license and probably several other legacy permissive licenses from that general era. However the second sentence may be unique to the PHP license.”⁸²⁾

In 1999, Lerdorf pointed to the Apache Software License 1.1 as the template for the PHP License, and admitted there was a troublesome clause they couldn't enforce.⁸³⁾

Our license is identical to the Apache license (since that's where we copied it from) except for that first clause. So no, we did not come up with anything except for that troublesome clause which we can't enforce.

This refers to clause 1 of the PHP License version 1.0, which stated:

Commercial redistribution of larger works derived from, or works which bundle PHP, requires written permission from the PHP Development Team. You may charge a fee for the physical act of transferring a copy, and must make it clear that the fee being charged is for the distribution, and not for the software itself. You may, at your option, offer warranty protection in exchange for a fee.

This clause first appeared in the new license that shipped with PHP 3.0.0 and was removed in PHP 3.0.14, before the PHP License was versioned.

A few terms in this document might stand out and require additional context:

• PHP project: Instead of using the narrower terms “PHP internals” or “PHP core,” this document uses “PHP project” to refer to the broader scope of everything that falls under the PHP.net umbrella.
• PHP software: PHP software refers to the reference implementation of the PHP programming language, found at https://github.com/php/php-src.
• Zend Engine: The Zend Engine is bundled as part of the PHP software in the Zend/ directory, found at https://github.com/php/php-src/tree/master/Zend.