Debian and the PHP license

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

Unclear or idiosyncratic licenses on projects can often be problematic for distributions. In particular, Debian seems to struggle with more of these license issues than most other distributions, largely because of the project's notorious attention to that kind of detail. Even so, it is a bit surprising to see the distribution wrestling with the PHP license. One might have guessed that any problems with it would have been worked out long ago, but a problem with that license, as it applies to PHP extensions, reared its head (again) at the end of June.

The problem has been present for years. The PHP License, version 3.01—the most recent as of this writing—contains statements about the software it covers that are specific to distributing PHP itself. According to Ondřej Surý, any package that uses the license but does not come from the "PHP Group" does not have a valid license:

I did have a quite long and extensive chat with FTP Masters and our conclusion was that PHP License (any version) is suitable only for software that comes directly from "PHP Group", that basically means only PHP (src:php5) itself.

In fact, the Debian FTP masters, who serve as the gatekeepers on what packages are allowed into the distribution, specifically mention PHP in a Reject FAQ that lists reasons the team may reject packages. For PHP extensions, it says:

includes Zend Engine, so its not applicable to anything else. You have a PHP add-on package (any php script/"app"/thing, not PHP itself) and it's licensed only under the standard PHP license. That license, up to the 3.x which is actually out, is not really usable for anything else than PHP itself. I've mailed our -legal list about that and got only one response, which basically supported my view on this. Basically this license talks only about PHP, the PHP Group, and, so its not applicable to anything else.

Given that the mail referenced is from 2005, this is clearly a longstanding problem, though little seems to have been done about it over the years. PHP has updated its license and removed some of the problematic wording (the "Zend Engine" wording in particular), but there is still a belief that PHP extensions shouldn't be using the PHP license. There are a number of possible solutions to that problem, which Surý outlined. Debian could get the extension upstreams to relicense under the BSD or MIT licenses (for example), show that the software does actually come from the PHP Group, or remove the affected packages from Debian entirely. He also updated a pile of bugs that were filed against various PHP add-on modules.

It's a complicated question and, unsurprisingly, there are multiple interpretations of the license. That is unfortunate, but it is something that only the PHP Group can address—something it seems unwilling to do. There are some who think that anything distributed from PEAR (PHP Extension and Application Repository) that uses the PHP license (version 3.01 or greater) should be considered to have a reasonable license, while others would add code that comes from PECL (PHP Extension Community Library) to that list as well.

But the use of the PHP license is pervasive throughout the PHP ecosystem, well beyond just PEAR and PECL. For example, Mike Gabriel wondered what the problem was for the LGPL-covered Smarty 3 template engine. As Surý pointed out, though, Smarty 3 also uses four separate PHP files that are under the PHP license.

Surý's email subject said that the extensions covered by the PHP license were "not distributable", but others took exception to that claim. The license text says that the software is being distributed by the PHP Group, which is clearly not the case when Debian (or anyone else) distributes. Other, similar language essentially requires the distributor to lie, as Steve Langasek said:

There is nothing in these licenses that makes the software undistributable; it just requires the distributor to attach *false statements* to it as part of distribution. I have no objection to the ftp team's decision to treat this as an automatic reject on this basis - I don't think a license that requires us to make false statements is suitable for main - but it's wrong to claim that these works are undistributable.

But Marco d'Itri thought that none of that mattered. PHP support for certain packages is critical:

Reality check #1: it is quite obvious that even if anybody else accepts this interpretation then nobody cares.

Reality check #2: Debian would not be viable without major packages like PHP support for imagemagick or memcached, if we do we may as well remove the the whole language.

Matthias Urlichs piled on to the "reality check" theme. He agreed that the problem is one that no other distribution cares about and noted that Debian has had these extensions in its repositories for years. Furthermore:

Thus, reality check #3: This license contains some strange terms that make it look like it doesn't really apply to the software it's distributed with, but QUITE OBVIOUSLY the author of the software in question thought otherwise, and there is no actual legal problem (nobody else is complaining about the license, much less threatening to revoke permissions, much less suing somebody). Thus, while we're in a reasonably good position to convince Upstream to fix that problem, filing RC bugs and thus making PHP [unusable] in Debian is certainly going to be regarded as typical Debian principles-above-all overkill but unlikely to be helpful to anybody.

Later in the thread, Urlichs summarized the situation. It is clear, he said, that PHP doesn't care about the misuse of its license and the misusers don't understand that they are making a mistake. Any efforts by Debian to change that just makes the extension authors "consider us quite strange for even mentioning" a license change. He outlined three options: removing the modules ("I'd be for this in a heartbeat if it would make people switch to a saner programming language, but that's wishful thinking"), getting all of the upstreams to change their licenses ("Fat chance"), or biting the bullet and just living with the status quo.

That last option seems to be winning the day (or else everyone ran out of steam to keep arguing). As Russ Allbery put it:

I don't see this as a matter of principle unless the principle is "we refuse to deal with even major software packages that do dumb and self-contradictory things with licenses but without any intent to actually restrict the freedom of the software covered by them." And I don't actually agree with that principle. For stuff not already in Debian, sure, let's stick to a simple policy because we can usually get people to change upstream and make the world a better place, and we don't lose much if we fail. But that doesn't really apply to PHP.

For his part, Surý plans to start closing bugs for those packages that are distributed from PEAR and PECL, which covers most of the affected packages.

While PHP is able to have an unclear license that gets wrongly applied to its extensions (at least in Debian's view), it can only do so because of its popularity—lesser packages may find it much harder to find their way into distributions with oddly constructed licenses. It is important that projects choose their licenses carefully, which is something that many of these extension developers seem to have skipped. It is possible that Debian is being overly critical of the terms, but anyone reading that license may find it to be rather informal and it certainly makes life difficult for distributors. Perhaps that's what the PHP project wants, but one gets the sense that what most project members really want is just to ignore licensing issues altogether.