[License-review] Request for Legacy Approval of PHP License 3.01

[Ben Ramsey]

> On Mar 5, 2020, at 05:44, Lukas Atkinson <opensource at lukasatkinson.de> wrote:
> 
> While approval of PHP 3.01 looks like a no-brainer, requiring approval for such changes seems problematic. How can this be avoided in the future?
> 
> All that changed between versions was the phrasing of attribution notices:
> 
> - "This product includes PHP, freely available from <http://www.php.net/>".
> + "This product includes PHP software, freely available from <http://www.php.net/software/>".
> 
> - This product includes the Zend Engine, freely available at <http://www.zend.com>.
> + PHP includes the Zend Engine, freely available at <http://www.zend.com>.
> 
> Arguably, the second change isn't even part of the license terms.
> 
> If the specific content of the notices were replaced with a placeholder, they could be updated in the future without affecting the approved license. This would be similar to how Apache 2.0 and additional terms in GPLv3 treat attribution notices. Placeholders are also used in the OFL, the GPL's notices suggested by the “How to apply these terms to your new programs” appendix, and other approved licenses.
> 
> Would such a parametrization be sensible, or would that be be unsuitable, given that this is a non-reusable license anyway?


Since the license has been in use for over 14 years with no changes, I don’t think parametrization of the license at this point is useful. There are no plans or discussions for any future changes to the text of the license.


> Regarding the problem that “The fact that 3.0 and 3.01 are substantively identical is no use to us at all”, I think it's impossible to satisfy requests for byte-identical licenses in general. I'd argue that is a problem with the downstream policy. Does OSI have any resources on good open source policies, e.g. whether “all open source dependencies MUST have an OSI-approved license” would be recommended?


The PHP project is unable to affect the downstream decisions of its users, so this isn’t something I’m able to address.


Cheers,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20200305/ea0276b7/attachment.asc>