I remember studying the source code to the PHP Zend Engine 25 years ago, and seeing a triple C pointer for the first time (I think it was `zval***`?) I did a lot of PHP in the following years, including using PHP for a high school programming contest (but my submission was rejected because the PHP language and using it in a standalone CLI context in particular was unfamiliar to the staff). I appreciate what it enable…
RFC: PHP license update
41–50 of 91 posts
Re: RFC: PHP license update
#42FYI in case anyone were wondering: Meta uses Hack, not PHP. (Hack's packaging, documentation, and availability suck because there's no performance review "impact" to making things better that no one inside Meta sees. Plus, there's job security in knowledge hoarding.) Licensing: Meta and Google[1], and likely Microsoft, Apple, and most other megacorps explicitly forbid any use of AGPL software because it cannot be pro…
Re: RFC: PHP license update
#43FYI in case anyone were wondering: Meta uses Hack, not PHP. (Hack's packaging, documentation, and availability suck because there's no performance review "impact" to making things better that no one inside Meta sees. Plus, there's job security in knowledge hoarding.) Licensing: Meta and Google[1], and likely Microsoft, Apple, and most other megacorps explicitly forbid any use of AGPL software because it cannot be pro…
Re: RFC: PHP license update
#44Earlier quoted context omitted.
It seems like the only clauses being removed are those that protect PHP and Zend trademarks. Other than that, it's just unifying the two projects under a single license. -- Basically, these two clauses (first from PHP, second from Zend) are removed: The name “PHP” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact group@p…
You may indicate that your software works in conjunction with PHP by saying “Foo for PHP” instead of calling it “PHP Foo” or “phpfoo” Now "Windows Subsystem for Linux" makes even less sense than it already did.
Re: RFC: PHP license update
#45Earlier quoted context omitted.
> I know I'm being pedantic, but this is a narrowing of rights. No, it's not. Explicitly stating which rights you don't grant is not more narrow than implicitly not granting them, it's just clearer. Copyrights and trademark rights are different.
> is not more narrow than implicitly not granting them Implicitly not granted? You mean, not mentioned at all? Imagine a world in which the modified BSD license exists in a vacuum. This license restricts how a product can be endorsed/promoted as per the clause. Granted, additional restrictions are removed in regard to "PHP" et al. The shape is different, not just clearer.
> This license restricts how a product can be endorsed/promoted as per the clause.
...is technically not true for licenses, because they do not _restrict_ usage, rather they _permit_ usage. The usage is, by default, always restricted by automatic copyright and authorship laws, so any license (including the GPL) is not a restriction but a permission, since it has _granted_ permissions that were implicitly not there.
So if you change your license in a way where it appears more restrictions have been added, but those restrictions were already implicit because they were not even covered or taken into account in your original license, no new restrictions were added, your "grant" was just made easier to understand.
Re: RFC: PHP license update
#46Earlier quoted context omitted.
Previously released versions are still available under the terms under which they were originally released.
Yep, that's my "however". For PHP, the new license will apply to version 9 and later if the proposal is adopted.
Re: RFC: PHP license update
#47FYI in case anyone were wondering: Meta uses Hack, not PHP. (Hack's packaging, documentation, and availability suck because there's no performance review "impact" to making things better that no one inside Meta sees. Plus, there's job security in knowledge hoarding.) Licensing: Meta and Google[1], and likely Microsoft, Apple, and most other megacorps explicitly forbid any use of AGPL software because it cannot be pro…
Meta _does_ have some PHP apps. They have a collection of sites running WordPress.
Re: RFC: PHP license update
#48I suppose my concern with not getting permission from all contributors is that a bad faith contributor could make life hard. For those S signs with a stripe, or just out of spite. For better or worse, in systems like the US anyone can sue anyone for any reason and everyone is expected to carry their own costs, which is why everyone is so paranoid and covers their ass with three tanks worth of metal. Aside: "Meanwhile…
The PHP Group can do anything they want since they can release a new version of the license without contributor approval because of the "or later" clause.
It amounts to the same thing, but the former framing means they're covered by the "or later".
Re: RFC: PHP license update
#49Re: RFC: PHP license update
#50Earlier quoted context omitted.
> I know I'm being pedantic, but this is a narrowing of rights. No, it's not. Explicitly stating which rights you don't grant is not more narrow than implicitly not granting them, it's just clearer. Copyrights and trademark rights are different.
> is not more narrow than implicitly not granting them Implicitly not granted? You mean, not mentioned at all? Imagine a world in which the modified BSD license exists in a vacuum. This license restricts how a product can be endorsed/promoted as per the clause. Granted, additional restrictions are removed in regard to "PHP" et al. The shape is different, not just clearer.
"Not mentioned at all" does not mean you can do it. Licenses do not restrict, they permit, from a default of "you may not use my stuff".
The license text could also say "you may not break into my house". That would not make it a "narrowing of rights", and that doesn't mean other licenses implicitly grant you the right to break into the software author's house if you use their software.