There and Back Again

The PHP License

As you might have noticed HTML_AJAX is licensed under the PHP license. It is mainly because it borrows some JavaScript for JPSpan that was released under this license. It has been brought to my attention that there are a number of conditions in the license make its distribution problematic.

The problematic items (at least from a Debian packaging prospective are)

3. The name “PHP” must not be used to endorse or promote products
derived from this software without prior written permission. For
written permission, please contact group@php.net.”

4. Products derived from this software may not be called “PHP”, nor
may “PHP” appear in their name, without prior written permission from
group@php.net. You may indicate that your software works in
conjunction with PHP by saying “Foo for PHP” instead of calling it
“PHP Foo” or “phpfoo”

6. Redistributions of any form whatsoever must retain the following
acknowledgment: “This product includes PHP, freely available from
http ://www.php.net/”.

Generally these terms don’t apply well to stuff that isn’t PHP.

Anyhow how have other people approached this problem. For phpDocumentor im looking towards just doing a dual license with PHP and BSD, just because its been PHP licensed for so long. If I can get Harry to relicense the code I used I might just release HTML_AJAX on the BSD license for the next release, otherwise I guess im stuck unless I finish up all the JS refactoring I have planned.

Update:
Charles Fry wrote up Debian’s concerns and sent them to pear-dev if you want more details on why the license is a problem.

18 thoughts on “The PHP License

  1. Chris Shiflett

    You could always write to the PHP Group to see if any sort of license juggling is even necessary. After all, it sounds like written permission would eliminate all of the problematic items for you.

  2. Joshua Eichorn Post author

    We have written in the phpDocumentor case and gotten approval (quite awhile ago actually) but that still doesn’t help the Debian case. Needing written permission makes it a non free license, plus term 6 seems to say you can’t package it without packaging it with PHP. Or at least thats the debian take.

  3. Helgi Þormar

    If I remember correctly those 3 points you listed above only applies if you have a fork of PHP or it self, not code written in PHP, thus the license has a tad much of info that does not apply to PHP written product them self.

    I recently got approach by a debian developer because on of the package I maintained was under the PHP License and there they highlighted some additional things iirc (one being I think that it was made from Apache License), all very much nitpicking and just really debians way of being a PITA πŸ˜‰
    Needless to say the license was not changed and really PHP apps should not bother IMHO to change their license just because of Debian πŸ™‚

    If you like I can dig up those emails in question, just let me know Joshua.

    Solution to the problem:
    Have one license as is for PHP it self and create another very similar license for PHP products and apps, but who really wants all that trouble because of one OS ? πŸ˜›

  4. Joshua Eichorn Post author

    Reading those email would be great. But i really would like to allow my PEAR code to be shipped with Debian, so I wonder what the solution is.

    Maybe the PHP group could add a small clause in to say those items don’t apply if your not a fork of PHP just to make the debian folks happy.

  5. Stefan Esser

    The Debian guys are sometimes very strange. A PEAR application is NOT derived work of PHP and therefore is not affected by these points of the license at all.

    Derived Work is work that uses the PHP source code itself, or is mainly based on it. The Debian guys should be more concerned with their PHP packages, because those actually violate the PHP license. They ship packages with patches that are not in the Upstream version and therefore they violate the license.

    Btw… The written permission paragraph is according to me and other persons a violation of the OSI definition of Open Source. The OSI definiton of Open Source clearly forbids discrimination of persons or groups. This basicly means, that all parts of the license have to apply to all people. The written permission is clearly a violation of this No-Discrimination paragraph of the OSI definition.

    But hey, the PHP Group thinks up other excuses, why a license that forbids some people to use the source and some others not, is not a discrimination on a day to day basis…

  6. Joshua Eichorn Post author

    Stefan:
    I agree with you on the written permission. I don’t really see the point in any case its like trying to enforce trademark law in your license instead of just using a trademark.

    Anyhow so 3 and 4 don’t apply which I guess affects the Debian sensabilities so i agree it doesn’t matter matter, but what about item 6, does that mean you just have to have a readme with that string in the file and your good?

  7. Stefan Esser

    Ohh hehe, I always ignored the presence of 6) because for me as PHP patcher it was always clear and fullfilled.

    I think Point 6) simply renders the PHP license useless for all applications that are programmed in the PHP language. Those programs do not include the PHP language and therefore fullfilling this paragraph would be nonsense.

  8. iamsure

    I’ve never been able to use PEAR modules for one simple reason: The PHP license. Its incompatible with the GPL, and all my code is under the GPL.

    I’ve asked numerous times for the PEAR website to include the ability to filter based on license, but years have gone by, and they’ve never added it.

    Honestly, using the PHP License for actual PHP applications is a guaranteed “can’t use it” for anyone using any GPL code. What people ‘think’ certain sections means matters little – the FSF has made a very clear statement that the PHPL is incompatible with the GPL, so I can’t use it.

    Would be nice to see more BSDL and GPL PEAR modules, or at least the ability to filter based on license.

    Good luck on finding a compromise.. Debian is great stuff, and their objections are quite reasonable.

  9. Joshua Eichorn Post author

    iamsure, i would like to point out that what the fsf thinks doesn’t really matter any more then anyone else. There interpetation isn’t any more important then anyone elses, until its been upheld in a court. Anyhow, I do think these clasues are a problem with the GPL as well as with Debian.

    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.

  10. iamsure

    Just to clarify, I wasn’t deifying the FSF. I was simply pointing to an organization that has put actual legal resources to the task of clarifying the legal implications of various licenses. Compared with “Bob” on a mailing list, I feel much more confident in their opinion. Further, they have on multiple occasions had their license upheld in courts around the world. I can’t say the same for “Bob”, from a mailing list.

    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. πŸ™‚

  11. Jan Schneider

    iamsure, what you say is only partially correct. While it is true that you can’t use GPL software inside PHP licensed software, AFAIK it is fine to use PHP licensed PEAR packages in your GPL software, as long as you don’t ship it with the PEAR packages bundled. Maybe that would even be possible too, but I am not so confident about this special case.

  12. Lukas

    I agree we dont need the PHP license really in PEAR. Getting all the code relicensed is going to be work but seems doable. We could just as well use BSD, Apache and the LGPL only.

    @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.

  13. Derick Rethans

    The Debian people where bugging me too about Xdebug’s license in a mail called “Why is Xdebug under a non-free license” (it’s a copy of the PHP license with s/PHP/Xdebug). My response as in nicer words “screw off, this is a free license” (http://xdebug.org/archives/xdebug-general/0265.html). IMO the Debian people should remove the legal fingers from their ass and start doing something useful with their time. I do like the distribution (using it myself), but it seems that they want to try to convert all non-GPL software to a GPL license, and that is stupid. I choose for a specific license for a reason (http://xdebug.org/archives/xdebug-general/0267.html), live with it. (And I don’t really care if it’s not available through Debian if they are so bloody anal about this Open Source license).

  14. Lukas

    just to clarify .. I think since most of us all in the “IANAL” category we need to use clear licenses. And while I dont follow the interpretation of the debian guys, I do see that using the PHPL for php user land code is needlessly confusing. You dont expect a license to list a ton of items that are irrelevant .. its almost like a filibuster πŸ™‚

  15. enquest

    Just use GPL or LGPL that are the best. Listen to Stallman he knows why he says the thing he says.

  16. Davey Shafik

    I believe the PHP License does not conflict with the GPL, because those “discrimation” clauses are on the *name* PHP, not the code.

    – Davey

  17. iamsure

    Davey: “I believe the PHP License does not conflict with the GPL”

    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.”

  18. Jeff Dickey

    You know, reading through the PHPL (and IANAL, nor do I play one on TV)…

    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