The primary goal of adding licensing logic to your software is to ensure that anyone using your application has access to what he or she is entitled to, for as long as he or she is entitled to it - nothing more, and nothing less. This topic summarizes some of the many different ways of managing access to your application.
You can choose to implement any combination of restrictions to limit the use of your application. The most common restrictions are described below, but keep in mind that Protection PLUS 5 SDK is very flexible, and does not limit you to the restrictions explained here.
The most common restriction is limited time. This is where licensing restricts the amount of time the application may be used before a purchase is required. As an example, this could simply be a free evaluation which only runs for 30 days. With time-limited licenses, your application would use the EffectiveEndDate in the license file to enforce the expiration date.
Another common restriction is to limit the amount of times a certain feature can be performed or the amount of times the application itself may be run. This allows use for a given number of times before requiring a purchase to increase the counter value. The counter value is an arbitrary numeric value "passed down" (or supplied) to the licensed application during the software activation process. For these scenarios, a writable license file is often necessary, as it allows your application to use the LicenseCounter field (recommended) or any of the numeric, user-defined properties to keep track of uses/counters. When using the LicenseCounter field, the customer can automatically purchase additional uses through SOLO Server and then refresh their license. For a more secure implementation, consider storing the usage counter in SOLO Server to track pay-per-use applications more securely (Internet connection always required).
Limitations on application features can also be implemented in a variety of ways.
First, applications that contain features which should be evaluated may want to make sure the feature is only used a reasonable number of times without allowing indefinite use. For these scenarios, a writable license file is often required, as it allows the application to use any of the numeric user-defined properties to keep track of uses/counters. An example of this scenario could include an application that transfers videos to a portable device, where the application might only permit the user to transfer a handful of such files during evaluation (so users feel comfortable it works as expected before purchasing). After the user purchases and activates the application, he or she can then be allowed to transfer any number of videos.
In other cases, applications might have features that could alter output in a way that would require purchase for practical use. For example, if the application produces some kind of document output (such as a PDF document), it could overlay a word or phrase (like "DRAFT COPY" or "EVALUATION VERSION") on the document to prevent practical use of the application's output until a license has been purchased and activated.
Other applications may simply have features completely disabled during the evaluation. An example could include image manipulation software which shows a limited preview of its output, but does not allow the manipulation/transformation to be applied to the photo and saved during the evaluation.
Furthermore, it is sometimes best to license additional features as if they are each their own application. One example of where this may be appropriate is an application which is licensed itself, but also supports dynamically loading additional plug-ins at runtime. The additional plug-ins which add additional features and functionality to the application could then be evaluated, purchased, and activated independently from the application's license.
A license model simply describes any type of license you may wish to support in your application, which typically also provides an abbreviated way to describe the type of restrictions enforced.
Evaluation (also commonly referred to as trial, demo, or shareware) licenses are licenses issued to prospective customers. Evaluations provide an opportunity to set a good impression with your prospects, which often compels them to make a purchase to continue using your application. Additionally, an evaluation by a prospect could be a collaborative effort, so this can also afford your prospects the freedom to share the software amongst colleagues freely. This enables you to increase exposure of your application, which can lead to an increase in sales. Protection PLUS 5 SDK offers two primary means of allowing prospects to evaluate your software.
Although it is possible to implement evaluations of your application that require the customer to activate before it starts, this is not a requirement of Protection PLUS 5 SDK. Using a writable license file with aliases makes it difficult for users to back-date their computer to gain additional time, and also remain on the computer when your application is uninstalled so that re-installing your application does not afford the user a new trial period. Relying on aliases in your application can be preferential for many reasons, including:
Keep in mind that the above reasons might make it look appealing to implement the recommended evaluation functionality, it is only reasonable to also mention potential drawbacks:
You can implement writable license files with the PLUSManaged API or the PLUSNative API to enable your application to issue evaluation periods automatically.
There are some cases where it may not be acceptable for just anyone to install the application and automatically receive an evaluation. This could, for example, include cases where purchase and/or activation is required to evaluate the application. Consequently, requiring activation and a higher level of security through the use of read-only license files is often desirable, if not required, in these types of scenarios.
Protection PLUS 5 SDK gives you the flexibility of defining your own license models and their respective behaviors by using the various properties available to you in the license file. Our recommendation is to configure your product option in SOLO Server, and then edit it as follows:
When configuring your product option, Protection PLUS 5 SDK requires the Issue Installation ID option to be checked!
Once you have defined and configured the product option, you can then expand on the license validation in your implementation as necessary. For example, if you picked a Trigger Code # of 1 to represent evaluation licenses, you may always want to verify that the date in EffectiveEndDate is not a past day when the value of TriggerCode is 1.
Periodic licenses are time-limited licenses (similar to evaluations) which always require activation to be used. This type of license model is suitable for scenarios where users are required to periodically pay to renew license to use the application.
Non-expiring licenses (also known as perpetual licenses) are licenses which, once activated, never expire. While this means that the license to use the software never expires, it is also common to use non-expiring licenses in software while using SOLO Server to maintain a subscription that affords your customers technical support and version updates.
There are wide variety of license models that you could potentially implement using Protection PLUS 5 SDK APIs. This includes, but is not limited to: