Close

​Cloud Compatible Licensing Schemes

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.

Leave your comment
Comments
1/15/2015 10:04 AM
Great article.  This definitely will help some vendors that haven't already been trying to tackle the issue, but it is missing a critical piece of information.  What if a vendor's license module is per instance?  There isn't any easy way to do this in Azure.  We're having to work quite a bit of magic there, and it's changed several times over the past year too, which makes Azure insanely difficult to support from a commercial business model perspective.
1/15/2015 10:19 PM
If you mean by 'per instance' as a 'per server' - with the advent of auto-scaling cloud computing, you simply have to adopt a different business model if you want to keep cloud customers.  One of the true advantages of the cloud is the ability to save on resource costs by using elastic infrastructure.  Most of the customers using cloud are interested in this side of the environment.  Your code might be running on 1 'server' one day, and 10 'servers' later that same day.  In an Azure Websites environment the 'server' might change 3 times in a single day, even if the install is not auto-scaled.  I put 'servers' in quotes because they don't really relate to what we traditionally might think of as a server- even a virtual server - from a couple of years ago.<br /><br />This is precisely the reason that DNN has moved away from server based licensing for Evoq in a cloud environment - it no longer matches what the customers want and need.  It's like trying to sell customers gasoline per barrel when they want to buy per gallon.  The truth is that software business models have to move forward and adapt.   That may mean using another metric (like page views, or domains, or users, or whatever suits).  No, it's not easy but it's where the future lies.
1/16/2015 9:46 AM
Thanks for the comment Bruce.  I completely understand and agree that licensing models sometimes need to change, and we know all too well the impacts of scale, but only SaaS offerings have the luxury of licensing using the alternative metrics.  Can you imagine an app on your phone charging you each time you opened it?  <br /><br />Module vendors are a bit more restricted in this regard, which is why it would be nice to know how you would track this in the context of the original article.  Most modules have a per instance licensing model, and I was simply commenting that this piece of information is missing.  :)
1/27/2015 9:51 AM
This is good information for module developers looking to get Evoq Preferred Product status. To the best of my knowledge Cart Viper would pass this licensing test. <br />As with Hot Cakes we have spent some time implementing our own licensing management feature. Our product is licensed at the portalID level so it doesn't matter the number of 'servers'  used to host that portal instance. <br /><br />Do you see anything on the DNN Roadmap that will provide an API for licensing against Azure?