We (at Zend) want to help people get more involved in testing PHPNG (PHP next generation), so we’re started to provide binaries for it, although it’s still a branch on top of PHP’s master branch. See more details about PHPNG on Zeev Suraski’s blog post.
The binaries (64bit) are compatible with Debian testing/unstable and Ubuntu Trusty (14.04) and up. The mod_php is built for Apache 2.4 which all three flavors have.
The repository is at http://repos.zend.com/zend-server/early-access/phpng/
# wget http://repos.zend.com/zend.key -O- 2> /dev/null | apt-key add -
# echo “deb [arch=amd64] http://repos.zend.com/zend-server/early-access/phpng/ trusty zend” > /etc/apt/sources.list.d/phpng.list
# apt-get update
# apt-get install php5
For the task of providing these binaries, I had a pleasure of combining my experience as a member of the Debian PHP team and a Debian Developer with stuff more internal to the PHP development process. Using the already existing Debian packaging enabled me to test more builds scenarios easily (and report problems accoredingly). Hopefully this could also be translated back into providing more experimental packages for Debian and making sure Debian packages are ready for the PHP released after PHP 5.6.
The Debian FTP masters have for quite a while a line in their reject FAQ about the PHP license. Despite that, quite a lot of PHP extensions were uploaded to the archive and accepted. Some are being managed/developed in PHP.net’s PECL website, and are done under the umbrella of the PHP Group, which is the group the PHP license is refers to. Over time, we started to see many more extension being developed outside of the PHP group (both technically with sites like github and copyright wise). This is true to certain degree with the PHP.net’s PEAR website which has software written in PHP.
The issue has been raised again in October 2013 with php-gearman using the PHP license while having different copyright holders (bug #728196). After discussions (ftp masters, release team & Ondřej), it was agreed that the current interpretation is still relevant, and almost all extensions and applications should be either removed or re-licensed by its upstream. This makes the todo list 41 packages long (full list based on Ondřej Surý’s bug reports). Any help with contacting upstream projects, explaining the situation and requesting a license change would be welcomed. We also need to monitor new release based on fulfilling these requests.
Until such a change happen, with automatic removal of packages from testing, we’re going to see packages disappear after mid July. This has a little wider affect due to package dependencies, but for the moment only on testing (Jessie).
The license says you can use free and open source software for any reason, but the FBI wouldn’t agree with your questions… Silk Road operator identified by asking a PHP related question on stackoverflow.
See “The Bonehead Mistake That Brought Down an Online Drug-Dealing Empire” on Slate.com
I’ve noticed that my post from three months ago (“Bye bye non-free PHP JSON extension“) was quoted quite often (thanks (: ). But I also noticed that most people didn’t read the post fully, and didn’t see the replacement package.
Hopefully the title of this post will correct that impression. I’d like to indicate the existence of the php5-json package. It’s part of Debian unstable since June 2013 and testing (jessie) since August 2013.
Users who wish to build the free extension on their own are welcome to download it from PECL at http://pecl.php.net/package/jsonc . It’s a good chance to thank Remi Collet for his work on this replacement. I’m happy that the main Linux distributions have already adopted it.
Two months ago I complained about how hard it was to get patches into PHP as the core member didn’t give much attention for pull requests on github. After posting it on the blog, I raised the issue in the developers mailing list and was suggested to join and help.
A month ago, I started sending a weekly report about new / pending / merged / closed pull requests and got cooperation from the community with reviewing the pull requests and processing them. In this period 40 requests were dealt with (obviously not all merged), and much more are work in progress while the developers are commenting on the requests.
The credit is obviously for the contributors for the patches and the core developers for the work. Stas Malyshev was of special help with this change.
You’re welcome to follow at https://github.com/php/php-src/pulls
One of the various ways to measure an open source project is the way it encourages and accepts patches from community members (or future members). The various open source projects I’m involved with have many ways to send patches: mailing list, bug tracking systems and more recently pre-commit tools for peer review (such as gerrit). Another popular option is to use github’s pull request feature for this. Personally, I find it too complex for simple patches and would prefer gerrit over it.
As part of my work at Zend, I try to make sure patches are sent back upstream. Comparing to other open source projects I know, it seems to me that PHP isn’t open enough for contributions. This might be just my private case, but if not, it would be discouraging people to contribute and blocking the community from expanding.
6 Months ago I submitted patch to #36103 (patch is at #63767), but no response. A month ago I submitted a simple patch to FPM’s shell script (#64764), and no response there as well.
To ease things up, I’ve created a github fork of the php-src repository and sent pull requests with each of the patches (as suggested at http://php.net/git-php.php). Even edited the bugs reports with the pull request details (as they provide such integration). I’m waiting to see if this will trigger a more rapid review process from the project. For the simple patch, I got a response very fast from a user, but still waiting for a core member to check it.
Going over the pull requests (both open and closed), I’m not too optimistic about having the patches merged, judging by past merged patches (most of them are at least 2 months) and by the open patches (e.g. a typos fix patch is waiting for month).
PHP 5.5 rc2 was recently uploaded to Debian unstable by Ondřej Surý. Along side the new PHP version and its features the PHP team has dealt with the JSON extension being non-free because of the “The Software shall be used for Good, not Evil” license (see debian #692613).
php5 (5.5.0~rc1+dfsg-1) experimental; urgency=low
* Add dfsg-repack.sh script to remove non-free JSON module
* Remove php5-json from Provides, since that's no longer true
-- Ondřej Surý <firstname.lastname@example.org> Fri, 17 May 2013 14:41:41 +0200
A package with a DFSG replacement for the JSON extension is waiting in the NEW queue and should be available soon. The new JSON extension was done by Remi Collet (PHP developer and Fedora’s PHP maintainer). Review and patches are welcomed, code is available at https://github.com/remicollet/pecl-json-c . I hope the PHP project will adopt the solution, after claiming they won’t fix it themselves (see php.net #63520).