Hi Ben
> On Nov 30, 2023, at 02:45, Andreas Heigl <andr...@heigl.org> wrote:
> >
> > On 30.11.23 09:39, James Titcumb wrote:
> >> On Thu, 30 Nov 2023 at 07:28, Andreas Heigl <andr...@heigl.org <mailto:
> andr...@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.[^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:
>
> 1. Retire the PHP License and Zend Engine License.
> 2. Drop the Zend/LICENSE file and replace the text of the LICENSE file
> with the exact text of the BSD 3-clause license.
> 3. 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:
>
> 1. Retire the Zend Engine License, effectively folding it into the PHP
> License.
> 2. 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.”
> 3. Replace the copyright notice in the file headers and LICENSE, as noted
> above.
> 4. 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
>
>
>
> [^1]: https://github.com/php/php-src/blob/master/LICENSE
> [^2]: https://github.com/php/php-src/blob/master/Zend/LICENSE
> [^3]:
> https://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/runtime/IntlObject.cpp
> [^4]: https://webkit.org/contributing-code/#develop-your-changes
> [^5]:
> https://github.com/unicode-org/icu/blob/8d3d214ad7f76b7d0650f19a871a0e7d58a5986f/icu4c/source/i18n/msgfmt.cpp
> [^6]:
> https://github.com/php/php-src/blob/4d51d588b90737016afb69e99432b2d0969b3723/LICENSE
> [^7]:
> https://github.com/php/php-src/blob/4d51d588b90737016afb69e99432b2d0969b3723/Zend/LICENSE
> [^8]: https://spdx.org/licenses/BSD-4-Clause.html
> [^9]: https://www.gnu.org/licenses/license-list.html#OriginalBSD
> [^10]: https://www.gnu.org/licenses/bsd.html
> [^11]: https://opensource.org/license/php-3-01/
> [^12]: https://1drv.ms/f/s!AoV7OZl7wKt-hcBhtk2mnkJOJWYk8Q
> [^13]: https://www.php.net/license/ZendGrant/
>
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:
https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license
That could be important for the reasoning (and that's one nice reason to
use GH for development)
Nicolas
