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
