Nitro-LM Basic Concepts

Summary

When using a software licensing system, there is certain terminology and concepts that are used. After reading this chapter, you should have a basic understanding of the parts of the Nitro-LM licensing solution.

Definition of Terms

  • Product - In Nitro-LM, a product is defined as a licensed software application. Your Flex or AIR application will be defined as a Product in Nitro-LM.
  • Product Key or License Key - The Product Key, sometimes called a License Key (*.ser), is assigned to the Product in Nitro-LM. This key is required and is used to uniquely encrypt all communication between your application and the Nitro-LM license servers.
  • Encryption Key or Product Encryption Key - An Encryption Key (*.vser) can optionally be assigned to a Product in Nitro-LM. It can be used to encrypt an entire Flex application inside a wrapper Flex application. This technique is no longer recommended for Flex/AIR applications as Module Encryption using Library Keys provides for a cleaner implementation. Encryption Keys are more likely to be used when encrypting Java applications.
  • Library Key - Library keys are encryption keys that can be assigned to a Product. Using Library keys to encrypt Flex and AIR modules (<mx:Module>) is the current recommended approach for encrypting applications. You can use a single library key for all modules, or encrypt each module with a unique key for additional security.
  • Licensee - In Nitro-LM, the licensee is defined as a Company or Entity that owns and defines Products. A Licensee also defines a list of Customers.
  • Customer - A Customer is an entity that can own any number of Pools of licenses in Nitro-LM. In Nitro-LM, the Licensee will also usually be shown as Customer of themselves. This allows for a pool of licenses to be created and effectively distributed among additional customers. Any new customers created in the system should be a sub-customer of the Licensee's customer account.
  • Pool - In Nitro-LM, a pool is assigned to a specific Customer and defines a set number of licenses distributed across any number of Products. A pool of licenses could be assigned to a single product, or shared among multiple products. A pool is also used to restrict access to the licenses to certain users or groups.
  • User - In Nitro-LM, a user doesn't belong to any one Customer. A user login is required to retrieve a license from Nitro-LM. The license pool restricts which users can retrieve a license for the product being requested.
  • Demo License - A demonstration license type doesn't belong to any pool and isn't assigned to any Customer. A Demo license doesn't count against the number of licenses you've purchased from Simplified Logic. It allows a potential customer to try out software before they buy. A demo license performs similarly to a Checked Out license and will expire after a set period of time. Nitro-LM has built-in API calls where the user of a demo license can request a demo extension that may be approved or denied via a link e-mailed to your sales team.
  • Checked Out License - A Checked Out License is retrieved from Nitro-LM and locked to a user's machine for a set period of time. This allows for offline use of software such as an AIR application used while disconnected from the Internet. A Checked Out license with a 1-day expiration can also be useful for Flex applications. Because an internet browser will sometimes shut down without notifying the FlashPlayer that it's doing so, a Floating license may be more difficult to release in this scenario.
  • Floating License - A Floating License requires an active Internet connection, but can be shared among multiple users and machines as long as they are not using the license at the same time. A Floating license must be released back to the pool by the user before it can be available to others. This license type is useful for AIR applications because the shutdown events of an AIR application can trigger a license release call. An application may use some or all license types over the course of an application lifecycle. For example, the default operation of an AIR application may be to retrieve a floating license. The user could optionally convert this to a Checked Out license for 2 weeks while traveling.
  • Rolling Checkouts - A rolling checkout is a technique in which a Checked Out license is continually renewed for additional time. Using this technique, you could have the user initial check out a license for 30 days. Each time they used the application within this 30 days, the license would be renewed for an additional 30 days from the current date. In this way, as long as the user was accessing the application regularly, they would not see another login screen.
  • Variables - In Nitro-LM, variables can be used as an extended remote registry. Variables are either company-specific, product-specific, or user-specific and can be used to save preferences. If a user logs onto an application from another machine, all of their preference information can come down with the license.
  • Notifications - Notifications, sometimes called Touch Points, are defined in Nitro-LM as the list of people who get notified when certain events occur. Sales, support, and enhancement requests can be configured in notifications. Approvers of demo license requests, new user registration notifications, no more licenses available messages, and other notifications can be configured in Nitro-LM.
  • Resellers - Resellers of your software can be configured in Nitro-LM. They can be configured to be the first contact for support, sales, and enhancements requests if desired. Nitro-LM can also track which customers registered through resellers so they can be paid the correct commission on their sales.