Re: Updating the PHP license

2024-05-25 Thread Ben Ramsey
> On May 25, 2024, at 10:03, Francesco Poli  wrote:
> 
> Some minor nitpicks (once again, by a non-native speaker, so they could
> be wrong...): it's not the PHP License, version 4.0, which adopts the
> 3-clause BSD license; it's the PHP Group which adopts the 3-clause BSD
> license as the new version (4.0) of the PHP License.


I think it could be worded either way in English and still make sense, but I’ve 
made the changes to make clear your distinction that it’s not the documents 
themselves adopting the BSD 3-Clause License but the organizations who maintain 
the documents. :-)

Cheers,
Ben




signature.asc
Description: Message signed with OpenPGP


Re: Updating the PHP license

2024-05-25 Thread Francesco Poli
On Fri, 24 May 2024 00:11:39 -0500 Ben Ramsey wrote:

> > On May 23, 2024, at 13:40, Francesco Poli  wrote:
> > 
> > On Wed, 22 May 2024 23:13:13 -0500 Ben Ramsey wrote:
> > 
> > [...]
> >> I’ve updated the RFC according to your suggestions.
> > 
> > Good!   :-)
> > Thanks for taking the time to do so.
> > 
> >> You may find a diff of the changes here:
> >> 
> >> https://wiki.php.net/rfc/php_license_update?do=diff&rev2%5B0%5D=1716433712&rev2%5B1%5D=1716437291&difftype=sidebyside
> >>  
> >> 
> >> Please let me know if you have any feedback on these changes.
> > 
> > After a short review, they look OK to me.
> > 
> > The only thing that I would emphasize more is: the PHP License, version
> > 4.0 should not just have the text identical to the 3-clause BSD
> > license, it should *be* the 3-clause BSD license. In other words, the
> > PHP Group would not merely publish a new license with a text identical
> > to the text of another license: the PHP Group would *designate*[^NOTE]
> > the 3-clause BSD license as the new version of the PHP License (i.e.:
> > version 4.0).
> > 
> > [^NOTE]: or *elect*, or *adopt*, the most suitable word should be
> >chosen by an English native speaker (which I am not) with legal
> >training (which I do not have)...
> > 
> > I think that, this way, clause 5 of the PHP License, version 3.01,
> > would be triggered, but there would be no need to explicitly mention
> > "PHP License, version 4.0" in the source code of a project that decides
> > to upgrade its license (from PHP License, version 3.01 to its
> > successor, the 3-clause BSD license).
> > The reason would that "PHP License, version 4.0" would become an alias
> > of "3-clause BSD license"...
> > 
> > Similarly for the Zend License, of course.
> > 
> > This is how I see it, but, clearly, it has to be checked with someone
> > more knowledgeable than me about the legal aspects.
> 
> 
> Again, great suggestions, Francesco. Many thanks!

You are welcome!  :-)

> 
> I’ve made a few small changes that make it clear that the PHP License, 
> version 4, and Zend Engine License, version 3, both adopt the 3-clause BSD 
> License.
> 
> Changes here: 
> https://wiki.php.net/rfc/php_license_update?do=diff&rev2%5B0%5D=1716438337&rev2%5B1%5D=1716527050&difftype=sidebyside

Yeah, I think this is an improvement.


Some minor nitpicks (once again, by a non-native speaker, so they could
be wrong...): it's not the PHP License, version 4.0, which adopts the
3-clause BSD license; it's the PHP Group which adopts the 3-clause BSD
license as the new version (4.0) of the PHP License.
If you agree with this reasoning, then I would change the following
sentences:

- This proposal addresses a longstanding issue within the open source
- community by publishing new versions of the PHP License and the Zend
- Engine License. The PHP License, version 4, and Zend Engine License,
- version 3, will adopt the BSD 3-Clause License.

into:

+ This proposal addresses a longstanding issue within the open source
+ community by publishing new versions of the PHP License and the Zend
+ Engine License. The BSD 3-Clause License is adopted as The PHP
+ License, version 4, and as The Zend Engine License, version 3.

and:

- Publish the PHP License, version 4, and Zend Engine License, version
- 3, both adopting the BSD 3-Clause License, and deprecate the PHP
- License and Zend Engine License, as proposed in the Proposal section?

into:

+ Publish the PHP License, version 4, and Zend Engine License, version
+ 3, by adopting the BSD 3-Clause License as the new version of both,
+ and deprecate the PHP License and Zend Engine License, as proposed in
+ the Proposal section?


I hope this helps.
Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpUWfjS4_WeA.pgp
Description: PGP signature


Re: Updating the PHP license

2024-05-23 Thread Ben Ramsey
> On May 23, 2024, at 13:40, Francesco Poli  wrote:
> 
> On Wed, 22 May 2024 23:13:13 -0500 Ben Ramsey wrote:
> 
> [...]
>> I’ve updated the RFC according to your suggestions.
> 
> Good!   :-)
> Thanks for taking the time to do so.
> 
>> You may find a diff of the changes here:
>> 
>> https://wiki.php.net/rfc/php_license_update?do=diff&rev2%5B0%5D=1716433712&rev2%5B1%5D=1716437291&difftype=sidebyside
>>  
>> 
>> Please let me know if you have any feedback on these changes.
> 
> After a short review, they look OK to me.
> 
> The only thing that I would emphasize more is: the PHP License, version
> 4.0 should not just have the text identical to the 3-clause BSD
> license, it should *be* the 3-clause BSD license. In other words, the
> PHP Group would not merely publish a new license with a text identical
> to the text of another license: the PHP Group would *designate*[^NOTE]
> the 3-clause BSD license as the new version of the PHP License (i.e.:
> version 4.0).
> 
> [^NOTE]: or *elect*, or *adopt*, the most suitable word should be
>chosen by an English native speaker (which I am not) with legal
>training (which I do not have)...
> 
> I think that, this way, clause 5 of the PHP License, version 3.01,
> would be triggered, but there would be no need to explicitly mention
> "PHP License, version 4.0" in the source code of a project that decides
> to upgrade its license (from PHP License, version 3.01 to its
> successor, the 3-clause BSD license).
> The reason would that "PHP License, version 4.0" would become an alias
> of "3-clause BSD license"...
> 
> Similarly for the Zend License, of course.
> 
> This is how I see it, but, clearly, it has to be checked with someone
> more knowledgeable than me about the legal aspects.


Again, great suggestions, Francesco. Many thanks!

I’ve made a few small changes that make it clear that the PHP License, version 
4, and Zend Engine License, version 3, both adopt the 3-clause BSD License.

Changes here: 
https://wiki.php.net/rfc/php_license_update?do=diff&rev2%5B0%5D=1716438337&rev2%5B1%5D=1716527050&difftype=sidebyside

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP


Re: Updating the PHP license

2024-05-23 Thread Francesco Poli
On Wed, 22 May 2024 23:13:13 -0500 Ben Ramsey wrote:

[...]
> I’ve updated the RFC according to your suggestions.

Good!   :-)
Thanks for taking the time to do so.

> You may find a diff of the changes here:
> 
> https://wiki.php.net/rfc/php_license_update?do=diff&rev2%5B0%5D=1716433712&rev2%5B1%5D=1716437291&difftype=sidebyside
>  
> 
> Please let me know if you have any feedback on these changes.

After a short review, they look OK to me.

The only thing that I would emphasize more is: the PHP License, version
4.0 should not just have the text identical to the 3-clause BSD
license, it should *be* the 3-clause BSD license. In other words, the
PHP Group would not merely publish a new license with a text identical
to the text of another license: the PHP Group would *designate*[^NOTE]
the 3-clause BSD license as the new version of the PHP License (i.e.:
version 4.0).

[^NOTE]: or *elect*, or *adopt*, the most suitable word should be
chosen by an English native speaker (which I am not) with legal
training (which I do not have)...

I think that, this way, clause 5 of the PHP License, version 3.01,
would be triggered, but there would be no need to explicitly mention
"PHP License, version 4.0" in the source code of a project that decides
to upgrade its license (from PHP License, version 3.01 to its
successor, the 3-clause BSD license).
The reason would that "PHP License, version 4.0" would become an alias
of "3-clause BSD license"...

Similarly for the Zend License, of course.

This is how I see it, but, clearly, it has to be checked with someone
more knowledgeable than me about the legal aspects.


Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2YhtpMKSg8.pgp
Description: PGP signature


Re: Updating the PHP license

2024-05-22 Thread Ben Ramsey
> On May 21, 2024, at 19:58, Ben Ramsey  wrote:
> 
> This is something that didn’t cross my mind while I was putting together the 
> RFC, so I’m glad I posted to this list.
> 
> Thank you for the suggestions! I’ll update the RFC and will reply here when 
> I’ve made the changes.


I’ve updated the RFC according to your suggestions. You may find a diff of the 
changes here:

https://wiki.php.net/rfc/php_license_update?do=diff&rev2%5B0%5D=1716433712&rev2%5B1%5D=1716437291&difftype=sidebyside
 

Please let me know if you have any feedback on these changes.

Cheers,
Ben






signature.asc
Description: Message signed with OpenPGP


Re: Updating the PHP license

2024-05-21 Thread Ben Ramsey
> On May 21, 2024, at 16:32, Francesco Poli  wrote:
> 
> On Sun, 19 May 2024 14:53:48 -0500 Ben Ramsey wrote:
> 
>> On May 19, 2024, at 11:42, Francesco Poli  wrote:
> [...]
>>> If the PHP Group decides to elect the 3-clause BSD license as the next
>>> version (4.0) of the PHP License, then clause 5 of the PHP License version
>>> 3.01 will kick in and any piece of software currently licensed under
>>> the terms of the PHP License version 3.01 will *instantly* be also
>>> available under the terms of the 3-clause BSD license, at the
>>> recipient's choice.
>>> 
>>> A similar reasoning should hold for the Zend Engine License, as well…
>> 
>> I want to be clear that this RFC does not exert any control over other
>> projects that use the PHP License.
> 
> I would not call it "control".
> 
> Nobody will be forced to stop copying/modifying/redistributing other
> projects under the terms of the PHP License version 3.01 .
> 
> It's just a license-upgrade clause that can be triggered by the license
> steward, which decides to publish a new version of the license.
> 
> People who released their own projects under the terms of the PHP
> License version 3.01 were (or should have been...) aware of the
> existence of that license-upgrade clause: they decided to trust the PHP
> Group as license steward.
> They should not be surprised, if, at some point in time, that
> license-upgrade clause is actually triggered.
> 
> [...]
>> One of my goals with the RFC is to get rid of the idea of a “PHP License,”
> 
> I agree with this goal.
> 
>> so it deprecates the PHP License and *replaces* it with the
>> BSD 3-Clause License. I don’t want there to be a “PHP License,
>> version 4.0.” I think that will continue to cause confusion
>> in the community.
> 
> If the PHP Group decides to adopt the 3-clause BSD license as the new
> PHP License, version 4.0, there will be no obligation, I think, to
> mention the term "PHP License, version 4.0" in each PHP source code
> file.
> It will be possible to mention the 3-clause BSD license in each source
> file and to state that PHP will be released under the terms of the
> 3-clause BSD license.
> 
> At the same time, somewhere on the php.net website, there will be a
> page that explicitly says that the PHP Group has adopted the 3-clause
> BSD license as the PHP License, version 4.0.


After thinking this over, I like your suggestions and approach. I’ll start 
working on updating the relevant sections of the RFC to call attention to this 
and to also mention this as the “PHP License, version 4.0,” even if we don’t 
put that name in any of the source files, etc.


>> Is there a reading of clause 5 (specifically “You may also choose
>> to use such covered code under the terms of any subsequent version
>> of the license published by the PHP Group.”) that would allow
>> projects using the PHP License to switch to the BSD 3-Clause License,
>> even if a subsequent version 4.0 of the PHP License is not published?
> 
> First off, and I should have stated this more explicitly from the
> beginning, IANAL, TINLA.


Understood. :-)


> That being said, I personally don't see how the license-upgrade clause
> could be triggered, without actually publishing a new version of the
> license.


This is how I understand it, as well.


> AFAICT, the strategy to "adopt" the 3-clause BSD license as the new
> version 4.0 of the PHP License would trigger the license-upgrade
> clause, while at the same time deprecating the use of the PHP License.
> The web page on the php.net website could even explicitly say that the
> PHP License is now deprecated and that the PHP Group has designated the
> 3-clause BSD license as its successor (PHP License, version 4.0).


+1. I like this approach.


> In addition, triggering the license-upgrade mechanism would make it
> much clearer that there's no need to ask for permission to all the
> external contributors and that the license change can be performed just
> with a vote within the PHP Group.


I think this was my biggest concern: I didn’t want to advise others that they 
could update their licenses, only to piss off a bunch of contributors, but if 
we adopt the 3-clause BSD as the next version of the PHP License, then I agree 
with you that it would trigger the license-upgrade mechanism and allow other 
projects to seamlessly upgrade the license, which doesn’t affect any of the 
terms or rights their contributors granted anyway.

This is something that didn’t cross my mind while I was putting together the 
RFC, so I’m glad I posted to this list.

Thank you for the suggestions! I’ll update the RFC and will reply here when 
I’ve made the changes.


> To a layman like me, the reasoning that no contributors, other than
> representatives of the PHP Group, are able to grant or assert clauses
> 4, 5, and 6, looks convincing. But I don't know whether it would
> actually hold water in a court.
> So, maybe, it's better, if the license-upgrade mechanism is also
> triggered.
> 
> Or at least, 

Re: Updating the PHP license

2024-05-21 Thread Ben Ramsey
> On May 21, 2024, at 11:49, Richard Laager  wrote:
> 
> On 2024-05-19 14:53, Ben Ramsey wrote:
>> One of my goals with the RFC is to get rid of the idea of a “PHP License,” 
>> so it deprecates the PHP License and *replaces* it with the BSD 3-Clause 
>> License. I don’t want there to be a “PHP License, version 4.0.” I think that 
>> will continue to cause confusion in the community.
> 
> You (the copyright holders) could do both. That is, the PHP 4.0 license would 
> be the same wording (other than the name) as BSD 3-Clause. That way, you 
> trigger the "any subsequent version" clause, but then you also subsequently 
> relicense PHP itself under BSD 3-Clause directly. This would indicate a clear 
> intention that the PHP License is deprecated, while still getting the "any 
> subsequent version" benefits for existing software.
> 
> Of course, this assumes that you WANT to trigger that option for third-party 
> projects, which you may or may not. (I think you should want that, but it's 
> not my code, so my opinion doesn't really matter.)


Honestly, I hadn’t considered this option before mailing this list, so I’m glad 
I mailed this list. :-)

After thinking it over, I do think we want to trigger this option for 
third-party projects, so that they have a clear path to upgrade the BSD 
3-Clause license.

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP


Re: Updating the PHP license

2024-05-21 Thread Francesco Poli
On Sun, 19 May 2024 14:53:48 -0500 Ben Ramsey wrote:

> On May 19, 2024, at 11:42, Francesco Poli  wrote:
[...]
> > If the PHP Group decides to elect the 3-clause BSD license as the next
> > version (4.0) of the PHP License, then clause 5 of the PHP License version
> > 3.01 will kick in and any piece of software currently licensed under
> > the terms of the PHP License version 3.01 will *instantly* be also
> > available under the terms of the 3-clause BSD license, at the
> > recipient's choice.
> > 
> > A similar reasoning should hold for the Zend Engine License, as well…
> 
> I want to be clear that this RFC does not exert any control over other
> projects that use the PHP License.

I would not call it "control".

Nobody will be forced to stop copying/modifying/redistributing other
projects under the terms of the PHP License version 3.01 .

It's just a license-upgrade clause that can be triggered by the license
steward, which decides to publish a new version of the license.

People who released their own projects under the terms of the PHP
License version 3.01 were (or should have been...) aware of the
existence of that license-upgrade clause: they decided to trust the PHP
Group as license steward.
They should not be surprised, if, at some point in time, that
license-upgrade clause is actually triggered.

[...]
> One of my goals with the RFC is to get rid of the idea of a “PHP License,”

I agree with this goal.

> so it deprecates the PHP License and *replaces* it with the
> BSD 3-Clause License. I don’t want there to be a “PHP License,
> version 4.0.” I think that will continue to cause confusion
> in the community.

If the PHP Group decides to adopt the 3-clause BSD license as the new
PHP License, version 4.0, there will be no obligation, I think, to
mention the term "PHP License, version 4.0" in each PHP source code
file.
It will be possible to mention the 3-clause BSD license in each source
file and to state that PHP will be released under the terms of the
3-clause BSD license.

At the same time, somewhere on the php.net website, there will be a
page that explicitly says that the PHP Group has adopted the 3-clause
BSD license as the PHP License, version 4.0.

> 
> Is there a reading of clause 5 (specifically “You may also choose
> to use such covered code under the terms of any subsequent version
> of the license published by the PHP Group.”) that would allow
> projects using the PHP License to switch to the BSD 3-Clause License,
> even if a subsequent version 4.0 of the PHP License is not published?

First off, and I should have stated this more explicitly from the
beginning, IANAL, TINLA.

That being said, I personally don't see how the license-upgrade clause
could be triggered, without actually publishing a new version of the
license.
AFAICT, the strategy to "adopt" the 3-clause BSD license as the new
version 4.0 of the PHP License would trigger the license-upgrade
clause, while at the same time deprecating the use of the PHP License.
The web page on the php.net website could even explicitly say that the
PHP License is now deprecated and that the PHP Group has designated the
3-clause BSD license as its successor (PHP License, version 4.0).

In addition, triggering the license-upgrade mechanism would make it
much clearer that there's no need to ask for permission to all the
external contributors and that the license change can be performed just
with a vote within the PHP Group.

To a layman like me, the reasoning that no contributors, other than
representatives of the PHP Group, are able to grant or assert clauses
4, 5, and 6, looks convincing. But I don't know whether it would
actually hold water in a court.
So, maybe, it's better, if the license-upgrade mechanism is also
triggered.

Or at least, this is how I personally see it.

Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpdDB3FKTMxI.pgp
Description: PGP signature


Re: Updating the PHP license

2024-05-21 Thread Richard Laager

On 2024-05-19 14:53, Ben Ramsey wrote:

One of my goals with the RFC is to get rid of the idea of a “PHP License,” so 
it deprecates the PHP License and *replaces* it with the BSD 3-Clause License. 
I don’t want there to be a “PHP License, version 4.0.” I think that will 
continue to cause confusion in the community.


You (the copyright holders) could do both. That is, the PHP 4.0 license 
would be the same wording (other than the name) as BSD 3-Clause. That 
way, you trigger the "any subsequent version" clause, but then you also 
subsequently relicense PHP itself under BSD 3-Clause directly. This 
would indicate a clear intention that the PHP License is deprecated, 
while still getting the "any subsequent version" benefits for existing 
software.


Of course, this assumes that you WANT to trigger that option for 
third-party projects, which you may or may not. (I think you should want 
that, but it's not my code, so my opinion doesn't really matter.)



Is there a reading of clause 5 (specifically “You may also choose to use such 
covered code under the terms of any subsequent version of the license published 
by the PHP Group.”) that would allow projects using the PHP License to switch 
to the BSD 3-Clause License, even if a subsequent version 4.0 of the PHP 
License is not published?


IMHO (IANAL, etc.), no.

--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Updating the PHP license

2024-05-19 Thread Ben Ramsey
> On May 19, 2024, at 11:42, Francesco Poli  wrote:
> 
> Here's some feedback about version 0.3 of your RFC.
> 
>> The proposed changes for the PHP software repository will not affect
>> the PHP Manual. The PHP Manual will remain licensed under the Creative
>> Commons Attribution 3.0 License or later.
> 
> How unfortunate!
> Creative Commons licenses are also controversial (although this one,
> CC-by-v3.0, is accepted by the Debian Project, I personally disagree).
> 
> Anyway, the general recommendation is to license the documentation
> under the same legal terms as the documented program or library.
> Hence, I would suggest to also switch the PHP Manual to the 3-clause
> BSD license... this would be absolutely great (although it would
> probably require to seek approval among its copyright holders).

The PHP manual is not distributed with the PHP source code, and it is managed 
by a separate team of volunteers. While related to the PHP source code, it can 
be thought of as a separate project, owned by a separate community. I called 
this out specifically in the RFC to alleviate any concerns that the RFC 
oversteps this invisible boundary by applying itself more broadly.

>> External extensions currently licensed under the PHP License may
>> continue to use the PHP License. There is no need to change extension
>> licenses.
> 
> I don't think so.
> 
> If the PHP Group decides to elect the 3-clause BSD license as the next
> version (4.0) of the PHP License, then clause 5 of the PHP License version
> 3.01 will kick in and any piece of software currently licensed under
> the terms of the PHP License version 3.01 will *instantly* be also
> available under the terms of the 3-clause BSD license, at the
> recipient's choice.
> 
> A similar reasoning should hold for the Zend Engine License, as well…

I want to be clear that this RFC does not exert any control over other projects 
that use the PHP License. This is important. PHP is not one, single unified 
project, despite how it might appear from the outside; it’s a bunch of small, 
independent projects with no single unifying body that can claim control over 
any one of the projects. For this reason, the scope of the RFC is narrow.

One of my goals with the RFC is to get rid of the idea of a “PHP License,” so 
it deprecates the PHP License and *replaces* it with the BSD 3-Clause License. 
I don’t want there to be a “PHP License, version 4.0.” I think that will 
continue to cause confusion in the community.

Is there a reading of clause 5 (specifically “You may also choose to use such 
covered code under the terms of any subsequent version of the license published 
by the PHP Group.”) that would allow projects using the PHP License to switch 
to the BSD 3-Clause License, even if a subsequent version 4.0 of the PHP 
License is not published?

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP


Re: Updating the PHP license

2024-05-19 Thread Francesco Poli
On Sat, 18 May 2024 15:18:36 -0500 Ben Ramsey wrote:

> Hi, all!

Hello Ben!

> 
> Over the years, the open source community, including Debian, has had
> a few lengthy discussions and disagreements regarding the PHP
> license.[^1][^2][^3] The TL;DR sentiment of all these discussions
> amounts to: change the license to something well-understood and less
> problematic.

Indeed, I have personally voiced my disappointment with the PHP License
for a long time. See, for instance, my [analysis] of the PHP License,
version 3.01, and an additional [comment] about another issue.

[analysis]: 
[comment]: 

And I have also attempted to persuade the PHP Group to switch to a well
known and widely adopted general purpose (DFSG-compliant) license.
I got in touch with the PHP Group back in 2016 and tried to convince
them to switch to the 3-clause BSD license, but my attempt was
unfortunately unsuccessful...

> 
> So, that’s what I’m proposing to do in a new RFC I’ve drafted for the
> PHP project: https://wiki.php.net/rfc/php_license_update 

Given what I said above, you may guess I am really happy about your RFC!
Thanks a lot for drafting it and for stewarding this proposal.

> 
> I’ve not opened this up for discussion within the PHP project yet,
> since I’m still collecting feedback, and that’s why I’m sharing it
> here. I’ve put a lot of work into presenting what I think is a sound
> and well-reasoned argument for this change, and I’m asking for
> feedback from this group regarding the method and theory I’m using to
> go about it.

Here's some feedback about version 0.3 of your RFC.

| The proposed changes for the PHP software repository will not affect
| the PHP Manual. The PHP Manual will remain licensed under the Creative
| Commons Attribution 3.0 License or later.

How unfortunate!
Creative Commons licenses are also controversial (although this one,
CC-by-v3.0, is accepted by the Debian Project, I personally disagree).

Anyway, the general recommendation is to license the documentation
under the same legal terms as the documented program or library.
Hence, I would suggest to also switch the PHP Manual to the 3-clause
BSD license... this would be absolutely great (although it would
probably require to seek approval among its copyright holders).

| External extensions currently licensed under the PHP License may
| continue to use the PHP License. There is no need to change extension
| licenses.

I don't think so.

If the PHP Group decides to elect the 3-clause BSD license as the next
version (4.0) of the PHP License, then clause 5 of the PHP License version
3.01 will kick in and any piece of software currently licensed under
the terms of the PHP License version 3.01 will *instantly* be also
available under the terms of the 3-clause BSD license, at the
recipient's choice.

A similar reasoning should hold for the Zend Engine License, as well...

> 
> Thanks in advance!

You're welcome.
Thanks to you for sharing this draft document!

> 
> Cheers,
> Ben

Bye!   :-)

> 
> 
> [^1]: 
> https://duckduckgo.com/?q=site%3Ahttps%3A%2F%2Flists.debian.org%2Fdebian-legal%2F+php
> [^2]: https://lwn.net/Articles/604630/
> [^3]: https://ftp-master.debian.org/php-license.html
> 


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpiFo3xMP9_N.pgp
Description: PGP signature


Re: Updating the PHP license

2024-05-18 Thread Andrew M.A. Cater
On Sat, May 18, 2024 at 03:18:36PM -0500, Ben Ramsey wrote:
> Hi, all!
> 
> Over the years, the open source community, including Debian, has had a few 
> lengthy discussions and disagreements regarding the PHP license.[^1][^2][^3] 
> The TL;DR sentiment of all these discussions amounts to: change the license 
> to something well-understood and less problematic.
> 

This seems like a simplification that's long overdue: your methodology
and justification seem eminently sensible: go for it!

[Disclaimer: IANAL, like most others in this group, but would be very
interested in anything that made licensing more understandable or simpler]

> So, that’s what I’m proposing to do in a new RFC I’ve drafted for the PHP 
> project: https://wiki.php.net/rfc/php_license_update 
> 
> I’ve not opened this up for discussion within the PHP project yet, since I’m 
> still collecting feedback, and that’s why I’m sharing it here. I’ve put a lot 
> of work into presenting what I think is a sound and well-reasoned argument 
> for this change, and I’m asking for feedback from this group regarding the 
> method and theory I’m using to go about it.
> 

See above: all looks good.

> Thanks in advance!
> 

Thanks to you for proposing this

> Cheers,
> Ben
> 

All the very best, as ever,

Andy Cater
(amaca...@debian.org)
> 
> [^1]: 
> https://duckduckgo.com/?q=site%3Ahttps%3A%2F%2Flists.debian.org%2Fdebian-legal%2F+php
> [^2]: https://lwn.net/Articles/604630/
> [^3]: https://ftp-master.debian.org/php-license.html
> 




Updating the PHP license

2024-05-18 Thread Ben Ramsey
Hi, all!

Over the years, the open source community, including Debian, has had a few 
lengthy discussions and disagreements regarding the PHP license.[^1][^2][^3] 
The TL;DR sentiment of all these discussions amounts to: change the license to 
something well-understood and less problematic.

So, that’s what I’m proposing to do in a new RFC I’ve drafted for the PHP 
project: https://wiki.php.net/rfc/php_license_update 

I’ve not opened this up for discussion within the PHP project yet, since I’m 
still collecting feedback, and that’s why I’m sharing it here. I’ve put a lot 
of work into presenting what I think is a sound and well-reasoned argument for 
this change, and I’m asking for feedback from this group regarding the method 
and theory I’m using to go about it.

Thanks in advance!

Cheers,
Ben


[^1]: 
https://duckduckgo.com/?q=site%3Ahttps%3A%2F%2Flists.debian.org%2Fdebian-legal%2F+php
[^2]: https://lwn.net/Articles/604630/
[^3]: https://ftp-master.debian.org/php-license.html



signature.asc
Description: Message signed with OpenPGP