Nested Product Items
Many challenges, one solution: Nested Product Items facilitate license configuration, prevent inconsistencies with licensing modular software, and guarantee the simple and smooth transfer of licenses. The ability to nest licenses and bequeath properties down the line answers the needs of many a product manager and avoids some headaches for developers grappling with licensing models.
Avoiding Redundant Information
When one looks at licenses that software vendors prepare for CmContainers, one often finds certain entries again and again in multiple licenses. The annual license for a software suite includes licenses for the various applications contained in it, but all of them have the same expiry date. Modular software with multiple license entries (Product Items) include defined maintenance periods in every license. If any of these settings needs to be changed, all of the licenses need to be reprogrammed one by one – an unnecessary effort that just invites errors and mistakes.
This case, and other scenarios that we will look at later on, all benefit from Nested Product Items: The nested licenses enable software developers to set the same configuration only once, but have it available wherever they need it.
Nesting Licenses
A license entry, the so-called Product Item, can come with several options: From time limits such as a defined expiry date or a defined usage period, or limited license counters or a countdown for the number of uses, to different data types, software vendors have a whole battery of settings at their disposal to model their license terms to their needs.
With Nested Product Items, licenses that use a Universal Firm Code now have the option of attaching one license entry to another. The attached nested item is called a Module Item. Such Module Items can use all the settings and options of a Product Item, without any restrictions. A Product Item can contain one, multiple, or no Module Items. Vertically, the nesting has only one level: A nested Module Item cannot have other Module Items nested within it.
Bequeathing Options
The unique feature of this nesting is that all Module Items inherit the properties of their parent Product Item. If a specific setting is made for a license in a Module Item that was already set differently in the parent Product Item, the new setting overrides the inherited setting. This is a case of traditional inheritance in software development.
Consider a concrete scenario: A trial version for an office suite. The applications in it (word processing, spreadsheet, contact database) are available for testing over a 30-day period. The license setup could be: one Product Item “Demo Pack” with a defined usage period of 30 days, with three nested Module Items for the three applications. If the user starts the spreadsheet application, the usage period kept in the parent Product Item springs into action. The start date then applies for all Module Items.
Separate License Allocation
Just like the usage period is defined in only one place in this case, the license counter can also be managed from one place. The available licenses are defined depending on the allowed access type. If our trial license is a single-user license, the Product Item defines a license counter of 1. If the software package has a user limit (requiring one license per running application), only one application can be run at any one time in that case; no free license is available when the user tries to start another application. If the applications are encrypted for station share use (meaning that one license covers all access by one workstation), then the user can have all three applications running in parallel.
Usable without Change
Protected applications normally do not have to be changed anymore. If a software developer decides to use several Product Items for his modular software, he can simply reorganize the license entries. For accessing the license in the software, it does not matter whether the right license is stored in a Product Item or a Module Item. When the application accesses the license, via AxProtector or an API, it will get the effective license, that is, the Module Item and its inherited properties. That also goes for cryptography: Whether the key is included in the parent Product Item or in a Module Item has no effect on its use. In both cases, the same entry parameters will return the same results.
Restricted
When working with modular software, care needs to be taken that all license access uses the same Nested Product Item. That is why the Module Items can be configured to allow their use only when the same process has already used the parent Product Item. Consider another real-life case: A games developer launches a truck simulation and a tram simulator. Both games come with optional support for multi-screen sessions. Technically speaking, this would use only one module (one .dll) that is protected by one set of license parameters. When a user buys the multi-screen option for the truck simulation, he should only be able to use it there and be limited to a single screen when playing the tram simulation. Making this possible needs a lot of careful manual effort on part of the developer: The license needs to include an additional ID to define which parent product is covered by it. The entire CmContainer has to be read and analyzed when it is used. All of this now becomes much easier: The license for multi-screen support can simply be included as a Module Item in the truck simulation license and configured to become active only when the parent Product Item – the truck simulation license – is also active.
Inseparable
A Product Item and its Module Items form an inseparable unit. If any such Product Item is activated in CodeMeter License Central, it shows exactly one entry for the product, and it can only be retrieved as one complete item. On a technical level, the Product Item is programmed and protected by means of a certificate. A Nested Product Item with one Product Item and allocated Module Items are similarly programmed by way of exactly one certificate. By turning Nested Product Items into inseparable units in this manner, they even save space during transfer or, if they can be shared, storing them in the CmContainer.
When modular software, formed by one Product Item and several Module Items, is borrowed, only the Product Item needs to be borrowed – the Module Items piggy-back along. Should, for example, the license count be split as part of a license transfer, the split applies only to the Product Item. When the license is transferred, all module items are included 1:1. The license entries that belong together always stay together, and the transferred license will work as expected at its destination, because it carries all other necessary licenses along.
This gives product managers as the master of the licenses another practical and straightforward way of handling all licensing scenarios.
KEYnote 30 – Edition Fall 2015