Re: PHP licence SFLC questions draft v4
Draft question for SFLC:
(there are no changes since v3 apart from fixes to the numbering of
some section cross-references)
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 three concerns (I, II and III, below), which need to be read
with some context (IV, 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
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 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
(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. Do the answers to these questions depend on whether the addon is
currently, or was ever, distributed via
II. Inaccuracy of the disclaimer text:
The warranty disclaimer text (in capitals after para 6 of the licence)
says that `THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM' etc.
The licence itself (para 1) requires this text to be included.
When the PHP licence is used for software which is not provided by the
PHP development team, the statement appears to be inaccurate.
Q4. Does including this statement pose any ethical, legal or practical
risk in the case where the software is _not_ in fact written or
provided by the PHP Development Team ?
Note that in Debian we do not normally worry whether warranty
disclaimers are effective in protecting Debian contributors. So we
are not interested in whether the warranty disclaimer does its job,
only in whether it poses additional risks (beyond those which we would
hypothetically face if it wasn't present at all) by virtue of it
containing an apparently inaccurate statement.
III. 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
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'. (Note that PHP is not a trademark - this
restriction is applied through the copyright licence.)
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
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.
Q5. 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) ?
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 our activities. 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
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.