Thank you for your reply.
I appreciate that phpList has a venerable heritage. 
Key to understanding how to follow EU privacy/data protection law is understanding the purposes for which personal data is processed, and in each case determining which processing is genuinely necessary to achieve each purpose.
So if phpList needs to store IP addresses to function, thatâs basically fine. But just because IP addresses are kept in server logs (for its own separate purpose), that doesnât make it okay for phpList to keep IP addresses as well if there is no reason for phpList to do so. As with the rest of that information (device, OS, etc.), if there isnât really a proper purpose for collecting it, then it shouldnât be collected. And if there is a reason to collect it, it shouldnât be kept for longer than is necessary to fulfil the purpose for which it was collected in the first place.
This follows from the GDPR principles of data minimisation and storage limitation, respectively, in articles 5 c) and 5 e). (And as a side note, when it comes to collecting information from the userâs device, the ePrivacy Directive actually comes into play)
With regards to consent, there is a legal requirement that the user is given a genuine choice in relation to each specific purpose consent is used for. There is a prohibition on bundling different purposes into one consent; there must be granularity related to purposes. This is explained in the European Data Protection Boardâs Guidelines on consent, for example paras 55-58 (page 13-14).
As for metrics that track engagement, I appreciate this is useful to many organisations running phpList.
However, keeping in mind consent and purposes, there must then be a separate choice for consenting to behavioural tracking. The purpose of signing up to a mailing list is typically to receive marketing or information from an organisation. You basically only need to collect an email address to achieve this. The organisationâs data collection enabling analysis of subscriber behaviour is a different purpose to merely maintaining the list and sending out the emails. Furthermore, it should be possible to withdraw consent without detriment. It follows that consenting for the purpose of receiving marketing/information should be possible without having to also accept data collection which isnât necessary for receiving the marketing/information.
When lists are imported into phpList, then the data controller has a responsibility to ensure consent was obtained and that this can be proven, whether by having this data in phpList or keeping track of it in a different manner.
As for a subscriber clicking the phpList logo/link, itâs again a matter of purposes and what data may be collected by the company phpList Ldt. An IP address in a server log is one thing, but if phpList Ldt was collecting device information on subscribers who happen to click the logo it would be another matter.
Iâm not a programmer, so I canât contribute with PRs, what I can offer at the moment is merely some insight into EU data protection law and how it relates to phpList. 
Believe me, I get that this might not be the most fun âcontributionâ to receive, and that phpList is probably way less intrusive than most other options out there!
Another principle of the GDPR is the accountability principle. Data controllers must be able to show how they comply with the principles of the GDPR. As individuals, marketers and supervisory authorities wake up, demand for newsletter software you can use in a compliant manner will only grow. By addressing these issues you could truly market phpList as a fully privacy conscious mailing list solution.
Maybe the easiest first step to take would be adding an interface toggle for that subscriber data collection on sign-up, and having it be off by default at least in completely new phpList installations.