OK so again when I asked for clarification I kind of meant you should clarify the differences.
A paid module with 25-year license with no active support is OK as long as it’s on the version that was released prior to support running out. The license is valid.
A paid module with 25-year license with no active support with on a version released after the support expired, that’s bad. That’s an invalid license. However, the actual module will continue to work you just can’t edit it via the GUI. Does that also include the APIs, etc? Does that include making changes in the database? So I can implement updates outside of the GUI and the module with the invalid license (or violated license) will continue to regenerate the dialplan and other functions needed along with working as expected.
So all of this confusion is over just blocking GUI access to a module with an invalid or unlicensed version being used while still allowing said invalid/unlicensed module to work over all?
If you are using a version of the module that was released before the end of your maintenance, then you should be fine. Based on the image you posted, it looks like Voicemail Reports would fall in to this category (but not the other modules as their maintenance expiry dates were before the release of v17.)
You should update the maintenance on those modules if you intend to continue using them.
Please open a ticket at https://sangoma.help with your Deployment ID to make that request, but again, any modules you intend to continue using should be renewed before this time, in order to help reduce confusion in the ticket.
That is the current state, but we are planning some refinements based on the specific module as the rollout continues and we get boxed into corner cases of some modules not being needed while simultaneously some are also being held back and others just need payment to continue updating properly.
This seems a late breaking change to the original subscription, I could see it going forward with new commercial subscriptions but feels like we with older 25-year subscriptions should be grand-fathered for these or perhaps refunded /haha/ the original 25-year license cost if we do not want to upgrade maintenance of some of the 25-year commercial modules but had still wanted to use them as we have always in the past.
Also, why not incorporate a way for users to remove portal subscriptions?
THAT is the key request here - but it does not serve Sangoma’s financial interest to put this ability into the system - My list of systems that I have claimed at one time or another is 124 - of which I am currently using about 50 - I would LOVE to be able to clean that list up, remove the systems I don’t use anymore, and remove the modules that I don’t use from the systems that I do - but you can’t.
There is serious confusion here. I believe I understand what Sangoma is trying to do without really saying what they are trying do.
There have been instances in the past where people have been able to get around expired support/maintenance on modules. They have been able to install current versions (from the same track i.e. v17, etc) without having to pay for the support renewal. They are trying to fix that problem.
In doing so they way they have communicated it and framed it makes it seem like people with valid licenses and no active support are going to have their module interfaces turned off. That’s not the case.
What they are saying is X module support expired freezing module at version v17.1.5 (for example). However, X module is on v17.1.10 meaning the user somehow bypassed the version freeze. So now that user will get a grace period to pay for support to have v17.1.10 or the interface will stop working.
That’s all this means…but they said it in a very convoluted and confusing way.
That does not seem to be the case, and as an aside, I never circumvented the process as was mentioned:
If you are using a version of the module that was released before the end of your maintenance, then you should be fine. Based on the image you posted, it looks like Voicemail Reports would fall in to this category (but not the other modules as their maintenance expiry dates were before the release of v17.)
This explains why I am only getting a critical error for voicemail reports. So it seems clear to me if I want to use any of the other 25-year licenses, I must renew the maintenance.
Please correct me if I’m wrong.
Of course upgrading to Debian V17 was just about a requirement in order to stay on an underlying O/S that itself was not EOL.
There’s a balance. And the less desirable alternative to stopping changes is stopping systems.
Is it breaking though if the module continues to load and generate the desired dial plan state, despite using a forbidden license?
Regarding the “original subscription” concept – you are perfectly free to use an existing validly licensed version of the module for the duration of the 25 year license. For example, you could be running commercial modules on v14, which went EOL years ago, even though you haven’t paid for maintenance for many years. But unless you kept the renewals active, then you shouldn’t expect to be able to continue to run the latest commercial modules indefinitely on v17 (mostly because in this example the v17 versions didn’t even exist when v14 was current!) The happy path is to renew the maintenance before you upgrade to v17. One of the main technical reasons buttressing the happy path is that the latest version of the modules will provide you with the most compatible and well QA’d backup/restore points between versions.
Thank you for the feedback. That’s something for discussion internally. It seems like additional filters might be useful for such a feature.
If you want to use modules on v17 that you haven’t paid maintenance on since before such modules even had versions available for v17, then yes, agreed.
