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.
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 game
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