|This article brought to you by LWN subscribers|
Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.
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:
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:
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:
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:
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, 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:
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.
Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds