Bring your own? A guide to deploying perpetual licenses in cloud services
As software vendors seek to migrate customers to subscription-based offerings one tactic they use is to enable currently-owned perpetual licenses to be used in cloud Infrastructure-as-a-Service environments such as AWS, Azure, and Oracle Cloud. The incentive appears to be clear – make use of your existing licenses and reduce cost. However, this approach is not without issues and must be considered carefully. This article seeks to understand whether and in which circumstances using BYOL rights make sense.
Typically, these rights allow you to transfer an on-premises license entitlement to a cloud deployment of the licensed software. In some cases you can even continue to use the license on-prem simultaneously. License assignment rules may apply – for example you may only be entitled to transfer the license once every 90 days. There may be documentation to complete for the vendor to grant you the right to assign the entitlement. Furthermore, use rights may require active software maintenance to be in place, and deployments may not count for determining entitlement levels at the end of a contract, as is the case in an Oracle ULA. Finally, you may be required to only deploy the license on machines dedicated to your use.
You need to consider the above restrictions when choosing to assign a currently-owned perpetual license to a cloud provider, and the next section of this article goes into more detail on that.
License Agreements
Your right to deploy software anywhere – not just the cloud – is defined in the license agreement and other contracts you have with the vendor. In order to understand what this means for cloud deployments we need to take a brief journey through the evolution of software licensing.
License Restrictions on cloud usage
The buying programmes and license agreements that apply to large companies aim to clearly define how a vendor’s software can be used by that organisation. Most were written when an IT environment consisted of desktop PCs and physical servers of varying types, all owned and managed by the customer. Datacenters had huge racks full of single-application servers with their own attached storage. Over the last two decades the server room has evolved through virtualisation of servers, to virtualisation of the entire computing infrastructure. Similarly, end user computing has evolved from a single device per user to each user potentially having multiple devices on which they consume software (laptop, desktop, tablet, mobile device).
License agreements have had to evolve to take account of this changing landscape. End-user software first had secondary use rights applied – allowing non-simultaneous use on a desktop and laptop – and increasingly is now swapping to per-user subscriptions allowing deployment on unlimited devices for that user.
In the datacenter world there has been an evolution, first to take account of virtual machines and then high core-density processors. Much server software is now licensed per core, or on a named user basis. The link has been broken in some cases between the underlying physical hardware and the deployed software. The right to dynamically move software has been granted, usually at additional cost or with certain restrictions. Some vendors are beginning to address the licensing challenges being presented by containerisation.
One fundamental area where the license agreement hasn’t evolved until recently is that of ownership. Most vendors still require the licensee to own the hardware on which the software is deployed. In practice this makes deployment of licenses you already own in a cloud service problematic. You don’t own the hardware, you have no idea on which physical box the software you licensed is running, and it is easy to dynamically assign compute in excess of the licensed capacity. How do you ensure you comply with license requirements regarding territory, compute, and ownership in the Cloud?
Solving the ownership problem
The answer from the vendors has been (in some cases) to allow deployment of your licenses on cloud infrastructure dedicated to your use. In AWS these are known as dedicated instances, dedicated hosts, and reserved instances. Dedicated instances can be used where your license permits per-VM licensing whereas Dedicated Hosts provide compliance for software licensed per physical host. Reserved instances can be used to potentially reduce costs over time – they provide a discount in return for a long-term commitment (say 12 months). Because the server is dedicated to your use it is effectively treated as an extension of your own datacenter from a licensing perspective.
BYOL Challenges
Whilst these deployment types may enable use of existing software you are required to pay a premium for them, meaning there is a reduction in ROI for your Cloud First deployment programme. In addition to this extra cost there is also the risk aspect to consider. The licenses remain yours, and you are responsible for ensuring compliance in the event of a software audit. Whilst AWS provide reports to assist with this it is likely that an auditor will see this as a risk area worth investigating. For example, you need to ensure that licenses formerly used on-prem are now only used in the cloud – you need a method to ensure your SAM tool counts those cloud instances when calculating an ELP. You will need rigorous processes in place to ensure compliance – on-prem datacenter compliance is challenging in itself and you’re adding another layer of complexity by using your own licenses in the cloud.
So, having considered all that – you’re still all set on deploying your perpetual licenses in the Cloud. Which use cases make sense? And which are a non-starter?
Non-starters:
Non-starters include:
- Dynamic allocation of compute resource to meet peak demand (e.g. a Finance system month-end).
- Temporary movement of licenses to the cloud in the event of a Business Continuity/Disaster Recovery Event
- Deployment of licenses on hardware not dedicated to your use.
All the above use cases fall foul of typical license restrictions on usage measurement, redeployment rights, and ownership.
Makes sense:
The following scenarios should be given further consideration:
- Permanent test/dev – but only in the event that the software requires production licensing for that deployment scenario. Otherwise, products such as Visual Studio with MSDN may be more cost-effective.
- Permanent migration of workloads to the Cloud – for example when on-prem hardware reaches End-of-Life. You need to check that the licenses allow reassignment (for example that they aren’t OEM) but otherwise this is an efficient use of a license.
- Hot standby services for BCP & DR, where the license doesn’t allow temporary reassignment for such an event and as such full production licensing is required.
Conclusion
All software vendors are keen to encourage you to move to the Cloud. On the whole however, they’re not that interested in you using your existing licenses, which is why it proves so difficult to do so. One of the typical benefits of a cloud strategy is a reduction in complexity and flexibility of deployment. Using perpetual licenses in the cloud increases complexity and flexibility. So why bother? Why not just buy compute from your cloud provider with the license included? You need to undertake a full analysis of both options, taking into account the challenges highlighted in this article.
I’d welcome your comments below, or in the forum – are you actively using your own licenses in the Cloud? How are you managing them from a SAM perspective? Does your existing tool do a good job of tracking cloud deployments?
Related articles:
- Tags: BYOL · cloud · License Agreements