When software on a regular consumer computer stops working, it is a nuisance. If it stops working in a commercial environment, it can threaten the mission (mission critical incident) or the entire business (business critical incident). As a software developer, it is essential for you to understand your users’ availability requirements and to respond to them with the right strategies and capabilities. You should never forget to include the question of licensing in your availability concepts.
One obvious and simple solution is to forego any licenses at all. In such cases, the software could simply be copied to a replacement computer, and the user can keep on working. However, this option has one often ignored condition and one potentially disastrous effect on your business. For the software to be installed on a replacement computer, that computer would have to be available or be bought on the spur of the moment if something happens. It would have to be fully compatible as well. Buying or organizing a replacement license would be just as easy as buying or organizing such a replacement computer. The great disadvantage of foregoing licensing in general is obvious: Unscrupulous or unwitting users could simply copy and use your software without paying for it at all. In any case, the lost revenue, especially in the form of unintended overuse, can be life-threatening for small and medium-sized enterprises.
The cotton sorter
One of our clients produces specialized sorting machines for cotton processing. The unique intellectual property of that client lies in the software that controls the sorting process – the rest of the machine is simply nuts and bolts and a few cameras, which any skilled engineer could copy without too much effort. As the machine sorts cotton during active production, any outage or disruption means an immediate loss, because production comes to a standstill. High availability is key. The sorting usually happens literally in the field, i.e. on the cotton plantation, so that an Internet connection is not always available when problems occur.
A solution would be to install two devices for controlling the machine. One of them has a dongle with an unlimited license for the control software. The second one has as a similar license, but it is limited to 30 days of use after first activation. If anything goes wrong, the first controller can be replaced or repaired without production having to be interrupted, whatever the problem might be. Service technicians would have 30 days to repair the system on site and set up a new emergency license.
This is called a cold standby solution. An additional license is available and ready for use as needed. Because it is for temporary use only, the user would not be able to trick the system and use it as a second full-scale license. Technically, this can be achieved by defining a usage period or integrating a unit counter. In the former case, you define for how many days the license should work after it is first activated. In the latter case, the unit counter tracks the number of individual actions or the actual time in use, down to the last minute.
Another scenario would be an architectural studio that owns a number of floating network licenses, stored on a license server. The studio’s architects have to work in the studio, from home, and on building sites, but they need full access to their software. VPN connections might not always be possible when they are in their home office or out and about in the field.
The solution is to borrow licenses from the license server and transfer them into a local CmContainer on the architect’s computer. The license is flagged as active on the server, and over-use is prevented. Architects can then work offline on their computers even with an unstable or without any VPN connection at all.
This approach represents a type of local caching of licenses. As developer, you decide whether this feature is allowed and for how long the user can borrow the licenses. You can integrate the borrow feature intelligently in your software to keep it as transparent as possible as a background process. Your users can also return licenses early when they do not need them anymore.
The checkout system
Everybody has been there: You wait in queue at the supermarket, and then there is a problem with the checkout system. The queue gets longer and longer, and people are getting more and more impatient. A high availability strategy is the ace in the hole for such situations.
The solution uses two license servers. The first contains all licenses as floating network licenses. The second contains the same licenses, but with a unit counter. The software checks whether the first server is available and uses the licenses from there. If all licenses are in use, an error is returned, because all licensed checkout systems are already active. The backup server comes into play only if the first server is not available. The software counts down the unit counter with minute-by-minute precision, allowing you to check the usage of your backup server and identify any potential misuse. This solution is called hot standby. The first server can also be combined with local caching.
The holiday season
In the run-up to the holidays, many supermarkets would love to have more checkouts open that they might have licenses for. It is the busiest period of the year by far. The supermarket would be ready to pay for these additional licenses, as long as it means fewer people having to queue at the checkout.
The solution is not unlike a hot-standby option, and it is called overflow licensing. Again, a second license with a unit counter is used. By contrast to the standby approach, this license is also used when all other licenses are in use. This gives the operator additional licenses to buffer any peaks in demand. Their use is recorded to the minute to ensure precise and accurate billing. Combined with a hot-standby solution, the entire setup needs four categories: Normal licenses, overflow licenses, backup licenses, and overflow backup licenses.
With factories spreading around the globe, licenses should be available 24/7. There are several ways of doing so: One strategy would be to distribute the licenses across local license servers, which keep the licenses directly available at each site. With CodeMeter License Central, you can allow the user to move licenses dynamically from one server to the next. Any licenses that are not currently needed can be shifted back into the cloud and activated at some other factory that needs them – and all of this without any manual support efforts.
An alternative strategy would be to install a centralized license server, which can be coupled with local caching and a hot-standby solution. A third option would use three license servers and a manual mechanism in the software that only starts up if two of the three servers are available and the required licenses are not used elsewhere. This Triple Mode Redundancy (TMR) solution lets you choose which rules you want to enforce. As a minimum, two servers have to be available and the active licenses have to be consistent. As a solution, it is ideally suited to permanent licenses.
Software about to retire
All software has its unique lifecycle, and every software will get to a point after which you would not sell or support it anymore. However, legal requirements might force you to provide your clients with licenses even after that point. This will not only mean the added effort of a highly manual process. Keeping an outdated licensing system running might also incur extra maintenance and licensing fees. Faced with these costs, many companies prefer to switch their older software to an unprotected version. But even this can mean high costs for implementation and testing. Not so with CodeMeter: A Protection Only License can be created at any point with an unbound general license. This creates a freely installable version of the software without any additional work. And even better: You get to keep your protections against reverse engineering.