Hi (again),
A quick re-intro for those who don't know or remember me: I'm one of the original PHP Group members, mostly active during the time of horses, buggies, and the transitions from PHP/FI to PHP 3 and PHP 4. I worked for MySQL through their acquisition by Sun (and then Oracle), and was responsible for a lot of the community/development infrastructure there that grew out of what we had done with PHP (mailing lists, bug tracking, the documentation comment system).
Anyway, one of the ways I've been getting back into the PHP community after a long time away is through people on Mastodon and following the #PHP tag there. Recently someone[1] brought up that there was no link from PHP.net to the PHP Foundation so that people and organizations who wanted to (financially) support PHP would even know where to look. I submitted a PR to the web-php project to add some text and a Donate button to the front page of PHP.net.
Derick suggested that I bring it to internals@ because of the politics involved. And certainly, since I've been out of the loop for a long time, I have to admit ignorance of where those may sit. But from my perspective, it looks like the PHP Foundation is the most sensible place to direct this energy, and worthy of it.
I'd be happy to shepherd an RFC on this. Since almost everyone in the PHP Group seems to have been inactive for a long time, I know there's not really a process in place for this sort of non-technical community discussion and decision making, so the RFC process may be the best way to handle it now.
Thanks.
Jim
Hi (again),
A quick re-intro for those who don't know or remember me: I'm one of
the original PHP Group members, mostly active during the time of
horses, buggies, and the transitions from PHP/FI to PHP 3 and PHP 4. I
worked for MySQL through their acquisition by Sun (and then Oracle),
and was responsible for a lot of the community/development
infrastructure there that grew out of what we had done with PHP
(mailing lists, bug tracking, the documentation comment system).Anyway, one of the ways I've been getting back into the PHP community
after a long time away is through people on Mastodon and following the
#PHP tag there. Recently someone[1] brought up that there was no link
from PHP.net to the PHP Foundation so that people and organizations who
wanted to (financially) support PHP would even know where to look. I
submitted a PR to the web-php project to add some text and a Donate
button to the front page of PHP.net.Derick suggested that I bring it to internals@ because of the politics
involved. And certainly, since I've been out of the loop for a long
time, I have to admit ignorance of where those may sit. But from my
perspective, it looks like the PHP Foundation is the most sensible
place to direct this energy, and worthy of it.I'd be happy to shepherd an RFC on this. Since almost everyone in the
PHP Group seems to have been inactive for a long time, I know there's
not really a process in place for this sort of non-technical community
discussion and decision making, so the RFC process may be the best way
to handle it now.Thanks.
Jim
Hi Jim. Welcome back. :-)
The PHP Project today is in a very weird place, strategically. Officially, it has no leadership, voting is open to over 1000 people, all decisions are made by voting of whichever 20 of those people show up at any given time, and even the servers we have and GitHub access is managed through good will and good luck and good relationships between informally key people. The legal authority is held by people who no longer have project involvement (like yourself, until today), which somehow hasn't bitten us yet.
(Whether that is a good or sustainable approach is a separate question I won't go into here.)
The project (meaning, the rough consensus of those who post on this list a lot and those with server access) has long tried to avoid "endorsing" any particular PHP user-space project, or company, or organization, or anything else, because of the (valid) fear that the weight of PHP "endorsing" some project would skew market usage. (The notable exception being Docuwiki, which has been used for RFCs for many years.) This even extends to stand-alone composer libraries, or composer itself, even when their usage would make the code for the decreasing number of servers we maintain ourselves smaller.
From the project's POV, everyone is a volunteer. In practice, there's a half-dozen or so people who are paid to work on PHP either part or full time (mostly by the Foundation, but also Zend), but that gives them no official special authority. (De facto, who knows.)
All of that is to say that the de facto consensus has been to run screaming from "endorsing" the Foundation as an organization, which is why Derick likely suggested bringing the topic up here for discussion as it would be a change of cultural direction, not something to be taken lightly.
All of that said...
I think the Foundation has proven itself valuable and beneficial to the project and community, and I for one would absolutely support an RFC to officially recognize the Foundation as a sponsoring organization to which people should give money. Yes, it's a cultural change, but it's a cultural change that we really do need to make. We no longer have Zend or JetBrains as an informal sugardaddy; instead, we have the Foundation as a clearing house for smaller sugardaddies (as well as big players like JetBrains and Zend). And that is a very good thing! That is the reality on the ground, and we should absolutely recognize and support that.
So count me in as a +1.
--Larry Garfield
Hey Larry, Hey Jim.
Hi (again),
A quick re-intro for those who don't know or remember me: I'm one of
the original PHP Group members, mostly active during the time of
horses, buggies, and the transitions from PHP/FI to PHP 3 and PHP 4. I
worked for MySQL through their acquisition by Sun (and then Oracle),
and was responsible for a lot of the community/development
infrastructure there that grew out of what we had done with PHP
(mailing lists, bug tracking, the documentation comment system).Anyway, one of the ways I've been getting back into the PHP community
after a long time away is through people on Mastodon and following the
#PHP tag there. Recently someone[1] brought up that there was no link
from PHP.net to the PHP Foundation so that people and organizations who
wanted to (financially) support PHP would even know where to look. I
submitted a PR to the web-php project to add some text and a Donate
button to the front page of PHP.net.Derick suggested that I bring it to internals@ because of the politics
involved. And certainly, since I've been out of the loop for a long
time, I have to admit ignorance of where those may sit. But from my
perspective, it looks like the PHP Foundation is the most sensible
place to direct this energy, and worthy of it.I'd be happy to shepherd an RFC on this. Since almost everyone in the
PHP Group seems to have been inactive for a long time, I know there's
not really a process in place for this sort of non-technical community
discussion and decision making, so the RFC process may be the best way
to handle it now.Thanks.
Jim
Hi Jim. Welcome back. :-)
The PHP Project today is in a very weird place, strategically. Officially, it has no leadership, voting is open to over 1000 people, all decisions are made by voting of whichever 20 of those people show up at any given time, and even the servers we have and GitHub access is managed through good will and good luck and good relationships between informally key people. The legal authority is held by people who no longer have project involvement (like yourself, until today), which somehow hasn't bitten us yet.
(Whether that is a good or sustainable approach is a separate question I won't go into here.)
The project (meaning, the rough consensus of those who post on this list a lot and those with server access) has long tried to avoid "endorsing" any particular PHP user-space project, or company, or organization, or anything else, because of the (valid) fear that the weight of PHP "endorsing" some project would skew market usage. (The notable exception being Docuwiki, which has been used for RFCs for many years.) This even extends to stand-alone composer libraries, or composer itself, even when their usage would make the code for the decreasing number of servers we maintain ourselves smaller.
From the project's POV, everyone is a volunteer. In practice, there's a half-dozen or so people who are paid to work on PHP either part or full time (mostly by the Foundation, but also Zend), but that gives them no official special authority. (De facto, who knows.)
All of that is to say that the de facto consensus has been to run screaming from "endorsing" the Foundation as an organization, which is why Derick likely suggested bringing the topic up here for discussion as it would be a change of cultural direction, not something to be taken lightly.
All of that said...
I think the Foundation has proven itself valuable and beneficial to the project and community, and I for one would absolutely support an RFC to officially recognize the Foundation as a sponsoring organization to which people should give money. Yes, it's a cultural change, but it's a cultural change that we really do need to make. We no longer have Zend or JetBrains as an informal sugardaddy; instead, we have the Foundation as a clearing house for smaller sugardaddies (as well as big players like JetBrains and Zend). And that is a very good thing! That is the reality on the ground, and we should absolutely recognize and support that.
I would even support an RFC that goes one step beyond that and not only
officially recognize the PHPFoundation as a sponsoring organization but
also transfers the Copyright on PHP from the ominous "PHP Group" to the
PHP Foundation.
I suppose that is actually nothing that an RFC can do as I imagine that
everyone from the PHP Group needs to support this and even an RFC
wouldn't legally be able to change anything in regards to that.
But it would be a strong signal to transfer the Licence from a group of
individuals that by now probably have only a very small interest in what
happens with PHP to an entity that is actively supporting PHP and
influencing the way PHP evolves.
Happy to help in any way to make this happen.
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
I would even support an RFC that goes one step beyond that and not only
officially recognize the PHPFoundation as a sponsoring organization but
also transfers the Copyright on PHP from the ominous "PHP Group" to the
PHP Foundation.
I'm tending to agree with you here. The PHP Foundation has proven itself as
a valuable organisation. As long as it doesn't go the way of PHP-FIG with
so much bureaucracy, rules, and processes, I would support this movement.
I suppose that is actually nothing that an RFC can do as I imagine that
everyone from the PHP Group needs to support this and even an RFC
wouldn't legally be able to change anything in regards to that.
Surely, everyone who has contributed (i.e. has voting karma) has the
opportunity to vote, and therefore, if they choose not to vote, that is
surely their choice. I don't know the ins and outs of it, but I'd have
thought an RFC, well advertised, with plenty of time to ensure as many
people can vote who have rights to.
Just my 2 cents, I don't often post on the internals list, but this would
be a monumental change.
On Thu, 30 Nov 2023 at 07:28, Andreas Heigl <andreas@heigl.org
mailto:andreas@heigl.org> wrote:
[...snip...]I suppose that is actually nothing that an RFC can do as I imagine that everyone from the PHP Group needs to support this and even an RFC wouldn't legally be able to change anything in regards to that.Surely, everyone who has contributed (i.e. has voting karma) has the
opportunity to vote, and therefore, if they choose not to vote, that is
surely their choice. I don't know the ins and outs of it, but I'd have
thought an RFC, well advertised, with plenty of time to ensure as many
people can vote who have rights to.
What I meant by that is that the members of "The PHP Group" are
currently the copyright holders. From a legal point of view no RFC can
change that. The only way to change that would be for the PHP Group to
transfer their copyright to someone else. What an RFC can do though is
propose that the PHP Group transfers their copyright to the PHP
Foundation.
Though I'm lo lawyer, so ¯_(ツ)_/¯
Cheers
Andreas
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
[...snip...]
I suppose that is actually nothing that an RFC can do as I imagine that
everyone from the PHP Group needs to support this and even an RFC
wouldn't legally be able to change anything in regards to that.
Surely, everyone who has contributed (i.e. has voting karma) has the opportunity to vote, and therefore, if they choose not to vote, that is surely their choice. I don't know the ins and outs of it, but I'd have thought an RFC, well advertised, with plenty of time to ensure as many people can vote who have rights to.What I meant by that is that the members of "The PHP Group" are currently the copyright holders. From a legal point of view no RFC can change that. The only way to change that would be for the PHP Group to transfer their copyright to someone else. What an RFC can do though is propose that the PHP Group transfers their copyright to the PHP Foundation.
Though I'm lo lawyer, so ¯_(ツ)_/¯
I have spoken at length with a lawyer about this, and the TL;DR version is that every contributor owns the copyright on their specific contributions, if the contributions are copyrightable. Some contributions (typo fixes, white space changes, etc.) aren’t copyrightable, but anything more significant that is the contributor’s own work belongs to them.
In other words, even though the license statement says the copyright belongs to The PHP Group^1 or Zend Technologies Ltd.^2, technically, these copyrights only apply to the specific code contributed by these organizations or contributed by people for these organizations (through work-for-hire or by legally transferring the copyright to them).
Contributing to an open source project is NOT an implicit transfer of your copyright to the project. To do this, every contributor needs to sign a CLA that specifies they are transferring their copyright to The PHP Group.
What is implied, however—and I’m told this is how most courts in the US and outside would view it—is assignment of license. When someone contributes to an open source project, they own the copyright on their contributions, but unless they specify a different license that covers their contributions, it’s implied that they are granting use of their contributions under the same license as the project. In this way, the contributor can’t later demand to have their copyrighted code removed; it’s under the terms of the same license, which can't be revoked.
Once a copyright statement is placed on a source file, there’s a bunch of legal reasons why you cannot change or remove that copyright statement. In general, you should keep all copyright statements added to a source file and never change one that already exists on a source file. Just look at the file header on any WebKit^3 source file. WebKit even specifies that you add a copyright notice to each file where you make “significant” changes.^4
With this in mind, it would be more proper to update the general copyright notice to something like this:
Copyright (c) 2023 and later, The PHP Foundation and contributors. All rights reserved.
Copyright (c) 1999-2023, The PHP Group and contributors. All rights reserved.
Since no reassignment of copyright is taking place, we don’t run into any major legal issues, and this tells a true and accurate story. The PHP Group were stewards of the project until 2023, at which point the community recognized The PHP Foundation as the new stewards of the project, and through all of this time (since 1999), the various copyrights have been owned by their respective owners (i.e., contributors).
If you look at the file headers on ICU source code, you can see that Unicode, Inc. made a similar change in 2016.^5
All this said… I am in favor of making this change.
I also have a lot more to say on this, as I’ve been considering opening up an RFC on just this topic. I had intended to reach out to Zend first (through Matthew Weier O’Phinney), but I haven’t done that yet, so this is the first time anyone from Zend has seen these ideas. My apologies. :-)
The PHP source code is interesting in that it is covered by two licenses: the PHP License^6 and the Zend Engine License.^7 This is an historical artifact of the early days of PHP when it was conceivable that other companies might develop their own engines for PHP, but we know how this story ends: for all intents and purposes, the Zend Engine is PHP and PHP is the Zend Engine. Yes, I’m aware of alternatives (with very limited adoption), and no, they don’t matter for this discussion.
Both the PHP License and Zend Engine License are based on the BSD 4-clause “Original” license,^8 and as a result, neither are compatible with the GPL.^9 In fact, the Zend Engine License isn’t an OSI Approved License, while the PHP License is,^11 and this can cause problems, especially with companies that require SBOMs listing the licenses of all third-party software used and these licenses must be OSI Approved. I’m not sure why no one has raised this as an issue yet, and I’ve been quiet about it (until now) to avoid it becoming an issue.
The BSD 4-clause license is the one that includes the “obnoxious” (in the words of the FSF) advertising clause, and the Zend license includes this. Both the PHP and Zend licenses include a statement that says The PHP Group and Zend Technologies Ltd. have the exclusive right to publish revised versions of the license, and both state that redistributions must include a specific “this product includes…” statement. The PHP License also includes the restrictions against using the name “PHP” in the name of any derivatives. If all of these statements are removed, the licenses become identical to the BSD 3-clause license.
So, a few points about this:
- In general, when changing a project’s license, you need every contributor to approve of the changes because they own the copyrights on their contributions and the license terms of their copyrighted contributions are changing.
- The PHP and Zend licenses are essentially the BSD 3-clause license with additional stuff.
- The additional stuff isn’t related to any rights a contributor (i.e., copyright holder), other than The PHP Group and Zend, would have on the source code.
- The PHP Group has already specified it has the right to modify its license.
- Zend has already specified it has the right to modify its license.
- The additional stuff is largely unimportant and unenforceable.
- If both licenses are modified to change them to the BSD 3-clause license, this does not change any of the terms the contributors (i.e., the copyright holders) have granted to users, so we don’t need explicit approval from all contributors (though an advance notice of several months to allow comments on the changes is a nice gesture).
Obviously, IANAL, but I’ve spoken with Pamela Chestek about these changes. She is a member of the Board and Chair of the License Committee for the Open Source Initiative, though I must make it clear (for legal reasons) that she was not acting in an official capacity of her role with the OSI when we spoke.
MY PROPOSAL:
-
Retire the PHP License and Zend Engine License.
-
Drop the Zend/LICENSE file and replace the text of the LICENSE file with the exact text of the BSD 3-clause license.
-
Replace the copyright notice in the file headers and LICENSE with the following:
Copyright (c) 2023 and later, The PHP Foundation and contributors.
Copyright (c) 1999-2023, The PHP Group and contributors.
Copyright (c) 1999-2023, Zend Technologies USA, Inc. ("Zend”),
a subsidiary of Perforce Software, Inc.
Here is an example diff of the proposed changes to the LICENSE file: https://gist.github.com/ramsey/96026cda9da33cb95e49357dc074cdb5
We would allow contributors (i.e., copyright holders) at least 3 months to make comments on the proposal, after which their approval is implied.
An ALTERNATE PROPOSAL, if others feel strongly about keeping the “additional stuff” in the LICENSE:
- Retire the Zend Engine License, effectively folding it into the PHP License.
- Make some light edits to the PHP License to bring it to parity with the exact text of the BSD 3-clause license, while keeping the aforementioned “additional stuff.”
- Replace the copyright notice in the file headers and LICENSE, as noted above.
- Bump the PHP License version number to 3.2.
Here is an example diff of the alternate proposed changes to the LICENSE file: https://gist.github.com/ramsey/b6bd0339a027b182f91133d912515d44
Again, we would allow contributors (i.e., copyright holders) at least 3 months to make comments on the proposal, after which their approval is implied.
It’s important to note that The PHP Group (or PHP Association) did exist at one time as a formal business entity in the US,^12 and Zend drafted a formal agreement with the PHP Association for its use of the Zend Engine.^13 So, there is some precedence here for members of The PHP Group to step forward and “bless” or approve of this proposal. Additionally, it’s important for Zend to also “bless” or approve of this.
So, this is a lot for a message in a thread about adding a donation link to the PHP website, but if others are interested, I can take this into a new thread and work on a separate RFC, or perhaps we use the same RFC for both and use it as an opportunity to formalize the project’s relationship with The PHP Foundation, as the successor to The PHP Group.
Cheers,
Ben
Hey Ben
[...snip...]
I suppose that is actually nothing that an RFC can do as I imagine that everyone from the PHP Group needs to support this and even an RFC wouldn't legally be able to change anything in regards to that.Surely, everyone who has contributed (i.e. has voting karma) has the opportunity to vote, and therefore, if they choose not to vote, that is surely their choice. I don't know the ins and outs of it, but I'd have thought an RFC, well advertised, with plenty of time to ensure as many people can vote who have rights to.
What I meant by that is that the members of "The PHP Group" are currently the copyright holders. From a legal point of view no RFC can change that. The only way to change that would be for the PHP Group to transfer their copyright to someone else. What an RFC can do though is propose that the PHP Group transfers their copyright to the PHP Foundation.
Though I'm lo lawyer, so ¯_(ツ)_/¯
I have spoken at length with a lawyer about this, and the TL;DR version is that every contributor owns the copyright on their specific contributions, if the contributions are copyrightable. Some contributions (typo fixes, white space changes, etc.) aren’t copyrightable, but anything more significant that is the contributor’s own work belongs to them.
In other words, even though the license statement says the copyright belongs to The PHP Group[^1] or Zend Technologies Ltd.[^2], technically, these copyrights only apply to the specific code contributed by these organizations or contributed by people for these organizations (through work-for-hire or by legally transferring the copyright to them).
Contributing to an open source project is NOT an implicit transfer of your copyright to the project. To do this, every contributor needs to sign a CLA that specifies they are transferring their copyright to The PHP Group.
What is implied, however—and I’m told this is how most courts in the US and outside would view it—is assignment of license. When someone contributes to an open source project, they own the copyright on their contributions, but unless they specify a different license that covers their contributions, it’s implied that they are granting use of their contributions under the same license as the project. In this way, the contributor can’t later demand to have their copyrighted code removed; it’s under the terms of the same license, which can't be revoked.
Once a copyright statement is placed on a source file, there’s a bunch of legal reasons why you cannot change or remove that copyright statement. In general, you should keep all copyright statements added to a source file and never change one that already exists on a source file. Just look at the file header on any WebKit[^3] source file. WebKit even specifies that you add a copyright notice to each file where you make “significant” changes.[^4]
With this in mind, it would be more proper to update the general copyright notice to something like this:
Copyright (c) 2023 and later, The PHP Foundation and contributors. All rights reserved. Copyright (c) 1999-2023, The PHP Group and contributors. All rights reserved.Since no reassignment of copyright is taking place, we don’t run into any major legal issues, and this tells a true and accurate story. The PHP Group were stewards of the project until 2023, at which point the community recognized The PHP Foundation as the new stewards of the project, and through all of this time (since 1999), the various copyrights have been owned by their respective owners (i.e., contributors).
If you look at the file headers on ICU source code, you can see that Unicode, Inc. made a similar change in 2016.[^5]
All this said… I am in favor of making this change.
I also have a lot more to say on this, as I’ve been considering opening up an RFC on just this topic. I had intended to reach out to Zend first (through Matthew Weier O’Phinney), but I haven’t done that yet, so this is the first time anyone from Zend has seen these ideas. My apologies. :-)
The PHP source code is interesting in that it is covered by two licenses: the PHP License[^6] and the Zend Engine License.[^7] This is an historical artifact of the early days of PHP when it was conceivable that other companies might develop their own engines for PHP, but we know how this story ends: for all intents and purposes, the Zend Engine is PHP and PHP is the Zend Engine. Yes, I’m aware of alternatives (with very limited adoption), and no, they don’t matter for this discussion.
Both the PHP License and Zend Engine License are based on the BSD 4-clause “Original” license,[^8] and as a result, neither are compatible with the GPL.[^9][^10] In fact, the Zend Engine License isn’t an OSI Approved License, while the PHP License is,[^11] and this can cause problems, especially with companies that require SBOMs listing the licenses of all third-party software used and these licenses must be OSI Approved. I’m not sure why no one has raised this as an issue yet, and I’ve been quiet about it (until now) to avoid it becoming an issue.
The BSD 4-clause license is the one that includes the “obnoxious” (in the words of the FSF) advertising clause, and the Zend license includes this. Both the PHP and Zend licenses include a statement that says The PHP Group and Zend Technologies Ltd. have the exclusive right to publish revised versions of the license, and both state that redistributions must include a specific “this product includes…” statement. The PHP License also includes the restrictions against using the name “PHP” in the name of any derivatives. If all of these statements are removed, the licenses become identical to the BSD 3-clause license.
So, a few points about this:
- In general, when changing a project’s license, you need every contributor to approve of the changes because they own the copyrights on their contributions and the license terms of their copyrighted contributions are changing.
- The PHP and Zend licenses are essentially the BSD 3-clause license with additional stuff.
- The additional stuff isn’t related to any rights a contributor (i.e., copyright holder), other than The PHP Group and Zend, would have on the source code.
- The PHP Group has already specified it has the right to modify its license.
- Zend has already specified it has the right to modify its license.
- The additional stuff is largely unimportant and unenforceable.
- If both licenses are modified to change them to the BSD 3-clause license, this does not change any of the terms the contributors (i.e., the copyright holders) have granted to users, so we don’t need explicit approval from all contributors (though an advance notice of several months to allow comments on the changes is a nice gesture).
Obviously, IANAL, but I’ve spoken with Pamela Chestek about these changes. She is a member of the Board and Chair of the License Committee for the Open Source Initiative, though I must make it clear (for legal reasons) that she was not acting in an official capacity of her role with the OSI when we spoke.
MY PROPOSAL:
Retire the PHP License and Zend Engine License.
Drop the Zend/LICENSE file and replace the text of the LICENSE file with the exact text of the BSD 3-clause license.
Replace the copyright notice in the file headers and LICENSE with the following:
Copyright (c) 2023 and later, The PHP Foundation and contributors.
Copyright (c) 1999-2023, The PHP Group and contributors.
Copyright (c) 1999-2023, Zend Technologies USA, Inc. ("Zend”),
a subsidiary of Perforce Software, Inc.Here is an example diff of the proposed changes to the LICENSE file: https://gist.github.com/ramsey/96026cda9da33cb95e49357dc074cdb5
We would allow contributors (i.e., copyright holders) at least 3 months to make comments on the proposal, after which their approval is implied.
An ALTERNATE PROPOSAL, if others feel strongly about keeping the “additional stuff” in the LICENSE:
- Retire the Zend Engine License, effectively folding it into the PHP License.
- Make some light edits to the PHP License to bring it to parity with the exact text of the BSD 3-clause license, while keeping the aforementioned “additional stuff.”
- Replace the copyright notice in the file headers and LICENSE, as noted above.
- Bump the PHP License version number to 3.2.
Here is an example diff of the alternate proposed changes to the LICENSE file: https://gist.github.com/ramsey/b6bd0339a027b182f91133d912515d44
Again, we would allow contributors (i.e., copyright holders) at least 3 months to make comments on the proposal, after which their approval is implied.
It’s important to note that The PHP Group (or PHP Association) did exist at one time as a formal business entity in the US,[^12] and Zend drafted a formal agreement with the PHP Association for its use of the Zend Engine.[^13] So, there is some precedence here for members of The PHP Group to step forward and “bless” or approve of this proposal. Additionally, it’s important for Zend to also “bless” or approve of this.
So, this is a lot for a message in a thread about adding a donation link to the PHP website, but if others are interested, I can take this into a new thread and work on a separate RFC, or perhaps we use the same RFC for both and use it as an opportunity to formalize the project’s relationship with The PHP Foundation, as the successor to The PHP Group.
Thank you for this in depth explanation!
To me that already before that email sounded more than just an add on to
the donation link question.
The reason I brought it up was that both seemed to have something to do
with the PHP Group.
After digesting these information I would definitely
a: want to go the path to change the license following one of your
proposals but
b: separate that from the question regarding the donation link!
I would happily help in drafting an RFC based on your proposals. My
first idea would be to not change the license in the middle of the
PHP8.3 lifecycle but have PHP8.4 or even PHP9 (as it kinda is a BC break
🙈) released with the new license.
As this would be a special RFC we'd definitely need a longer discussion
period than the required minimum of 2 weeks but we can explain those
details in the RFC itself.
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
Hey Ben
[...snip...]
I suppose that is actually nothing that an RFC can do as I imagine that everyone from the PHP Group needs to support this and even an RFC wouldn't legally be able to change anything in regards to that.Surely, everyone who has contributed (i.e. has voting karma) has the opportunity to vote, and therefore, if they choose not to vote, that is surely their choice. I don't know the ins and outs of it, but I'd have thought an RFC, well advertised, with plenty of time to ensure as many people can vote who have rights to.
What I meant by that is that the members of "The PHP Group" are currently the copyright holders. From a legal point of view no RFC can change that. The only way to change that would be for the PHP Group to transfer their copyright to someone else. What an RFC can do though is propose that the PHP Group transfers their copyright to the PHP Foundation.
Though I'm lo lawyer, so ¯_(ツ)_/¯
I have spoken at length with a lawyer about this, and the TL;DR version is that every contributor owns the copyright on their specific contributions, if the contributions are copyrightable. Some contributions (typo fixes, white space changes, etc.) aren’t copyrightable, but anything more significant that is the contributor’s own work belongs to them.
In other words, even though the license statement says the copyright belongs to The PHP Group[^1] or Zend Technologies Ltd.[^2], technically, these copyrights only apply to the specific code contributed by these organizations or contributed by people for these organizations (through work-for-hire or by legally transferring the copyright to them).
Contributing to an open source project is NOT an implicit transfer of your copyright to the project. To do this, every contributor needs to sign a CLA that specifies they are transferring their copyright to The PHP Group.
What is implied, however—and I’m told this is how most courts in the US and outside would view it—is assignment of license. When someone contributes to an open source project, they own the copyright on their contributions, but unless they specify a different license that covers their contributions, it’s implied that they are granting use of their contributions under the same license as the project. In this way, the contributor can’t later demand to have their copyrighted code removed; it’s under the terms of the same license, which can't be revoked.
Once a copyright statement is placed on a source file, there’s a bunch of legal reasons why you cannot change or remove that copyright statement. In general, you should keep all copyright statements added to a source file and never change one that already exists on a source file. Just look at the file header on any WebKit[^3] source file. WebKit even specifies that you add a copyright notice to each file where you make “significant” changes.[^4]
With this in mind, it would be more proper to update the general copyright notice to something like this:
Copyright (c) 2023 and later, The PHP Foundation and contributors. All rights reserved. Copyright (c) 1999-2023, The PHP Group and contributors. All rights reserved.Since no reassignment of copyright is taking place, we don’t run into any major legal issues, and this tells a true and accurate story. The PHP Group were stewards of the project until 2023, at which point the community recognized The PHP Foundation as the new stewards of the project, and through all of this time (since 1999), the various copyrights have been owned by their respective owners (i.e., contributors).
If you look at the file headers on ICU source code, you can see that Unicode, Inc. made a similar change in 2016.[^5]
All this said… I am in favor of making this change.
I also have a lot more to say on this, as I’ve been considering opening up an RFC on just this topic. I had intended to reach out to Zend first (through Matthew Weier O’Phinney), but I haven’t done that yet, so this is the first time anyone from Zend has seen these ideas. My apologies. :-)
The PHP source code is interesting in that it is covered by two licenses: the PHP License[^6] and the Zend Engine License.[^7] This is an historical artifact of the early days of PHP when it was conceivable that other companies might develop their own engines for PHP, but we know how this story ends: for all intents and purposes, the Zend Engine is PHP and PHP is the Zend Engine. Yes, I’m aware of alternatives (with very limited adoption), and no, they don’t matter for this discussion.
Both the PHP License and Zend Engine License are based on the BSD 4-clause “Original” license,[^8] and as a result, neither are compatible with the GPL.[^9][^10] In fact, the Zend Engine License isn’t an OSI Approved License, while the PHP License is,[^11] and this can cause problems, especially with companies that require SBOMs listing the licenses of all third-party software used and these licenses must be OSI Approved. I’m not sure why no one has raised this as an issue yet, and I’ve been quiet about it (until now) to avoid it becoming an issue.
The BSD 4-clause license is the one that includes the “obnoxious” (in the words of the FSF) advertising clause, and the Zend license includes this. Both the PHP and Zend licenses include a statement that says The PHP Group and Zend Technologies Ltd. have the exclusive right to publish revised versions of the license, and both state that redistributions must include a specific “this product includes…” statement. The PHP License also includes the restrictions against using the name “PHP” in the name of any derivatives. If all of these statements are removed, the licenses become identical to the BSD 3-clause license.
So, a few points about this:
- In general, when changing a project’s license, you need every contributor to approve of the changes because they own the copyrights on their contributions and the license terms of their copyrighted contributions are changing.
- The PHP and Zend licenses are essentially the BSD 3-clause license with additional stuff.
- The additional stuff isn’t related to any rights a contributor (i.e., copyright holder), other than The PHP Group and Zend, would have on the source code.
- The PHP Group has already specified it has the right to modify its license.
- Zend has already specified it has the right to modify its license.
- The additional stuff is largely unimportant and unenforceable.
- If both licenses are modified to change them to the BSD 3-clause license, this does not change any of the terms the contributors (i.e., the copyright holders) have granted to users, so we don’t need explicit approval from all contributors (though an advance notice of several months to allow comments on the changes is a nice gesture).
Obviously, IANAL, but I’ve spoken with Pamela Chestek about these changes. She is a member of the Board and Chair of the License Committee for the Open Source Initiative, though I must make it clear (for legal reasons) that she was not acting in an official capacity of her role with the OSI when we spoke.
MY PROPOSAL:
Retire the PHP License and Zend Engine License.
Drop the Zend/LICENSE file and replace the text of the LICENSE file with the exact text of the BSD 3-clause license.
Replace the copyright notice in the file headers and LICENSE with the following:
Copyright (c) 2023 and later, The PHP Foundation and contributors.
Copyright (c) 1999-2023, The PHP Group and contributors.
Copyright (c) 1999-2023, Zend Technologies USA, Inc. ("Zend”),
a subsidiary of Perforce Software, Inc.Here is an example diff of the proposed changes to the LICENSE file: https://gist.github.com/ramsey/96026cda9da33cb95e49357dc074cdb5
We would allow contributors (i.e., copyright holders) at least 3 months to make comments on the proposal, after which their approval is implied.
An ALTERNATE PROPOSAL, if others feel strongly about keeping the “additional stuff” in the LICENSE:
- Retire the Zend Engine License, effectively folding it into the PHP License.
- Make some light edits to the PHP License to bring it to parity with the exact text of the BSD 3-clause license, while keeping the aforementioned “additional stuff.”
- Replace the copyright notice in the file headers and LICENSE, as noted above.
- Bump the PHP License version number to 3.2.
Here is an example diff of the alternate proposed changes to the LICENSE file: https://gist.github.com/ramsey/b6bd0339a027b182f91133d912515d44
Again, we would allow contributors (i.e., copyright holders) at least 3 months to make comments on the proposal, after which their approval is implied.
It’s important to note that The PHP Group (or PHP Association) did exist at one time as a formal business entity in the US,[^12] and Zend drafted a formal agreement with the PHP Association for its use of the Zend Engine.[^13] So, there is some precedence here for members of The PHP Group to step forward and “bless” or approve of this proposal. Additionally, it’s important for Zend to also “bless” or approve of this.
So, this is a lot for a message in a thread about adding a donation link to the PHP website, but if others are interested, I can take this into a new thread and work on a separate RFC, or perhaps we use the same RFC for both and use it as an opportunity to formalize the project’s relationship with The PHP Foundation, as the successor to The PHP Group.
Thank you for this in depth explanation!
To me that already before that email sounded more than just an add on to
the donation link question.The reason I brought it up was that both seemed to have something to do
with the PHP Group.After digesting these information I would definitely
a: want to go the path to change the license following one of your
proposals but
b: separate that from the question regarding the donation link!I would happily help in drafting an RFC based on your proposals. My
first idea would be to not change the license in the middle of the
PHP8.3 lifecycle but have PHP8.4 or even PHP9 (as it kinda is a BC break
🙈) released with the new license.As this would be a special RFC we'd definitely need a longer discussion
period than the required minimum of 2 weeks but we can explain those
details in the RFC itself.Cheers
Andreas
I would agree that linking to the Foundation for donations and fully switching up the license/copyright are separate issues and should be separate proposals/RFCs. That said, I in principle support both.
A license switch sounds like something that should be part of PHP 9; that's also ample time for discussion.
--Larry Garfield
Hi Ben
On Thu, 30 Nov 2023 at 07:28, Andreas Heigl <andreas@heigl.org <mailto:
andreas@heigl.org>> wrote:
[...snip...]
I suppose that is actually nothing that an RFC can do as I imagine
that
everyone from the PHP Group needs to support this and even an RFC
wouldn't legally be able to change anything in regards to that.
Surely, everyone who has contributed (i.e. has voting karma) has the
opportunity to vote, and therefore, if they choose not to vote, that is
surely their choice. I don't know the ins and outs of it, but I'd have
thought an RFC, well advertised, with plenty of time to ensure as many
people can vote who have rights to.What I meant by that is that the members of "The PHP Group" are
currently the copyright holders. From a legal point of view no RFC can
change that. The only way to change that would be for the PHP Group to
transfer their copyright to someone else. What an RFC can do though is
propose that the PHP Group transfers their copyright to the PHP
Foundation.Though I'm lo lawyer, so ¯_(ツ)_/¯
I have spoken at length with a lawyer about this, and the TL;DR version is
that every contributor owns the copyright on their specific contributions,
if the contributions are copyrightable. Some contributions (typo fixes,
white space changes, etc.) aren’t copyrightable, but anything more
significant that is the contributor’s own work belongs to them.In other words, even though the license statement says the copyright
belongs to The PHP Group^1 or Zend Technologies Ltd.^2, technically,
these copyrights only apply to the specific code contributed by these
organizations or contributed by people for these organizations (through
work-for-hire or by legally transferring the copyright to them).Contributing to an open source project is NOT an implicit transfer of your
copyright to the project. To do this, every contributor needs to sign a CLA
that specifies they are transferring their copyright to The PHP Group.What is implied, however—and I’m told this is how most courts in the US
and outside would view it—is assignment of license. When someone
contributes to an open source project, they own the copyright on their
contributions, but unless they specify a different license that covers
their contributions, it’s implied that they are granting use of their
contributions under the same license as the project. In this way, the
contributor can’t later demand to have their copyrighted code removed; it’s
under the terms of the same license, which can't be revoked.Once a copyright statement is placed on a source file, there’s a bunch of
legal reasons why you cannot change or remove that copyright statement. In
general, you should keep all copyright statements added to a source file
and never change one that already exists on a source file. Just look at the
file header on any WebKit^3 source file. WebKit even specifies that you
add a copyright notice to each file where you make “significant”
changes.^4With this in mind, it would be more proper to update the general copyright
notice to something like this:Copyright (c) 2023 and later, The PHP Foundation and contributors. Allrights reserved.
Copyright (c) 1999-2023, The PHP Group and contributors. All rights
reserved.Since no reassignment of copyright is taking place, we don’t run into any
major legal issues, and this tells a true and accurate story. The PHP Group
were stewards of the project until 2023, at which point the community
recognized The PHP Foundation as the new stewards of the project, and
through all of this time (since 1999), the various copyrights have been
owned by their respective owners (i.e., contributors).If you look at the file headers on ICU source code, you can see that
Unicode, Inc. made a similar change in 2016.^5All this said… I am in favor of making this change.
I also have a lot more to say on this, as I’ve been considering opening up
an RFC on just this topic. I had intended to reach out to Zend first
(through Matthew Weier O’Phinney), but I haven’t done that yet, so this is
the first time anyone from Zend has seen these ideas. My apologies. :-)The PHP source code is interesting in that it is covered by two licenses:
the PHP License^6 and the Zend Engine License.^7 This is an historical
artifact of the early days of PHP when it was conceivable that other
companies might develop their own engines for PHP, but we know how this
story ends: for all intents and purposes, the Zend Engine is PHP and PHP is
the Zend Engine. Yes, I’m aware of alternatives (with very limited
adoption), and no, they don’t matter for this discussion.Both the PHP License and Zend Engine License are based on the BSD 4-clause
“Original” license,^8 and as a result, neither are compatible with the
GPL.^9 In fact, the Zend Engine License isn’t an OSI Approved
License, while the PHP License is,^11 and this can cause problems,
especially with companies that require SBOMs listing the licenses of all
third-party software used and these licenses must be OSI Approved. I’m not
sure why no one has raised this as an issue yet, and I’ve been quiet about
it (until now) to avoid it becoming an issue.The BSD 4-clause license is the one that includes the “obnoxious” (in the
words of the FSF) advertising clause, and the Zend license includes this.
Both the PHP and Zend licenses include a statement that says The PHP Group
and Zend Technologies Ltd. have the exclusive right to publish revised
versions of the license, and both state that redistributions must include a
specific “this product includes…” statement. The PHP License also includes
the restrictions against using the name “PHP” in the name of any
derivatives. If all of these statements are removed, the licenses become
identical to the BSD 3-clause license.So, a few points about this:
- In general, when changing a project’s license, you need every
contributor to approve of the changes because they own the copyrights on
their contributions and the license terms of their copyrighted
contributions are changing.- The PHP and Zend licenses are essentially the BSD 3-clause license with
additional stuff.- The additional stuff isn’t related to any rights a contributor (i.e.,
copyright holder), other than The PHP Group and Zend, would have on the
source code.- The PHP Group has already specified it has the right to modify its
license.- Zend has already specified it has the right to modify its license.
- The additional stuff is largely unimportant and unenforceable.
- If both licenses are modified to change them to the BSD 3-clause
license, this does not change any of the terms the contributors (i.e., the
copyright holders) have granted to users, so we don’t need explicit
approval from all contributors (though an advance notice of several months
to allow comments on the changes is a nice gesture).Obviously, IANAL, but I’ve spoken with Pamela Chestek about these changes.
She is a member of the Board and Chair of the License Committee for the
Open Source Initiative, though I must make it clear (for legal reasons)
that she was not acting in an official capacity of her role with the OSI
when we spoke.MY PROPOSAL:
Retire the PHP License and Zend Engine License.
Drop the Zend/LICENSE file and replace the text of the LICENSE file
with the exact text of the BSD 3-clause license.Replace the copyright notice in the file headers and LICENSE with the
following:Copyright (c) 2023 and later, The PHP Foundation and contributors.
Copyright (c) 1999-2023, The PHP Group and contributors.
Copyright (c) 1999-2023, Zend Technologies USA, Inc. ("Zend”),
a subsidiary of Perforce Software, Inc.Here is an example diff of the proposed changes to the LICENSE file:
https://gist.github.com/ramsey/96026cda9da33cb95e49357dc074cdb5We would allow contributors (i.e., copyright holders) at least 3 months to
make comments on the proposal, after which their approval is implied.An ALTERNATE PROPOSAL, if others feel strongly about keeping the
“additional stuff” in the LICENSE:
- Retire the Zend Engine License, effectively folding it into the PHP
License.- Make some light edits to the PHP License to bring it to parity with the
exact text of the BSD 3-clause license, while keeping the aforementioned
“additional stuff.”- Replace the copyright notice in the file headers and LICENSE, as noted
above.- Bump the PHP License version number to 3.2.
Here is an example diff of the alternate proposed changes to the LICENSE
file: https://gist.github.com/ramsey/b6bd0339a027b182f91133d912515d44Again, we would allow contributors (i.e., copyright holders) at least 3
months to make comments on the proposal, after which their approval is
implied.It’s important to note that The PHP Group (or PHP Association) did exist
at one time as a formal business entity in the US,^12 and Zend drafted a
formal agreement with the PHP Association for its use of the Zend
Engine.^13 So, there is some precedence here for members of The PHP Group
to step forward and “bless” or approve of this proposal. Additionally, it’s
important for Zend to also “bless” or approve of this.So, this is a lot for a message in a thread about adding a donation link
to the PHP website, but if others are interested, I can take this into a
new thread and work on a separate RFC, or perhaps we use the same RFC for
both and use it as an opportunity to formalize the project’s relationship
with The PHP Foundation, as the successor to The PHP Group.Cheers,
Ben
Thanks for the details, I now need to find some time to read this in depth
:P
There's one important piece missing in your analysis:
That could be important for the reasoning (and that's one nice reason to
use GH for development)
Nicolas
Nicolas Grekas wrote:
There's one important piece missing in your analysis:
Note the second paragraph there:
Isn't this just how it works already? Yep. This is widely accepted as the norm in the open-source community; it's commonly referred to by the shorthand "inbound=outbound". We're just making it explicit.
My reading of Ben's analysis is that not only is this widely accepted by the community, it's widely accepted by the legal system as well. So contributing via GitHub isn't doing anything extra here, they're just reminding their users, like statements of "all rights reserved" or "this does not affect your statutory rights".
As to the main thrust of the thread: I agree with Larry's last email: both donation and licensing changes seem sensible steps forward.
The only note of caution I would throw in is that the recent Technical Committee proposal [1] was soundly rejected, so any organisational changes are likely to be a lot more contentious. So care should be taken to separate those from purely legal or financial links.
[1] https://wiki.php.net/rfc/php_technical_committee
Regards,
--
Rowan Tommins
[IMSoP]
The only note of caution I would throw in is that the recent Technical Committee proposal [1] was soundly rejected, so any organisational changes are likely to be a lot more contentious. So care should be taken to separate those from purely legal or financial links.
I think a very important distinction to be made is in replacing/reforming the PHP Group is that it should be seen solely as a group that manages the non-technical aspects of the PHP project, which makes it very different from this Technical Committee proposal.
Jim
I would even support an RFC that goes one step beyond that and not only
officially recognize the PHPFoundation as a sponsoring organization but
also transfers the Copyright on PHP from the ominous "PHP Group" to the
PHP Foundation.I'm tending to agree with you here. The PHP Foundation has proven itself as
a valuable organisation. As long as it doesn't go the way of PHP-FIG with
so much bureaucracy, rules, and processes, I would support this movement.
Just to put my marker down, one of my longer-term goals here is to see the PHP Group become a group with a process for evolving its membership, and if folding it into the PHP Foundation is the best alternative we find for that (which seems the most likely to me), I would support it. There's some history to why it never quite got there before, but I think it's long past time to try again to correct that.
Jim
voting is open to over 1000 people, all decisions are made by voting of whichever 20 of those people show up at any given time
I'd like to jump in here. I see a decline in number of votes. Well,
maybe it's just uncontentious topic of recent RFCs, maybe not. I'd like
to propose a possible solution to this situation. My take is that many
of these people are not aware they can vote. I know, I was one of them
until someone informed me at some point, long after I got that right.
So, let's send a message to all of them, something like "Hey, do you
know you still have voting rights?". I can see that some people might
not like the idea of bringing more new-old voters, though.
--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com