Re: php5-xapian: PHP licence vs GPL
On 2009-04-17, Ken Arromdee arrom...@rahul.net wrote: (And I was also under the impression that Debian follows the wishes of the copyright holder, so it doesn't matter if this argument has any legal merit, just that the FSF makes it.) Note that there's no FSF copyright code in the xapian-bindings upstream tarball, except for files generated by autoconf, automake, and libtool which are all either not GPL or GPL+exception. So the FSF isn't a relevant copyright holder that I can see, whatever Debian's policy in such matters might be. Cheers, Olly -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
* Olly Betts: It's possible this FAQ entry may not have been updated for GPLv3 - I notice that it talks about PHP4, which is obsolete now, and PHP5 predates GPLv3. Yes, I think this may be the case. I guess Florian's thinking is based on additional restrictions allowed by GPLv3 7c: c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version Right, and there is also this one: d) Limiting the use for publicity purposes of names of licensors or authors of the material; or (When applied to the *PHP* group.) And: e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or If so, the key issue seems to be whether the naming restriction in section 4 of the PHP licence can be considered reasonable: 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from gr...@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 This may not be covered by c), but I think it's covered by e). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
On Sat, 18 Apr 2009 09:52:35 +0200 Florian Weimer wrote: * Olly Betts: It's possible this FAQ entry may not have been updated for GPLv3 - I notice that it talks about PHP4, which is obsolete now, and PHP5 predates GPLv3. Yes, I think this may be the case. The same page extensively talks about GPLv3 and GPLv2, explicitly distinguishing the two versions when a license is compatible with one, but not with the other. See, for instance: | Apache License, Version 2.0 | | This is a free software license, compatible with version 3 of the GPL. | | Please note that this license is not compatible with GPL version 2, | because it has some requirements that are not in the older version. | These include certain patent termination and indemnification provisions. quoted from http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses It's obviously possible that they forgot to update the PHP license entry, but it seems unlikely. Moreover, it should be noted that they also state the Apache License, Version 1.1 is incompatible with the GNU GPL, because of an overly aggressive name-change clause, similar to the one included in the PHP License: | Apache License, Version 1.1 | | This is a permissive non-copyleft free software license. It has a few | requirements that render it incompatible with the GNU GPL, such as | strong prohibitions on the use of Apache-related names. quoted from http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses I guess Florian's thinking is based on additional restrictions allowed by GPLv3 7c: c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version Right, and there is also this one: d) Limiting the use for publicity purposes of names of licensors or authors of the material; or (When applied to the *PHP* group.) And: e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or If so, the key issue seems to be whether the naming restriction in section 4 of the PHP licence can be considered reasonable: 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from gr...@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 This may not be covered by c), but I think it's covered by e). I don't think it's covered by e), either. Clause #4 of the PHP License v3.01 seems to forbid me to use the following names for a derivative work of PHP: * RALPHPANTHER * TELEGRAPHPOLE * GRAPHPOOL * GRAPHPAINTER * GRAPHPRODUCER * ... Since I don't think the above names are confusingly similar to PHP, I am under the impression that no trademark right grants are needed in order to use those names for a server-side script interpreter... At least, this is how I (poorly) understand trademark laws: if I am wrong, anyone who's more knowledgeable than me is encouraged to correct me. Assuming the above is correct, clause #4 of the PHP License v3.01 is doing something more restrictive than simply declining to grant rights under trademark law. Disclaimers, of course: IANAL, TINLA, IANADD, TINASOTODP. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpXngKvWF99A.pgp Description: PGP signature
Re: php5-xapian: PHP licence vs GPL
In message pine.lnx.4.44.0904171144360.27732-100...@violet.rahul.net, Ken Arromdee arrom...@rahul.net writes On Fri, 17 Apr 2009, Anthony W. Youngman wrote: I was under the impression that the FSF thinks that if it's illegal to link a program with GPL software and distribute that, it's also illegal if you just distribute the other program and have the user do the link. HOW? I hope the FSF doesn't think this, because imho it is so sloppy legal thinking as to be incompetent! http://sources.redhat.com/ml/guile/1999-02/msg00151.html This talks about static or dynamic linking. I don't actually see how it applies, because if it's statically linked it's a clear violation - the person distributing the program has to distribute the library as well. But if it's dynamically linked and the program - as distributed - merely EXPECTS to find the library on the target machine, I don't see any violation. http://www.gnu.org/licenses/lgpl-java.html I don't understand this. http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs Also http://www.fsfeurope.org/projects/gplv3/bangalore-rms-transcript : Eben Moglen: As when, for example, people tried to draw a line between static linking and dynamic linking under GPL version two, and we had to keep telling people that whatever the boundary of the work is under copyright law, it doesn't depend upon whether resolution occurs at link time or run time. Ummm... This whole thing is a rather grey area, but I still stick by what I said. You may have noticed references to the system library exception. Is that there as a valid exception, or because they're not sure whether it'll stick in court? At the end of the day, if the proprietary program does not contain any GPL code *as* *shipped*, I find it hard to see a copyright violation suit sticking. Who is violating the GPL? The FSF would like to say it's the proprietary vendor but ... (and it's certainly not the user, the GPL explicitly says they're in the clear). Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
On Sat, 18 Apr 2009, Anthony W. Youngman wrote: I was under the impression that the FSF thinks that if it's illegal to link a program with GPL software and distribute that, it's also illegal if you just distribute the other program and have the user do the link. HOW? I hope the FSF doesn't think this, because imho it is so sloppy legal thinking as to be incompetent! http://sources.redhat.com/ml/guile/1999-02/msg00151.html This talks about static or dynamic linking. I don't actually see how it applies, because if it's statically linked it's a clear violation - the person distributing the program has to distribute the library as well. But if it's dynamically linked and the program - as distributed - merely EXPECTS to find the library on the target machine, I don't see any violation. You don't, but the FSF does. I'm well aware that their reasoning for this is somewhat fuzzy. But that's exactly what they think. It's been their position for over a decade, even though they don't make public pronouncements about it any more and just about everyone not from the FSF thinks that it isn't true. Eben Moglen: As when, for example, people tried to draw a line between static linking and dynamic linking under GPL version two, and we had to keep telling people that whatever the boundary of the work is under copyright law, it doesn't depend upon whether resolution occurs at link time or run time. This whole thing is a rather grey area, but I still stick by what I said. You may have noticed references to the system library exception. Is that there as a valid exception, or because they're not sure whether it'll stick in court? The GPL explicitly says that you're allowed to link with system libraries. At the end of the day, if the proprietary program does not contain any GPL code *as* *shipped*, I find it hard to see a copyright violation suit sticking. Who is violating the GPL? The FSF would like to say it's the proprietary vendor but ... (and it's certainly not the user, the GPL explicitly says they're in the clear). The FSF thinks that a work which is designed to link with GPL code is a derived work of that code and, therefore, would violate copyright when distributed even if no lines of the code have been copied into it. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
Olly Betts o...@survex.com wrote: For reference, this is #513796 in the BTS. Will you summarise/link or should we cc? [...] Steve Langasek: There are several other PHP extensions in circulation that use GPLed libraries, some of them distributed with the PHP source itself. (The readline extension is one example.) Binaries for these modules can't be distributed in Debian, but that doesn't mean you can't write a PHP extension for a GPL library and distribute it on your own. http://article.gmane.org/gmane.linux.debian.devel.legal/7867 [...] * Is the quote above an accurate summary of the currently accepted interpretation? (That mail is from 2003 so perhaps things have changed since). I think it's still accurate. More recent links can be found in http://lists.debian.org/debian-legal/2006/04/msg00117.html The FSF seems to support the general idea of GPL-incompatibility in http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses * If so, is there anything which can be done other than removing php5-xapian from the archive? Relicensing in some way. It might not be simple or even possible, but it seems like the only alternative I can see. See http://fsfeurope.org/projects/ftf/reporting-fixing-violations for a helpful guide. * Assuming php5-xapian must be removed from the archive, can the xapian-bindings source package (which builds bindings for python, ruby, etc too) continue to include (now unused) source code for it, or do I need to prepare a special dfsg version of the upstream source tarball without this code? (I notice Steve says binaries for these modules, which hints that source may be OK). http://trac.xapian.org/ticket/191 makes me think the combination only happens at compile time, so including unused source would be OK. Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
On Fri, 17 Apr 2009, MJ Ray wrote: http://trac.xapian.org/ticket/191 makes me think the combination only happens at compile time, so including unused source would be OK. I was under the impression that the FSF thinks that if it's illegal to link a program with GPL software and distribute that, it's also illegal if you just distribute the other program and have the user do the link. This is the same situation, and therefore would be a GPL violation. (And I was also under the impression that Debian follows the wishes of the copyright holder, so it doesn't matter if this argument has any legal merit, just that the FSF makes it.) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
In message pine.lnx.4.44.0904170825550.19077-100...@violet.rahul.net, Ken Arromdee arrom...@rahul.net writes On Fri, 17 Apr 2009, MJ Ray wrote: http://trac.xapian.org/ticket/191 makes me think the combination only happens at compile time, so including unused source would be OK. I was under the impression that the FSF thinks that if it's illegal to link a program with GPL software and distribute that, it's also illegal if you just distribute the other program and have the user do the link. HOW? I hope the FSF doesn't think this, because imho it is so sloppy legal thinking as to be incompetent! This is the same situation, and therefore would be a GPL violation. (And I was also under the impression that Debian follows the wishes of the copyright holder, so it doesn't matter if this argument has any legal merit, just that the FSF makes it.) Just to explain why the FSF *must* be wrong, ask yourself who *needs* the GPL in the situation you describe. The distributor isn't distributing GPL'd software, so he doesn't need it. The user doesn't need the GPL in order to *use* the GPL'd software - that is EXplicit in the GPL. So where's the violation? Who is copying/distributing/using GPL software in violation of the GPL? Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
On Fri, 17 Apr 2009, Anthony W. Youngman wrote: I was under the impression that the FSF thinks that if it's illegal to link a program with GPL software and distribute that, it's also illegal if you just distribute the other program and have the user do the link. HOW? I hope the FSF doesn't think this, because imho it is so sloppy legal thinking as to be incompetent! http://sources.redhat.com/ml/guile/1999-02/msg00151.html http://www.gnu.org/licenses/lgpl-java.html http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs Also http://www.fsfeurope.org/projects/gplv3/bangalore-rms-transcript : Eben Moglen: As when, for example, people tried to draw a line between static linking and dynamic linking under GPL version two, and we had to keep telling people that whatever the boundary of the work is under copyright law, it doesn't depend upon whether resolution occurs at link time or run time. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
* Olly Betts: To summarise, php5-xapian wraps the GPLv2+ licensed Xapian library for PHP v3.01 licensed PHP5. The PHP license is fine if you use Xapian under the GPLv3. The remaining problem is the Zend license, which contains an advertizing clause. For historical/political reasons, the FSF does not want to make the GPL compatible with such licenses, unfortunately. As a workaround, you can ship php5-xapian packages from your own server because you can make use of the system library exception. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
On Fri, 17 Apr 2009 23:09:57 +0200 Florian Weimer wrote: * Olly Betts: To summarise, php5-xapian wraps the GPLv2+ licensed Xapian library for PHP v3.01 licensed PHP5. The PHP license is fine if you use Xapian under the GPLv3. The FSF seems to disagree: quoting from http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses | PHP License, Version 3.01 | | This license is used by most of PHP4. It is a non-copyleft free | software license. It is incompatible with the GNU GPL because it | includes strong restrictions on the use of “PHP” in the name of derived | products. | | We recommend that you not use this license for anything except PHP | add-ons. As you may see, GPL *incompatibility* is explicitly stated. P.S.: As most debian-legal regulars know, I don't agree that the PHP license is a free software license, but that's another story... -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpHoGPwvRAd1.pgp Description: PGP signature
Re: php5-xapian: PHP licence vs GPL
On 2009-04-17, Francesco Poli f...@firenze.linux.it wrote: On Fri, 17 Apr 2009 23:09:57 +0200 Florian Weimer wrote: * Olly Betts: To summarise, php5-xapian wraps the GPLv2+ licensed Xapian library for PHP v3.01 licensed PHP5. The PHP license is fine if you use Xapian under the GPLv3. The FSF seems to disagree: quoting from http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses | PHP License, Version 3.01 | | This license is used by most of PHP4. It is a non-copyleft free | software license. It is incompatible with the GNU GPL because it | includes strong restrictions on the use of PHP in the name of | derived products. | | We recommend that you not use this license for anything except PHP | add-ons. As you may see, GPL *incompatibility* is explicitly stated. It's possible this FAQ entry may not have been updated for GPLv3 - I notice that it talks about PHP4, which is obsolete now, and PHP5 predates GPLv3. I guess Florian's thinking is based on additional restrictions allowed by GPLv3 7c: c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version If so, the key issue seems to be whether the naming restriction in section 4 of the PHP licence can be considered reasonable: 4. Products derived from this software may not be called PHP, nor may PHP appear in their name, without prior written permission from gr...@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 Since the FSF FAQ describes these as strong restrictions, I guess they at least probably wouldn't regard them as reasonable. Cheers, Olly -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: php5-xapian: PHP licence vs GPL
On 2009-04-17, MJ Ray m...@phonecoop.coop wrote: Olly Betts o...@survex.com wrote: For reference, this is #513796 in the BTS. Will you summarise/link or should we cc? Good question. Since I didn't Cc: the start of the thread, I'll update the bug with a link to this thread, and summarise the consensus if/when one is reached. http://article.gmane.org/gmane.linux.debian.devel.legal/7867 [...] * Is the quote above an accurate summary of the currently accepted interpretation? (That mail is from 2003 so perhaps things have changed since). I think it's still accurate. More recent links can be found in http://lists.debian.org/debian-legal/2006/04/msg00117.html Hmm, neither this nor any of the linked messages seem to talk about GPL compatibility though - they all seem to be discussing if the PHP licence is DFSG compatible at all, and whether it's OK for non-PHP group code. * If so, is there anything which can be done other than removing php5-xapian from the archive? Relicensing in some way. It might not be simple or even possible, but it seems like the only alternative I can see. It's not possible on the Xapian side (unless/until all the Open Muscat code is replaced), and it seems unlikely on the PHP side. Given others seem to have tried and failed to do something about the PHP naming clause, I don't feel optimistic about my own chances. * Assuming php5-xapian must be removed from the archive, can the xapian-bindings source package (which builds bindings for python, ruby, etc too) continue to include (now unused) source code for it, or do I need to prepare a special dfsg version of the upstream source tarball without this code? (I notice Steve says binaries for these modules, which hints that source may be OK). http://trac.xapian.org/ticket/191 makes me think the combination only happens at compile time, so including unused source would be OK. Yes, there's no code under the PHP licence in the upstream Xapian tarballs. Cheers, Olly -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
php5-xapian: PHP licence vs GPL
Hi, For reference, this is #513796 in the BTS. To summarise, php5-xapian wraps the GPLv2+ licensed Xapian library for PHP v3.01 licensed PHP5. The two licences are regarded as incompatible due to the restriction on names containing PHP in clause 4 of the PHP licence. The build process doesn't link against PHP (on Linux), though it does use PHP API header files. PHP is a rather noisy search term (since lots of URLs end .php) but my research of past debian-legal discussion eventually found this from Steve Langasek: There are several other PHP extensions in circulation that use GPLed libraries, some of them distributed with the PHP source itself. (The readline extension is one example.) Binaries for these modules can't be distributed in Debian, but that doesn't mean you can't write a PHP extension for a GPL library and distribute it on your own. http://article.gmane.org/gmane.linux.debian.devel.legal/7867 Also, note that Xapian upstream don't control the copyright of all the code, so aren't able to add a special exception to the licence to allow for the PHP naming restriction. And it seems from past debian-legal discussion that PHP upstream are rather attached to this clause (though it seems to me a trademark would achieve the intended ends much better as a licence clause only has power over software derived from PHP itself). So I don't see relicensing as a plausible route for fixing this problem. So my questions are: * Is the quote above an accurate summary of the currently accepted interpretation? (That mail is from 2003 so perhaps things have changed since). * If so, is there anything which can be done other than removing php5-xapian from the archive? * Assuming php5-xapian must be removed from the archive, can the xapian-bindings source package (which builds bindings for python, ruby, etc too) continue to include (now unused) source code for it, or do I need to prepare a special dfsg version of the upstream source tarball without this code? (I notice Steve says binaries for these modules, which hints that source may be OK). Cheers, Olly -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
