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

From: Date: Wed, 30 Jul 2014 21:55:59 +0000
Subject: Re: Re: Re: [PHP-QA] Debian and the PHP license
References: 1 2 3  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-12117@lists.php.net to get a copy of this message
On 30/07/14 22:00, Stas Malyshev wrote:
On the other hand, my own reading of the PHP Licence is that we may not, in fact, distribute (binaries of) modified versions of PHP software (the interpreter as well as everything else under that licence), period - but
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 fork of PHP, they can distribute it still, but not under the name of "PHP". I don't think Debian even claimed that the thing they distribute under the name of PHP is anything but the original product, so I don't see a problem here. I'm not sure why there's an effort to seek maximally contorted interpretation of the rules that would appear to disallow Debian to do something that Debian is already doing, has been doing for years, and nobody ever objected to Debian doing and nobody ever intends to object. To me this effort does not seem to be constructive, and not leading to any improvement of anything, but only to more inconvenience and annoyance to everybody involved. They have a point. A buggy php version with an added patch that avoids
that it crashes when run on even dates could be considered -from a legal POV- a «derivative product of PHP». Legal-speak is quite different than common sense. Trying to keep the spirit of the PHP License and at the same time solve that strict interpretation, I propose the following change to the PHP License 3.01, which will hopefully please both parties:
--- 3_01.txt    2014-07-30 22:58:13.682449866 +0200
+++ 3_02.txt    2014-07-30 23:20:07.332445907 +0200
@@ -24,6 +24,13 @@
      from group@php.net.  You may indicate that your software works in
      conjunction with PHP by saying "Foo for PHP" instead of calling
      it "PHP Foo" or "phpfoo"
+ + 4½ On the other hand, minor patches to products already containing
+     the "PHP" label, including without exception those fixing its
+     security and/or functionality, are not considered a new product
+     and do not require any additional permission. Nonetheless their
+     version string should be modified in order to clearly differenciate
+     them from the official versions published by the original author(s).
5. The PHP Group may publish revised and/or new versions of the
      license from time to time. Each version will be given a
Notes: There is some ambiguity on what is a «minor patch», but I feel it's better to leave that to the courts should a lawsuit really arise (which would be a non-clear case) than attempting to set an arbitrary limit on number of diff lines or an appropiate ratio with the original code, which would fail sooner or later. Use Common Sense for determining if it's a minor patch. Still, bugfixes are explicitely listed as minor, given that they will be the most common case and the one which concerns Debian modifications. The result of those small modifications of PHP-labeled products is that requisites of §3 and §4 are waived, which IMHO is in the spirit of the PHP License as asserted by the current usage. The mention for modifying the version string was inspired by Thorsten email, and is related to the clause present on other licenses that a Modified work should be presented as such. A variant would be changing the "should" into "shall". I chose the former version to allow waiving the requirement for trivial changes or those without a clear version string (think on builds from git or from proposed patches). The term “original author(s)” was preferred over “The PHP Group” for including works by third parties. PS: 4½ is just a placeholder for discussion, the final version would need renumbering. Would this change have the blessing of Debian and the approval of PHP?

« previous php.pecl.dev (#12117) next »