In a new post to his site Christian Weiske shares his interaction with the Open Source group at Apple concerning his Structures_Graph PEAR package. While they were interested in the package and its functionality but with one issue.

Fact is that Structures_Graph is used in the PEAR installer, which is shipped as part of OSX's PHP packages. Apple simply wanted to continue their current setup without changing anything

Unfortunately, Apple had issues with the package being under the LGPLv3 license. They had a concern that, in certain circumstances, the license could allow the owner access to other potentially sensitive information from the user. He lists out his options - bascially either changing the license, asking Apple for compensation or just tell them "no". Unfortunately, if they decide that having it under that license isn't acecptable, they may drop PEAR all together (as the package is a part of the installer itself).

On the Laravel News site there's a new post that continues their series about building applications with Composer. In this latest post they talk about the "other half" of the Composer ecosystem - Packagist.

In our last blog post, we saw the basics of Composer but skipped over where it actually finds its packages, and how to publish packages of your own. In this blog post, we will be looking at exactly this, plus some security considerations when using composer in your application.

Packagist is the primary package repository for Composer. This is where you can publish your packages, and also where you can view other people’s packages. Composer will use Packagist to look for packages by default, however, more advanced users can customize this if they wish.

With the basic description out of the way, they then get into how to add your package to Packagist for others to use. The post also talks about package licensing, development versions, branch aliases, security considerations and how to keep on top of new versions of the packages you have installed.

The BugSnag blog has posted a tutorial from a guest author, Graham Campbell, introducing you to Packagist and the PHP ecosystem continuing on from the previous post introducing the Composer tool.

In our last blog post we saw the basics of Composer, but skipped over where it actually finds its packages, and how to publish packages of your own. In this blog post, we will be looking at exactly this, plus some security considerations when using composer in your application.

The post starts off by introducing Packagist and how you can distribute your package there. There's a section that covers Open Source licenses, a few of the different types and how to list licenses of your currently installed packages. Following this the post talks about using branches and aliases to pull in the code you need (not just the latest release). The tutorial wraps up with a look at some of the security concerns around using packages and how to keep on top of new versions with new bugfixes.

If you've been working with open source software for any amount of time, chances are you've seen licenses attached to the projects you've used (or even contributed to). There's quite a few of them out there and it can be confusing as to what's actually covered by them and how it effects you directly. In this recent post to Kyle E. Mitchell's site he explains, line-by-line, one of the most common Open Source licenses: the MIT license.

The MIT License is the most popular open-source software license. Here’s one read of it, line by line.

If you’re involved in open-source software and haven’t taken the time to read the license from top to bottom—it’s only 171 words—you need to do so now. Especially if licenses aren’t your day-to-day. Make a mental note of anything that seems off or unclear, and keep trucking. I’ll repeat every word again, in chunks and in order, with context and commentary. But it’s important to have the whole in mind.

He then walks you through the different sections of the license, explaining what it all means:

• License title (header)
• Copyright notice (header)
• Grant scope (license grant)
• Conditions (license grant)
• Attribution notice, warranty disclaimer and limitation of liability

There's a lot of detail here but in the end you'll definitely understand the license in and out. He ends the post with links to a few other resources that have helped him better understand source licenses.

The PHP Town Hall podcast has released their latest episode today - Episode 22, The Great Joomla! License Battle of 2014 with guests David Stanley and Don Gilbert.

This week Ben Edmunds is joined by new guest David Stanley and recurring guest Don Gilbert to discuss the latest Joomla! framework licensing drama. Phil was too busy having a real world life to join us this week, boo! Don does a great job of articulating why switching the Joomla! Framework to an LGPL license would be best for everyone and just might cure cancer. Ben tries to play devil’s advocate but eventually can’t even maintain the ruse. David talks now and then, mostly about his new found love of the AeroPress.

You can catch this latest episode in a few different ways: either through the in-page audio player, by downloading the mp3 or you can watch the video of the live recording.

In a recent post to the Pantheon blog community member Cal Evans makes one request for the developers out there (PHP and others) - please license your code.

It is wonderful that you have put your code up on GitHub. That is the essence of "Social Coding". However, if you do not put a license on it, you are just teasing developers. In essence, you are saying "See what I made? You can't use it, but I wanted to show you anyhow." Granted, sometimes, developers will use unlicensed code in their projects anyhow, but usually not. Without a proper license, others have no idea what is a permissible use. You wrote it, you own it, you shared it, so let people know they can use it.

He points out that GitHub makes it easy to just throw code up and expose it to the word for use. Unfortunately, due to restrictions put in place by business or technology groups, code without a license simply can't be used. If you're not familiar with code licenses, he links to the Choose a License site that can walk you through the choice via a series of questions.

Despite the misleading title, this post on Reddit talks some about a switch that some Linux distributions are making when it comes to JSON support in PHP. They're moving away from the built-in support in favor of including this one.

In a quote from Nikita Popov (a comment on the post) he notes that:

It is true that some Linux distribution switched from json to json-c, but this should be transparent to the user. The standard PHP distribution still ships the JSON extension as it always did. [...] You should all take this chance to switch to PHP 5.5, so you can see that everything works fine and that PHP 5.5 is awesome

He also includes comments from the Remi (Fedora) project about the switch, noting that the end user shouldn't notice any kind of issues. The reasoning behind the switch has to do with licensing and usage issues of the previously built-in extension. You can find out more about that issue in this bug report.

On PHPMaster.com today there's a new article posted that has a review of PHPStorm, an IDE from JetBrains that focuses on providing a great experience for PHP developers and tons of features.

It's said the tool doesn't make the craft - a carpenter can drive a nail into a wooden plank using a hammer, a rock, another plank, or his forehead, but he'll rarely choose anything other than the hammer. [...] I'm talking about using a text editor versus using a full-fledged PHP-dedicated project-oriented IDE for PHP application development. Both will get the job done, but productivity-wise, one is obviously a better choice than the other.

Bruno Skvorc goes through a brief summary of what the editor is about and talks about some of the more notable features including:

• Being built on Java (good and bad)
• The IDE being strictly project-oriented
• Supports the latest PHP version, including 5.4
• Smart refactoring
• Good intellisense support

He also mentions the plugin architecture that's included with the product and a few of the more handy plugins available. They're also running a giveaway in collaboration with the PHPStorm folks and are giving out IDE licenses and copies of SitePoint's "PHPMaster: Create Cutting Edge Code" book (rules are included in the article).

As Alexey Zakhlestins' mentions on his blog, the PHP-FPM project is now under the BSD license with the potential for it to be included in the main PHP distribution.

PHP-FPM is "deciphered" as "PHP FastCGI Process Manager" and is a patch for php to greatly improve FastCGI SAPI usage in production. It adds a bunch of additional features to php's fastcgi such as: easy php-process daemonization (with ability to specify uid/gid/chroot/log-file), safe php-processes restart (without losing requests), custom error-handling and accelerated file-upload support (requires additional support from web-server).

You can find out more about the project from its main site including a FAQ and documentation to get it up and running.

Time are getting tough out there - a recession is coming around and companies all over are feeling the impact. People are looking for places to save money without having to compromise on functionality and quality. Larger numbers are turning to Open Source communities to provide solutions to fill that gap. Stefan Koopmanschap looks at this trend in his most recent blog post.

As we all know by now, we're living in times of crisis. A recession is hitting us, and it's hitting us hard. Even here in The Netherlands, where at first it seemed we'd be avoiding the biggest hit, we're now getting reports that the recession is the biggest since WWII. The crisis seems to be hitting bigtime in many places. So how does it affect open source and PHP?

Stefan talks about Enterprise resources and their shift in needs away from the "vanity projects" and more into the day-to-day, stable clients. Open Source is giving them a bit of that "fun" back in and allowing them to do more with less - little to no licensing, no vendor lockdown, etc.