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

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

Thorsten Glaser wrote:
Ángel González dixit:

On 30/07/14 22:00, Stas Malyshev wrote:
You could not distribute other derived products bearing the name of PHP
- but distributing PHP itself is fine, since it's not a "product derived
from PHP" but the actual PHP. If Debian OTOH decides to make their own
The actual PHP is still normally patched in a distribution.

+  4B= On the other hand, minor patches to products already containing
Absolutely no! That would make the situation much worse.
This is very vague language, which will not help but
add insecurities.
I understand that's what the PHP developers are trying to express with the PHP License
(although it's not explictely named as such). You may prefer a term like "substantially
modified" but it's the same thing.

There is some ambiguity on what is a B+minor patchB;, but I feel it's better
to leave that to the courts should a lawsuit really arise (which would be a
The very idea of a distribution doing licence review is to
avoid things that could possibly, ever, go to court.
There are clear cases of minor changes (eg. it applies some three-line patches), clear
cases of major changes (suppose that the php engine was changed to run _javascript_
instead!) and cases where it's not that clear (and should thus be avoided without a
package rename).

You can see Scratch_Trademark_Policy for an example of lawyer-written text using similar terms.

Please remember that we are just talking about changes that Debian itself may want to
perform (so it doesn't require a renaming which would be bad both for PHP and Debian

or later. Use Common Sense for determining if it's a minor patch.
That does not work in a legal environment, unfortunately.
That tried to explain the . Yet some dumb could that their _javascript_-running engine
can be named php-foo because he has a series of three-line patches converting one
into the other.

This is why the OSI (and many others) say to please leave
writing licences (code for the scripting language called
legalese) to experts (lawyers), just as we’d not want the
lawyers to write C code.
This was just a proposal that could serve as starting point. I wouldn't expect that PHP
blindly accepted it without consulting a lawyer!

Would this change have the blessing of Debian and the approval of PHP?
I highly doubt it. The current php5 source package in Debian
has 49 patches… on top of a 5.6 release candidate. Things like
porting to new platforms, etc. are not minor. One is named
“hack-phpdbg-to-explicitly-link-with-libedit.patch”. You could
say that every distribution makes a fork.
Even with that funny name, it only changes PHPDBG_EXTRA_LIBS="$PHP_READLINE_LIBS" to PHPDBG_EXTRA_LIBS="-ledit -ltermcap".
I have reviewed them. Most are trivial-minor at first sight, often chanes to m4s.
Some fpm patches do define new functions and may deserve a second look (but
are still simple, specially when compared to the full codebase).
use_embedded_timezonedb.patch does , although .

You raise a good point about porting, although it doesn't seem so bad. Those
should be small changes (perhaps problems would appear if you needed to
include a lot of patches copying libc functions not available natively…
but instead of copyng them on each program, they should be a library).

At the end of the day, php is substantially the same software on Linux or Hurd
(where ptrace(2) doesn't work so Debian patched it), using date.timezone or getting
it from /etc/localtime
Changes to the build system seem specially clear as “not changing too much” the program itself.

Looking at a BSD… there are 34 patches in MirPorts for PHP
as well,
I count only 20 :S (all minor things, some that should have been done at PHP)

(As an aside, it's sad in general to check package patches, since most of them
should really be at upstream…)

though the licence information there is set to say
that binaries may not be redistributed. 
You are creating the patches with a license not allowing binary redistribution?? You leave me

Another option would be to simply rename PHP to… Icescriptinglanguage? ;-)
Well, that would be bad for Debian users just due to not fixing the license to say what they
mean. Quite similar to the problem a few years back of djb programs (considered
uncopyrightable by himself) which could not be considered PD due to lack of an explicit

Thanks for your insights, Thorsten

PS: The cvs daemon at anoncvs.mirbsd.org doesn't seem to be listening on its IPv4 interface (

Reply to: