Thorsten Glaser wrote:
I understand that's what the PHP developers are trying to express with the PHP LicenseÁ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 ownThe actual PHP is still normally patched in a distribution.+ 4B= On the other hand, minor patches to products already containingAbsolutely no! That would make the situation much worse. This is very vague language, which will not help but add insecurities. (although it's not explictely named as such). You may prefer a term like "substantially modified" but it's the same thing. There are clear cases of minor changes (eg. it applies some three-line patches), clearThere 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 aThe very idea of a distribution doing licence review is to avoid things that could possibly, ever, go to court. 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. http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code#Scratch_Trademark_Policy 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 users). That tried to explain the . Yet some dumb could that their _javascript_-running engineor later. Use Common Sense for determining if it's a minor patch.That does not work in a legal environment, unfortunately. can be named php-foo because he has a series of three-line patches converting one into the other. This was just a proposal that could serve as starting point. I wouldn't expect that PHPThis 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. blindly accepted it without consulting a lawyer! Even with that funny name, it only changes PHPDBG_EXTRA_LIBS="$PHP_READLINE_LIBS" to PHPDBG_EXTRA_LIBS="-ledit -ltermcap".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. 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. I count only 20 :S (all minor things, some that should have been done at PHP)Looking at a BSD… there are 34 patches in MirPorts for PHP as well, (As an aside, it's sad in general to check package patches, since most of them should really be at upstream…) You are creating the patches with a license not allowing binary redistribution?? You leave methough the licence information there is set to say that binaries may not be redistributed. speechless. Well, that would be bad for Debian users just due to not fixing the license to say what theyAnother option would be to simply rename PHP to… Icescriptinglanguage? ;-) 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 license. Thanks for your insights, Thorsten PS: The cvs daemon at anoncvs.mirbsd.org doesn't seem to be listening on its IPv4 interface (81.169.181.30). |