Re: [PHP-QA] Debian and the PHP license
MJ Ray writes (Re: [PHP-QA] Debian and the PHP license): On 4 August 2014 13:26:11 GMT+01:00, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Can you please confirm that the question I put in my draft questions for SFLC, on this subject, addresses this point ? If I haven't fully captured your understanding of the problem then my draft needs to be updated. I'm not sure it does. The question to me should be more like does putting a name restriction in the copyright licence rather than using a trademark licence mean we lose any ability to package this software under its own name and if so, how? but worded more slickly like you do. I think that's exactly what my question (Q5) is asking: Q5. Does the fact that the PHP licence conditions about the use of the PHP name are contained in the actual copyright licence, rather than in a separate trademark licence, significantly increase the risks we would face if we had a disagreement with upstream about our modifications (or our failure to seek approval) ? At best, the earlier paragraph suggesting we rely on assurances from trademark holders rather than usual rights in law, just for packaging, seems beside the point. At worst, it could mislead about the question. I think it is an important point. Many of the projects whose software we use have trademarks. Those trademarks often come with a restrictive trademark licence which says that we have to submit changes for approval, or some other unacceptable conditions. We often ignore those trademarks because the upstream community doesn't appear to actually mean what the project's laywers have written. We can afford to do this because, if we are wrong, the result is that we must rename the software. Renaming it is annoying but it doesn't leave us high and dry. So the real concern about the name restriction being in the copyright licence is not that it might be used, at some point in the future, to force us to rename. We already tolerate exactly that situation with trademarks. It is also not that we might be in technical break of the condition (eg, to seek written approval) right now. We already take exactly that risk with trademarks. The concern is this: should upstream have a problem with some of our changes, or our failure to formally get approval, they may seek to apply legal pressure based on the name restriction clause. In that case if it were a trademark problem we would rename the software and carry on. We need to know that this is a sufficient response when the name restriction is in a copyright clause. Or to put it another way, addressing your first paragraph again: I'm not sure it does. The question to me should be more like does putting a name restriction in the copyright licence rather than using a trademark licence mean we lose any ability to package this software under its own name and if so, how? but worded more slickly like you do. The question is not about some kind of abstract `ability', as if law was always hard-edged and clear. The question is our _practical_ ability. What can we (by which I include Debian and all of our downstreams) do without incurring significant risk ? If you disagree with me on this point then you probably disagree with the Debian project's existing approach to troublesome trademarks. For example, when there is a trademark whose licence requires us to seek approval, but where the trademark holder and their community don't appear to want to enforce this rule. If you think that in that situation we should decline to package the software, or rename it right away, then that is a coherent position. But that is not our current practice. If you want to change that you will need a GR, I think. But perhaps I have misunderstood. If my reply doesn't seem to make sense perhaps you would like to suggest an alternative wording for this part of the question email. Thanks, Ian. -- 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/21472.47088.559307.899...@chiark.greenend.org.uk
Re: [PHP-QA] Debian and the PHP license
Charles Plessy writes (Re: [PHP-QA] Debian and the PHP license): I think that it is important that a few of the ‘some members’ would identify themselves in support for that request, and explain what they would do if the worries expressed below turned out to be true. At the moment people are playing bug tag, and packages are being sometimes rejected or sometimes prevented from migrating to testing. If the worries turn out to be justified then we should apply that same policy to all of the affected packages - but in fact, I would hope that given an unequivocal statement from actual laywers it would be easy to persuade the PHP developers to change the licence. If the only support for contacting lawyers comes from Developers who have the least stakes in the question (GR only), then we should really consider if the work that we are about to ask to the lawyers will be wasted in the trash bin instead of being seriously considered. If the worries turn out to be unjustified then I hope that the people who have been complaining would stop doing so. Here are two other coments on the text itself. Q4. Does the fact that the PHP licence conditions about the use of the PHP name are contained in the actual copyright licence, rather than in a separate trademark licence, significantly increase the risks we would face if we had a disagreement with upstream about our modifications (or our failure to seek approval) ? Note that PHP does not hold a trademark on the PHP name and therefore can not grant a trademark license. I will mention this. It is important to note that clarifications on the PHP license have already been given by PHP developers. The question is then if they are free to revert their clarifications and use a new interpretation of their license to force Debian to stop distributing or modifying PHP and its modules. This clarification is not sufficient because in the general case the copyright to a PHP addons is not held by the PHP developers and so the actual copyrightholders of the addon haven't issued the clarification. And future joint copyrightholders of PHP itself may not have participated in the clarification. If you disagree, perhaps you'd like to suggest a workable process to distinguish addons for which we can rely on the clarification, from ones where we can't. Personally I think that is a daft way to carry on and we (the Free Software community as a whole including Debian and the PHP community) should either dismiss these concerns (if they are unfounded), or fix them properly (if they are well-founded). Thanks, Ian. -- 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/21471.30829.927457.749...@chiark.greenend.org.uk
Re: [PHP-QA] Debian and the PHP license
Francesco Poli writes (Re: [PHP-QA] Debian and the PHP license): On Fri, 1 Aug 2014 16:59:11 +0100 Ian Jackson wrote: Paragraph 6 of the main licence text requires this notice: This product includes PHP software, freely available from http://www.php.net/software/. I would also add some mention of the final disclaimers (the text in capital letters and the text under the separation lines in the license), which also risk to become false or irrilevant for software not written by (or on behalf of) the PHP Group. I have added a new section and a new question about this. This is probably unproblematic for PHP itself. However, most PHP addons are also distributed under the PHP licence. The worry is that putting that statement in the copyright information for a PHP addon package is might be making a false statement, since (i) the package Probablys/is might/might/ Fixed. Thanks, Ian. -- 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/21471.31495.17328.105...@chiark.greenend.org.uk
Re: [PHP-QA] Debian and the PHP license
(-project dropped from the CC) MJ Ray writes (Re: [PHP-QA] Debian and the PHP license): Secondly, unless it says otherwise, a naming restriction in a copyright licence doesn't permit honest source attribution and all the other nominative and fair uses that a trademark would. This is more of a problem for Debian. Can you please confirm that the question I put in my draft questions for SFLC, on this subject, addresses this point ? If I haven't fully captured your understanding of the problem then my draft needs to be updated. (I'm about to post a v3 but it's essentially identical on this point.) There are many ways this could be solved, but the ostrich approach of closing the bugs without fixing them and hiding this from users must be one of the worst. Please support another approach. I think you're being rather rude here. It's not the case that people are deliberately `hiding' these `bugs'. Rather, they disagree whether the problem is real or imaginary. Ian. -- 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/21471.31715.967008.957...@chiark.greenend.org.uk
Re: [PHP-QA] Debian and the PHP license
On 4 August 2014 13:26:11 GMT+01:00, Ian Jackson ijack...@chiark.greenend.org.uk wrote: (-project dropped from the CC) MJ Ray writes (Re: [PHP-QA] Debian and the PHP license): Secondly, unless it says otherwise, a naming restriction in a copyright licence doesn't permit honest source attribution and all the other nominative and fair uses that a trademark would. This is more of a problem for Debian. Can you please confirm that the question I put in my draft questions for SFLC, on this subject, addresses this point ? If I haven't fully captured your understanding of the problem then my draft needs to be updated. I'm not sure it does. The question to me should be more like does putting a name restriction in the copyright licence rather than using a trademark licence mean we lose any ability to package this software under its own name and if so, how? but worded more slickly like you do. At best, the earlier paragraph suggesting we rely on assurances from trademark holders rather than usual rights in law, just for packaging, seems beside the point. At worst, it could mislead about the question. I take your point about rudeness. I shouldn't fight fire with fire. Sorry. -- 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/159d5264-da1e-4384-b45f-c494eab4b...@email.android.com
Re: [PHP-QA] Debian and the PHP license
On 31 July 2014 01:03:00 CEST, Charles Plessy ple...@debian.org wrote: Back to the question of rebranding, the PHP developers have already explained that because PHP is a three-letter word, they are not in a position to protect their name with a trademark. Therefore, they do it with a license. We can not take Mate and distribute it as “Gnome Plus”. We can not take a fork of PHP and call it “BetterPhp”. People can not take a Debian CD, add non-free software, and sell it as “Debian Enhanced”. We and other protect our names, and PHP does it too. I do not see a problem. There are two problems with trying to use a copyright licence to do the job of a trademark. It's like trying to use a gun to cut your steak. One, it doesn't affect people who write something without using your code. We could clean- room write the perfect hamster punisher and then distribute it as PHP, possibly harming their reputation, but their licence would do nothing to stop us. This is not a worry for Debian but it does show why the licence term is not much like a trademark. Secondly, unless it says otherwise, a naming restriction in a copyright licence doesn't permit honest source attribution and all the other nominative and fair uses that a trademark would. This is more of a problem for Debian. Isn't part of the reason why the name PHP cannot be trademarked that restricting use of such a simple name is obnoxious? There are many ways this could be solved, but the ostrich approach of closing the bugs without fixing them and hiding this from users must be one of the worst. Please support another approach. -- 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/417acac3-ca13-4f82-9f4b-ccce6e4b5...@email.android.com
Re: [PHP-QA] Debian and the PHP license
On Fri, 1 Aug 2014 16:59:11 +0100 Ian Jackson wrote: Francesco Poli writes (Re: [PHP-QA] Debian and the PHP license): Wait! This license version is already obsolete! Thanks for pointing that out. You're welcome! Please revise your draft in light of the current PHP License, version 3.01: http://php.net/license/3_01.txt https://lists.debian.org/debian-legal/2005/11/msg00271.html Done - see below. Good, many thanks for doing so. For the record, my own personal concerns about the PHP License are described in https://lists.debian.org/debian-legal/2005/11/msg00272.html I hope I have dealt with these adequately in my draft below. Please see my comments below. (Your point about the overreach of perhaps forbidding `php' in the names of addons isn't a legal one AFAICT, so I haven't asked anything about it in my draft. It doesn't appear that the ftpmasters agree with your point.) You're right that the FTP Masters seem to disagree with me on the non-freeness of PHP itself: I think that clause 4 of the PHP License version 3.01 makes PHP non-free, while FTP Masters seem to have issues with the PHP License only when it is applied to software not provided by the PHP Group. I think you are also right that legal advice would not help to clarify this specific freeness point. Draft question for SFLC: [...] I. Requirement to perhaps-falsely acknowledge: Paragraph 6 of the main licence text requires this notice: This product includes PHP software, freely available from http://www.php.net/software/. I would also add some mention of the final disclaimers (the text in capital letters and the text under the separation lines in the license), which also risk to become false or irrilevant for software not written by (or on behalf of) the PHP Group. This is probably unproblematic for PHP itself. However, most PHP addons are also distributed under the PHP licence. The worry is that putting that statement in the copyright information for a PHP addon package is might be making a false statement, since (i) the package Probablys/is might/might/ itself does not include PHP and (ii) the addon may not in fact be available via that URL. [...] -- http://www.inventati.org/frx/ fsck is a four letter word... . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpS8mKTz3b5x.pgp Description: PGP signature
Re: [PHP-QA] Debian and the PHP license
Draft question for SFLC: Some members of the Debian project have some concerns about the PHP licence. These worries are dismissed by other members and by relevant upstreams. We are concerned here with the PHP 3.0 Licence, which can be found here: http://php.net/license/3_0.txt There are two concerns (I and II, below), which need to be read with some context (III, below): I. Requirement to perhaps-falsely acknowledge: Paragraph 6 of the main licence text requires this notice: This product includes PHP, freely available from http://www.php.net/. This is unproblematic for PHP itself. However, most PHP addons are also distributed under the PHP licence. The worry is that putting `This product includes PHP' in the copyright information for a PHP addon package is in fact making a false statement, since the package itself does not include PHP. Counterarguments which may be relevant or have been put forward include: (a) When a PHP addon is distributed under the PHP licence, the licensor obviously did not intend the licencees to make a false statement, and the requirement in the licence should be read down accordingly. (b) The word `product' does not refer to a specific package but the to the system as a whole, including PHP. (c) PHP addon packages are often distributed from www.php.net and those packages therefore be regarded as `PHP' for the purposes of this statement. (But what if the addon later ceases to be distributed from www.php.net, or was never so distributed?) We have the following questions: Q1. What is the best approach for Debian and its downstreams to take to comply with this licence ? Specifically, when preparing and distributing Debian package of PHP addon, should we include the statement: This product includes PHP, freely available from http://www.php.net/ ? Q2. If the answer to Q1 is to include the statement, does including this statement pose any ethical, legal or practical risk to anyone in the Free Software community ? Is it fair to say that the statement is materially false or misleading ? Q3. If the answer to Q1 is to NOT include the statement, does that present a risk that the copyrightholders of a PHP addon might be able to effectively revoke the Free Software community's ability to rely on the licence for existing versions of the addon, by insisting on strict compliance with paragraph 6, or by issuing a statement `clarifying' their licence ? II. Restrictions on the name `PHP' Debian routinely modifies all the software that we distribute, and we expect our downstreams to further modify it. (Because we want the freedom to modify to be available not only to us, but also to all of those downstreams, we have a practice of refusing to submit our modifications for approval and declining to accept any Debian-specific permissions.) Paragraphs 3 and 4 can be read to mean that Debian should not be distributing its modified version of PHP under the name `PHP'. We have been informally assured by members of the PHP community that this is not the intent and that the PHP project does not want us to rename things. Similar situations often arise in relation to trademarks. Our usual approach in such cases has been to rely on the informal assurances, and not seek any kind of formal trademark licence amendment. However, we remain prepared to rename the software. If we receive a formal legal request or threat from a trademark holder, or we hear of our downstreams receiving such communications, we will rename the software to avoid any potential infringement of the trademark. For example, Mozilla insisted on prior written approval of patches, so our version of Firefox is called Iceweasel. Our reactive rather than proactive approach has served us and our downstreams very well. Q4. Does the fact that the PHP licence conditions about the use of the PHP name are contained in the actual copyright licence, rather than in a separate trademark licence, significantly increase the risks we would face if we had a disagreement with upstream about our modifications (or our failure to seek approval) ? III. Context When answering these questions, please have regard to this context: Firstly, as we say above, we are concerned not just about the risk to contributors to and participants in Debian, but also about risks to our downstreams. Our downstreams include derivative distros, individual users, and also other contributors who may simply produce and distribute further-modified versions of some package(s). As a matter of principle, we don't want to expose our downstreams to risks we judge unacceptable for ourselves. Sadly we must consider in this context the fact that it does happen - thankfully rarely - that an upstream takes offence to something Debian does and attempts to revoke or renounce the licence or claim that the licence forbids. It is important to us that we can still, under such conditions, continue
Re: [PHP-QA] Debian and the PHP license
On Fri, 1 Aug 2014 14:22:50 +0100 Ian Jackson wrote: Draft question for SFLC: [...] We are concerned here with the PHP 3.0 Licence, which can be found here: http://php.net/license/3_0.txt Wait! This license version is already obsolete! Please revise your draft in light of the current PHP License, version 3.01: http://php.net/license/3_01.txt https://lists.debian.org/debian-legal/2005/11/msg00271.html For the record, my own personal concerns about the PHP License are described in https://lists.debian.org/debian-legal/2005/11/msg00272.html Thanks for your time! -- http://www.inventati.org/frx/ fsck is a four letter word... . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgptRkw3l4IEq.pgp Description: PGP signature
Re: [PHP-QA] Debian and the PHP license
Francesco Poli writes (Re: [PHP-QA] Debian and the PHP license): Wait! This license version is already obsolete! Thanks for pointing that out. Please revise your draft in light of the current PHP License, version 3.01: http://php.net/license/3_01.txt https://lists.debian.org/debian-legal/2005/11/msg00271.html Done - see below. For the record, my own personal concerns about the PHP License are described in https://lists.debian.org/debian-legal/2005/11/msg00272.html I hope I have dealt with these adequately in my draft below. (Your point about the overreach of perhaps forbidding `php' in the names of addons isn't a legal one AFAICT, so I haven't asked anything about it in my draft. It doesn't appear that the ftpmasters agree with your point.) Draft question for SFLC: Some members of the Debian project have some concerns about the PHP licence. These worries are dismissed by other members and by relevant upstreams. We would like some advice. We are concerned here with the PHP 3.01 Licences, which can be found here: http://php.net/license/3_01.txt There are two concerns (I and II, below), which need to be read with some context (III, below): I. Requirement to perhaps-falsely acknowledge: Paragraph 6 of the main licence text requires this notice: This product includes PHP software, freely available from http://www.php.net/software/. This is probably unproblematic for PHP itself. However, most PHP addons are also distributed under the PHP licence. The worry is that putting that statement in the copyright information for a PHP addon package is might be making a false statement, since (i) the package itself does not include PHP and (ii) the addon may not in fact be available via that URL. Counterarguments which may be relevant or have been put forward include: (a) A licensor who uses this licence obviously did not intend the licencees to make a false statement, and the requirement in the licence should be read down accordingly. (b) The word `product' does not refer to a specific package but the to the system as a whole, including PHP itself. (c) PHP addon packages (at least those whose upstream versions are available from www.php.net) should be regarded as `PHP software' for the purposes of this statement. (But what if the addon later ceases to be distributed from www.php.net, or was never so distributed?) We have the following questions: Q1. What is the best approach for Debian and its downstreams to take to comply with this licence ? Should we always include the statement as requested ? Q2. If the answer to Q1 is to always include the statement, does including this statement pose any ethical, legal or practical risk to anyone in the Free Software community ? Is it fair to say that the statement is or can be materially false or misleading ? Q3. Does the answers to these questions depend on whether the addon is currently, or was ever, distributed via http://www.php.net/software/ ? II. Restrictions on the name `PHP' Debian routinely modifies all the software that we distribute, and we expect our downstreams to further modify it. (Because we want the freedom to modify to be available not only to us, but also to all of those downstreams, we have a practice of refusing to submit our modifications for approval and declining to accept any Debian-specific permissions.) Paragraphs 3 and 4 can be read to mean that Debian should not be distributing its modified versions of PHP itself, and of PHP addons, under the name `PHP'. We have been informally assured by members of the PHP community that this is not the intent and that the PHP project does not want us to rename things. Similar situations often arise in relation to trademarks. Our usual approach in such cases has been to rely on the informal assurances, and not seek any kind of formal trademark licence amendment. However, we remain prepared to rename the software. If we receive a formal legal request or threat from a trademark holder, or we hear of our downstreams receiving such communications, we will rename the software to avoid any potential infringement of the trademark. For example, Mozilla insisted on prior written approval of patches, so our version of Firefox is called Iceweasel. Our reactive rather than proactive approach has served us and our downstreams very well. Q4. Does the fact that the PHP licence conditions about the use of the PHP name are contained in the actual copyright licence, rather than in a separate trademark licence, significantly increase the risks we would face if we had a disagreement with upstream about our modifications (or our failure to seek approval) ? III. Context When answering these questions, please have regard to this context: Firstly, as we say above, we are concerned not just about the risk to contributors to and participants in Debian, but also about risks to our downstreams. Our downstreams include derivative distros
Re: [PHP-QA] Debian and the PHP license
On 1 August 2014 17:59:11 CEST, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Similar situations often arise in relation to trademarks. Our usual approach in such cases has been to rely on the informal assurances, and not seek any kind of formal trademark licence amendment. I thought we relied on the fact that trademark law isn't as brain dead as copyright laws and actually allows honest description, functional uses and other things that we do. Firefox's renaming was more to do with the trademark licence being used to try to force in a few non free files and restrict downstream autonomy IIRC. -- 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/ee8ead64-a994-455f-ae48-040490408...@email.android.com
Re: [PHP-QA] Debian and the PHP license
Last minute concerns: The warranty disclaimer states that the software is provided by the PHP development team. What if it isn't? Do people that are not members of the PHP development team have the right to make that claim on their behalf? Similarly, the license includes the phrase This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. (However, this may already be covered by the false statements 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/53dc0c1c.5000...@bitmessage.ch
Re: [PHP-QA] Debian and the PHP license
Le Fri, Aug 01, 2014 at 04:59:11PM +0100, Ian Jackson a écrit : Draft question for SFLC: Some members of the Debian project have some concerns about the PHP licence. These worries are dismissed by other members and by relevant upstreams. We would like some advice. Hello Ian and everybody, I think that it is important that a few of the ‘some members’ would identify themselves in support for that request, and explain what they would do if the worries expressed below turned out to be true. Among the Debian Developers, some have more stakes in the packages than others. Members of the FTP team may remove the packages or ask them to move to non-free; members of the release team can remove them from Stable and Testing; members from the security team can refuse to support the packages; the maintainers of the packages can orphan or abandon them. Lastly, any Debian Developer can start a General Resolution. If the only support for contacting lawyers comes from Developers who have the least stakes in the question (GR only), then we should really consider if the work that we are about to ask to the lawyers will be wasted in the trash bin instead of being seriously considered. Here are two other coments on the text itself. Q4. Does the fact that the PHP licence conditions about the use of the PHP name are contained in the actual copyright licence, rather than in a separate trademark licence, significantly increase the risks we would face if we had a disagreement with upstream about our modifications (or our failure to seek approval) ? Note that PHP does not hold a trademark on the PHP name and therefore can not grant a trademark license. Sadly we must consider in this context the fact that it does happen - thankfully rarely - that an upstream takes offence to something Debian does and attempts to revoke or renounce the licence or claim that the licence forbids. It is important to us that we can still, under such conditions, continue to distribute the software (perhaps under a different name), since we may have come to rely on it. It is important to note that clarifications on the PHP license have already been given by PHP developers. The question is then if they are free to revert their clarifications and use a new interpretation of their license to force Debian to stop distributing or modifying PHP and its modules. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140801231037.ga8...@falafel.plessy.net
Re: [PHP-QA] Debian and the PHP license
Le Sat, Aug 02, 2014 at 08:10:49AM +0900, Charles Plessy a écrit : I think that it is important that a few of the ‘some members’ would identify themselves in support for that request, and explain what they would do if the worries expressed below turned out to be true. Sorry for the extra mail; I just would like to clarify that by “Developers in support”, I mean: “Developers who think that the PHP license may be problematic”, not “Developers who think that calling lawyers will be an efficient mean to resolve the disagreements”. Cheers, -- Charles -- 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/20140801235712.gb8...@falafel.plessy.net
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: [PHP-QA] Debian and the PHP license
You're advocating a position, then, that the PHP license can require recipients to make false, and even nonsensical, claims, and that this is not a problem to be addressed by improving the license terms. I think that this is similar to the BSD licenses. Look at /usr/share/common-licenses/BSD. It specifically states: Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. From this, it would seem that it is possible to use this license even if you are not the University. Why else would Debian keep this in /usr/share/common-licenses? Is that the position of the PHP Group: that a requirement for the recipient to make false claims is “absolutely no problem” of the license? I don't think that the position of the PHP Group is that requiring the recipient to make false claims is absolutely no problem; the license works for *them*; it just doesn't work for anyone else who chooses to use their license When applied to software that is not available from *.php.net, the license terms may not be sensible, but they still can be followed. Is the fact they can't sensibly be followed not a problem to be addressed by improving the license terms? It could be addressed by improving the licensing terms, but it isn't necessary, and the PHP Group seems very unwilling to do so. -- 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/53d88e86.3060...@bitmessage.ch
Re: [PECL-DEV] Re: [PHP-QA] Debian and the PHP license
2014.07.30. 3:35, Ben Finney ben+deb...@benfinney.id.au ezt írta: Rasmus Lerdorf ras...@lerdorf.com writes: I see absolutely no problem with PHP projects distributed from *.php.net carrying the PHP license. The license talks about PHP Software which we define as software you get from/via *.php.net. Specifically, the license text URL:http://php.net/license/3_01.txt has this clause: 6. Redistributions of any form whatsoever must retain the following acknowledgment: This product includes PHP software, freely available from http://www.php.net/software/. Nowhere is “PHP software” defined in the license. Will you update the license to make your above definition explicit in the license terms? for the record: http://www.php.net/software.php explicitly lists php.net, pear.php.net and pecl.php.net as the places you can get the Software from.
Re: Re: [PHP-QA] Debian and the PHP license
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. 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 that distributing the original source alongside patches is okay (e.g. as 3.0 (quilt) source package). Since Debian isn't distributing source pak- kages, this does not help us. A written permission from gr...@php.net is not helpful either, because of DFSG#8. (In BSD ports, we also do not distribute binaries of PHP.) I think you should rethink your stance and the PHP licence on all of the issues listed. Similar issues arose from the Firefox trademark after all (and it would be fun if Debian distributed Icescriptinglanguage, instead of PHP, except for those affected). bye, //mirabilos -- 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/lrajm9$j5p$1...@ger.gmane.org
Re: [PHP-QA] Debian and the PHP license
On 30/07/14 21:07, Thorsten Glaser 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. I agree that this would violate DFSG#3. However, I'm not convinced that the PHP license is only valid if the software is distributed under *.php.net. Nowhere within the license does it say that the program being licensed is PHP software, so the PHP Group's definition of PHP software is irrelevant. 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 that distributing the original source alongside patches is okay (e.g. as 3.0 (quilt) source package). Since Debian isn't distributing source pak- kages, this does not help us. A written permission from gr...@php.net is not helpful either, because of DFSG#8. Good point. (I think you're referring to section 4; correct me if I'm wrong.) This would make PHP-licensed software *with PHP in the title* non-free until rebranded, like firefox was until rebranded to iceweasel. This would not, however, make the license non-free, it would just make for some annoying rebranding, which should be much more manageable. -- 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/53d8d73e.2010...@bitmessage.ch
Re: [PECL-DEV] Re: [PHP-QA] Debian and the PHP license
On 30/07/2014 06:09, Pierre Joye wrote: hi Walter, On Tue, Jul 29, 2014 at 9:16 PM, Walter Landry wlan...@caltech.edu wrote: Ferenc Kovacs tyr...@gmail.com wrote: I've find it a bit disturbing, that ftpmasters can make a decision on legal grounds(which is the probably the highest priority for debian as far as I'm concerned), without any backing from debian-legal debian-legal has no authority to decide anything. It is just a mailing list. We can discuss things here day and night and ftp-masters can ignore it. With that said, debian-legal can be useful when issues are clear-cut. For example, if someone asks if the Apache 2.0 license is compatible with the GPL (no for GPL 2.0, yes for GPL 3.0). Think of debian-legal as the secretary for ftp-masters. We can sometimes divine what they are thinking, but the final word belongs to ftp-masters. In any case, in the interest of making this email constructive, my take on the PHP license is that it does need to be fixed. From ftp-masters REJECT-FAQ, they also think so. So my advice would be to just use a well known, existing license and be done with it. Judging from the existing PHP license, the closest thing would be the 3 clause BSD license http://opensource.org/licenses/BSD-3-Clause Apache 2.0 would also be a good choice. Now, I understand that changing licenses is a huge chore, and the benefits can sometimes be intangible. The main benefit is that you will never have to deal with us again ;) 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. I see this move as yet another attempt to force developers to abandon a totally valid license in the name of the Debian ideal, Free Softwares. I cannot blame anyone willing to reach this goal but as a matter of fact, there is no issue with the PHP license, not anymore since 3.01. And about dealing with Debian about that, well, Debian has actually more to lose than any other 3rd parties. Let focus on getting the web stack rocks on Debian instead. Cheers, Hi all, Is it possible we can then work towards a resolution on this near decade old problem? Now we've established that the PHP License v3.01 resolves the problem outlined in the 2005 email, surely the PHP License can be removed from the Serious violations list on the Debian FTP. https://ftp-master.debian.org/REJECT-FAQ.html Thanks. -- 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/53d8d36d.7090...@gmail.com
Re: [PECL-DEV] Re: [PHP-QA] Debian and the PHP license
Hi all, Is it possible we can then work towards a resolution on this near decade old problem? Now we've established that the PHP License v3.01 resolves the problem outlined in the 2005 email, surely the PHP License can be removed from the Serious violations list on the Debian FTP. https://ftp-master.debian.org/REJECT-FAQ.html Thanks. When was the problem outlined in the 2005 email resolved? The debate is still very much going on on -legal, at least. -- 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/53d8dd7b.8090...@bitmessage.ch
Re: [PHP-QA] Debian and the PHP license
There has been an ongoing and wholly unproductive conversation on -legal about some difficulties with the PHP licence. Would it be possible for us to obtain some proper legal advice ? Do we have a relationship with the SFLC we could use for this ? If so I would be happy to write up a summary of the facts and the questions to put to our lawyers. I think this is likely to be straightforward but I would send a draft to -legal and ftpmaster@ to check that the answer would actually resolve the problem one way or another. Ian. -- 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/21464.57458.594359.314...@chiark.greenend.org.uk
Re: [PHP-QA] Debian and the PHP license
Hi Ian, Thanks for bringing this up. On 30/07/14 at 13:09 +0100, Ian Jackson wrote: There has been an ongoing and wholly unproductive conversation on -legal about some difficulties with the PHP licence. Would it be possible for us to obtain some proper legal advice ? Do we have a relationship with the SFLC we could use for this ? Sure, we could ask for advice from SFLC about this. If so I would be happy to write up a summary of the facts and the questions to put to our lawyers. I think this is likely to be straightforward but I would send a draft to -legal and ftpmaster@ to check that the answer would actually resolve the problem one way or another. I think that such a summary would be very useful, at least to increase the awareness about the issue, and to improve the description of the violation on ftpmasters' REJECT FAQ. However, based on my own (possibly limited) understanding of the issue[1], this is case of a license (the PHP License) with sub-optimal wording that is misused by third parties, as it was initially designed for PHP itself, and is used for random software written in PHP. As a result, the license adds some restrictions for derivative works that could prevent software under that license to meet the DFSG. So I think that it is important to distinguish between two different questions: (1) Is there a legal risk for Debian to distribute such software? (2) Does the Debian project want to tolerate and ignore this sad situation, or try to make the world a better place by working on fixing this mess? [1] built on reading #728196, the thread starting at https://lists.debian.org/debian-devel/2014/06/msg00493.html and the one starting at https://lists.debian.org/debian-legal/2014/07/msg00024.html When you have a summary and questions ready, we can work together on forwarding them to SFLC for legal advice. Lucas signature.asc Description: Digital signature
Re: [PHP-QA] Debian and the PHP license
Lucas Nussbaum writes (Re: [PHP-QA] Debian and the PHP license): On 30/07/14 at 13:09 +0100, Ian Jackson wrote: Would it be possible for us to obtain some proper legal advice ? Do we have a relationship with the SFLC we could use for this ? Sure, we could ask for advice from SFLC about this. OK, good. If so I would be happy to write up a summary of the facts and the questions to put to our lawyers. I think this is likely to be straightforward but I would send a draft to -legal and ftpmaster@ to check that the answer would actually resolve the problem one way or another. I think that such a summary would be very useful, at least to increase the awareness about the issue, and to improve the description of the violation on ftpmasters' REJECT FAQ. Yes. However, based on my own (possibly limited) understanding of the issue[1], this is case of a license (the PHP License) with sub-optimal wording that is misused by third parties, as it was initially designed for PHP itself, and is used for random software written in PHP. As a result, the license adds some restrictions for derivative works that could prevent software under that license to meet the DFSG. That is the contention of the critics, yes. So I think that it is important to distinguish between two different questions: (1) Is there a legal risk for Debian to distribute such software? I would want to ask whether there is a risk for others, too. (2) Does the Debian project want to tolerate and ignore this sad situation, or try to make the world a better place by working on fixing this mess? If we have a piece of legal advice which says that the risk is minimal, then surely that would be sufficient to make the world a place. It would surely be nice to fix this wrinkle in the PHP licence but if it doesn't actually meaningfully prevent anyone from doing anything they would want to, then no-one's actual freedom is impinged and reacting to it by throwing this software out of the archive is quite disproportionate. On the other hand if it _does_ pose a legal risk, then a legal opinion to say so would be very helpful in persuading the software's upstreams that it needs to be fixed. When you have a summary and questions ready, we can work together on forwarding them to SFLC for legal advice. I will get back to you. Ian. -- 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/21464.63997.84090.692...@chiark.greenend.org.uk
Re: [PHP-QA] Debian and the PHP license
Lucas Nussbaum wrote: However, based on my own (possibly limited) understanding of the issue[1], this is case of a license (the PHP License) with sub-optimal wording that is misused by third parties, as it was initially designed for PHP itself, and is used for random software written in PHP. That, too. But AIUI that licence also forbids us from shipping a modified version of PHP without rebranding (like Firefox(tm)). bye, //mirabilos -- 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/lrb022$oik$1...@ger.gmane.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: [PHP-QA] Debian and the PHP license
On Wed, Jul 30, 2014 at 1:47 PM, Thorsten Glaser t...@debian.org 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 that distributing the original source alongside patches is okay (e.g. as 3.0 (quilt) source package). Since Debian isn't distributing source pak- kages, this does not help us. A written permission from gr...@php.net is not helpful either, because of DFSG#8. Good point. (I think you're referring to section 4; correct me if I'm Right. wrong.) This would make PHP-licensed software *with PHP in the title* non-free until rebranded, like firefox was until rebranded to iceweasel. Indeed. And seeing this, I think that Debian may ship neither the PHP interpreter nor anything else under PHP licence without doing a rebranding. This would not, however, make the license non-free, it would just make for some annoying rebranding, which should be much more manageable. It would, however, make the licence inacceptable for Debian for anything bearing PHP in its name, which is kinda the point of the PHP licence. This is not what the license says. The license says you cannot create a derivative project and use PHP in its name. hhvm is a derivative work for example. Distributing php, even by back porting patches, is not a derivative work. 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/CAEZPtU7iSD4faxeoti_1=icf-cfpqtfo6dza9ufvhohz9da...@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: [PHP-QA] Debian and the PHP license
Le Wed, Jul 30, 2014 at 02:38:58PM +, Thorsten Glaser a écrit : That, too. But AIUI that licence also forbids us from shipping a modified version of PHP without rebranding (like Firefox(tm)). I think that we are ridiculing ourselves by ignoring the arguments that have been given to us by the PHP developers in the past. See, we are getting famous in Wikipedia: https://en.wikipedia.org/wiki/PHP_License#Debian_packaging_controversy Debian maintainers have had a long-standing discussion (since at least 2005) about the validity of the PHP license.[4] Expressed concerns include that the license contains statements about the software it covers that are specific to distributing PHP itself, which, for other software than PHP itself therefore would be false statements. I think that the situation is different: - It has been proposed by a developer to remove PHP modules licensed under the PHP license, in application of a policy that had been neglected for years. This proposition was eventually represented by release-critical bugs. - For some PHP modules, the bugs have been closed, and there was no further reaction. - In the meantime the usual vocal people sending the majority of emails on our mailing lists are giving the impression that removing PHP modules is a position of Debian as a whole, while it is definitely not. This drama can be ended by closing the remaining bugs and going back to work. This has been done for packages that some people care most, like php-memcached, and could be done for other packages. When things have cooled down, it can be proposed to correct the REJECT-FAQ according to current practice of accepting PHP-licensed code. Back to the question of rebranding, the PHP developers have already explained that because PHP is a three-letter word, they are not in a position to protect their name with a trademark. Therefore, they do it with a license. We can not take Mate and distribute it as “Gnome Plus”. We can not take a fork of PHP and call it “BetterPhp”. People can not take a Debian CD, add non-free software, and sell it as “Debian Enhanced”. We and other protect our names, and PHP does it too. I do not see a problem. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140730230300.gb24...@falafel.plessy.net
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
Re: [PHP-QA] Debian and the PHP license
On Tue, Jul 29, 2014 at 3:55 PM, James Wade jpsw...@gmail.com wrote: Hi all, There seems to be some confusion over the PHP License. We had this bug report into a PEAR project which outlines that Debian cannot include any projects that fall under the PHP License. * https://pear.php.net/bugs/bug.php?id=20172 You will find details of the reason behind it here: * https://ftp-master.debian.org/REJECT-FAQ.html You have a PHP add-on package (any php script/app/thing, not PHP itself) and it's licensed only under the standard PHP license. That license, up to the 3.x which is actually out, is not really usable for anything else than PHP itself. I've mailed our -legal list about that and got only one response, which basically supported my view on this. Basically this license talks only about PHP, the PHP Group, and includes Zend Engine, so its not applicable to anything else. And even worse, older versions include the nice ad-clause. One good solution here is to suggest a license change to your upstream, as they clearly wanted a free one. LGPL or BSD seems to be what they want After a quick search, I quickly found that this isn't an isolated case... * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728196 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752530 * http://pear.php.net/bugs/bug.php?id=20316 * https://www.mail-archive.com/debian-bugs-rc@lists.debian. org/msg362847.html * https://github.com/nicolasff/phpredis/issues/384 Judging by the email to legal sent almost a decade ago this situation is in need of a review... * https://lists.debian.org/debian-legal/2005/08/msg00128.html I can't understand this line of thought in this context: GPL enforces many restrictions on what can and cannot be done with the licensed code. The PHP developers decided to release PHP under a much more loose license (Apache-style), to help PHP become as popular as possible. - http://php.net/license/ I also read that Rasmus Lerdorf issued a statement which said that the PHP license is pretty much identical to the Apache license. * http://pear.php.net/manual/en/faq.devs.php I've also discovered that this is not the first instance that this issue has been discussed: * http://lwn.net/Articles/604630/ All this has raised some questions: 1. Is 'The PHP License, version 3.01' an Open Source license, certified by the Open Source Initiative? Their website only lists 'PHP License 3.0 (PHP-3.0)'. 2. When was 'The PHP License, version 3.01' released? 3. Can 'The PHP License, version 3.01' be used for anything other than PHP itself? 4. Are there any legal implications of changing a project from 'The PHP License, version 3.01' to LGPL or BSD? 5. Is the PHP license clear enough to ensure that it is correctly applied to extensions? 6. Why would the (Apache-style) PHP License be listed by Debian as a 'serious violation' yet the Apache license is not? Thanks. Hi, please see the thread at http://comments.gmane.org/gmane.comp.php.pecl.devel/11046 and if you want to reply I think pecl-dev@ is a better place than php-qa@ Most of your links are old and some of the previous problems claimed by debian was addressed with php license version 3.01. from the replies on the debian mailing lists it seems that this decision on dropping any project using the php license distributed outside of php-src is controversial to say the least. I've tried to start a discussion to find some kind of resolution, but most of the replies from php-dev side was that the current license is fine, and we don't need to change anything, while we didn't got any reply from the debian-legal (apart from the mail from Francesco Poli who explicitly stated that not part of the debian project and not speaking on behalf of it). Based on the lack of clarification and cooperation from their side, I think the consensus on our part will be to keep everything as-is, and at the end of the day, it is up to the package maintainer to decide if they take the advice from the debian package maintainers and change the license for their project. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-QA] Debian and the PHP license
debian-legal isn't the body that makes this decision, you might want ftpmas...@ftp-master.debian.org Thanks, Paul On Tue, Jul 29, 2014 at 10:47 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 29, 2014 at 3:55 PM, James Wade jpsw...@gmail.com wrote: Hi all, There seems to be some confusion over the PHP License. We had this bug report into a PEAR project which outlines that Debian cannot include any projects that fall under the PHP License. * https://pear.php.net/bugs/bug.php?id=20172 You will find details of the reason behind it here: * https://ftp-master.debian.org/REJECT-FAQ.html You have a PHP add-on package (any php script/app/thing, not PHP itself) and it's licensed only under the standard PHP license. That license, up to the 3.x which is actually out, is not really usable for anything else than PHP itself. I've mailed our -legal list about that and got only one response, which basically supported my view on this. Basically this license talks only about PHP, the PHP Group, and includes Zend Engine, so its not applicable to anything else. And even worse, older versions include the nice ad-clause. One good solution here is to suggest a license change to your upstream, as they clearly wanted a free one. LGPL or BSD seems to be what they want After a quick search, I quickly found that this isn't an isolated case... * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728196 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752530 * http://pear.php.net/bugs/bug.php?id=20316 * https://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg362847.html * https://github.com/nicolasff/phpredis/issues/384 Judging by the email to legal sent almost a decade ago this situation is in need of a review... * https://lists.debian.org/debian-legal/2005/08/msg00128.html I can't understand this line of thought in this context: GPL enforces many restrictions on what can and cannot be done with the licensed code. The PHP developers decided to release PHP under a much more loose license (Apache-style), to help PHP become as popular as possible. - http://php.net/license/ I also read that Rasmus Lerdorf issued a statement which said that the PHP license is pretty much identical to the Apache license. * http://pear.php.net/manual/en/faq.devs.php I've also discovered that this is not the first instance that this issue has been discussed: * http://lwn.net/Articles/604630/ All this has raised some questions: 1. Is 'The PHP License, version 3.01' an Open Source license, certified by the Open Source Initiative? Their website only lists 'PHP License 3.0 (PHP-3.0)'. 2. When was 'The PHP License, version 3.01' released? 3. Can 'The PHP License, version 3.01' be used for anything other than PHP itself? 4. Are there any legal implications of changing a project from 'The PHP License, version 3.01' to LGPL or BSD? 5. Is the PHP license clear enough to ensure that it is correctly applied to extensions? 6. Why would the (Apache-style) PHP License be listed by Debian as a 'serious violation' yet the Apache license is not? Thanks. Hi, please see the thread at http://comments.gmane.org/gmane.comp.php.pecl.devel/11046 and if you want to reply I think pecl-dev@ is a better place than php-qa@ Most of your links are old and some of the previous problems claimed by debian was addressed with php license version 3.01. from the replies on the debian mailing lists it seems that this decision on dropping any project using the php license distributed outside of php-src is controversial to say the least. I've tried to start a discussion to find some kind of resolution, but most of the replies from php-dev side was that the current license is fine, and we don't need to change anything, while we didn't got any reply from the debian-legal (apart from the mail from Francesco Poli who explicitly stated that not part of the debian project and not speaking on behalf of it). Based on the lack of clarification and cooperation from their side, I think the consensus on our part will be to keep everything as-is, and at the end of the day, it is up to the package maintainer to decide if they take the advice from the debian package maintainers and change the license for their project. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- 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/cao6p2qscni8ha54jmd6rqs7uox9xaljugj0+smqtjnputkd...@mail.gmail.com
Re: [PHP-QA] Debian and the PHP license
On Tue, Jul 29, 2014 at 05:20:21PM +0200, Ferenc Kovacs wrote: If you feel to dispute this please take your *well-formed* and *well-thought* arguments to debian-legal. ... to discuss it. d-legal is a proper venue for *discussing* it, but it's not the right one to discuss the actual critera for archive fitness. Which is likely why you didn't get a reply. So I was under the impression that debian-legal is the correct list to contact. debian-legal has no delegated authority to make such decisions for the archive. From the mails from Ondřej it seems that the reject decision was made by the ftpmaster team, but as the argument for the decision was a legal one, so I think that debian-legal is appropriate. ... to discuss it. Not decide on critera. -- Ferenc Kovács @Tyr43l - [4]http://tyrael.hu Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: [PHP-QA] Debian and the PHP license
On Tue, Jul 29, 2014 at 5:11 PM, Paul Tagliamonte paul...@ubuntu.com wrote: debian-legal isn't the body that makes this decision, you might want ftpmas...@ftp-master.debian.org Thanks, Paul Hi Paul, To quote Ondřej from http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg360686.html If you feel to dispute this please take your *well-formed* and *well-thought* arguments to debian-legal. So I was under the impression that debian-legal is the correct list to contact. From the mails from Ondřej it seems that the reject decision was made by the ftpmaster team, but as the argument for the decision was a legal one, so I think that debian-legal is appropriate. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-QA] Debian and the PHP license
On Tue, Jul 29, 2014 at 5:23 PM, Paul Tagliamonte paul...@debian.org wrote: On Tue, Jul 29, 2014 at 05:20:21PM +0200, Ferenc Kovacs wrote: If you feel to dispute this please take your *well-formed* and *well-thought* arguments to debian-legal. ... to discuss it. d-legal is a proper venue for *discussing* it, but it's not the right one to discuss the actual critera for archive fitness. Which is likely why you didn't get a reply. nobody participated in the discussion from your side. So I was under the impression that debian-legal is the correct list to contact. debian-legal has no delegated authority to make such decisions for the archive. I didn't said anything about debian-legal having the authority to do any decision. Ondrej claimed that the decision was made on legal concerns, and that any further discussion should happen on debian-legal, which kind-of made sense. From your reply I'm not sure what are you arguing about. That this isn't a legal problem, so no reason to discuss it on debian-legal, or you think that there isn't much to discuss there, because you have no power over the decision? I've find it a bit disturbing, that ftpmasters can make a decision on legal grounds(which is the probably the highest priority for debian as far as I'm concerned), without any backing from debian-legal(the original thread one debian-legal got a single reply which doesn't supported the reject. https://lists.debian.org/debian-legal/2005/08/msg00130.html), years later ftpmasters can decide to drop a bunch of packages based on the legal problem and point to debian-legal@ for further discussion where first nobody replies, then we are told that it isn't the proper place to write and that we should write to the same people who made the decision. o.O From the mails from Ondřej it seems that the reject decision was made by the ftpmaster team, but as the argument for the decision was a legal one, so I think that debian-legal is appropriate. ... to discuss it. Not decide on critera. sigh. you are trying a nice job making any kind of discussion as talking to a brick wall. where did I said anything about you making any decision? I was talking about why did it seemed reasonable to follow Ondrej's advice and write to debian-legal@ to discuss a decision made on legal grounds to discuss the decision and find a solution satisfying all parties. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-QA] Debian and the PHP license
Ferenc Kovacs tyr...@gmail.com wrote: I've find it a bit disturbing, that ftpmasters can make a decision on legal grounds(which is the probably the highest priority for debian as far as I'm concerned), without any backing from debian-legal debian-legal has no authority to decide anything. It is just a mailing list. We can discuss things here day and night and ftp-masters can ignore it. With that said, debian-legal can be useful when issues are clear-cut. For example, if someone asks if the Apache 2.0 license is compatible with the GPL (no for GPL 2.0, yes for GPL 3.0). Think of debian-legal as the secretary for ftp-masters. We can sometimes divine what they are thinking, but the final word belongs to ftp-masters. In any case, in the interest of making this email constructive, my take on the PHP license is that it does need to be fixed. From ftp-masters REJECT-FAQ, they also think so. So my advice would be to just use a well known, existing license and be done with it. Judging from the existing PHP license, the closest thing would be the 3 clause BSD license http://opensource.org/licenses/BSD-3-Clause Apache 2.0 would also be a good choice. Now, I understand that changing licenses is a huge chore, and the benefits can sometimes be intangible. The main benefit is that you will never have to deal with us again ;) Cheers, Walter Landry wlan...@caltech.edu -- 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/20140729.121653.1175255053010754152.wlan...@caltech.edu
Re: [PECL-DEV] Re: [PHP-QA] Debian and the PHP license
On 07/29/2014 03:16 PM, Walter Landry wrote: Ferenc Kovacs tyr...@gmail.com wrote: I've find it a bit disturbing, that ftpmasters can make a decision on legal grounds(which is the probably the highest priority for debian as far as I'm concerned), without any backing from debian-legal debian-legal has no authority to decide anything. It is just a mailing list. We can discuss things here day and night and ftp-masters can ignore it. With that said, debian-legal can be useful when issues are clear-cut. For example, if someone asks if the Apache 2.0 license is compatible with the GPL (no for GPL 2.0, yes for GPL 3.0). Think of debian-legal as the secretary for ftp-masters. We can sometimes divine what they are thinking, but the final word belongs to ftp-masters. In any case, in the interest of making this email constructive, my take on the PHP license is that it does need to be fixed. From ftp-masters REJECT-FAQ, they also think so. So my advice would be to just use a well known, existing license and be done with it. Judging from the existing PHP license, the closest thing would be the 3 clause BSD license http://opensource.org/licenses/BSD-3-Clause Apache 2.0 would also be a good choice. Now, I understand that changing licenses is a huge chore, and the benefits can sometimes be intangible. The main benefit is that you will never have to deal with us again ;) We will not be changing the license to Apache 2.0 I see absolutely no problem with PHP projects distributed from *.php.net carrying the PHP license. The license talks about PHP Software which we define as software you get from/via *.php.net. We support external repos such as github, but they are still linked back to php.net via their pecl.php.net entries, for example. For things that aren't distributed via pecl.php.net, pear.php.net or www.php.net itself, I can see the argument, but those are not projects we can do anything about. -Rasmus -- 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/53d813e5.5030...@lerdorf.com
Re: [PHP-QA] Debian and the PHP license
Le Tue, Jul 29, 2014 at 04:47:34PM +0200, Ferenc Kovacs a écrit : from the replies on the debian mailing lists it seems that this decision on dropping any project using the php license distributed outside of php-src is controversial to say the least. Hello Ferenc, from an outsider point of view (I do not maintain PHP packages in Debian), my impresssion is also that the removal of PHP packages is controversial. I guess you also saw the LWN article here: http://lwn.net/Articles/604630/ The good news is that things can resolve without formal decision: the immediate cause for removing some PHP packages from our Testing distribution (that represents our future release, not the Debian archive as a whole) is that bugs of severity serious were filed against them to represent the licensing question. If one closes these bugs or downgrade their severity, then the packages automatically (modulo a small delay) become part of Testing again. This already has been done for packages such as php-memcached, and could be done for others. Thank you for your patience ! -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20140729223824.gc31...@falafel.plessy.net
Re: [PHP-QA] Debian and the PHP license
Rasmus Lerdorf ras...@lerdorf.com writes: I see absolutely no problem with PHP projects distributed from *.php.net carrying the PHP license. The license talks about PHP Software which we define as software you get from/via *.php.net. Specifically, the license text URL:http://php.net/license/3_01.txt has this clause: 6. Redistributions of any form whatsoever must retain the following acknowledgment: This product includes PHP software, freely available from http://www.php.net/software/. Nowhere is “PHP software” defined in the license. Will you update the license to make your above definition explicit in the license terms? We support external repos such as github, but they are still linked back to php.net via their pecl.php.net entries, for example. For things that aren't distributed via pecl.php.net, pear.php.net or www.php.net itself, I can see the argument, but those are not projects we can do anything about. The problem is exacerbated, though, by the specific license terms. The license terms do not apply sensibly outside your stated definition; yet many software works begin outside that definition, and only later make their way to the locations you mention. This distinction is *not* the case for more widely-accepted license terms, so the distinction is easy to miss. This does not need to be the case; it is made the case by the specific terms of this license. That is a problem which can be addressed by changing the terms of the license to be generally applicable. -- \ “Those who write software only for pay should go hurt some | `\ other field.” —Erik Naggum, in _gnu.misc.discuss_ | _o__) | Ben Finney -- 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/85k36v3abc@benfinney.id.au
Re: [PHP-QA] Debian and the PHP license
On 30/07/14 10:21, Ben Finney wrote: Rasmus Lerdorf ras...@lerdorf.com writes: I see absolutely no problem with PHP projects distributed from *.php.net carrying the PHP license. The license talks about PHP Software which we define as software you get from/via *.php.net. Specifically, the license text URL:http://php.net/license/3_01.txt has this clause: 6. Redistributions of any form whatsoever must retain the following acknowledgment: This product includes PHP software, freely available from http://www.php.net/software/. Nowhere is “PHP software” defined in the license. Will you update the license to make your above definition explicit in the license terms? PHP software doesn't need to be defined. The phrase is not used in the license except as an acknowledgement that must accompany any redistributions. It could just as easily require that any redistributions must have the acknowledgement This project contains giraffes, which are a type of fish, and the software could still be considered free. If you're worried about having to include false information with your software product, you could say something along the lines of The below notices are untrue, but are requirements of various FOSS licenses. The license terms do not apply sensibly outside your stated definition; yet many software works begin outside that definition, and only later make their way to the locations you mention. This distinction is *not* the case for more widely-accepted license terms, so the distinction is easy to miss. When applied to software that is not available from *.php.net, the license terms may not be sensible, but they still can be followed. The only problem that I can see with the license is the phrase: This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. The word 'voluntary' may not apply to all contributions made by individuals made on behalf on the PHP group. Also, not everyone that uses the PHP license is able to act on behalf of the PHP group. -- 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/53d87ca0.3000...@bitmessage.ch
Re: [PECL-DEV] Re: [PHP-QA] Debian and the PHP license
hi Walter, On Tue, Jul 29, 2014 at 9:16 PM, Walter Landry wlan...@caltech.edu wrote: Ferenc Kovacs tyr...@gmail.com wrote: I've find it a bit disturbing, that ftpmasters can make a decision on legal grounds(which is the probably the highest priority for debian as far as I'm concerned), without any backing from debian-legal debian-legal has no authority to decide anything. It is just a mailing list. We can discuss things here day and night and ftp-masters can ignore it. With that said, debian-legal can be useful when issues are clear-cut. For example, if someone asks if the Apache 2.0 license is compatible with the GPL (no for GPL 2.0, yes for GPL 3.0). Think of debian-legal as the secretary for ftp-masters. We can sometimes divine what they are thinking, but the final word belongs to ftp-masters. In any case, in the interest of making this email constructive, my take on the PHP license is that it does need to be fixed. From ftp-masters REJECT-FAQ, they also think so. So my advice would be to just use a well known, existing license and be done with it. Judging from the existing PHP license, the closest thing would be the 3 clause BSD license http://opensource.org/licenses/BSD-3-Clause Apache 2.0 would also be a good choice. Now, I understand that changing licenses is a huge chore, and the benefits can sometimes be intangible. The main benefit is that you will never have to deal with us again ;) 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. I see this move as yet another attempt to force developers to abandon a totally valid license in the name of the Debian ideal, Free Softwares. I cannot blame anyone willing to reach this goal but as a matter of fact, there is no issue with the PHP license, not anymore since 3.01. And about dealing with Debian about that, well, Debian has actually more to lose than any other 3rd parties. Let focus on getting the web stack rocks on Debian instead. 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/caezptu7yan3y_cht3sfgclrjrg07wg3yguhwzk1g0b86f9o...@mail.gmail.com
Re: [PHP-QA] Debian and the PHP license
Riley Baird bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch writes: On 30/07/14 10:21, Ben Finney wrote: Rasmus Lerdorf ras...@lerdorf.com writes: I see absolutely no problem with PHP projects distributed from *.php.net carrying the PHP license. The license talks about PHP Software which we define as software you get from/via *.php.net. […] It could just as easily require that any redistributions must have the acknowledgement This project contains giraffes, which are a type of fish, and the software could still be considered free. If you're worried about having to include false information with your software product, you could say something along the lines of The below notices are untrue, but are requirements of various FOSS licenses. You're advocating a position, then, that the PHP license can require recipients to make false, and even nonsensical, claims, and that this is not a problem to be addressed by improving the license terms. Is that the position of the PHP Group: that a requirement for the recipient to make false claims is “absolutely no problem” of the license? […] When applied to software that is not available from *.php.net, the license terms may not be sensible, but they still can be followed. Is the fact they can't sensibly be followed not a problem to be addressed by improving the license terms? The only problem that I can see with the license is the phrase: This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. Thanks, I agree that's a problem. It doesn't belong in the license (it has nothing to do with the permissions granted to the recipient), but rather belongs in the copyright statement for the specific work. The license would be improved – made clearer and more generally applicable – by removing that clause from the license and placing it instead in the copyright statement. -- \ “I put contact lenses in my dog's eyes. They had little | `\ pictures of cats on them. Then I took one out and he ran around | _o__) in circles.” —Steven Wright | Ben Finney -- 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/85y4vbct3f@benfinney.id.au
