zur Hauptnavigation springen zum Inhaltsbereich springen

 
Menu

Categories: Licensing

From Workshop to Workflow: Building Effective Licensing Models

Integrating CodeMeter into software and business processes is never a one-size-fits-all endeavor. Every company operates in its own environment, shaped by unique requirements and workflows. Success ful licensing models emerge when these differences are acknowledged, mapped, and translated into a coherent strategy. Drawing on our experience from countless workshops with customers and prospects, we outline how to bring the right stakeholders together, ask the right questions, and turn insights into robust, future-ready licensing solutions.

Kick-Off

Based on our experience, initial workshops are most success ful when participants from all relevant departments are pre sent. In the context of developing licensing models, the following representatives should be included:

  • Developers, to integrate CodeMeter into the software
  • Product owners and sales teams, to define the desired li censing models
  • Technical administrators of the CRM/ERP system, to config ure the necessary interfaces to CodeMeter License Central
  • Support staff, to assist end customers with potential issues.

The goal of this initial session is to establish a common language, ensuring that later discussions do not miss the mark. At the same time, each participant gains insight into the different workstreams, preventing the creation of concepts at one end that turn out to be technically unfeasible at the other.

Software

The starting point in this process is always the assessment of the software into which CodeMeter will be integrated. Typical questions at this stage include:

  • Are there modules and/or functions that should be licensed or protected individually?
  • Are there different editions with varying feature sets?
  • Is pay-per-use a desired licensing model? Whether the technical implementation is then carried out through simple encryption of finished artifacts using AxProtector or via deeper integration of the CodeMeter API directly into the software is, at this point, of secondary importance in this discussion.

Sales

On one hand, this stage is about defining licensing models. On the other, existing sales processes directly impact how these models are realized. This phase includes questions such as:

  • Which licensing models should be implemented?
  • Is there a configurator to define the exact specifications of the required license?
  • How are license upgrades handled?
    • Does the CRM/ERP system always know the complete configuration of the new license?
    • Can a customer purchase add-ons independently of an existing license?
  • In the case of subscription models, does the CRM/ERP sys tem include a dedicated module for their management?
  • In the case of pay-per-use, how and when should billing take place?
  • What do upgrade processes look like?
  • Are there different channels through which licenses are distributed?

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 work streams, 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 cur rent 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 22 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 li censing model implemented and for every module to be li censed, 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 sub scription 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 re quired 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.

 

KEYnote 50 - Edition Fall/Winter 2025

Back
To top