[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PHP-QA] Debian and the PHP license

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

We are concerned here with the PHP 3.0 Licence, which can be found
here: http://php.net/license/3_0.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, freely available from

This is unproblematic for PHP itself.  However, most PHP addons are
also distributed under the PHP licence.  The worry is that putting
`This product includes PHP' in the copyright information for a PHP
addon package is in fact making a false statement, since the package
itself does not include PHP.

Counterarguments which may be relevant or have been put forward

(a) When a PHP addon is distributed under the PHP licence, the
licensor obviously did not intend the licencees to make a false
statement, and the requirement in the licence should be read down

(b) The word `product' does not refer to a specific package but the to
the system as a whole, including PHP.

(c) PHP addon packages are often distributed from www.php.net and
those packages therefore be regarded as `PHP' 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 ?  Specifically, when preparing and
    distributing Debian package of PHP addon, should we include the
	This product includes PHP, freely available from

Q2. If the answer to Q1 is to 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 materially false or misleading ?

Q3. If the answer to Q1 is to NOT include the statement, does that
   present a risk that the copyrightholders of a PHP addon might be
   able to effectively revoke the Free Software community's ability to
   rely on the licence for existing versions of the addon, by
   insisting on strict compliance with paragraph 6, or by issuing a
   statement `clarifying' their licence ?

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 version of PHP 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.


Reply to: