Thanks for the reply.
I see that there is no answer for Q4 in your forwarded mail, was that originally not answered or just lost somewhere when forwarding?
My understanding on the first look is that the PHP license is flawed (tries to limit the usage of php in naming but that is a futile attempt without registering a trademark) but the debian project shouldn't get into any legal trouble from distributing software licensed via the php license and even less likely when distributing software coming from the sources listed on http://www.php.net/software/
Is there anything else I'm missing which would make debian distributing pear/pecl.php.net packages problematic based on this legal advice?
Ferenc Kovacs writes ("Re: debian status on using the PHP license for pear/pecl extensions"):
> I was just wondering if you were contacted or that you still plan to
> publish the legal advice received back then?
Thanks for the reminder. I knew I wouldn't need to make a note in my
Here you go. The mail below is c&p from the "INBOX Presentation"
buffer in my MUA (VM). I have left in the bottom-quote of Lucas
(then-DPL)'s mail which includes, in turn, the questions I drafted. I
have redacted contact information which would identify the specific
SFLC laywer, as I don't have the lawyer's consent to share their
From: [redacted by iwj] <[redacted]@softwarefreedom.org>
To: Neil McGovern <[redacted]@halon.org.uk>, Neil <email@example.com>
CC: Ian Jackson <firstname.lastname@example.org>,
Debian FTP Masters <email@example.com>
Subject: Re: PHP license questions
Date: Wed, 24 Jun 2015 16:38:58 -0400
I have studied your questions with the context provided carefully and
these are my observations and advice.
The PHP license 3.0 is a badly drafted copyright license that attempts
to go beyond the rights afforded by copyright law. It does attempt to
control the use of the term "PHP", which as Ian correctly points out in
his summary, is not trademarked. Despite these requirements, 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. I would generally recommend to refrain using it for
any other software than PHP or PHP add-ons.
>> 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 ?
I think the best approach for Debian is to issue a statement to the
Debian packages include PHP and PHP add-ons but we don't attempt to nor
can we resolve the impossible quandry that the language of the PHP 3.01
license creates. It is a free software license and we modify the
software and correctly designate the source of its origin by calling it
PHP or X for PHP. The license requires us to make a statement,
"This product includes PHP software, freely available from
<http://www.php.net/software/>", the veracity of which cannot be
verified by us, nor can we be held responsible for the maintenance of
The license also makes warranty disclaimers that may be inaccurate in
certain circumstances but all these inconsistencies owe to its drafting
Such a statement or a blog post will clarify your approach and if PHP
community has no objection, it will create an estoppel, if ever, in
future there is a dispute.
>> 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 ?
Yes but a statement from you about your best efforts to resolve this
impossible issue will ensure that you have sufficient defense for any
legal, ethical or practical risk.
>> Q3. Do the answers to these questions depend on whether the addon is
>> currently, or was ever, distributed via
>> http://www.php.net/software/ ?
If the add-ons were available from the link then it is no longer an
inaccurate statement and if they weren't, a statement as suggested above
should cover any risk that you may have.
>> 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.
Same as above.
>> 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 ?
>> 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) ?
No they don't increase your risks as they are attempting to enforce a
trademark rights (that they may or may not have) through a copyright
license, the chances of enforceability of such terms are weak.
On 02/12/2015 09:58 AM, Lucas Nussbaum wrote:
> Dear [first name],
> There has been some discussion in Debian about the status of the PHP
> license. Ian Jackson (Cced) kindly wrote a summary and some questions,
> which you will find below.
> Unfortunately the FTPmasters team, who are in fine responsible for
> making decisions about acceptable software licenses in Debian, have not
> found the time to comment on the questions below. Despite that, I still
> think that it would be very useful to have your opinion about all this.
> The current opinion of FTPmasters (from 2005) is given in
> https://ftp-master.debian.org/REJECT-FAQ.html. However, it hasn't been
> consistantly enforced (we do have some PHP-license-only extensions in
> the Debian archive).
> - Lucas
> ------------------ Ian's questions below this line --------------------
> 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
> http://www.php.net/software/ ?
> 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
> 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'. (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
> 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.
> 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) ?
> IV. 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 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.
[ name and title redacted - iwj ]
Software Freedom Law Center
1995 Broadway Floor 17
New York, NY-10023
[ title redacted ]
K-9, Second Floor
application/pgp-signature [Press RETURN to save to a file]