Francesco Poli writes ("Re: [PHP-QA] Debian and the PHP license"): > Wait! This license version is already obsolete!
Thanks for pointing that out. > Please revise your draft in light of the current > PHP License, version 3.01: > http://php.net/license/3_01.txt > https://lists.debian.org/debian-legal/2005/11/msg00271.html Done - see below. > For the record, my own personal concerns about the PHP License are > described in > https://lists.debian.org/debian-legal/2005/11/msg00272.html I hope I have dealt with these adequately in my draft below. (Your point about the overreach of perhaps forbidding `php' in the names of addons isn't a legal one AFAICT, so I haven't asked anything about it in my draft. It doesn't appear that the ftpmasters agree with your point.) Draft question for SFLC: Some members of the Debian project have some concerns about the PHP licence. These worries are dismissed by other members and by relevant upstreams. We would like some advice. We are concerned here with the PHP 3.01 Licences, which can be found here: http://php.net/license/3_01.txt There are two concerns (I and II, below), which need to be read with some context (III, below): I. Requirement to perhaps-falsely acknowledge: Paragraph 6 of the main licence text requires this notice: "This product includes PHP software, freely available from <http://www.php.net/software/>". This is probably unproblematic for PHP itself. However, most PHP addons are also distributed under the PHP licence. The worry is that putting that statement in the copyright information for a PHP addon package is might be making a false statement, since (i) the package itself does not include PHP and (ii) the addon may not in fact be available via that URL. Counterarguments which may be relevant or have been put forward include: (a) A licensor who uses this licence obviously did not intend the licencees to make a false statement, and the requirement in the licence should be read down accordingly. (b) The word `product' does not refer to a specific package but the to the system as a whole, including PHP itself. (c) PHP addon packages (at least those whose upstream versions are available from www.php.net) should be regarded as `PHP software' for the purposes of this statement. (But what if the addon later ceases to be distributed from www.php.net, or was never so distributed?) We have the following questions: Q1. What is the best approach for Debian and its downstreams to take to comply with this licence ? Should we always include the statement as requested ? Q2. If the answer to Q1 is to always include the statement, does including this statement pose any ethical, legal or practical risk to anyone in the Free Software community ? Is it fair to say that the statement is or can be materially false or misleading ? Q3. Does the answers to these questions depend on whether the addon is currently, or was ever, distributed via http://www.php.net/software/ ? II. Restrictions on the name `PHP' Debian routinely modifies all the software that we distribute, and we expect our downstreams to further modify it. (Because we want the freedom to modify to be available not only to us, but also to all of those downstreams, we have a practice of refusing to submit our modifications for approval and declining to accept any Debian-specific permissions.) Paragraphs 3 and 4 can be read to mean that Debian should not be distributing its modified versions of PHP itself, and of PHP addons, under the name `PHP'. We have been informally assured by members of the PHP community that this is not the intent and that the PHP project does not want us to rename things. Similar situations often arise in relation to trademarks. Our usual approach in such cases has been to rely on the informal assurances, and not seek any kind of formal trademark licence amendment. However, we remain prepared to rename the software. If we receive a formal legal request or threat from a trademark holder, or we hear of our downstreams receiving such communications, we will rename the software to avoid any potential infringement of the trademark. For example, Mozilla insisted on prior written approval of patches, so our version of Firefox is called Iceweasel. Our reactive rather than proactive approach has served us and our downstreams very well. Q4. Does the fact that the PHP licence conditions about the use of the PHP name are contained in the actual copyright licence, rather than in a separate trademark licence, significantly increase the risks we would face if we had a disagreement with upstream about our modifications (or our failure to seek approval) ? III. Context When answering these questions, please have regard to this context: Firstly, as we say above, we are concerned not just about the risk to contributors to and participants in Debian, but also about risks to our downstreams. Our downstreams include derivative distros, individual users, and also other contributors who may simply produce and distribute further-modified versions of some package(s). As a matter of principle, we don't want to expose our downstreams to risks we judge unacceptable for ourselves. Sadly we must consider in this context the fact that it does happen - thankfully rarely - that an upstream takes offence to something Debian does and attempts to revoke or renounce the licence or claim that the licence forbids. It is important to us that we can still, under such conditions, continue to distribute the software (perhaps under a different name), since we may have come to rely on it. However, in general we do not concern ourselves with the risk that future upstream versions of a program will be insufficiently free. It is enough that we and our downstreams have the relevant freedoms in relation to the upstream versions we actually use. In extremis we deal with unfavourable upstream licence changes by forking from the last sufficiently free version. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21467.47439.483047.604...@chiark.greenend.org.uk