Проект PHP, который в течение многих лет был обременен проблемами лицензирования, теперь готовится к серьезной и тщательной очистке: предложение во главе с членом сообщества Беном Рэмси.Планируется объявить устаревшими два набора пользовательских лицензий, используемых в настоящее время — лицензию PHP 3.01, которая покрывает большую часть кода, и лицензию Zend 2.0 для кода каталога Zend — и вместо этого использовать лицензию BSD с тремя пунктами (модифицированная BSD) в будущих выпусках.Сообщество PHP в настоящее время голосует по этому RFC «Обновление лицензии PHP» до 4 апреля 2026 года.

На ранних этапах разработки PHP изменения лицензии проекта были довольно частыми: с 1995 по 2006 год PHP претерпел в общей сложности семь изменений лицензий или условий. Первоначально PHP был выпущен под лицензией GPLv2; PHP 3, выпущенный в 1998 году, принял метод двойной авторизации GPLv2 и новую лицензию PHP. Эта новая лицензия была основана на лицензии Apache 1.0 и была сформулирована основателем PHP Расмусом Лердорфом, чтобы сделать PHP более «дружественным» для коммерческих пользователей, сохраняя при этом атрибуты свободного программного обеспечения. Лердорф тогда сказал, что он надеется на то, что PHP останется бесплатным, чтобы коммерческие компании могли опробовать коммерческие версии, не заставляя основных участников чувствовать себя «использованными».
Однако исходная версия пользовательской лицензии PHP включала пункт, требующий письменного разрешения команды разработчиков PHP на коммерческое распространение, что оказалось трудно реализовать на практике и в конечном итоге было удалено в версии PHP 3.0.14. В файле LICENSE, поставляемом с этим выпуском, даже не указан номер версии лицензии.
PHP 4.0, выпущенный в мае 2000 года, представлял собой крупный рефакторинг, который представил движок Zend, написанный Зеевым Сураски и Энди Гутмансом, которые позже основали Zend Technologies в надежде коммерциализировать движок Zend по пути, независимому от PHP. Zend предоставляет проектам PHP лицензии на интеграцию движка Zend в PHP и обещает, что соответствующий код останется под лицензией Zend или другими лицензиями, соответствующими определению открытого исходного кода (OSD), хотя сама лицензия Zend не была официально одобрена Инициативой открытого исходного кода (OSI). С тех пор код в каталоге Zend в дереве исходного кода PHP принял лицензию Zend; PHP 4.0 также полностью отказался от GPLv2 и принял PHP License 2.02.
В последующие годы лицензия PHP продолжала дорабатываться: версия лицензии PHP 3.0 была одобрена OSI, но затем была внесена незначительная модификация, чтобы сформировать лицензию PHP 3.01. Эта модификация изменяет только год авторских прав и способ выражения текста подтверждения для PHP и Zend, но не меняет сами лицензионные права. Однако эта новая версия больше никогда не рассматривалась OSI. Ситуация еще больше усугубляется тем, что текст лицензии якобы применим только к программному обеспечению, выпущенному «PHP Group», которая сама по себе не является юридическим лицом, а представляет собой список из десяти ранних разработчиков PHP. Эта двусмысленность привела некоторых людей к мысли, что программное обеспечение, выпущенное другими организациями, не может по закону использовать лицензию PHP в качестве текста авторизации, что создает практические проблемы для таких проектов, как Debian. Рэмси раскрывает эту историческую подоплеку конкретно в RFC.
В текущем RFC Рэмси предлагает заменить текущую лицензию PHP и лицензию Zend лицензией BSD из трех пунктов, начиная со следующей основной версии (первоначально написанной как PHP 9.0, а затем обновленной до «следующей версии PHP»). Он сказал, что при написании предложения он работал с председателем комитета по лицензированию OSI Памелой Честек для решения соответствующих юридических вопросов и вопросов.
Рэмси сказал, что он поговорил со всеми членами PHP Group, и каждый из них выразил поддержку изменениям. В то же время он также приобрел лицензию у Perforce Software — Perforce взяла Zend под свою защиту в 2019 году благодаря приобретению Rogue Wave, которая приобрела Zend в 2015 году. Можно задаться вопросом: поскольку на протяжении многих лет так много людей отправляли код на PHP, должен ли каждый участник соглашаться, прежде чем лицензия может быть изменена? В RFC точка зрения Рэмси такова: Нет. PHP не требует от участников подписывать соглашение CLA, которое передает авторские права проекту, поэтому участники сохраняют авторские права на внесенный ими код; но при условии, что в них прямо не указаны другие условия лицензирования, их можно рассматривать как предоставление проекту права использовать свои вклады в соответствии с действующей лицензией проекта.
Другими словами, участники владеют авторскими правами на код, который они отправляют, но если не указана другая лицензия, их вклады лицензируются для проекта в соответствии с лицензией, принятой проектом. Рэмси далее указал, что обычно при изменении лицензии проекта с открытым исходным кодом требуется согласие всех правообладателей, поскольку новая лицензия может изменить объём прав, предоставляемых пользователям. Но в этом случае переход на трехпунктовую лицензию BSD не меняет прав, предоставленных другим участникам, кроме PHP Group и Perforce Software. Поэтому он считает, что проектам не нужно запрашивать явное разрешение у всех участников в отдельности.
Хотя RFC отмечает, что по закону согласие не требуется получать в каждом конкретном случае, Рэмси предлагает в качестве «любезности» продлить период обсуждения как минимум на шесть месяцев, чтобы гарантировать, что все заинтересованные стороны имеют адекватную возможность выразить свои взгляды. Поскольку RFC был предложен в июле 2025 года, он выпустил несколько обновлений и напомнил сообществу, что эта тема все еще обсуждается; на данный момент существенных возражений не возникло.
В ходе обсуждения также возник ряд конкретных вопросов. Например, Дерик Ретанс спросил, почему необходимо ждать PHP 9 вместо того, чтобы вносить изменения в «следующую версию» после 8.5. Рэмси ответил, что для этого нет серьезных технических или юридических причин, это просто интуитивное суждение, основанное на ритме версий, и если сообщество посчитает, что более целесообразным завершить изменения в PHP 8.6, он не будет возражать. С тех пор RFC перенес реализацию с «PHP 9» на «следующую версию».
Другой разработчик, Питер Кокот, предложил уточнить совместимость с GPL, чтобы уменьшить проблемы при работе с программным обеспечением под лицензией GPL в будущем. Он отметил, что PHP при сборке имеет возможность связываться с двумя библиотеками под лицензией GPLv3: GNU Readline и GNU dbm (GDBM). Он надеется постепенно отказаться от возможности связывания с этими библиотеками GPL на этапе сборки, чтобы упаковщикам больше не приходилось беспокоиться о потенциальных несовместимостях, и в конечном итоге полностью исключить возможность связывания с GDBM и Readline. Рэмси ответил, что согласно существующей лицензии PHP 3.01 из-за некоторых дополнительных ограничений для пользователей лицензия несовместима с GPL. Эту несовместимость в настоящее время невозможно устранить; однако если вместо этого будет использоваться модифицированная лицензия BSD, то пока окончательный пакет будет выпущен на условиях GPL в целом, таких проблем с совместимостью не будет, что также значительно упростит работу по упаковке дистрибутива.
14 марта 2026 года Рэмси объявил об официальном открытии голосования по RFC. Результаты голосования публично записываются на странице RFC PHP Wiki. Общее количество людей, имеющих право голоса, в настоящее время неизвестно: по подсчетам 2019 года, в общей сложности 180 разработчиков имели право голоса на тот момент. Вскоре после начала голосования 47 человек проголосовали за, двое воздержались. Предварительные результаты показывают, что отношение сообщества к этому предложению весьма положительное, но результат нельзя считать предрешенным до завершения процесса голосования. Независимо от окончательного результата, ясно, что эта очистка и оптимизация разрешений будет невозможна без закулисного общения, координации и содействия Рэмси на протяжении последних нескольких лет.