PART 4: Patches for Microsoft
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:
- Log Shipping
- 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  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  (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  – 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)  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.
Cerno Professional Services Ltd
 ‘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’.
 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’.
 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’.
 Cerno insertion