Many vendors in the DNN Store implement their own custom licensing schemes. This is a diverse collection of schemes which vary on both what the license is made for, and how that is enforced technically. Diversity in this case means strength – a compromised scheme from a single product wouldn’t mean all products are affected, and vendors can choose a model which best suits their business model and practice.
The introduction of different cloud providers for implementing DNN Installations has brought with it a number of challenges for vendors in the DNN ecosystem. Initially, a lot of the challenges were about making sure products installed and ran in cloud environments. Cloud-deployed DNN installs are a mature product area, and many customers are turning to cloud providers like Microsoft Azure or Amazon Web Services as a source of flexible hosting.
EVS Testing
EVS was created as a general quality checking tool, which also explicitly checks for Microsoft Azure compatibility where it can. This is an important first step to ensuring an Extension is compatible with Azure. However, there are things that EVS cannot check. EVS cannot check anything that happens at ‘run time’ rather than at installation time.
One of those conditions is the licensing scheme that a Vendor product may be using. In general, these shouldn’t be affected by running in a cloud environment, but some schemes may be affected. The reason for this is that many environmental variables change during the normal operation of a cloud-based site. Many of these variables are static in an On Premise deployment at a dedicated hosting facility, and have been adopted by Vendors as a way of locking software to a specific level of use.
DNN Environment Variables
Licensing schemes often read environmental variables about a DNN installation which help determine both the uniqueness and scale of an implementation.
The following table shows how environmental variables may be impacted in a cloud environment, making them unsuitable as the basis for a licensing scheme in a cloud environment.
‘Phone Home’ Licensing Schemes
Some vendors may implement a ‘Phone Home’ scheme whereby software contacts an external licensing server to determine if it is still a current licence.
It’s impossible to give a direction to the broad amount of possibilities. Any Vendors implementing a ‘phone home’ licensing system must be careful to ensure that the network communications being used still work inside a cloud environment, which may have many ports and services switched off by default, with the customer unable to change those settings to accommodate.
While licensing schemes of this type are useful and powerful, it’s important that they are maintained and robust, and provide a way for customers to deal with a scenario where the Vendor licensing server goes offline for any reason. It’s important to provide a fallback mode in this case.
Evoq Preferred Products
The Evoq Preferred Products list includes products suitable for use with Evoq products in all deployment scenarios, including cloud deployment in the Evoq OnDemand environment.
Candidate products for the Evoq Preferred Products must meet the following conditions for licensing schemes under normal operating conditions.
- No changes to product operation should be visible to end users of the product
- A message to administrative or host users is permitted
- License re-activation in response to environmental changes is fully automated and immediate
Normal operating conditions include scaling of the site resources (adding/removing more servers), redeploying of the site to new resources and stopping/suspending/restarting the site. Non-payment of a subscription renewal or using the product outside the license conditions (e.g., adding a new site in a site-restricted licence)
Unacceptable licence behaviour in response to the cloud environment changing include:
- Stopping the product from working (e.g., Enquiry form stops accepting enquiries)
- Showing a visible licensing message to end-users of the product (e.g., showing a red warning message to blog visitors)
- Requiring human intervention to re-activate a product (e.g., requiring an administrator to relicense when the server name changes)
The above list doesn’t apply to violations of the licensing scheme by the customer (e.g., using the product on a different domain name).
Most Vendors already have licensing schemes that work well with Cloud environments and provide a good model for ensuring compliance with licensing conditions without interfering with customer usage. It’s important for all DNN Store Vendors to be aware of the diverse set of environments that products get deployed in, and be sure that licensing schemes work in all scenarios.
Is there an environment variable you use or have seen used, and is not in the above list? Please share via the comments.
**This article was written for the DNN Store Blog by Bruce Chapman, Product Manager at DNN Corp.
