Divide and conquer: Modular Licensing
Many enterprises in the software business want to generate additional revenue streams. The solution depends on many aspects, but one classic option is frequently mentioned: Feature-on-demand licenses.
Features-on-demand. The concept needs no explanation. The term does not even have to be translated into other languages. Everybody understands it intuitively: Software makers do not sell their work as a single, monolithic block, but instead offer individual features that can be activated for a certain fee. This relies on a modular license, which is often combined with additional licensing models like the current favorites: subscriptions and pay-per-use options. Why is this done? First, to create new, continuous revenue streams and, second, to break into more cost-sensitive markets, as the initial investment required from buyers is spread out over a longer time. One fact that should not be ignored is that the right combination of feature-on-demand and subscription concepts will generate more revenue over a product’s lifecycle than a simple upfront sale would ever bring.
Feature-On-Demand as an Aftermarket Afterburner
All of these advantages apply to software makers, but they can apply in the same way to hardware manufacturers (Intelligent Device Manufacturers, or IDMs). Most of the features and capabilities of their hardware is determined by the software that runs on it. Especially in particularly competitive markets, enterprises have to ask themselves how they can lower the entry threshold to attract more buyers, without losing sight of their overall commercial performance. And this is where modularity can be the answer.
The basic features of an application can be included in a package that allows users to enjoy the product in its essential form. Attractive add-on features can then be offered as top-up purchases. The users would originally receive a license for the basic package and can then buy additional features to match their profile and requirements.
The challenge for the vendor is to define the right separate pieces with added value that creates real demand in the market. These could be add-on modules or functions that might be particularly interesting for specific user groups or markets. These customers would be more willing to invest extra to enjoy the additional benefits.
Modular licensing also creates interesting new opportunities in the aftermarket business. There might be more demand for certain features that is only discovered once users have become accustomed to using it. Alternatively, vendors could innovate and add new features over time. Both are interesting possibilities not just for pure software developers, but increasingly also in the industrial arena. Machines are sold with the entire feature set on board, and the buyer either pays for the entire lot upfront or buys additional features in the aftermarket over time, activating the licenses for them online or offline. The automotive industry is already making use of such models in many areas, with Tesla pioneering the idea of activating features separately.
The ability to produce one standard hardware with all features theoretically on board, instead of many feature-specific variants, also reduces manufacturing costs. But even for devices that need separate hardware added, there are lots of savings to be made and successful business models to be introduced in the aftermarket if the add-on features are defined and priced intelligently.
Realized with CodeMeter
The simplest way to integrate a feature-on-demand model in your software is to use CodeMeter Protection Suite. AxProtector, the protection tool available for a range of target platforms and programming languages, offers modular licensing not just as a way to license application features separately; it also increases their level of protection with separate encryption: You can monetize your features and make them safer in the market at the same time.
AxProtector works by taking the unencrypted executable or library and turns it into encrypted, protected software. When end users want to use that software, they need the right license entries in their license containers.
It does not matter whether you as the software vendor use a hardware CmDongle, a software-only CmActLicense, a CmCloudContainer, or any combination of the three as the secure place to store your software’s license entries, the structure of the entries is essentially similar and fully compatible. The Firm Code is a globally unique identifier of the license publisher, created by Wibu-Systems. As the vendor, you yourself define the Product Codes that AxProtector can assign to individual features.
Each feature is protected with its own cryptographic key for the Product Code. A simple license entry would be a combination of the vendor’s Firm Code and a Product Code. This would suffice to create a feature-on-demand model without having to change anything about your software. Every feature that you can sell separately is given its Product Code, and the end users only need the right license entries in their license containers. You also have an API available as software vendor to make direct use of the information in the license container.
Licensing Models on Top
By defining the feature-on-demand licensing model, you have created the perfect foundations for more sophisticated licenses. Product Codes can be given additional properties by way of the Product Item Options. For example, adding an expiry date lets you offer a subscription model and adding a use counter allows billing by the number of uses or the active time in use. Many other Product Item Options are available to give you a toolkit to construct your chosen licensing system. Ideally, the application does not have to know the underlying licensing model at all and only expects the right Product Code. You can then pick and mix the licensing models for each market or industry without having to change anything in the software itself.
The Route to the Client
One aspect that should never be neglected, not just for feature-on-demand licenses, is the necessary product structure in the order handling system used by your company (e.g. an ERP system like SAP, Oracle, Microsoft Dynamics, …) and the effective link between this system and the license management system, CodeMeter License Central.
Each individual marketable feature (represented by the Product Code) should be given its own product number, which would be known to both systems to form the logical bridge between both. The order management system would have all of the information about the order, and License Central would have the details about the licenses. When an order is received, the order management requests the generation of a ticket ID (activation code) and feeds it back to the lead system. The clients receive the licenses they paid for that they can then activate on their devices with the ticket ID. The process can be fully automated with the simple integration of CodeMeter License Central and the vendor’s ERP system. Should the client pay for another feature at some point in the software’s life, the same process springs back into life.
This gives the Latin adage “Divide et impera” a completely new meaning: You can conquer your market by dividing your software’s capabilities up with CodeMeter’s modular licensing.
KEYnote 45 – Edition Spring/Summer 2023