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