I have to agree with this. If one is either moving the deployment to a new machine (either because the old one isn’t fast enough or is failing), there should be zero penalty for explicitly deactivating the licenses on the first machine before activating them on the replacement machine. Penalizing your customer for doing performing what is a common maintenance procedure just is NOT COOL.
The only time I should have to beg Sangoma for the ability to activate a paid-for license on a new server is if the machine the deployment is licensed for was burnt so badly that it cannot cleanly communicate with them and cleanly release the licenses in preparation for the move. That’s where “zend resets” should be a limited “resource”, and only there.
At this point I haven’t even rolled out a new PBX to my church, and for some reason I’m already at 1 reset remaining. For various reasons learned in the process of setting up the system in the first place, I’m now planning on moving the deployment to a VM, which to my understanding will leave me with ZERO resets. If that VM becomes damaged in any way and requires a rebuild, I will be completely screwed until Sangoma deigns to give me another reset, which is not acceptable. More immediately, if I determine during the process of building the VM up that for one reason or another it ends up not actually being a good idea, I’ll be screwed again unless Sangoma takes pity on me. I must activate the VM deployment, because in order to even consider placing this PBX in the “cloud” I must have VPN functionality, which is a licensed feature. I also must be able to validate EPM functionality in relation to the VPN.
EVERY other “seat”-based licensing system out there (I’m specifically referring to things like $1M software packages used for e.g. chip design, etc.) has a continuous check-in/check-out mechanism, with zero penalties for moving the license. FreePBX should be exactly the same.