Data Recovery Environments using Copying, Synchronizing or Mirroring Standby and Remote Mirroring are commonly used terms to describe these methods of deploying Data Recovery environments. In these Data Recovery deployments, the data, and optionally the Oracle binaries, are copied to another storage device. In these Data Recovery deployments all Oracle programs that are installed and/or running must be licensed per standard policies documented in the Oracle Licensing and Services Agreement (OLSA). This includes installing Oracle programs on the DR server(s) to test the DR scenario. Licensing metrics and program options on Production and Data Recovery/Secondary servers must match.
Servers – Disaster Recovery Rights: For each Instance of eligible server software Customer runs in a Physical OSE or Virtual OSE on a Licensed Server, it may temporarily run a backup Instance in a Physical OSE or Virtual OSE on either, another one of its Servers dedicated to disaster recovery, or, for Instances of eligible software other than Windows Server, on Microsoft Azure Services, provided the backup Instance is managed by Azure Site Recovery to Azure. The License Terms for the software and limitations apply to Customer’s use of the backup Instance.
If its not specifically called out in the VMware Product Guide it will need licensing, and that means everything other than Continuent and vRelaise for Log Insight. Surprisingly, VMware deem an install to be 'use' of the software - yep - just binaries sitting on a disk.
RHEL Linux Subscription Guide: Cold backups: The server has software installed and configured, but it is turned off until the disaster occurs or for periodic disaster recovery procedure tests. For Red Hat Enterprise Linux, this means that the customer is allowed to preload the bits as a courtesy. However, Red Hat Content Delivery Network cannot be used to update the system until the disaster happens. Then, the paid subscription on the failed machine transfers to the cold backup sever. In this case, a customer does not need two subscriptions. The customer will consume only one subscription at any point in time. Red Hat will allow the customer to pre-provision the software bits onto the cold backup machine as a courtesy. If a customer is found to be running more units of Red Hat Enterprise Linux than the customer has subscribed for because the customer has found a use for these pre-provisioned servers other than this cold backup use case, the customer is obligated to pay Red Hat.
Backup Use Defined: For programs running or resident on backup machines, IBM defines 3 types of situations: “cold”; “warm”; and “hot”. In the “cold” and “warm” situations, a separate license for the backup copy is normally not required, no additional charge applies, and IBM does not need to be notified. In a “hot” backup situation, the customer needs to acquire another license. All programs running in backup mode must be under the customer’s control, even if running at another enterprise’s location.
The world is certainly a different place than it was just weeks ago. From what was a normal days work to stay-at-home advisories, self-isolation and lock-downs, business and workers face enormous challenges.
In such adverse times it's not possible to predict what the landscape will look like in the months ahead, but with the unfortunate loss of jobs and closure of businesses all we can know is that it will be a dramatically different place.
Those that can and do keep operating are an imperative for the economy, both now and through recovery, and whilst it would be reprehensible of vendors to audit companies when the corner is turned, there are those that inevitably will still do so.
So while there is much to contemplate and deal with in just keeping your business running, a quick check on some basic principles could avert some later issues. Consider some of the most common licensing pitfalls with typical BCP scenario's:
Working From Home
Working from Home means mobility - if you are allocating laptops and notebooks be wary of installation or device based licenses, all of which might be overlooked with the rapid deployment of SOE's and new devices. There may even be restrictions on what category of device the software can be installed on, or even where physically it can be used (eg. designated offices or specific geographic locations). Where applicable, check you mobility rights cater for your intended use, and are current (eg. Microsoft SA Benefits).
Remote access can be another minefield where in the rush to get staff connected controls that would normally be in place might get overlooked. While solutions like an F5 BIG-IP Edge Gateway provide user based licensing to their own resources via secure VPN, other storefront and virtualisation products such as Citrix Gateway with VDI if not properly administered can be at greater risk of exposing applications unintentionally - make sure your access controls eg. AD Groups etc) are aligned to your licensing, and any additions to those secure groups have corresponding entitlements.
If you are in the position of having to invoke your DR (or partial DR) things will undoubtedly be more complicated. License transfer rights, powering servers up, or moving capacity from cold to hot can easily lead to over use. Migrating (or worse, extending) production workload to DR will certainly have conditions and constraints that if over-looked will leave you visibly non-compliant at a later date via audit trails such as SCRT or license server logs. Keep appropriate records that will help to mitigate any action you needed to take, and make sure you enable/track license migration alongside any workload you move.
While we'd like to think some leniency would be afforded through these difficult times, keeping a good handle on your compliance position just makes good business sense.
So stay compliant, but mostly, stay well, and stay safe.