Introduction

All of us know that, when we acquire commercial software from a software vendor that what is being obtained is just a non-exclusive license to use: the vendor retains copyright ownership in the code; they permit a transfer or download of the code to the buyer; and, in exchange for a fee, the buyer takes a license subject to often extensive terms and conditions.

Although therefore business people and indeed lawyers talk about software being bought or sold, the legal basis is (at least for commercial applications) invariably with no transfer of ownership: only a limited right to use is being acquired.

Second-hand software market

However, a new market in ‘used’ business software has developed since the Court Of Justice ruling in the UsedSoft[1] case.

Software is a major expense for many organisations; pressures on them derive not only from immediate business needs but also a continuing anxiety that they might be under-licensed and thereby possibly infringing copyright.

Many bodies will have:

• Redundant or shelved software – software packages which were once used but no longer or where user numbers have decreased;

• Unused software: packages bought on a precautionary basis or for a project that never materialised;
• Surplus software: software still in use but where processor or user numbers have decreased;
• Software acquired as part of a settlement following a software audit where there was no need for the software but the vendor pressed for a settlement (for other under-licensing) on the basis of new software purchases.

Receivers of insolvent businesses, in particular, can readily divest themselves of their enterprise software under these rules: often it is clear that all software use has been ceased and so this scenario is particularly germane to resale of the software, obtaining considerable and unexpected recoveries for the receivers or administrators.

The legal issues regarding the resale of software

Historically, such licenses have not been transferable. The reason for this is that, save where there is specially-commissioned software where the developer agrees to assign copyright, enterprise software is licensed not sold.

The UsedSoft case

The UsedSoft case is a judgment of the Grand Chamber of the Court of Justice handed down on 3 July 2012. It effectively subverts the standard license provisions and, subject to certain conditions, invalidates the non-assignment terms. In short, it makes the license transferable irrespective of the contract wording.

Conditions for transfer under the UsedSoft case:

1. Sale relates to a ‘computer program’                            
2. The first sale took place within the European Union
3. License originally granted for an unlimited period      
4. License grant was in return for payment of commercial fee   
5. The copy still in the hands of the reseller is made unusable;   and
6. The licence has not been divided

Further case law

There has been some cases heard at which the UsedSoft principles have been further examined. None of these however affect the key rulings in UsedSoft.

In Ranks and Vasiļevičs: (C166/15 12 October 2016), for instance, the Court of Justice restated the legality of the resale of software in Europe in this judgment but confirmed that the principle does not extend to software transferred on back-up discs. The case concerned a Latvian reseller of Microsoft Windows and Office software sold on eBay using fake certificates of authenticity and duplicate discs copied over from original OEM discs supplied with PCs.

Position outside Europe

Neither the UsedSoft case nor the applicable directives have any application outside the EU. The case concerned only the interpretation of the EU Software Directive.

Accordingly, no weight can be given from these principles in any litigation or transaction involving software usage outside the EU. Indeed, within the USA, the United States District Court for the Southern District of New York has expressly rejected the possibility of exhaustion for digital products (in this case, music downloads) under the Re-Digi case[2].

Potential buyers, within the EU, should have some regard to the fact that jurisdictions outside Europe have not followed the UsedSoft case in cases where:

• On-premise software is to be hosted by or for the buyer on servers outside the EU;
• Users may be based outside the EU, but accessing the software remotely; and/or
• Back-up or disaster recovery is outside the EU.

These last two elements may not be fatal but place of actual deployment of software (particularly across networks) will need to be examined for any territorial ramifications.

How have software vendors reacted resale of software in practice?

It appears that they have not reacted explicitly to the new second-hand software market. They remain principally concerned at counterfeit and pirated software and their preferred focus is in this area rather than lawful sales which follow the UsedSoft case.

Impact of Brexit

Still, the continuing applicability of jurisprudence from the Court of Justice has not been settled. However, it seems certain that the key EU rules here will continue at least for the transitional period until May 2021[3] and probably beyond.

Conclusion

Resale of software can unlock very considerable value to an organisation and there is no reason why this cannot occur with appropriate diligence and support.

Despite software license agreements declaring that they are personal to the user, the UsedSoft case rules that, subject to conditions, such a prohibition is ineffective.

This is still a nascent area and expert specialist advice would be needed. There have been some cases which have litigated (even for UsedSoft itself) but these have largely been against careless intermediaries or obvious pirates.  The commercial market is still developing and, even in the UK, is unlikely to be affected by Brexit. Certainly major corporates and insolvency firms should always consider the value that can be unlocked in this space.

Robin Fry

Director of Cerno Professional Services Ltd

[1] https://www.reuters.com/article/us-britain-eu-ecj/uk-will-be-subject-to-ecj-rulings-under-brexit-transition-deal-minister-idUSKBN1FD15N

[2] https://h2o.law.harvard.edu/collages/34138

[3] UsedSoft GmbH v Oracle International Corp. C-128/11 of 3 July 2012

Cerno today releases its guidance note, for consultation purposes, on IAS 37 Contingent Liabilities and Provisions related to Software Under-Licensing. 

You can read more on this topic by Robin Fry on MEDIUM.

Background

Licensing of business software but where the extent and usage by the customer is not fully covered (‘under-licensing’) is a widespread (but rarely publicised) issue for major corporates and public-sector bodies.

The consequent exposure to the software supplier for the shortfalls can be material but often not apparent until the supplier exercises any contractual right of audit. At that stage, and over a period of some months, a license position is obtained for each and every product line with license grant being compared to usage that, inevitably, exposes license shortfalls.

Although it might be considered that a customer’s software licensing can predictably and readily be assessed for compliance, there is complexity here, with a high degree of risk, for a number of reasons:

1. The main software vendors have huge numbers of product lines – IBM’s software catalogue for instance has over 60,000 items – with 250 different metrics on which program usage is charged; even the largest corporates rarely have the knowledge and oversight necessary to fully understand what exactly is being used, under which applicable metrics and of which product version;

2. The license agreements have been developed iteratively over 30-40 years but many key concepts (‘use’, ‘access’, ‘processor’, ‘running’) are still left undefined; many terms are ambiguous and dependent on the vendor’s – not the customer’s – interpretation(s);

3. As technology has moved on with cloud usage, virtualisation and robotics, IT deployments by customers are changing constantly; the related licensing position is therefore a moving target;

4. The vendor’s own license agreements have not kept pace with the technology they are licensing; the vendors have instead sought iteratively to bolster the reach of their licensing schemes. Users are pointed to multiple guidance notes, ‘partitioning policies’, white papers, manuals and special conditions all loaded onto their websites with many further cross-references then on to other documents deep in the vendor’s library: often there is no single license agreement and significant ambiguity as to how usage of software tracks to software licenses granted and which documents are binding on the customer;

5. The IT, procurement, accounting and legal functions of large businesses may not together have considered the risks and lacunae around the software usage required by the organisation;

6. All of the major software vendors declare that their licenses are personal, non-assignable, and for use only by the contracted licensee entity for their own internal business purposes: use then by other group companies is not implied and must be negotiated at time of license grant. The difference between the named licensee and the actual corporate user entity often then becomes confused or overlooked.

Does the software have to be in use?

Software license fees are generally charged on the basis of installation or running. Accordingly, software that has been shelved or servers that have been put to one side for, for instance, fail-over or archiving still need a full suite of licenses even if rarely used.

Furthermore, much software licensing is charged on the number of processors potentially available to execute the software. With many businesses, a decision to maintain high availability (where excess loads at any time can be diverted to other groups of servers, often using ‘virtualised environments’ – particularly with VMware), means that very high numbers of processors and hardware all need to be fully licensed even if rarely fully utilised.

Level of risk

Although software licenses can often be negotiated at very high discounts and with preferential contract terms, the software vendor’s rights are reserved, contractually, to enable claims to be asserted at list-price with recovery of audit costs and 2 or 3 years of back-support (generally each year at 22% of perpetual license list fees).  Technically, rights to fees for back-support at full list price can cover the complete period going back to the later of first usage or six years.

With no opportunity to negotiate, for even small infractions, the eventual legal liability, when costed, can be many times what the corporate might otherwise typically pay.  IT teams and CIOs may not be aware of this and therefore downplay or disregard shortfalls that then unexpectedly give rise to material claims.

The question, to be answered by way of formal declaration from the CIO is:

• Are there any shortfalls of licenses in respect of the group’s usage or installation of software supplied by any of: Oracle, Microsoft, Informatica, IBM, VMware or SAP?

• What scripts have been run, or assessments made, to know this?

• Has there been an external verification as to the group’s level of financial exposure to that vendor if they were to carry out their own audit today?

Under-licensing is a present liability

Although the liability may generally only be exposed when a software vendor triggers their contractual rights to a software license review or software audit, nevertheless the payment shortfall is present at any time when the user has insufficient number or type of licenses required for their usage.

Although all the major software vendors have their own audit processes, it is clear that this only obtains the evidence for under-licensing rather than creates the liability: the liability is present at any time the corporate is using the software beyond the original license grant.

Is this a contingent liability?

IAS 37 declares a contingent liability as being:

• a possible obligation depending on whether some uncertain future event occurs, or 
• a present obligation but payment is not probable or the amount cannot be measured reliably[1].

It is submitted that any liability to a software vendor, as a counter-party to a license agreement, for under-licensing is generally an extant liability related to use; it is not dependent on future events eg whether the vendor identifies the user as under-licensed and/or initiates a software audit or other legal claim.

Furthermore, payment is probable in time by reason of the cycle of software audits carried out by the major software vendors.

Finally, the amount can generally be assessed by the conducting of an internal software license review by licensing consultants.

If a provision, how should this be measured?

The starting point will be the extent of any shortfall in licenses identified through an internal software license review or otherwise known by the organisation. This will produce a schedule of required license types and numbers to which published list prices and back-support can be applied.  This is known as an Effective License Position (ELP).

With the assistance of advisers, a best estimate can then be obtained in order to identify the likely outflow to settle the obligation in approaching the vendor[2].

Is the possibility of there being ‘an outflow of resources embodying economic benefit’ [3]too remote?

This is a matter for determination based on the identity of the software vendor, their practices around recovery of software under-licensing fees, and any remediating steps being carried out by the customer.

However, it is submitted, that, in the case of the principal software vendors – SAP, Microsoft, Oracle, Informatica, VMware and IBM, it would be imprudent to maintain that putative clams by any of them for unlicensed usage are remote – even if not immediately in view.

Conclusion

A number of high-profile cases, and the experience of IT asset managers, have confirmed that software under-licensing is a continuing issue for major corporates and public-sector bodies and that the amounts consequently available to be sought by the relevant vendors can be material.

Cerno Professional Services Limited © 2020

Note: The above represents opinion only and is made available without liability. Guidance is not to be taken or read as legal advice nor relied on without confirmation by your statutory auditors and your solicitors. Please refer to IFRS.org for latest version of standards and amendments.

Version: updated 140120 to incorporate footnote 2 referencing IAS 38 and IFRS 16

[1] Quotation © IFRS Foundation

[2] IAS 38 and IFRS 16 may both also be considered; however, IAS 38 only addresses the position of a software license as an asset and says nothing as to how the allied lease liability should be recognised.

[3] Quotation © IFRS Foundation

Is passive fail-over freely licensed for SQL Server?

The answer is it depends, because the rights granted have changed significantly and repeatedly over the last 12 years.

Previously, e.g for SQL Server 2008 and 2012, the primary license for the active instance automatically gave a (free) license to an equivalent passive fail-over instance on another server.

The rules have, over the years, changed for every edition. Now, to know the correct contractual position, regard needs to be had to both the original SQL Server rules for the particular edition when released and the applicable Product Use Rights or Product Terms, from release and now.

The latest edition is SQL Server 2019, with the licensing position [1] (as at November 2019) for this as follows:

Can shared servers be used?

Both this provision and the Outsourcing Software Management provision require the passive instance to be running on a Dedicated Host or Dedicated Instance.

Confusingly, the Product Terms elsewhere indicate that shared servers can it seems be used:

Fail-over Rights
For Products that are also granted Fail-Over Rights, Customer may run passive fail-over Instances on the qualifying shared servers in anticipation of a fail-over event. The number of licenses that otherwise would be required to run the passive fail-over Instances must not exceed the number of licenses required to run the corresponding production Instances on the same partner’s shared servers.

However, it appears that this is intended to cover the scenario where the licenses are made available to a shared environment e.g within EC2 using License Mobility: Microsoft’s SQL Server 2017 Licensing Guide states this:

In the case where you are using License Mobility to license your primary database running on shared hardware in the cloud, you may run the same number of passive SQL Server instances in a separate OSE running in the cloud on shared hardware to support failover events.

Can you rely on the SQL Server Licensing Guide?

It must be noted that the SQL Server Licensing Guide is a guide only (stated as ‘This document is for informational purposes only’) and is not legally binding.

For the correct position, one must rely only on the Product Terms in place when the product was first acquired. This declares, fundamentally, that ‘If Customer complies with its volume licensing agreement, it may use the software as expressly permitted in the Product Terms’.

So, it is this document that is central to what a customer can do.

What are the use rights for SQL Server Enterprise?

For SQL Server Enterprise, the primary use right is this:  ‘Customer may run any number of Instances of the server software in up to four OSEs on the Licensed Server at a time’.

The key here is ‘the Licensed Server’:  one license only covers one server – so that covers the primary usage only: no additional fail-over or high availability instances are included.

The latest Product Terms (December 2019) however enlarges the rights for SQL Server 2019 where Software Assurance is in place:

4.2 SQL Server 2019 – Fail-over Rights

For each of its Primary Workloads, Customer is entitled to:

• One Fail-over OSE for any purpose, including high availability, on any Server dedicated to Customer’s use (subject to the Outsourcing Software Management clause); and
• Two Fail-over OSEs specifically for disaster recovery purposes:
  • one on any Server dedicated to Customer’s use (subject to the Outsourcing Software Management clause) and
  • one on Microsoft Azure servers

Customer may also run Primary Workloads and its disaster recovery Fail-over OSEs simultaneously for brief periods of disaster recovery testing every 90 days. Customer may perform the following maintenance-related operations for any permitted Fail-over OSE:

• Database consistency checks or Checkdb
• Log Back-ups
• Full Back-ups
• Monitoring resource usage data

The difference with Azure

So, a clear distinction is drawn between whether or not you utilise Azure. The Licensing Guide confirms this:

‘The secondary passive server can also be setup in Azure for Disaster recovery with no additional SQL Server licenses required. Customers will only have to cover for the compute costs for VM/server used for passive replica’.

What ‘fail-over’ is licensed?

The Product Terms also make it clear what limited fail-over is included.

Fail-over OSEs permitted for disaster recovery must be asynchronous and manual. Fail-over OSEs may not serve SQL Server data to users or devices or otherwise run active SQL Server workloads. The number of licenses that otherwise would be required for a Fail-over OSE must not exceed the number of licenses required for the corresponding Primary Workload. These fail-over rights require SA for both the Licensed Server and CALs, if any, and do not apply when Customer deploys SQL Software under License Mobility through SA.

The base right then is for one fail-over OSE on any server dedicated to the customer

By contrast, if Azure is utilised, then the right is for one fail-over OSE on dedicated server dedicated and, also, one Fail-over disaster recovery OSE on Microsoft Azure servers.

Can you use AWS for fail-over from on-premise?

There is no technical reason why AWS EC2 could not be the fail-over destination from your on-premise database/programs – provided it is to ‘a Server dedicated to Customer’s use’ (see the Cerno Guide on this ‘Moving Microsoft to AWS: the licensing issues Part 2’.

There are also diagrams showing (e.g on p.27 of the Microsoft SQL Server 2017 Licensing Guide and on p.29 of the 2019 Guide) indicating that a fail-over, passive in the cloud, simply needs the same number of licenses as the active primary server. 

That guide (for Microsoft SQL Server 2017) declares that

‘The passive fail-over instances can run on a separate server. … The secondary server used for fail-over support does not need to be separately licensed for SQL Server as long as it is truly passive, and the primary SQL Server is covered with active SA…’

but not mentioning any restriction to on-premise backing to cloud.

For SQL Server 2019, the Licensing guide uses this wording:

The secondary passive server can also be setup in Azure for Disaster recovery with no additional SQL Server licenses required.

…but what is the position for use, outside of Azure e.g in AWS?

The guide states ‘All the three passive secondary replica benefits can be used simultaneously as long as the on-prem primary is covered with SA’ with the primary instance being shown as on-premise and the failover being shown as ‘Passive in the Cloud’.

Certainly the position is not clear but we cannot find any explicit wording, in the document or in the Product Terms regarding this prohibition.

What is permitted with a passive fail-over?

Conclusion

It might be thought that a simple question as to whether fail-over is licensed for SQL Server might have one simple answer.  But, as may be seen, much depends on the version used, the applicable product terms, whether software assurance is in place and whether if fail-over to the cloud, Azure is utilised.

Robin Fry

Cerno Professional Services Ltd

[1] SQL Server 2019 Licensing Guide  (2019)

Software often needs to be patched or upgraded. This Part 4, Patches for Microsoft, therefore looks at the licensing impacts in order to permit this.

In earlier Parts of this Guide, we looked at usage within AWS EC2 and how instances can be moved from one nominated server or environment to another.

The concept of patching

The concept of patching is almost completely absent from the 123 pages of Microsoft’s Product Terms (only one passing reference in the context of the Utilities for Visual Studio).  Accordingly, no explicit rights or concessions are given.

So, what is allowed?

Patching will generally comprise:

• Service Packs;
• Security Patches, and
• Cumulative Updates.

If patching is carried out, there are multiple means to achieve high availability with, for instance, SQL Server including:

• Replication
• Log Shipping
• Mirroring
• Always-On Failover clustering; and
• Always-On Availability Groups.

But for a number of these options, a second instance of the program – SQL Server for instance – necessarily needs to be available – maybe not running but certainly installed. Either that instance is then patched and tested or, as a passive instance, it takes over, becoming the new active instance, so enabling the original active instance (now passive) to be patched.

That of course is prudent and predictable. But there are licensing implications. We shall look at failover and back-up separately in this series but, for instance for SQL Server, it can be assumed that a second instance in warm standby [1] for failover would not require its own Microsoft license.

However, the switch to that instance and then back again, for production, would require an additional licensing because of the 90-day rule [2] (see Part 3).

The fact that it is, for most of the time, a purely passive install does not diminish the fact that it still needs to be fully-licensed for production purposes. That of course substantially increases total license costs.

The exception is where licenses are reassigned but only less often than 90 days or software assurance is in place (which means that the 90-day rule would not apply [3] – see Part 3). That would then allow the switch to a new second instance – and then back again – with the license being assigned in one direction and then back again during the process.

For desktop applications, multiple instances can be installed – but only on the same dedicated device:

Customer may install any number of copies of the software on a Licensed Device and on any Server dedicated to Customer’s use for each License it acquires.

Equally, for Server Licences, licensed per core, there is no mention of any limitation as to instances on the same sever:

Customer may use the server software on a Licensed Server, provided it acquires sufficient Server Licenses as described below.

The number of Licenses required equals the number of Physical Cores on the Licensed Server subject to a minimum (number) of Licenses per Physical Processor.

And where there is server licensing by Individual Virtual OSE:

Customer may use any number of Running Instances of the server software in any Virtual OSE on the Licensed Server, provided it acquires sufficient Licenses as described ….

Even with Software Assurance, no specific rights are given to enable use of a back-up for patching. There are rights for failover and disaster recovery but not back-up on another device or server maintained or installed for patching.

The basic position therefore is this:  Microsoft does not freely allow a second instance of a program to be installed or run on separate servers or devices maintained for high availability; where a program needs to be patched and then is to take over the original active instance, there is often then the need for additional licensing.

Do EU laws help?

As may be seen in relation to back-ups (see Part 5 of this Guide) , there can be, overlaid across the imposition of licenses, agreements and policies from vendors, certain laws that can still give rights to customers. These apply even if not mentioned in product documentation or on software vendors’ websites or FAQs.

One overlooked rule is that patching, in order to maintain adequate running of a computer program, has been explicitly recognised by the EU:

‘In the absence of specific contractual provisions, the acts … of … (reproduction, storage and adaptation) [4] shall not require authorisation by the rightholder where they are necessary for the use of the computer program by the lawful acquirer in accordance with its intended purpose, including for error correction’

This seems then to be saying that various acts are allowed by users for ‘error correction’.

Like much of EU law, what the wording means, and how it relates to the position on the ground, is not clear. What is meant by ‘In the absence of specific contractual provisions’? And does this means that a general prohibition in Microsoft’s license agreement as to making additional copies is this ‘contractual provision’? 

Furthermore, nothing is said as to whether this permits the making (or running) of a second copy in order to allow patching to be carried out without interrupting day to day production use.

One of the Recitals (13) to the Directive may assist:

‘This means that the acts of loading and running necessary for the use of a copy of a program which has been lawfully acquired, and the act of correction of its errors, may not be prohibited by contract.’

What this means in practice for patching rights and use of back-ups is not absolutely clear with no case-law yet on this either at EU or UK level.

European Court Interpretation

Our view is that the European Court would give a purposive interpretation of the Directive: in short, in our view, it would agree that, realistically, the running of a duplicate copy, for a short temporary time only to allow patching, would be a recognised exception and so allowed – even if the software vendor’s policies or contract wording prohibited this.

In short, this law would override vendor license prohibitions or contradictory wording.

This of course would be a major issue for Microsoft and it is doubtful that they would agree with the Cerno view.  However, if pressed forcefully by a customer, they might prefer to offer a conciliatory license agreement or preferential pricing in order to avoid elevation to Group Legal and delay in any license purchases.

Clearly, if patching is identified in an audit situation, the licensing infraction may only be measured in hours whereas standby use on shared servers would be (if unlicensed) a permanent 24/7 licensing breach. So it is possible that very occasional patching might be overlooked – particularly if Cerno’s arguments as to error correction under EU laws are pressed forward.

In our next part of our Guide (Part #5), we shall look at the issue of Failover.

Robin Fry

Cerno Professional Services Ltd

[1] ‘For SQL Server Instances run under License Mobility through SA rights, Customer may run passive fail-over Instances in one OSE on the qualifying shared servers in anticipation of a fail-over event. The number of licenses that otherwise would be required to run the passive fail-over Instances must not exceed the number of licenses required to run the corresponding production Instances on the same partner’s shared servers’.

[2] Section 9 Microsoft Universal License Terms: ‘Customer may reassign a License to another device or user, but not less than 90 days since the last reassignment of that same License, unless the reassignment is due to (i) permanent hardware failure or loss, (ii) termination of the user’s employment or contract or (iii) temporary reallocation of CALs, Client Management Licenses and user or device SLs to cover a user’s absence or the unavailability of a device that is out of service. Customer must remove the software or block access from the former device or to the former user’.

[3] Microsoft Product Terms ‘License Mobility’: ‘Under License Mobility Across Server Farms, Customer may reassign any of its Licenses which are designated as having License Mobility and for which it has SA to any of its Licensed Servers located within the same Server Farm as often as needed’.

[4] Cerno insertion

In Part 2 of the Moving Microsoft to AWS guide, we looked at usage within AWS EC2 on dedicated hosts and/or dedicated instances. Also, Part 1 of our Moving Microsoft to AWS Guide explained the requirement for customers to use dedicated hardware for their move to AWS, unless software assurance were in place.

However, the considerable advantage of EC2 – its elasticity – is primarily delivered through shared environments. Therefore Part 3 of the Moving Microsoft to AWS Guide looks at the licensing impacts in order to permit this.

Use on Shared Servers

The position as to use on shared servers is markedly different to dedicated hosts: shared servers are of course not ‘dedicated’ and so do not fall within the allowance given under Section 8 of its Universal License Terms:

Customer may install and use licensed copies of the software on Servers and other devices that are under the day-to-day management and control of Authorized Outsourcers, provided all such Servers and other devices are and remain fully dedicated to Customer’s use.

The Universal License Terms of Microsoft’s Product Terms do however also allow movement of customer licenses to shared environments – but only if software assurance is in place:

Permitted Use:
With License Mobility through SA, Customer may:

• Run its licensed software on shared servers;
• ….

The consequence of this is that Microsoft does permit customers to use third-party shared servers (such as Amazon EC2 Shared Servers) but only if software assurance is in place or the hoster itself has adequate licenses for the customer (‘License Included’ see section below) – not otherwise.

License included

As an alternative to Bring Your Own License (BYOL), AWS of course also offers license-included instances – fully-compliant Microsoft software licenses bundled with either Amazon EC2 or Amazon RDS instances.

Amazon Machine Images (AMIs) are available with just Microsoft Windows Server or with Windows Server and Microsoft SQL Server pre-installed.
For more information on this, Amazon has a useful e-Book:

MODERNIZE YOUR APPLICATIONS WHEN YOU MIGRATE TO AWS

Moving Microsoft to AWS – Software Assurance and License Mobility

Software assurance is standard with licenses sold through a Microsoft Enterprise Agreement and optional, on a case by case basis, with other Microsoft product licenses acquired under a Microsoft Open License and/or a Microsoft Products and Services Agreement.

Mobility within the same Server Farm

Within software assurance, there are a number of included rights. New version rights are of course central but of considerable importance is is License Mobility:

License Mobility Across Server Farms

Under License Mobility Across Server Farms, Customer may reassign any of its Licenses which are designated as having License Mobility and for which it has SA to any of its Licensed Servers located within the same Server Farm as often as needed.

Server Farm means a single data center or two data centers each physically located either in time zones not more than four hours apart, or within the EU or EFTA. A data center can be moved from one Server Farm to another, but not on a short-term basis. (EU is European Union; EFTA is European Free Trade Association).

The right therefore is for movement, at any time and as often as needed, between servers within one server farm. Microsoft’s standard 90-day rule (see box below) does not apply to this movement.

The 90-day rule

Microsoft concedes that, although licenses have to be assigned to a device or individual[1], customers can still reassign the licenses. The base position here is that this is permitted only once every 90 days save where there is permanent hardware loss or other conditions are satisfied[2]:

Section 9, Universal License Terms:
Customer may reassign a License to another device or user, but not less than 90 days since the last reassignment of that same License, unless the reassignment is due to (i) permanent hardware failure or loss, (ii) termination of the user’s employment or contract or (iii) temporary reallocation of CALs, Client Management Licenses and user or device SLs to cover a user’s absence or the unavailability of a device that is out of service.

Mobility across to other Server Farms

With License Mobility, there is also an allowance for movement to other server farms – but only every 90 days:

Customer may also reassign these Licenses from one Server Farm to another, but not on a short-term basis (i.e., not within 90 days of the last assignment).

This is also expressed elsewhere as this:

Customer may also move Instances run or OSEs managed under a particular License from shared servers in one Server Farm to its shared servers in another Server Farm, but not on a short-term basis (not within 90 days of the last assignment).

Mobility back to customer’s own servers

Once the software is utilised on the shared servers, the customer can also revert it back to its own servers (or another party’s shared servers) – but again no more often than every 90 days:

Customer may move its licensed software from shared servers back to its Licensed Servers or to another party’s shared servers, but not on a short term basis (not within 90 days of the last assignment).

Use can be on shared hardware

The second advantage permitted by License Mobility is use on shared – rather than dedicated – hardware:

License Mobility through Software Assurance

Under License Mobility Through Software Assurance (SA), Customer may move its licensed software to shared servers under any of its Licenses which are designated as having License Mobility for which it has SA, subject to the requirements below.

Products used for Self-Hosting may be used at the same time under License Mobility through SA rights, subject to the limitations of the Self-Hosting License Terms.

Permitted Use:

With License Mobility through SA, Customer may:

• Run its licensed software on shared servers;
• Access that software under access licenses and for which it has SA, and under its User and Device SLs that permit access to the Products;
• Manage its OSEs that it uses on shared servers; and/or
• Manage its OSEs that it uses on its servers using software that it runs on shared servers.

Certain additional requirements[3] are also made by Microsoft.

What is the effect of License Mobility?

License Mobility therefore enables the movement of licenses, unrestricted by the 90-day rule (see the box above). It is included as a benefit of Software Assurance but software assurance is not always a pre-requisite to license mobility.

It is important to note that license mobility is not equally available for all products. There are differences, in particular, between:

• Windows Server; and
• SQL Server licensing.

For all mobility, however, there is a process to go through: customers must complete a license verification process and Microsoft will ensure that you have eligible licenses with active Software Assurance[4].

A License Mobility Verification Form[5] has to be used, with a section to provide information about the Authorized Mobility Partner. For AWS, ‘Amazon Web Services’ is to be specified as the partner name.

Microsoft then provides confirmation to you and to AWS that you have completed this verification process. The application server software can still be deployed prior to the verification process including up to ten days before submitting the form.

Microsoft has published its own guide on license mobility:

License Mobility through Microsoft Software Assurance: Verification Guide for Customers

To use License Mobility through Software Assurance, you need to deploy on Microsoft Azure or with an Authorized Mobility Partner. Any current Authorized Mobility Partner can accept your assigned licenses and deploy them as appropriate to your chosen hosted deployment solution.

Microsoft also declares in its License Mobility through Microsoft Software Assurance: Licensing options to support cloud adoption that:

With more businesses adopting Infrastructure as a Service (IaaS), customers moving server workloads and applications to the cloud want to take advantage of their existing licensing investments as part of their IT strategy.

License Mobility through Microsoft Software Assurance gives Microsoft Volume Licensing customers the flexibility to deploy certain server applications with active Software Assurance on-premises or in the cloud, without having to buy additional licenses.

As a result, customers can take advantage of the lowest and flexible cost infrastructure for changing business priorities. Because of this new Software Assurance benefit, customers do not need to purchase new Microsoft Client Access Licenses (CALs), and no associated mobility fees exist.

Eligibility Requirements

The following conditions must be met:

• The Microsoft Server application products to be migrated to AWS via the License Mobility through Software Assurance program must be covered with active Software Assurance (SA); and
• The server applications must be on the list of eligible products. [6]

What Microsoft software can you move over?

Most Microsoft products utilised on-premise can be moved over to AWS. These include:

Note: It will be seen that this list of products, permitted for a transfer to EC2’s shared environment, does not cover: Microsoft Windows Client operating system, Desktop application products (e.g. Microsoft Office), and/or Microsoft Windows Server operating system.

In our next part of our Moving Microsoft to AWS Guide (Part #4), we shall look at the issue of Patching.

Robin Fry

Cerno Professional Services Ltd

(1) Section 9, Universal License Terms: ‘Before Customer uses software under a License, it must assign that License to a device or user, as appropriate.’

(2)Section 9, Universal License Terms: ‘Customer may reassign a License to another device or user, but not less than 90 days since the last reassignment of that same License, unless the reassignment is due to (i) permanent hardware failure or loss, (ii) termination of the user’s employment or contract or (iii) temporary reallocation of CALs, Client Management Licenses and user or device SLs to cover a user’s absence or the unavailability of a device that is out of service’.

(3)[Requirements:

To use License Mobility through SA, Customer must:

• Run its licensed software and manage its OSEs on shared servers under the terms of its volume licensing agreement;Deploy its Licenses only with Microsoft Azure Services or a qualified License Mobility through Software Assurance Partner; and Complete and submit the License Mobility Validation form with each License Mobility through Software Assurance Partner who will run its licensed software on their shared servers.

(4) https://www.microsoft.com/en-us/licensing/licensing-programs/software-assurance-license-mobility.aspx.

(5) A sample is available here: http://microsoftvolumelicensing.com/Downloader.aspx?DocumentId=11640

(6) There is a full list of eligible server application products within the Microsoft Product Terms at http://www.microsoft.com/licensing/about-licensing/product-licensing.aspx

Part 1 of our Guide explained the requirement for customers to use dedicated hardware for their move to AWS, unless software assurance were in place. In this Part, we consider this more closely particularly in the context of what Amazon offers, ‘Dedicated Hosts’ and ‘Dedicated Instances’, its customers.

Basic position

Microsoft confirms the position that using AWS is no different to using a traditional outsourcer. Even without Microsoft software assurance (see later in this Series), AWS’s dedicated hosts can, according to Amazon, be used:

‘Using Amazon EC2 Dedicated Hosts, you can access hardware fully dedicated to your use. This makes it possible to bring Microsoft software licenses ….’.

What type of ‘dedicated’ devices does AWS offer?

AWS has two defined ‘dedicated’ products:  ‘Dedicated Hosts’ and ‘Dedicated Instances’.

How these are established and run is important because Microsoft customers need to know whether, without software assurance, their existing licenses can be migrated to EC2 with Amazon supplying the necessary ‘Servers and other devices …. fully dedicated to Customer’s use’.

How then are these ‘Dedicated Hosts’ and ‘Dedicated Instances’ described and physically set up by Amazon?

The most reliable definitions, at least legally, are those in AWS Service Terms (last updated November 11, 2019).

Further, in its FAQs, AWS declares:

What is a Dedicated Host?

An Amazon EC2 Dedicated Host (“Dedicated Host” or “host”) is a physical server with EC2 instance capacity fully dedicated to your use.

Is a Dedicated Host a bare metal offering?

No, the instances that run on a Dedicated Host are the same virtualized instances that you’d get with traditional EC2 instances that use the Xen hypervisor.

So, the server is always that of the customer?

Obviously, if something is fully dedicated it implies that the customer has full control of that particular device. But, still, despite AWS’s repeated use of the word ‘dedicated’, it appears that AWS could still swap out the hardware.  Its Service Terms (4.11) has the following reservation:

• ‘As part of using Amazon EC2, you agree that your Amazon EC2 resources may be terminated or replaced due to failure, retirement or other AWS requirement(s). … THE USE OF AMAZON EC2 DOES NOT GRANT YOU, AND YOU HEREBY WAIVE, ANY RIGHT OF PHYSICAL ACCESS TO, OR PHYSICAL POSSESSION OF, ANY AWS SERVERS, EQUIPMENT, REAL OR PERSONAL PROPERTY, OR OTHER ASSETS’.

This casts some uncertainty as to exactly what control the customer has in AWS’s EC2 environment, even over ‘their’ dedicated hosts.

Although there might be some technical differences, Amazon maintains that the Microsoft licensing position is the same for both:

• ‘Dedicated infrastructure provides servers that are physically isolated for use by a single customer. Amazon EC2 has two dedicated infrastructure options: Dedicated Hosts and Dedicated Instances. If you bring existing licenses to Dedicated Hosts or Dedicated Instances, then you are using hardware that is fully dedicated to your use. In that case, the outsourcing language within the Microsoft Product Terms applies’.

On this basis, and despite the contractual reservation in Amazon’s favour mentioned above, it is clear that both Microsoft and AWS assume that use of EC2 dedicated hosts or dedicated instances can and does satisfy Microsoft’s requirement that the sever or device is dedicated to the customer.

In practice, which must I use – Dedicated Instances or Dedicated Hosts?

Although either of Dedicated Hosts or Dedicated Instances can satisfy Microsoft’s terms, there is still the issue of license management eg counting numbers of cores etc:

According to Amazon:

What is the difference?

This table shows the differences:

Are AWS’s ‘Dedicated Hosts’ and ‘Dedicated Instances’ sufficient to fall within Microsoft’s conditions?

Certainly AWS considers so:

‘Microsoft BYOL Licensing. Under this option, Amazon EC2 enables you to provision Amazon EC2 instances using your Microsoft Software and Microsoft Licenses (the “BYOL Program”).

Unless otherwise specified in your agreement(s) with Microsoft, you can use this benefit only if you comply with the requirements here, and you (a) use Dedicated Instances or Dedicated Hosts; (b) launch from Virtual Machines (VMs) sourced from software binaries provided by you; and (c) run the instances within your designated AWS regions’.  [AWS Service Terms 4.11]

Its introduction to Microsoft Licensing on AWS also declares:

Your existing licenses may be used on AWS with Amazon EC2 Dedicated Hosts, Amazon EC2 Dedicated Instances, or EC2 instances with default tenancy using Microsoft License Mobility through Software Assurance.

How does Microsoft explain the position?

Microsoft itself is less forthcoming as to use within AWS but does say, in the context of permitted third party datacenters, that ‘Some examples include Azure Dedicated Host, Amazon EC2 Dedicated Hosts, VMware Cloud on Amazon Web Services (AWS), and single tenant nodes from Google’.

Its Product Terms make it clear that

‘Any dedicated device that is under the management or control of an entity other than Customer or one of its Affiliates is subject to the Outsourcing Software Management clause’

Can any third party be used?

Formerly, Microsoft was largely agnostic as to the identity of the third party host. However, although a move to AWS is still permitted, the rules are now (from October 2019) much more constricted

Outsourcing Software Management

Customer may install and use licensed copies of the software on Servers and other devices that are under the day-to-day management and control of Authorized Outsourcers, provided all such Servers and other devices are and remain fully dedicated to Customer’s use.

Customer is responsible for all of the obligations under its volume licensing agreement regardless of the physical location of the hardware upon which the software is used.

Except as expressly permitted here or elsewhere in these Product Terms, Customer is not permitted to install or use licensed copies of the software on Servers and other devices that are under the management or control of a third party.

It is important to note that an ‘Authorized Outsourcer’ is different from an ‘Authorized Mobility Partner’. Only Microsoft, Alibaba, Amazon (including VMware Cloud on AWS), and Google are such Authorized Outsourcers; they are also referred to as ‘Listed Providers’.

Relevant details for this are set out here: Updated licensing terms for dedicated hosted cloud services: FAQs

So, it is clear that AWS is, and remains for the time being, an Authorized Outsourcer and so migration of Microsoft BYOL licenses is (subject to conditions) permitted.

In Part 3 of our Guide, we will examine whether and to what extent customers can move to AWS EC2’s shared environments.

Robin Fry,

Cerno Professional Services Ltd

PART 1: Overview

Introduction

“The emergence of dedicated hosted cloud services has blurred the line between traditional outsourcing and cloud services and has led to the use of on-premises licenses on cloud services’’ [1]

Amazon Web Services

What does AWS offer?

AWS offers a very broad range of cloud-based products across compute, storage, analytics and applications. Its principal compute offering EC2 (Elastic Compute Cloud) is both secure, and, critically, hugely resizable, allowing new server instances to be launched in a few minutes and virtually unlimited capacity.

The elasticity is obviously made available on the basis that (subject to certain limitations) AWS chooses where, at any moment, your instances are running or data is stored. AWS utilises multiple Availability Zones (AZs) for high availability and durability each with its own physically distinct, independent infrastructure.

Amazon also offers multiple different options such as On-Demand Capacity Reservations and Reserved Instances. However, these do not lock-down instances to fixed physical hardware.

Microsoft licensing

What rights do you get with Microsoft licenses?

Whether you can move your on-premise licenses to AWS depends on the permissions you are granted by Microsoft’s own licensing rules.

Microsoft’s licensing is determined by a raft of documentation including the relevant agreement with Microsoft: Microsoft Products and Services Agreement, Select, Select Plus or Open agreement and/or an Enterprise Agreement.

In addition there are Microsoft’s ‘Product Use Rights’ now called ‘Product Terms’ as well as other guidance, policies and white papers that may or may not have legal force.

However, the ten key elements are these:

1. Microsoft’s grant is for the (named) Customer to use the software;
2. No rights are granted to third parties – the licenses are non-transferable;
3. Sub-licensing is possible to ‘Affiliates’ (i.e. greater than 50% owned subsidiaries);
4. License transfers are not permitted save to Affiliates or where there is a divestment;
5. “use” or “run” means to copy, install, use, access, display, run or otherwise interact with;
6. Depending on edition, server licensing can be either on a Server + CAL (Client Access Licenses) model or on a per-core basis;
7. Before use, the license must be ‘assigned’ to a particular device or person as appropriate; [2]
8. Use or running in third-party environments is not permitted [3] save that
9. Outsourcers e.g. IaaS can be used provide that the servers or devices under their day-to-day management are and remain ‘fully dedicated’ to the customer [4], and also that,
10. If Microsoft’s ‘Software Assurance’ is in place, this allows use in third-party shared environment for most products.

How do Microsoft’s usage conditions work with Amazon?

It will be seen, then, from the last two points that Microsoft does allow controlled usage in third-party environments, with an enhanced facility for license mobility if the customer has its Software Assurance (further explored later in this series).

However, even without this, customers can move their existing on-premise licenses into third-party environments but only onto servers or devices that are ‘fully dedicated’ to the customer.

How, then, does a Bring Your Own License (BYOL) facility work with Amazon where, its elasticity of usage implies that customer’s applications can and will be running across large number of servers, changing repeatedly? By definition, these physical hosts are quite obviously not dedicated to one customer.

Do you need to own the servers or devices used?

Amazon EC2

EC2’s principal offering is one of instances with a tenancy of default; this means that programs are run on physical servers that may/do host multiple instances from different customers. So, these are shared environments that clearly would not satisfy Microsoft’s insistence as to third party hardware being dedicated to the customer.

AWS however fully recognises the need that certain customers have for dedicated hosts, offering not only its primary shared services but also bare metal, dedicated hosts and dedicated instances.

It confirms the position that using AWS is no different to using a traditional outsourcer. Even without Microsoft software assurance (see below), AWS’s dedicated hosts can, according to Amazon, be used:

‘Using Amazon EC2 Dedicated Hosts, you can access hardware fully dedicated to your use. This makes it possible to bring Microsoft software licenses ….’.

AWS has two defined ‘dedicated’ products: ‘Dedicated Hosts’ and ‘Dedicated Instances’. These have different characteristics and whether – and how – these conform to Microsoft’s requirements will be in Part 2 of this Guide.

Robin Fry
Cerno Professional Services Ltd, 2019

^{[1] Updated Microsoft licensing terms for dedicated hosted cloud services (August 1, 2019)}

[2] Section 9, Universal License Terms: ‘Before Customer uses software under a License, it must assign that License to a device or user, as appropriate’

[3] ‘Except as expressly permitted here or elsewhere in these Product Terms, Customer is not permitted to install or use licensed copies of the software on Servers and other devices that are under the management or control of a third party’.

[4] ‘Customer may install and use licensed copies of the software on Servers and other devices that are under the day-to-day management and control of third parties, provided all such Servers and other devices are and remain fully dedicated to Customer’s use’

[5] Section 9: Universal License Terms (November 1, 2019)

[6] Note the new use of the limitation ‘Authorised Outsourcers’: until November 2019, the possibility was for use on any servers or devices ‘under the day-to-day management and control of third parties …’

IBM software audits are expected significantly to increase for its Domino and Notes solutions ahead of the agreed sale to HCL scheduled to close later this year.

The sale announced in December covers IBM’s cognitive solutions — AppScan, BigFix, Unica, Commerce, Portal, Notes (formerly Lotus Notes), Domino and Connections — and is for a total value of US$1.775 bn.

So what does this mean for users of these products and what are the financial imperatives on IBM and HCL as the sale process continues?

Robin Fry’s article here for MEDIUM explains the jeopardy for legacy users of these products and likelihood of increased audit activity.

Despite IBM’s remarkably successful shift to its cloud services with US$20bn+ revenues, its legacy business is still substantial with many customers still using – and depending on – IBM middleware and solutions on-premise. However these customers should not be anxious that they are being overlooked: there is still a vigorous audit cycle in place with KPMG’s and Deloitte’s licensing divisions busy identifying under-licensing liabilities across enterprise and public sector customers.

These IBM software license reviews (= software audits) are intensely challenging given its 24,000 different product lines and 250 different licensing metrics.

However, at the heart of most audits are two questions which give radically different answers to how much the customer owes: Is IBM’s License Metric Tool (ILMT) installed? And are you reporting correctly under that?

If not, then, license fee demands are triggered often at 3-4 times the pricing that would have been obtained if this monitoring tool had been in place.

ILMT is not compulsory. But its correct use enables customers to take advantage of IBM’s sub-capacity licensing pricing as opposed to the default ‘full-capacity’ licensing.

ILMT monitors actual loads every 30 minutes and so can report maximum usage across time. Without the tool, IBM assumes that the processing power of the servers and clusters are used to the full and, accordingly, the full value of all attributable processor value units (PVUs) must be charged.

IBM is insistent on the key conditions being met in or outside any audit process.  ILMT is a free download and there is support provided the customer places a (free) order for ILMT in order to establish an IBM entitlement record for the license as well as software subscription and technical support. However, ILMT is not easy to install or run.

IBM insists that, with ILMT’s latest version 9.2x, there is its BigFix Inventory management also in place. This monitors every machine in the environment including backup and recovery machines, in order to ‘ensure audit readinesses’.

The license rules are exacting, declaring in the Passport Advantage Agreement that ‘Product deployments that cannot meet Sub-Capacity Licensing requirements must be licensed using Full Capacity terms.’  These are that the relevant products are eligible for sub-capacity licensing, eligible virtualization and processors technologies are used; and quarterly reports are returned.  If any of these conditions are not met for any reason, the customer does not advantage of IBM’s concessionary pricing.

So, that’s clear: IBM’s position is both immoveable and implacable.

The difficulty is the problems in installing or rolling out ILMT, despite its longevity (since 2008).  These are many and can revolve round inability to access the web console, BigFix crashing, and migration issues to ILMT’s latest version.

In the usual course, these difficulties count for nothing: either the sub-capacity conditions are met or they are not.

However, dig deeper and IBM’s rigid license structures begin to unravel. Its insistent statement under the IPAA that ‘Failure to generate Reports or provide Reports to IBM will cause charging under full capacity for the total number of physical processor cores activated and available for use on the server’ does not have the legal weight that IBM and the industry seem to believe and accept.

Critically, key pivotal expressions such as ‘available for use’, ‘activated’ and ‘processor core’ are not defined. Nor indeed is ‘full-capacity’.  Starting from differing interpretations that could then be overlaid, one can begin to build a case as to the instability of elements of IBM licensing.

IBM will never openly concede those points.  But in any audit situation, the most astute method is to confidently begin to destabilise the vendor, pushing forward authoritative legal and technical arguments. And then to use these, powerfully, in strong commercial negotiations to obtain the lowest-cost settlement.

Many consultants take the view that IBM’s sub-capacity/full-capacity licensing rules are unassailable.  We disagree. Yes, users should properly pay – but only for their true usage particularly where there have been significant difficulties in installation of IBM’s own license metric tool.

Increasingly, within audits, there are plaintive complaints as to the difficulty in installing ILMT – or running it correctly across the environment. There are 1,000s of questions and observations round this on IBM forums clearly evidencing that this is not an easy administrative task but one that, for some organisations, is a serious or impossible task.

If that is the case, then demands based on full-capacity licensing need to be reduced down. However, this needs carefully-marshaled arguments and a committed belief that IBM’s license terms are not, in fact, as certain as they (and others) might believe.

Robin Fry

Director, Cerno