Interestingly we are probably in a relaxed situation on certain external legal issues, but we still need to work on our internal issues such as

The primary feature is to immediately reject any support query for PHP 5.

Premising that I do not see the action plan here. What are the features that we are missing and we want to use, for example in the involved features and diffs?

I'm inclined to actually implement this, partly because (AFAIK) nobody on the team is actually running on PHP 5 to check for problems.

getLoginIcon() { return PlatformSymbols::getPlatformServerName(); } returns Phorge.
Thus no corresponding icon is found as Phorge.png does not exist and code falls back to first icon.

OK just to have a stub somewhere to start with, please feel free to edit this page:

A quick thing we can do: creating a Legalpad to accept (in a more explicit way) the terms of the Apache 2.0.

There is a blog post from Bryan Cantrill about why Node.js stopped using CLA's which might be of interest: Broadening Node.js Contributions.

A big bug we have now is the absence of a free license in the footer.

This is not triggered for {{{a}}} a or with a a {{{a}}} a, only for 1 string in front of a string with three squares.

(I think this is a sub-task of T15022)

Premising that very probably a fix there would not 100% resolve that upstream issue but surely this deserves a fix :D

This discussion (and disagreement) is exactly the reason why we need a CLA ASAP.
While consulting with a relevant legal counsel.

Just some probably interesting notes :D

From https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html

Many people, myself included, contribute to open source projects under the assumption that my contributions will help serve a project which continues to be open source in perpetuity, and a CLA provides a means for the project maintainers to circumvent that.

Assumption here is key. The entire purpose of a CLA is to remove this assumption and clarify how contributions are managed. This post and disposition is based entirely around the organization receiving contributions will behave in an adversarial manner in the future. If the organization doesn't earn your trust then why trust them with your contributions?

In T15121#8063, @avivey wrote:

Any contribution to Phorge is implicitly covered by Apache 2.0, which allows re-licensing by anyone.
The CLA is only making this explicit.

Sorry if this unrelated, but this is an interesting partially-related commit:

@avivey:

Make sure Phorge is not hit by legal action because of your contribution

Rust Conduit Client/R4 is the first project in Phactory!

By not signing a CLA, you'd have to explicitly set a license for each contribution you make - i.e., every single revision would have to include an explicit license, or it could not be incorporated into the main code-base.
This is technically handled by item 5 in our license, but it's reasonable to assume nobody ever reads that.

In T15121#3880, @valerio.bozzolan wrote:

I honestly do not want to allow my contributions to be re-licensed, since this usually means that the repository owner wants to re-license that work under a proprietary license when needed. I don't accept that. Normal volunteers do not accept that. This is probably not what we want.

Maybe this is the root problem:

I just want to note down that this stack trace has no sense to me: