Kevin Schroeder has a new post to his blog today asking "Why PHP?" - not so much a "why you should chose PHP for your development", more of a why PHP is the way it is.

Today on twitter there was a conversation going on about the responsiveness of the core PHP developers to PHP users. [...] This post isn't necessarily to correct perceived errors, to stand behind correct statements, or to state what I believe the problem is. Rather, it is to add something to the conversation that I don't think I've seen much of. The Twitter conversation was, for me, more of a contemplation kickoff and so the purpose of this post is to propose some thoughts for consideration. I don't have sufficient karma to propose changes directly, but I have bet my career on PHP and I want to see it beat the crap out of every language out there.

He points out that most of the opinions out there seem to be of the "what" PHP is rather than the "why" PHP is. He notes that the discussions about the core development (and developers) that's been happening recently is more of a symptom of a larger problem - an unclear definition as to what PHP is and what problem it's there to solve.

The PHP community, specifically the PEAR group has lost a member of their family - Bertrand Gugger (toggg), a valued contributor to the PEAR project.

The PEAR Project has lost a member of its community. Bertrand Gugger (toggg) passed away in the night from June 16th to 17th after suffering a heart attack.

Bertrand was involved in the maintenance of several important PEAR packages, including the Validate package family.

Posted here, here, here and here is more information about his contributions to the PEAR project and personal experiences with him.

The PHP community, specifically the PEAR group has lost a member of their family - Bertrand Gugger (toggg), a valued contributor to the PEAR project.

The PEAR Project has lost a member of its community. Bertrand Gugger (toggg) passed away in the night from June 16th to 17th after suffering a heart attack.

Bertrand was involved in the maintenance of several important PEAR packages, including the Validate package family.

Posted here, here, here and here is more information about his contributions to the PEAR project and personal experiences with him.

Markus Wolff takes a look at a part of the setup surrounding the Zend Framework in this blog post today - the Framework's CLA.

Contributors to the Zend Framework must first sign a Contributor License Agreement (CLA) before they're allowed to commit anything. This is claimed to make the Zend Framework "IP clean", so big corporations have no problem adopting it.

I've never believed in this proclaimed need of being "IP clean". Maybe that's because stealing someone's proprietary code never came to mind - am I just to good a person? However, in a world where in certain strange countries (I won't drop any names here) you can actually patent software - or worse, ideas - it is increasingly difficult to write a single line of code that you can be sure of not violating anyone else's so-called intellectual property.

He quotes from the CLA's FAQ on the Framework site about the protection this CLA offers to both the Framework and to the developers that contribute to it.

His rebuttal is one of "how can this be enforced?", which, of course, he realizes is just not possible. He casts a "marketing first" light on the CLA, suggesting that it's just a way to help sell it to corporations.

Markus Wolff takes a look at a part of the setup surrounding the Zend Framework in this blog post today - the Framework's CLA.

Contributors to the Zend Framework must first sign a Contributor License Agreement (CLA) before they're allowed to commit anything. This is claimed to make the Zend Framework "IP clean", so big corporations have no problem adopting it.

I've never believed in this proclaimed need of being "IP clean". Maybe that's because stealing someone's proprietary code never came to mind - am I just to good a person? However, in a world where in certain strange countries (I won't drop any names here) you can actually patent software - or worse, ideas - it is increasingly difficult to write a single line of code that you can be sure of not violating anyone else's so-called intellectual property.

He quotes from the CLA's FAQ on the Framework site about the protection this CLA offers to both the Framework and to the developers that contribute to it.

His rebuttal is one of "how can this be enforced?", which, of course, he realizes is just not possible. He casts a "marketing first" light on the CLA, suggesting that it's just a way to help sell it to corporations.

From Stuart Herbert, a developer on the Gentoo project, there's a post with his perspective on the whole Zend Framework issue, but from a bit different angle than most have come from. He looks more at the Contributor License Agreement.

One thing I don't think has had fair praise has been the Contributor License Agreement. Anyone who wants to commit to the Framework has to sign the Contributor License Agreement first. If you're using someone else's code in your product, it's important to know that all the third-party code is their's to relicense in the first place.

As the FAQ says, if you contribute code to the framework, you're not signing over all rights to your code to Zend. It's still your code; you've just granted Zend a license to use the code in the framework. That's very generous of Zend - they could easily have used their position to gobble up all the rights to all contributions. But I think that it'll also turn out to be the keystone that makes the Zend Framework much more successful than the alternatives.

He also mentions Gentoo's own struggles with this kind of licensing in the past.

From Stuart Herbert, a developer on the Gentoo project, there's a post with his perspective on the whole Zend Framework issue, but from a bit different angle than most have come from. He looks more at the Contributor License Agreement.

One thing I don't think has had fair praise has been the Contributor License Agreement. Anyone who wants to commit to the Framework has to sign the Contributor License Agreement first. If you're using someone else's code in your product, it's important to know that all the third-party code is their's to relicense in the first place.

As the FAQ says, if you contribute code to the framework, you're not signing over all rights to your code to Zend. It's still your code; you've just granted Zend a license to use the code in the framework. That's very generous of Zend - they could easily have used their position to gobble up all the rights to all contributions. But I think that it'll also turn out to be the keystone that makes the Zend Framework much more successful than the alternatives.

He also mentions Gentoo's own struggles with this kind of licensing in the past.