it seems to me that the PHPL was designed to support two development models, with others either not considered (if you’re generously inclined) or deliberately screwed (if you’re not):
1) Zend Technologies, Ltd., who have a (quite understandable) desire to protect their revenue streams whilst providing a “look, but if you touch, you can’t sell touches” license; and
2) corporate in-house developers, who, since they’re not redistributing their PEAR-derived apps or code goodies to the outside world anyway, and thus don’t have to worry about complying with licenses less restrictive than the PHPL.

Personally, I’d like to believe that what the PHP Group meant by Item 6 sould have been better phrased in a manner similar to:
6. Redistributions of any form whatsoever must retain the following
acknowledgment:
“This product is based upon and/or utilises code and/or other
technology components of PHP, which is freely available from
. Therefore, this product is not
guaranteed to function properly from a system on which PHP
has not been properly installed and configured”.

But that and $5 will get you a taxi in New York, too. Somebody wrote an article in one of the Ziff-Davis rags a while back talking about how one thing that was holding back the widespread adoption of open source in the enterprise may be the proliferation of conflicting licenses. I’d like to see attributed and verifiable opinions from competent attorneys in various jurisdictions on how htese licenses coexist. But I agree with the earlier post: definite answers will have to wait until real courts decide real cases - in the writer’s and (code) client’s and users’ jurisdictions. Just because the Internet doesn’t respect borders doesn’t mean that your local law enforcement folks take that into consideration.

The only other solution - and I don’t see this happening - is for open-source legal licenses to be standardised (or at least organised) under UN-sponsored treaty; signatories to the treaty thereby promise to respect those terms within their own legal systems (by passing enabling legislation or whatnot). Yes, it’s complicated, yes, it’s messy, yes, it’s something that most software geeks wish would just Go Away, and no, it’s not going to get resolved anytime soon.

I’m exploring migrating to Python, Ruby and a couple of other candidates simply because of the open questions regarding reuse in PHP. Not perl - any language that brags “There’s always more than one way to do it” just introduces needless complexity into my development life. I’m biling clients based on problems solved, not time spent evaluating which pin will let more angels dance upon its head. PHP is going in that direction; perl is not only there already, but has put up huge billboards advertising the fact.

Just my two cents.

Jeff Dickey

It does, and in multiple ways. Remember, a key statement in the GPL is: “You may not impose *any * further restrictions on the recipients’ exercise of the rights granted herein”

And what does the PHPL do that the GPL doesn’t?

- It restricts the endorsing or promotion of products
- It requires you to include the statement “This product includes PHP”
- By doing so, it requires you to include PHP

All of which are far beyond the requirements of the GPL, and as others have noted, are completely non-sensical OR were not what was originally intended. There are others, but those are crystal clear items that put an undue burden on a php developer trying to use GPL’d code with PHPL’d code.

Helgi’s comments about thinking certain sections don’t apply, and that its only a problem for one OS are all totally inaccurate. Its a problem for anyone trying to follow the law, and respect the terms of the code they use. I use code that is under the GPL. As a result, I cannot use code thats under the PHPL. Considering the usefulness of PEAR, thats a serious problem, and not limited to just one OS, just one programmer, or just one application.

It’s really rather simple: Multiple groups are trying to be reasonable, and the terms of the PHPL just simply aren’t. They make perfect sense for PHP or for a php extension, but not for any applications written in PHP. Which is exactly what the FSF says about the PHPL: “We recommend that you not use this license for anything except PHP add-ons.”

But let me once again remind people.. there are precisely *two* organizations that have actual lawyers looking at the real legal implications of these licenses: Debian, and the Free Software Foundation. If you are comfortable ignoring their published advice, based on legal knowledge, feel free.

For the rest of us, that aren’t lawyers, and that are trying to do the right thing, its an invaluable resource - not one to call “anal”, or ridiculous. If anything, requiring a 20,000 line php app to INCLUDE php itself is the height of ridiculous.

It’s Joshua’s blog, and he said it best: “I want my code to be useful, and I want people writing GPL’d (or any other licensed) apps to feel comfortable using it.”

- Davey

@iamsure: the filter will help you little, since the PEAR base class is PHPL licensed and all PEAR packages use it for error handling in some way or another.

Personally, I don’t hold the FSF up as anything more than they are.. but credit where credit is due - they are a better source for license legal advice than Bob.

I think my solution will be to dual license phpDocumentor and possibly just switch HTML_AJAX (or dual license) to bsd or lgpl (I prefer the lgpl) but that depends on what I can work out with the other authors in both cases.

Really at the end of the day I want my code to be useful, and I want people writing GPL’d (or any other licensed) apps to feel comfortable using it.