You should definitely be fine now. I see that you chose to write your own license statements instead of using my one-sentence statement suggest which would have been enough. But either way, there is now no chance that VCV will accept someone’s fork named “Aria Salvatrice” to replace your plugin in the VCV Library in the event that you become an inactive developer.
By the way, when I said “take it or leave it”, I was referring to my license statement suggestion, not anything else. Apologies if there was any confusion over what that was referring to.
If you’re curious why I’m not adopting a general policy that bans all forks that use the original plugin’s name from being accepted to the VCV Library and replacing the original plugin, imagine the following very likely scenario.
According to Rack development blog, there will be a >=6 week period where plugin developers have access to Rack v2’s source and development builds but before Rack v2.0 is released. In this period, I predict most developers will do what is needed to make their plugin work in Rack v2. But there still might be a dozen or so who can’t be reached, so VCV or volunteers may update their plugins for them. (This is usually as trivial as updating their plugin’s version from v1.2.3 to v2.migrate1.2.3.)
In this case, it’s perfectly reasonable to make this change, because the developer would likely not want their plugin to be unavailable in Rack v2 simply because they were busy or on vacation for 6 weeks.
And yes, some of the plugins we migrate contain the author’s name or pieces of the name, such as ChowDSP, JW-Modules, Grande, KautenjaDSP Potato Chips, DHE Modules, ML Modules, and a few more, but if they are inactive and a volunteer adopts those plugins, I will likely accept them as is.