Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
On 31/07/14 10:54, Walter Landry wrote: Stas Malyshev smalys...@sugarcrm.com wrote: Would you change the licence to something more usual, like MIT/X style? No, this is completely infeasible That is not correct. It is very easy to change the license because the license has an upgrade clause (condition #5). Of course, if the license is changed, then it shouldn't be MIT/X exactly, but it should be MIT/X plus an upgrade clause. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d9e16a.4020...@bitmessage.ch
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and 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 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. 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. or later. Use Common Sense for determining if it's a minor patch. That does not work in a legal environment, unfortunately. 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. 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. Looking at a BSD… there are 34 patches in MirPorts for PHP as well, though the licence information there is set to say that binaries may not be redistributed. Another option would be to simply rename PHP to… Icescriptinglanguage? ;-) bye, //mirabilos (Debian Developer, but also MirBSD founder) who’d personally prefer to just shut up and hack instead of dealing with legal issues… -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour” -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1407310720520.23...@herc.mirbsd.org
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. 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). 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 speechless. 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 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).
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Ángel González dixit:
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).
Right, but Debian probably (though it’s up to Ondřej Surý, the
maintainer; there is no central instance) would not want to accept
a licence that says “you may keep the name if your patches are
only this small, and if they get bigger or disagree with what
we say, you may not keep the name”.
There is innovation, writing of new code, and patching code when
the packager disagrees with upstream (or – worse – when tech-ctte
says so because some *other* maintainer within Debian is important
enough for them to judge to not force him to fix the bugs in *his*
package instead, and so the packager is in the minority and forced
to deviate from upstream, so that the package still fits into the
distro).
Also, Debian is a bit of promise to downstreams. I am not sure (I
did not specifically look at this part), but I think downstreams
should be able to not need to look at how _much_ patching the
licence allows…
Looking at a BSDb as well,
I count only 20 :S (all minor things, some that should have been done at PHP)
There are some hidden in ../{core,extensions}/patches/
(As an aside, it's sad in general to check package patches, since most of them
should really be at upstreamb
Right. It’s been problematic (and doesn’t scale well when
you’re a small project) to get patches for a non-mainstream
OS into upstream (though the situation did get better over
the years). In fact, most of our patches are carried over
from OpenBSD, who also either did not submit them or did
not have luck with that. (Though their relationship to both
their upstreams and downstreams is a bit special anyway.)
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 speechless.
No, what I meant is: the port metadata says that we may not
distribute the binary packages.
It’s your licence which forbids that ;-)
PS: The cvs daemon at anoncvs.mirbsd.org doesn't seem to be listening on its
IPv4 interface (81.169.181.30).
There is no cvs dæmon, it’s anonymous CVS over ssh. (Nobody
sane uses pserver – it’s susceptible to MITM and all.)
(And yes, I’m gonna update that thing some day… but for what
I’m currently using it, that old beast serves well enough…)
bye,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/pine.bsm.4.64l.1407312028310.12...@herc.mirbsd.org
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
On Wed, Jul 30, 2014 at 1:07 PM, Thorsten Glaser t...@debian.org wrote: Pierre Joye wrote: As Rasmus, and I, said numerous times, the PHP License is a perfectly valid choice as long as the software are distributed under *.php.net. This reading clearly fails DFSG#3 and OSD#3 at the very least, and makes *all* software using the PHP Licence non-free, because redistribution of derived works is only permitted from *.php.net which is clearly inaccep- table. This makes not just forking the software impossible but also dis- tribution of binaries made from modified sources, for example. This is a wrong interpretation. The releases are/must be distributed under *.php.net to be able to use the PHP License. It means that one reading the license after having installed php using apt-get php5 will find all software installed with php5. There is nothing wrong here and nothing about the location of the software release is against Free Software. The incompatibility between Free Software's GPL and the PHP license is only due to the naming restriction and nothing else. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAEZPtU5aXtMHv6o4V5Fw=o-yh77Pd0pDd=o5bbnccrqn62o...@mail.gmail.com
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Hi! This reading clearly fails DFSG#3 and OSD#3 at the very least, and makes *all* software using the PHP Licence non-free, because redistribution of derived works is only permitted from *.php.net which is clearly inaccep- table. This makes not just forking the software impossible but also dis- tribution of binaries made from modified sources, for example. I've by now read the PHP license here: http://php.net/license/3_01.txt about a dozen times and I still can't figure out where the claim redistribution of derived works is only permitted from *.php.net could come from. This of course is false both theoretically and practically. 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. (and it would be fun if Debian distributed Icescriptinglanguage, instead of PHP, except for those affected). I think taking this route would make Debian a huge disservice. Of course, 99.999% of Debian users would immediately switch to using a third-party repo that would include actual PHP packages instead of that contraption, but there's no reason to inflict this onto Debian users. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d94ed1.1020...@sugarcrm.com
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
On 30 July 2014 22:00:17 CEST, Stas Malyshev smalys...@sugarcrm.com wrote: 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. I think everyone does claim that. You do know Debian doesn't just distribute the binaries from Php.net, right? No contortion: the php5 in Debian is a derived work. Here's a list of patches http://sources.debian.net/src/php5/5.6.0%7Erc2%2Bdfsg-5/debian/patches I agree that renaming would not be constructive. Why can't people call this PHP, please, PHP project? Would you change the licence to something more usual, like MIT/X style? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c6887a8b-365a-4cae-8378-51037985d...@email.android.com
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
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.txt2014-07-30 22:58:13.682449866 +0200 +++ 3_02.txt2014-07-30 23:20:07.332445907 +0200 @@ -24,6 +24,13 @@ from gr...@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? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d969ef.7090...@gmail.com
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Ángel González keis...@gmail.com wrote: 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: Stop. Please just stop. Please pick an existing, well known license so that we do not have to argue *again* over whether this really solves all of the problems. Thanks, Walter Landry
RES: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Walter : I agree to stop discussing this. The problem is not PHP. Only Debian can't accept de PHP license. The PHP License is good for PHP as is? YES!!! that's all. Alejandro M.S -Mensagem original- De: Walter Landry [mailto:wlan...@caltech.edu] Enviada em: quarta-feira, 30 de julho de 2014 19:35 Para: keis...@gmail.com Cc: smalys...@sugarcrm.com; t...@debian.org; pecl-...@lists.php.net; debian-legal@lists.debian.org Assunto: Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license ngel Gonz lez keis...@gmail.com wrote: 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: Stop. Please just stop. Please pick an existing, well known license so that we do not have to argue *again* over whether this really solves all of the problems. Thanks, Walter Landry --- Este email está limpo de vírus e malwares porque a proteção do avast! Antivírus está ativa. http://www.avast.com -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/019f01cfac47$be038170$3a0a8450$@com
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Hi! I think everyone does claim that. You do know Debian doesn't just Everyone being whom specifically? distribute the binaries from Php.net, right? No contortion: the php5 in Debian is a derived work. Here's a list of patches http://sources.debian.net/src/php5/5.6.0%7Erc2%2Bdfsg-5/debian/patches There is no such thing as binaries from php.net, at least when Debian-supported OSes are concerned. But even if they were, it's not a separate product in any sane meaning of a product. Adding a config file does not make it into a new product. Neither I have ever seen any communication from Debian claiming it is anything but the product we all know and love as PHP. One could invent a thousand of contorted definition of product, including defining every binary with different sha1 checksum as separate product, but this pointless exercise has nothing to do with PHP and is just that - pointless. I agree that renaming would not be constructive. Why can't people call this PHP, please, PHP project? They can, and they were told so many, many times. Would you change the licence to something more usual, like MIT/X style? No, this is completely infeasible - this would require asking permission from every contributor from the start of the project. Moreover, this titanic effort would be completely useless as it would achieve no useful purpose, because everybody - including Debian - is free to distribute PHP under PHP license right now, and nobody ever tried to prevent anybody from doing so. Literally nobody except Debian people ever said there's any problem in that. Frankly, I am astonished at how much effort is spend to find trouble where there was not ever one. Can't we spend our time on something more useful? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d985bb.5030...@sugarcrm.com
Re: [PECL-DEV] Re: Re: [PHP-QA] Debian and the PHP license
Stas Malyshev smalys...@sugarcrm.com wrote: Would you change the licence to something more usual, like MIT/X style? No, this is completely infeasible That is not correct. It is very easy to change the license because the license has an upgrade clause (condition #5). Cheers, Walter Landry -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140730.175410.333118138785423294.wlan...@caltech.edu
