KEYnote 50 English - Fall/Winter 2025 | Page 23

CodeMeter License Central
At this stage, the focus shifts to how licensing models are implemented in CodeMeter License Central and which extended options are available. Key questions to address include:
■ Which license options fit which models?
■ How should modular software be licensed?
■ Which interfaces are available for integration with external systems?
■ How are new licenses created?
■ How are updates to existing licenses performed?
Time to Get to Work
Once all these questions are answered, projects move into their real implementation phase across parallel workstreams.
■ Development starts with integrating CodeMeter into the software. This can range from creating configurations for AxProtector to embedding the CodeMeter API. In most cases, this workstream is straightforward, since CodeMeter Runtime handles most of the heavy lifting. Only in the case of pay-per-use models are additional steps required.
■ Sales and / or product owners define the items in the CRM / ERP system and in CodeMeter License Central. Ideally, there should always be a 1:1 relationship: for every sellable item in the CRM / ERP system that requires a license, there must be a corresponding item in CodeMeter License Central.
■ The administrators of the CRM / ERP system then set up the connections to the CodeMeter License Central interfaces.
Licensing Models for Modular Software
There are major dependencies between the last two workstreams, since the capabilities of the CRM / ERP system and the chosen sales processes always influence the items defined in CodeMeter License Central.
Configurator
If the CRM / ERP system supports a configurator and always provides the exact license details when changes are made, then licensing in CodeMeter License Central should always be modeled with Module Items in combination with Replace Orders. Module Items offer the significant advantage that, once defined, they can be reused across a wide variety of licensing models. The required license options for each licensing model are defined only at the ModuleItemParent level and then inherited by the associated children. When a customer requests a change to an existing license, the configurator simply adjusts the relevant parameters, and the existing license in CodeMeter License Central is replaced by a new one.
From the end customer’ s perspective, this approach is also optimal, as there is always a single ticket that reflects the current state of the license.
Independent Modules
If, from a sales perspective, the software is more a logical grouping of separate modules, where an end customer can also purchase additional modules independently of an existing li- cense, then default items should always be used in CodeMeter License Central, which can then be grouped into additional bundle items.
With this approach, however, all required license options must be defined for each individual item. As a result, for every licensing model implemented and for every module to be licensed, there is a separate item in CodeMeter License Central.
From an end user’ s perspective, this method has the advantage that modules can be purchased independently of existing licenses. The drawback, however, is that licenses for one system are often distributed across several tickets, which in turn makes support processes more complex.
Subscription Models
With subscription models, the crucial point is usually whether the CRM / ERP system in use includes its own module for subscription management. In this scenario, it makes sense to use that module and define the“ Expiration Date” license option in CodeMeter License Central as order-specific.
If this is not possible or not desired, subscriptions can instead be managed via CodeMeter License Portal. In this case, the“ Expiration Date” license option is defined as activation-specific, and the exact value is calculated when licenses are activated. In this setup, a reporting mechanism is usually required to feed the active subscriptions back into the CRM / ERP system.
Using relative values( e. g., 365 days) for the“ Expiration Date” option only makes sense if there is no contractual commitment with the end customer. Since the exact expiration date is then calculated internally by CodeMeter License Central at activation, the subscription start date is not known in the CRM / ERP system, which complicates billing. For such cases, implementing time contingents in CodeMeter License Portal is the preferred approach.
The“ Usage Period” license option must never be used in connection with subscription models.
The best licensing models are not the most complex, but the most practical. Start simple and resist the urge to cover every possible scenario from the outset. Before going live, stress-test your model. Once licenses are in customer hands, changes become costly. Finally, establish a unified approach across all your software products. This prevents fragmentation in your sales processes, simplifies development, and eases support.
LICENSING
WIBU-SYSTEMS AG 23