Re: [PEAR-QA] PHP License
Sean Kellogg [EMAIL PROTECTED] wrote: [...] When a user downloads phpbb2 and joins it with PHP to create the finished derivative product it seems they are in violation of the license. Can users call the combined thing 0x6a671236 or something? It'd still be accurate to say it's produced from phpbb2. I doubt many of them refer to that bit by name anyway. Yes, it sucks. EU users might not need to worry: I think a directive says that copying necessary to use software isn't infringement (from memory of the summary in last Autumn's copyright consultation paper by the European Commission). I was under the impression that d-l took it as one of its responsibilities to ensure that users don't get put in these sorts of situations. Responsibility to ensure? Can't really ensure it, so can't really take that responsibility on with any honesty. I think we try our best. Is picking this over our best? PHP seem unlikely to try enforcing against phpbb2: Q. I've written a project in PHP that I'm going to release as open source, and I'd like to call it PHPTransmogrifier. Is that OK? A. We cannot really stop you from using PHP in the name of your project unless you include any code from the PHP distribution [...] (from http://www.php.net/license/ ) Having a PEAR-approved licence which requires untruthful statements seems a more obvious and fixable problem. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
On Friday 26 August 2005 02:51 am, MJ Ray wrote: Sean Kellogg [EMAIL PROTECTED] wrote: [...] When a user downloads phpbb2 and joins it with PHP to create the finished derivative product it seems they are in violation of the license. Can users call the combined thing 0x6a671236 or something? It'd still be accurate to say it's produced from phpbb2. I doubt many of them refer to that bit by name anyway. Yes, it sucks. EU users might not need to worry: I think a directive says that copying necessary to use software isn't infringement (from memory of the summary in last Autumn's copyright consultation paper by the European Commission). Well, the US has a similar clause regarding holding necessary copying as non-infringing, which I mentioned in one of the first mails on this subject. But while you certainly wouldn't be liable for it, you would be creating a derivative work... which is all I'm trying to say here. I was under the impression that d-l took it as one of its responsibilities to ensure that users don't get put in these sorts of situations. Responsibility to ensure? Can't really ensure it, so can't really take that responsibility on with any honesty. I think we try our best. Is picking this over our best? PHP seem unlikely to try enforcing against phpbb2: Q. I've written a project in PHP that I'm going to release as open source, and I'd like to call it PHPTransmogrifier. Is that OK? A. We cannot really stop you from using PHP in the name of your project unless you include any code from the PHP distribution [...] If that's cool by Debian, it's certainly cool by me :) (from http://www.php.net/license/ ) Having a PEAR-approved licence which requires untruthful statements seems a more obvious and fixable problem. Yeah, certainly is problematic. -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: [PEAR-QA] PHP License
Sean Kellogg [EMAIL PROTECTED] wrote: [...] As source code, it is not a derivative, I agree... but once it is compiled it is now a derivative work joining the library with the code to form the final binary. Its the act of compilation that creates the derivative work. Most (all?) php applications like phpbb2 are distributed as source and covered only by their licence not the PHP one, last I saw. The compilation happens on the installed system and isn't usually distributed. All this seems moot. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
On Thursday 25 August 2005 02:01 am, MJ Ray wrote: Sean Kellogg [EMAIL PROTECTED] wrote: [...] As source code, it is not a derivative, I agree... but once it is compiled it is now a derivative work joining the library with the code to form the final binary. Its the act of compilation that creates the derivative work. Most (all?) php applications like phpbb2 are distributed as source and covered only by their licence not the PHP one, last I saw. The compilation happens on the installed system and isn't usually distributed. All this seems moot. Yeah, that's certainly one way of looking at it. But then again, the license says Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from [EMAIL PROTECTED] When a user downloads phpbb2 and joins it with PHP to create the finished derivative product it seems they are in violation of the license. I was under the impression that d-l took it as one of its responsibilities to ensure that users don't get put in these sorts of situations. -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: [PEAR-QA] PHP License
On Wed, August 24, 2005 02:39, Alan Knowles wrote: While I agree we probably need to review 3-5.. It may be worth reminding debial-legal that AFAIK packages like phpgroupware, phpbb etc. violate the PHP licence.. So I do hope they are addressing those issues with as much vigor... ;) I don't quite follow you here. PhpBB2 is licenced under the GNU GPL. Reading the PHP licence, the only way it could be bound to the terms of tha licence is when it was derived from PHP itself. I don't think you can call something programmed in PHP derived from PHP. I'm curious how you think phpbb violates this licence, so we can resolve the problem. Regards, Thijs Kinkhorst (Debian phpbb2 co-maintainer) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
On Wed, August 24, 2005 10:20, Joe Stump wrote: On Aug 24, 2005, at 12:41 AM, Thijs Kinkhorst wrote: On Wed, August 24, 2005 02:39, Alan Knowles wrote: While I agree we probably need to review 3-5.. It may be worth reminding debial-legal that AFAIK packages like phpgroupware, phpbb etc. violate the PHP licence.. So I do hope they are addressing those issues with as much vigor... ;) I don't quite follow you here. PhpBB2 is licenced under the GNU GPL. Reading the PHP licence, the only way it could be bound to the terms of tha licence is when it was derived from PHP itself. I don't think you can call something programmed in PHP derived from PHP. I'm curious how you think phpbb violates this licence, so we can resolve the problem. He's referencing the passage that mentions that you can't use PHP in your package name. If you called it BB of PHP it would be fine. I fail to understand why the licence under which the PHP programming language resorts, can govern software under the GPL, since the PHP licence only mentions derivative works, not applications written in that programming language. If phpbb would be a PHP-derivative you would be completely correct. But it's clearly not, so in what way do those terms apply to it? Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
He's referencing the passage that mentions that you can't use PHP in your package name. If you called it BB of PHP it would be fine. --Joe On Aug 24, 2005, at 12:41 AM, Thijs Kinkhorst wrote: On Wed, August 24, 2005 02:39, Alan Knowles wrote: While I agree we probably need to review 3-5.. It may be worth reminding debial-legal that AFAIK packages like phpgroupware, phpbb etc. violate the PHP licence.. So I do hope they are addressing those issues with as much vigor... ;) I don't quite follow you here. PhpBB2 is licenced under the GNU GPL. Reading the PHP licence, the only way it could be bound to the terms of tha licence is when it was derived from PHP itself. I don't think you can call something programmed in PHP derived from PHP. I'm curious how you think phpbb violates this licence, so we can resolve the problem. Regards, Thijs Kinkhorst (Debian phpbb2 co-maintainer) -- PEAR QA Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Joseph C. Stump [EMAIL PROTECTED] http://www.joestump.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
hi folks, On Wed, Aug 24, 2005 at 10:38:23AM +0200, Thijs Kinkhorst wrote: He's referencing the passage that mentions that you can't use PHP in your package name. If you called it BB of PHP it would be fine. I fail to understand why the licence under which the PHP programming language resorts, can govern software under the GPL, since the PHP licence only mentions derivative works, not applications written in that programming language. If phpbb would be a PHP-derivative you would be completely correct. But it's clearly not, so in what way do those terms apply to it? the PHP license can not be enforced on packages written in PHP and distributed under a different license. however, the if PHP has a trademark on the PHP name, this may be a different issue. the php project could, if they had and were actively enforcing their trademark, send us (or certain upstream authors) a cease-and-desist letter requiring that all php libraries/modules/packages not contain the term PHP, or only if we arranged to do so under some agreement (which might or might not include the exchange of cash). however, i don't think they have a trademark (and they are certainly not actively enforcing it if they do, and no trademark notice appears on their homepage), and the pre-existance of a large amount of software with such naming conventions for several years would suggest that they aren't concerned that we name packages to include php, such as libphp-adodb and the like. if they have an issue with the name of an upstream project like phpbb2, then it is between php and phpbb2 developers to work that out, and contact software distributions accordingly after the fact, but again, it's a similar situation based on whether or not they've established and are actively enforcing their trademark rights. hth, sean -- signature.asc Description: Digital signature
Re: [PEAR-QA] PHP License
On Wednesday 24 August 2005 01:38 am, Thijs Kinkhorst wrote: I fail to understand why the licence under which the PHP programming language resorts, can govern software under the GPL, since the PHP licence only mentions derivative works, not applications written in that programming language. If phpbb would be a PHP-derivative you would be completely correct. But it's clearly not, so in what way do those terms apply to it? I'm pretty sure it is a PHP-derivative. It relies on all sorts of built in PHP functions to create the finished work. Perhaps... PERHAPS... the code you download for phpbb, on its own, MIGHT be a separate and distinct work, but it's not phpbb until it's merged with PHP functions to create the finished, derived work. Now, some might claim a defense under (s)107(a)(1) of the U.S. Copyright statute that says that copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner is not infringement... but just because it's not infringement does not make the resulting work a derivative work. So that's why the terms apply, Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: [PEAR-QA] PHP License
Sean Kellogg wrote: On Wednesday 24 August 2005 01:38 am, Thijs Kinkhorst wrote: I fail to understand why the licence under which the PHP programming language resorts, can govern software under the GPL, since the PHP licence only mentions derivative works, not applications written in that programming language. If phpbb would be a PHP-derivative you would be completely correct. But it's clearly not, so in what way do those terms apply to it? I'm pretty sure it is a PHP-derivative. It relies on all sorts of built in PHP functions to create the finished work. Perhaps... PERHAPS... the code you download for phpbb, on its own, MIGHT be a separate and distinct work, but it's not phpbb until it's merged with PHP functions to create the finished, derived work. I see a little problem with this line of reasoning. It would seem to imply that if I post a C program I wrote on my website, in source code form, that program is subject to the license of every libc anyone might ever compile it with. It would also seem to imply that if someone reimplemented PHP from scratch, phpBB would then be subject to that implementation's license as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
On Wednesday 24 August 2005 01:46 pm, Catatonic Porpoise wrote: Sean Kellogg wrote: I'm pretty sure it is a PHP-derivative. It relies on all sorts of built in PHP functions to create the finished work. Perhaps... PERHAPS... the code you download for phpbb, on its own, MIGHT be a separate and distinct work, but it's not phpbb until it's merged with PHP functions to create the finished, derived work. I see a little problem with this line of reasoning. It would seem to imply that if I post a C program I wrote on my website, in source code form, that program is subject to the license of every libc anyone might ever compile it with. I would think the code you post is just code. You're free to post your own code as much as you like. However, if I download that code and use it in conjunction with glibc, then yes, I must abide by the license chosen by the authors of glibc. But it does raise an interesting question... Assume the developer of phpBB never actually downloads PHP, and never agrees to the PHP3.0 license. Develops the entire thing without any testing against PHP and then releases it, calling it phpBB in violation of the PHP3.0 license. Since the developer hasn't agreed to its terms, there is no enforcement mechanism. But what about end users who have to use phpBB in conjunction with PHP? Would it be a violation of the license to use PHP with a product whose name includes php in a prohibited manner? An interesting hypothetical. But if we assume the developers of phpBB actually downloaded PHP, they agreed to not make derivative software with certain titles. Going back to the C example you raised... the developer of the C program must abide by the terms of the libc he or she chose to develop with. What end users chose to do, or agree to, is not the developers concern. It would also seem to imply that if someone reimplemented PHP from scratch, phpBB would then be subject to that implementation's license as well. I don't think so... hopefully my rambling above cleared that up. -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: [PEAR-QA] PHP License
Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 24 August 2005 01:46 pm, Catatonic Porpoise wrote: Sean Kellogg wrote: I'm pretty sure it is a PHP-derivative. It relies on all sorts of built in PHP functions to create the finished work. Perhaps... PERHAPS... the code you download for phpbb, on its own, MIGHT be a separate and distinct work, but it's not phpbb until it's merged with PHP functions to create the finished, derived work. I see a little problem with this line of reasoning. It would seem to imply that if I post a C program I wrote on my website, in source code form, that program is subject to the license of every libc anyone might ever compile it with. I would think the code you post is just code. You're free to post your own code as much as you like. However, if I download that code and use it in conjunction with glibc, then yes, I must abide by the license chosen by the authors of glibc. But it does raise an interesting question... [...] But if we assume the developers of phpBB actually downloaded PHP, they agreed to not make derivative software with certain titles. Going back to the C example you raised... the developer of the C program must abide by the terms of the libc he or she chose to develop with. I build my code on a variety of systems, including Linux/glibc, *BSD, Solaris, AIX, MacOSX, etc. Does this mean that my programs are derivatives of all these C libraries/compilers? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
On Wednesday 24 August 2005 02:17 pm, Måns Rullgård wrote: Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 24 August 2005 01:46 pm, Catatonic Porpoise wrote: Sean Kellogg wrote: I'm pretty sure it is a PHP-derivative. It relies on all sorts of built in PHP functions to create the finished work. Perhaps... PERHAPS... the code you download for phpbb, on its own, MIGHT be a separate and distinct work, but it's not phpbb until it's merged with PHP functions to create the finished, derived work. I see a little problem with this line of reasoning. It would seem to imply that if I post a C program I wrote on my website, in source code form, that program is subject to the license of every libc anyone might ever compile it with. I would think the code you post is just code. You're free to post your own code as much as you like. However, if I download that code and use it in conjunction with glibc, then yes, I must abide by the license chosen by the authors of glibc. But it does raise an interesting question... [...] But if we assume the developers of phpBB actually downloaded PHP, they agreed to not make derivative software with certain titles. Going back to the C example you raised... the developer of the C program must abide by the terms of the libc he or she chose to develop with. I build my code on a variety of systems, including Linux/glibc, *BSD, Solaris, AIX, MacOSX, etc. Does this mean that my programs are derivatives of all these C libraries/compilers? Yeah, I believe so. This is why glibc is under the LGPL. It's really easy to create derived works under U.S. Law. As a side note, there is some really interesting unexplored areas of law relating to derivative works and things like dynamic vs. static linked libraries. There is some case law, but I think it leaves a lot unanswered. For the purposes of this discussion, I'm supporting the popular contention that using a dynamically linked library creates a derivative work (although, I have my doubts). -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: [PEAR-QA] PHP License
Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 24 August 2005 02:17 pm, Måns Rullgård wrote: Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 24 August 2005 01:46 pm, Catatonic Porpoise wrote: Sean Kellogg wrote: I'm pretty sure it is a PHP-derivative. It relies on all sorts of built in PHP functions to create the finished work. Perhaps... PERHAPS... the code you download for phpbb, on its own, MIGHT be a separate and distinct work, but it's not phpbb until it's merged with PHP functions to create the finished, derived work. I see a little problem with this line of reasoning. It would seem to imply that if I post a C program I wrote on my website, in source code form, that program is subject to the license of every libc anyone might ever compile it with. I would think the code you post is just code. You're free to post your own code as much as you like. However, if I download that code and use it in conjunction with glibc, then yes, I must abide by the license chosen by the authors of glibc. But it does raise an interesting question... [...] But if we assume the developers of phpBB actually downloaded PHP, they agreed to not make derivative software with certain titles. Going back to the C example you raised... the developer of the C program must abide by the terms of the libc he or she chose to develop with. I build my code on a variety of systems, including Linux/glibc, *BSD, Solaris, AIX, MacOSX, etc. Does this mean that my programs are derivatives of all these C libraries/compilers? Yeah, I believe so. That's absurd. In theory, I could write the code without access to any of the libraries, only using the POSIX spec for reference. The result could be compiled and run on any POSIX compliant system (and there are some). Now in practice, I'll occasionally make a mistake, so I need to test the code to make sure it works. If this makes my program a derivative of all these C libraries, I'm in real trouble, since I have no license to create such derivatives of most of them. This is why glibc is under the LGPL. No, the reason for that is that the FSF insists that using the GPL would disallow non-GPL programs linking with it at all, and for whatever reason they don't want that situation. It's really easy to create derived works under U.S. Law. As a side note, there is some really interesting unexplored areas of law relating to derivative works and things like dynamic vs. static linked libraries. There is some case law, but I think it leaves a lot unanswered. Indeed. For the purposes of this discussion, I'm supporting the popular contention that using a dynamically linked library creates a derivative work (although, I have my doubts). The same logic applies here. If the program can work with either of several different libraries, it is not a derivative of any. If it were, we'd have the absurd situation of programs being derivatives of libraries written after the program. Clearly, this is not possible. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
On Wednesday 24 August 2005 03:44 pm, Måns Rullgård wrote: Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 24 August 2005 02:17 pm, Måns Rullgård wrote: Sean Kellogg [EMAIL PROTECTED] writes: On Wednesday 24 August 2005 01:46 pm, Catatonic Porpoise wrote: Sean Kellogg wrote: I'm pretty sure it is a PHP-derivative. It relies on all sorts of built in PHP functions to create the finished work. Perhaps... PERHAPS... the code you download for phpbb, on its own, MIGHT be a separate and distinct work, but it's not phpbb until it's merged with PHP functions to create the finished, derived work. I see a little problem with this line of reasoning. It would seem to imply that if I post a C program I wrote on my website, in source code form, that program is subject to the license of every libc anyone might ever compile it with. I would think the code you post is just code. You're free to post your own code as much as you like. However, if I download that code and use it in conjunction with glibc, then yes, I must abide by the license chosen by the authors of glibc. But it does raise an interesting question... [...] But if we assume the developers of phpBB actually downloaded PHP, they agreed to not make derivative software with certain titles. Going back to the C example you raised... the developer of the C program must abide by the terms of the libc he or she chose to develop with. I build my code on a variety of systems, including Linux/glibc, *BSD, Solaris, AIX, MacOSX, etc. Does this mean that my programs are derivatives of all these C libraries/compilers? Yeah, I believe so. That's absurd. In theory, I could write the code without access to any of the libraries, only using the POSIX spec for reference. The result could be compiled and run on any POSIX compliant system (and there are some). Now in practice, I'll occasionally make a mistake, so I need to test the code to make sure it works. If this makes my program a derivative of all these C libraries, I'm in real trouble, since I have no license to create such derivatives of most of them. I must be failing to explain this very well... because I feel like I've addressed this before. Critical to this discussion is that the law finds distinction between source code and object code. Source code, like what you wrote in the hypo above, is an original work. You are free to do whatever you want with that source code. But when you compile that source code, you include bits and peices of the C library you are compiling against, and as a result you create a derivative work. As for the license, I suggest to you most of the C libraries you are using do give you permission to create derivative works (although they may not call them derivatives) or there is an understood implicit license to create limited derivative works necessary for creating your binaries. This is why glibc is under the LGPL. No, the reason for that is that the FSF insists that using the GPL would disallow non-GPL programs linking with it at all, and for whatever reason they don't want that situation. We are saying the same thing... although you do so in a manner that suggests you disagree with the FSF position on the GPL. It's really easy to create derived works under U.S. Law. As a side note, there is some really interesting unexplored areas of law relating to derivative works and things like dynamic vs. static linked libraries. There is some case law, but I think it leaves a lot unanswered. Indeed. For the purposes of this discussion, I'm supporting the popular contention that using a dynamically linked library creates a derivative work (although, I have my doubts). The same logic applies here. If the program can work with either of several different libraries, it is not a derivative of any. If it were, we'd have the absurd situation of programs being derivatives of libraries written after the program. Clearly, this is not possible. As source code, it is not a derivative, I agree... but once it is compiled it is now a derivative work joining the library with the code to form the final binary. Its the act of compilation that creates the derivative work. -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://www.probonogeek.org So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: [PEAR-QA] PHP License
While I agree we probably need to review 3-5.. It may be worth reminding debial-legal that AFAIK packages like phpgroupware, phpbb etc. violate the PHP licence.. So I do hope they are addressing those issues with as much vigor... ;) The easiest solution is probably need to call this the PEAR licence... and just rename the phrases in 3-5 to say PEAR instead of PHP Regards Alan On Tue, 2005-08-23 at 18:30 -0400, Charles Fry wrote: Hi, I am working with other members of the Debian devlopment team to include many of your fine PEAR packages in Debian. One recurring problem has been consistently arising however, that we have had a hard time addressing at the correct level, which is why I am contacting you about it. The problem is that many of the PEAR packages are licensed under the PHP License. As you probably know, many packages take the PHP License by default, probably because they assume that they are writting in PHP and so they want to use the same license. The problem is that the current version of The PHP License (version 3.0) contains several clauses which are specific to the PHP language, and either inapplicable or even problematic for applications written in PHP. For the sake of completeness, and in an effort to get this issue ironed out once and for all, let's walk through the six points of The PHP License: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. These two points are almost identical to the first two points in the BSD License, and are all kinds of good. :-) 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 [EMAIL PROTECTED] 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from [EMAIL PROTECTED] You may indicate that your software works in conjunction with PHP by saying Foo for PHP instead of calling it PHP Foo or phpfoo Hmm. These two points are very specific to distributions of the PHP language. A PHP application that is distributed separately from PHP itself should 1) not need to stipulate how the name PHP is used, and 2) probably lacks any authority to make such claims. 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License. Good, good. 6. Redistributions of any form whatsoever must retain the following acknowledgment: This product includes PHP, freely available from http://www.php.net/. Ouch. This means that I can't distribute a PEAR module released under the PHP License without bundling in PHP itself. This makes it impossible to distribute PEAR modules by themselves (i.e. not bundled with the PHP language) in a deb or an rpm. :-( The problem is severe enough that we are currently unable to package PEAR modules for Debian when they are relased under the PHP License. We attempt to contact the upstream authors, and ask them to adopt a new license, but our requests are not always accepted. So, what can be done to rectify this situation? 1) The PHP License itself could be modified to become a more generic license, removing points that don't apply to PHP applications, making it compatible with its current use by most PEAR modules. (Arguably the resultant license would be indistinguishable from the BSD license.) 2) The PEAR Group could change its licensing policy, and no longer include the PHP License in the list of officially acceptable PEAR licenses. Of course it might take a while for existing modules to be changed, but if the PEAR Group had an official position on this, it would be a lot easier for us to work with individual package maintainers to incrementally make this change. Your assistance in finding a workable solution to this problem is solicited. As you can tell, we at Debian are quite excited about PEAR and the clean interface which it provides for installing and working with PHP modules. Thus our interest in working this issue out, so that we can include more PEAR modules in Debian. :-) Let me clarify that while I maintain several Debian
Re: [PEAR-DEV] Re: [PEAR-QA] PHP License
I agree. I never understood why we used the PHP license over, say, the BSD or LGPL (which both fit library level type code a lot better IMO). To have the license require distribution of PHP is a little odd. What I'm a tad more confused about is why anyone would maintain their packages through apt instead of pear.pear upgrade Package_Name- or -pear upgrade-allTranslates about as well as "apt-get install php4-pear-package-name" I would think.--JoeOn Aug 23, 2005, at 5:39 PM, Alan Knowles wrote:While I agree we probably need to review 3-5.. It may be worthreminding debial-legal that AFAIK packages like phpgroupware, phpbb etc.violate the PHP licence.. So I do hope they are addressing those issueswith as much vigor... ;)The easiest solution is probably need to call this the PEAR licence...and just rename the phrases in 3-5 to say PEAR instead of PHPRegardsAlanOn Tue, 2005-08-23 at 18:30 -0400, Charles Fry wrote: Hi,I am working with other members of the Debian devlopment team to includemany of your fine PEAR packages in Debian. One recurring problem hasbeen consistently arising however, that we have had a hard timeaddressing at the correct level, which is why I am contacting you aboutit.The problem is that many of the PEAR packages are licensed under the PHPLicense. As you probably know, many packages take the PHP License bydefault, probably because they assume that they are writting in PHP andso they want to use the same license.The problem is that the current version of The PHP License (version 3.0)contains several clauses which are specific to the PHP language, andeither inapplicable or even problematic for applications written in PHP.For the sake of completeness, and in an effort to get this issue ironedout once and for all, let's walk through the six points of The PHPLicense: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.These two points are almost identical to the first two points in the BSDLicense, and are all kinds of good. :-) 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 [EMAIL PROTECTED]. 4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from [EMAIL PROTECTED]. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"Hmm. These two points are very specific to distributions of the PHPlanguage. A PHP application that is distributed separately from PHPitself should 1) not need to stipulate how the name "PHP" is used, and2) probably lacks any authority to make such claims. 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.Good, good. 6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes PHP, freely available from http://www.php.net/".Ouch. This means that I can't distribute a PEAR module released underthe PHP License without bundling in PHP itself. This makes it impossibleto distribute PEAR modules by themselves (i.e. not bundled with the PHPlanguage) in a deb or an rpm. :-(The problem is severe enough that we are currently unable to packagePEAR modules for Debian when they are relased under the PHP License. Weattempt to contact the upstream authors, and ask them to adopt a newlicense, but our requests are not always accepted.So, what can be done to rectify this situation? 1) The PHP License itself could be modified to become a more generic license, removing points that don't apply to PHP applications, making it compatible with its current use by most PEAR modules. (Arguably the resultant license would be indistinguishable from the BSD license.) 2) The PEAR Group could change its licensing policy, and no longer include the PHP License in the list of officially acceptable PEAR licenses. Of course it might take a while for existing modules to be changed, but if the PEAR Group had an official position on this, it would be a lot easier for us to work with individual package maintainers to incrementally make this change.Your assistance in finding a workable solution to
Re: [PEAR-QA] PHP License
On Tue, Aug 23, 2005 at 05:46:58PM -0700, Joe Stump wrote: odd. What I'm a tad more confused about is why anyone would maintain their packages through apt instead of pear. pear upgrade Package_Name - or - pear upgrade-all Translates about as well as apt-get install php4-pear-package-name I would think. Depends: php-mail-mime - Matt signature.asc Description: Digital signature
Re: [PEAR-DEV] Re: [PEAR-QA] PHP License
On Tuesday 23 August 2005 05:46 pm, Joe Stump wrote: I agree. I never understood why we used the PHP license over, say, the BSD or LGPL (which both fit library level type code a lot better IMO). To have the license require distribution of PHP is a little odd. What I'm a tad more confused about is why anyone would maintain their packages through apt instead of pear. pear upgrade Package_Name - or - pear upgrade-all Translates about as well as apt-get install php4-pear-package-name I would think. - Consistency. If there were many packaging systems, the OS as a whole would be an inconsistent mishmash. - Security. Debian has a centralized security system, and using a 3rd-party packaging system on a Debian box defeats that. - Because Debian Stable should be Debian Stable. PEAR_FooBar 1.0.6 may have a fix for a security issue or critical bug, but may break in relation to 0.9.0b3 or 1.0.1, as shipped with the last Debian Stable. Upgrading to PEAR_FooBar 1.0.6 is an unknown quantity, while you know that your packages will only get BC fixes when upgrading with apt-get. pgpkydGmBPwdl.pgp Description: PGP signature
Re: [PEAR-QA] Re: [PEAR-DEV] Re: [PEAR-QA] PHP License
On Tuesday 23 August 2005 09:34 pm, Justin Patrin wrote: On 8/23/05, Ian Eure [EMAIL PROTECTED] wrote: On Tuesday 23 August 2005 05:46 pm, Joe Stump wrote: I agree. I never understood why we used the PHP license over, say, the BSD or LGPL (which both fit library level type code a lot better IMO). To have the license require distribution of PHP is a little odd. What I'm a tad more confused about is why anyone would maintain their packages through apt instead of pear. pear upgrade Package_Name - or - pear upgrade-all Translates about as well as apt-get install php4-pear-package-name I would think. - Consistency. If there were many packaging systems, the OS as a whole would be an inconsistent mishmash. - Security. Debian has a centralized security system, and using a 3rd-party packaging system on a Debian box defeats that. - Because Debian Stable should be Debian Stable. PEAR_FooBar 1.0.6 may have a fix for a security issue or critical bug, but may break in relation to 0.9.0b3 or 1.0.1, as shipped with the last Debian Stable. Upgrading to PEAR_FooBar 1.0.6 is an unknown quantity, while you know that your packages will only get BC fixes when upgrading with apt-get. And someone working in Debian is checking all PEAR packages for BC breaks? For security updates, yes. Only the fix in question is backported, not the full set of changes. Come on now. PEAR packages adhere to BC rules. Any stable package *may not break BC*. If a new release breaks BC it's a bug and will be fixed either by the author or the QA team. I honestly don't see how a Debian maintainer is going to know about and deal with BC problems any better than the PEAR QA team. I believe there have been several instances where these rules weren't followed. Also, there's the possibility for more subtle breakage. Consider that some functions work, but return notices from one stable version to another. Net_Curl is one example, and I know that QuickForm also does something similar, though I don't know if the change happened from a.b.c to a.b.c+1 or a+1.0.0. While the calls may still work, the behavior isn't the same as before, and could easily cause problems, particularly when used in an XHTML site, where they could break a page's well-formedness. Backporting only the security fix avoids this problem. pgpFTVRQgkPUB.pgp Description: PGP signature
Re: [PEAR-QA] Re: [PEAR-DEV] Re: [PEAR-QA] PHP License
On 8/23/05, Ian Eure [EMAIL PROTECTED] wrote: On Tuesday 23 August 2005 05:46 pm, Joe Stump wrote: I agree. I never understood why we used the PHP license over, say, the BSD or LGPL (which both fit library level type code a lot better IMO). To have the license require distribution of PHP is a little odd. What I'm a tad more confused about is why anyone would maintain their packages through apt instead of pear. pear upgrade Package_Name - or - pear upgrade-all Translates about as well as apt-get install php4-pear-package-name I would think. - Consistency. If there were many packaging systems, the OS as a whole would be an inconsistent mishmash. - Security. Debian has a centralized security system, and using a 3rd-party packaging system on a Debian box defeats that. - Because Debian Stable should be Debian Stable. PEAR_FooBar 1.0.6 may have a fix for a security issue or critical bug, but may break in relation to 0.9.0b3 or 1.0.1, as shipped with the last Debian Stable. Upgrading to PEAR_FooBar 1.0.6 is an unknown quantity, while you know that your packages will only get BC fixes when upgrading with apt-get. And someone working in Debian is checking all PEAR packages for BC breaks? Come on now. PEAR packages adhere to BC rules. Any stable package *may not break BC*. If a new release breaks BC it's a bug and will be fixed either by the author or the QA team. I honestly don't see how a Debian maintainer is going to know about and deal with BC problems any better than the PEAR QA team. -- Justin Patrin
Re: [PEAR-QA] Re: [PEAR-DEV] Re: [PEAR-QA] PHP License
Can you please make this another thread, this is outside the scope of the original message :) Arnaud. Ian Eure wrote: On Tuesday 23 August 2005 09:34 pm, Justin Patrin wrote: On 8/23/05, Ian Eure [EMAIL PROTECTED] wrote: On Tuesday 23 August 2005 05:46 pm, Joe Stump wrote: I agree. I never understood why we used the PHP license over, say, the BSD or LGPL (which both fit library level type code a lot better IMO). To have the license require distribution of PHP is a little odd. What I'm a tad more confused about is why anyone would maintain their packages through apt instead of pear. pear upgrade Package_Name - or - pear upgrade-all Translates about as well as apt-get install php4-pear-package-name I would think. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] Re: [PEAR-DEV] Re: [PEAR-QA] PHP License
On Tue, Aug 23, 2005 at 09:34:18PM -0700, Justin Patrin wrote: On 8/23/05, Ian Eure [EMAIL PROTECTED] wrote: On Tuesday 23 August 2005 05:46 pm, Joe Stump wrote: I agree. I never understood why we used the PHP license over, say, the BSD or LGPL (which both fit library level type code a lot better IMO). To have the license require distribution of PHP is a little odd. What I'm a tad more confused about is why anyone would maintain their packages through apt instead of pear. pear upgrade Package_Name - or - pear upgrade-all Translates about as well as apt-get install php4-pear-package-name I would think. - Consistency. If there were many packaging systems, the OS as a whole would be an inconsistent mishmash. - Security. Debian has a centralized security system, and using a 3rd-party packaging system on a Debian box defeats that. - Because Debian Stable should be Debian Stable. PEAR_FooBar 1.0.6 may have a fix for a security issue or critical bug, but may break in relation to 0.9.0b3 or 1.0.1, as shipped with the last Debian Stable. Upgrading to PEAR_FooBar 1.0.6 is an unknown quantity, while you know that your packages will only get BC fixes when upgrading with apt-get. And someone working in Debian is checking all PEAR packages for BC breaks? Come on now. PEAR packages adhere to BC rules. Any stable package *may not break BC*. If a new release breaks BC it's a bug and will be fixed either by the author or the QA team. I honestly don't see how a Debian maintainer is going to know about and deal with BC problems any better than the PEAR QA team. If this is the same sort of BC support that PHP upstream provides, it will be of little comfort to users of Debian's stable PHP packages when a security update is made available only for a newer major version of the PEAR package which doesn't support the frozen version of PHP that we've shipped... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
