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

[Ben Ramsey]

> On Mar 5, 2020, at 16:03, McCoy Smith <mccoy at lexpan.law> wrote:
> 
>>> -----Original Message-----
>>> From: License-review <license-review-bounces at lists.opensource.org> On Behalf Of Ben Ramsey
>>> Sent: Thursday, March 5, 2020 1:25 PM
>>> To: License submissions for OSI review <license-review at lists.opensource.org>
>>> Subject: Re: [License-review] Request for Legacy Approval of PHP License 3.01
> 
>>>> Perhaps a more salient example, which came to mind upon reflection on the early part of my career, was “PCI Hot Plug,” circa 1997
>>>> There's at least one IT use of that acronym dated from at least the late Aughts: http://packet-lab.com/main/service-provider/ccip/item/89-mpls-penultimate-hop-popping.html
>>> These are non-issues, IMO, since PCI Hot Plug and Penultimate Hop Popping aren't derivatives of PHP software.
> 
> My point was more (similar to Richard's) one could write a PCI Hot Plug driver, or some code for Penultimate Hop Popping, based upon code licensed under PHP 3.01, but arguably be precluded from using the names "PCI Hot Plug" or "Penultimate Hop Popping" for that code.  Maybe a better example is PeachPie?
> 
>>>> Or, suppose the Ceph project creates some sort of Kubernetes-related project called "cephpod" and suppose for some bizarre reason it uses a copyrightable snippet of PHP-licensed code.
>>> This is definintely an interesting scenario. Hypothetically, this might be handled by requesting something to distinguish the name as not being “PHP." Perhaps "CephPod?"
> 
> Yes, but in the absence of such an agreement, the license potentially bars you from using that name or variants of it, less you lose your copyright grant.  Is that a right result under OSD?


I think everyone is raising good points and questions about the text of the license. I don’t think we should stop discussing these issues, but are they important to the extent that they would block legacy approval of the license as-is? The existing 3.0 license is OSI-approved and has these same clauses.

If the answer is “yes, these issues could potentially block legacy approval,” then I’ll need to go back to the PHP internals team and discuss what that means for us and how we can fix it.

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/fd281f5d/attachment.asc>