The problem is those instructions are not passed along to the user via the Update Center or pluginManager UI; it's just gone 403 to the user.
If you have it installed, Jenkins will tell you. It's just not available for installation.
https://github.com/jenkins-infra/update-center2/blob/55f6a4370e090b25cf359c0773a60c1939e8253f/resources/deprecations.properties#L129 creates a deprecation notice with a link to the issue. There could be better docs but by the time we did this it had been deprecated in docs for well over a year.
In this case, there's no indication in the Update Center/ pluginManager why it's no longer available AND there's no indication in GitHub there's anything wrong by policy or vulnerability.
Good point. At the time we removed it, I hoped it would be temporary, so didn't add a label that would inform existing users. This is a simple oversight that can easily be addressed with a PR to update-center2.
The banner could be a useful mechanism to warn existing plugin users of the license violation (which may impact their continued use).
As above, we have ways to inform existing users, it's just new users (and that includes renewed users, e.g. in ephemeral Jenkins setups) that have a harder time figuring out what happened. As deprecation metadata is served through the usual means, this is an RFE to whatever the plugin management tool of choice is.
a banner similar to UNAVAILABLE
Possible by iterating over over each entry in deprecations/security warnings and creating placeholders for the plugin IDs, but the code underlying the update center is a bit of a mess, plus we don't have any metadata right now other than plugin ID. Additionally we've had plenty negative feedback to "UNAVAILABLE", indicating it's confusing, so I'm not sure this is a great choice.
TBH with the plugin site showing placeholders for plugins that are no longer being distributed, I'm not sure we need a solution inside Jenkins. I Would hold that off for a bit.