Transitioning an Open Source License: Lessons from the PHP Project's Move to BSD

Introduction

Changing the license of an established open-source project is a delicate legal and community process. The PHP project recently completed such a transition, replacing its own custom PHP License and the Zend Engine License with the widely used three-clause BSD license. This how-to guide breaks down the exact steps the PHP project followed, offering a reproducible framework for any project considering a license change. Whether you're maintaining a small library or a major platform, understanding these stages – from gaining written consent from original contributors to navigating a six-month community review – will help you avoid common pitfalls.

What You Need

• Legal expertise – An attorney experienced in open-source licensing to review the proposal and advise on legal questions.
• Written consent – Formal approval from all individuals or entities holding copyright under the old license (e.g., original project founders, corporate successors).
• Community process – A documented RFC or similar proposal mechanism, plus a public discussion period and formal vote.
• Successor cooperation – If the project incorporates code from another entity (e.g., Zend Engine), obtain a formal letter of authority from that entity's legal successor.
• Time – Allow at least six months for community discussion and legal coordination.

Step-by-Step Guide

1. Step 1: Draft and publish an RFC (Request for Comments)

   The process began when a member of the PHP community – in this case, PHP core developer Joe Watkins – wrote a formal proposal to retire the PHP License and relicense under BSD. The RFC outlined the exact changes, the rationale, and a migration plan. Publishing an RFC is critical: it gives stakeholders an early opportunity to review and comment before any binding decisions are made.

2. Step 2: Secure approval from original license holders

   The PHP License grants the PHP Group the authority to change it, but that authority required written consent from each original PHP Group member. Watkins tracked down every living member and obtained their individual approval. This step cannot be skipped – any missing consent can later be challenged. In parallel, Perforce Software, as the legal successor to Zend Technologies (which held the Zend Engine License), provided a formal letter confirming their full authority and support for the change.

3. Step 3: Hire an attorney for legal review

   Watkins engaged a lawyer specializing in open-source licensing to review the proposal and advise on any legal questions that might surface during the discussion period. This proactive legal counsel helped ensure the new license was compatible with all dependencies and that the change wouldn't inadvertently create new obligations or conflicts. The attorney also verified that the written consents were properly executed.

4. Step 4: Open a six-month community discussion period

   Before any vote, the project allowed six months for the wider PHP community to review and debate the proposal. This period served two purposes: it gave developers time to understand the implications, and it surfaced any hidden concerns (such as compatibility with third-party code or trademark issues). During this time, the project maintained a mailing list thread and a dedicated wiki page. The attorney was available to answer legal questions from the community.

5. Step 5: Conduct a formal vote

   After the discussion period closed, the PHP project held a formal vote among its core developers and contributors. The vote was unanimous, reflecting the thorough preparation and community buy-in. The voting process should be transparent, recorded, and follow the project's established governance rules (e.g., simple majority or supermajority).

6. Step 6: Implement the license change in the codebase

   Once the vote passed, the project updated all source files to replace the old PHP License and Zend Engine License headers with the three-clause BSD license. This included updating the LICENSE file, COPYING file, and any documentation that referenced the license. The project also ensured that all new contributions would fall under the new license by updating the contributor agreement or pull request template.

7. Step 7: Announce the change and update external references

   Finally, the project announced the retirement of the PHP license via an official blog post (see this blog entry for the original announcement). They updated the project website, package registries (like Packagist), and any downstream dependency trackers. For maximum transparency, they published the list of consenting original members and the lawyer's statement.

Tips and Best Practices

• Start legal review early. Don't wait until after the RFC is written – involve your attorney from the initial proposal stage to identify potential showstoppers.
• Get written consent, not verbal approval. For each copyright holder, require a signed document or verified email. Verbal agreements can be contested later.
• Plan for extended discussion. Six months may feel long, but it builds trust and reduces the risk of last-minute objections. Shorter periods can alienate part-time contributors.
• Document authority clearly. When dealing with corporate successors (like Perforce for Zend), obtain a formal letter on company letterhead that explicitly grants permission and confirms their right to relicense.
• Communicate frequently. Provide regular updates on the process's progress – who has responded, what legal questions arose, and when the vote will happen.
• Test the new license with your dependencies. Run a license compatibility check (e.g., using FOSSology or SPDX tools) to ensure the new BSD license is compatible with all third-party code you incorporate.
• Update your continuous integration pipeline. Make sure CI scripts check for the correct license header on new pull requests.

By following these steps – as demonstrated by the PHP project – you can retire a custom license and adopt a standard open-source license with minimal disruption.