Original plans had customers entitled to a 24 hour support response time when their Software Assurance spend was more than $250,000 USD - as of next year though, you'll need a Support Contract. That means either a Unified Support arrangement across your enterprise, or the uptake of pay-per-incident support (also available as a 5-pack option that expire within a 12 month period), which doesn't seem a particularly attractive proposition to smaller organisations. If you do have a Unified Support Contract you can transfer any current Software Assurance 24x7 Problem Resolution Support incidents before February 1, 2023. And the costs - well Unified Support is customised based on the actual spend, where pay-per-incident is published at Professional Support For Single Incident – $499 USD for 1 user. Professional Support For Five Pack Annual – $1,999 USD for 1 User. So you might need to revisit those 2023 forecasts just to make sure you've covered any additional costs you might incur - or maybe challenge Microsoft to their commitment that "Our goal is to ensure every customer gets comparable support services at a comparable price, despite the benefit retirement." !
0 Comments
A caution when relying on vendors to deliver projects with software installs.Many projects require the expertise of vendors to install, configure and productionize their software and systems, however as the client and end-consumer you need to be aware of what exactly is making its way into your environments. All too often following discovery we'll find unaccounted for vendor software, which typically after an onerous investigation is found to be remnants from the vendor-led project, anything from desktop clients to entire VM's, each of which can have dire compliance implications and cost. But "hold-on - we didn't install it - the vendor did" is the common response, however a quick pointer to the relevant contracts will soon expose that this does not offer any defense - the customer is always responsible for compliance, even if it is the very vendors software in question. At a more concerning level is when a vendor installs another vendors software - while this is not uncommon with the extent of partnerships and interoperability in the modern industry, it still needs to be clearly and formally covered, ideally contractually or by reference to the vendors right to distribute and use any IP they don't own. These artefacts need to be registered and retained in the event of an audit that questions your usage rights - in the worst case scenario if the vendor has breached another parties IP rights you too could end up subject to an infringement claim, and that's no place you want to be.
And never rely on the vendor's personal emails or assurances that 'all is well' - none of that will hold-up under audit (even if they are still there). When it comes to IP all bases need to be formally covered, and if that's proving to be a problem, well you might want to be even more wary.
Does your company distribute Adobe Reader to employees? ... if so, make sure you have a valid Distribution License.Now it's not as onerous as it sounds - it can all be done online, so lets look at some of the detail. When do I need it?A Distribution License Agreement is required for:
Note: You do not need to apply for a Reader Distribution License if you prefer to direct users from your website to Adobe.com to download Reader. What does the Agreement allow me to do?You will be authorised to:
What are the key restrictions?You must:
Ok, got it ... what do I do now?You'll need to apply for a desktop license which will take just a few minutes and is required to determine how you intend to use Reader. After you complete the short online form, you'll receive an email with a link to the installers. You'll also need to mark a renewal date 12 months from receipt to reapply - the agreement is only valid for one year.
In the absence of strict procurement practices and robust record keeping its all to common to see organisations struggling to retrieve their records of purchase backing-up their claim to entitlements. In fact how often do we hear "yeah we've got 20 licenses for that - they're listed on Dave's spreadsheet". Now lets be clear - the fact that it's on Dave's, or Susan's or anyone's spreadsheet does not constitute evidential fact. For that, you'll need the Proof of Entitlement if issued by the vendor, or the (signed) Contract containing the license grant, or the Order issued under it for the products in question. At a minimum if those are lost in the tracks of time (no doubt residing only in someone's email who has long departed the employ of the company), you'll need the latest invoice that shows the products and quantities that were covered by the last payment (ie. either actual purchase or renewal). Again, its all too common that it's not until an audit that organisations are forced to scramble through the purchasing, legal, IT et al records looking for some artefact to substantiate the otherwise baseless right of use claim for the vast overage of licenses that have been deployed! This trek down memory lane can be the most time consuming - and often fruitless - use of specialized resources, the cost of which is not generally recognized by management and similarly overlooked in the justification of a dedicated SAM function. So what's the alternative? Quite simply a process that ensures those essential records are properly recorded in an organized and readily accessible system, and are kept current through routine and ongoing ownership - once established this is not as much of an overhead as it might seem, and having all of that data at hand when challenged by a vendor can go a long way in underlining your disciplined approach and credibility in such a way that you'll be last on the next audit round list, if in fact on their radar at all. Now this will no doubt rally those skeptics with their "wait - I just call my reseller and say give me a list of what we own" approach, and while this might offer some solace it doesn't necessarily constitute proof in the same way that last document of fact - the invoice - does. How's that? Well for one example think of step-up licenses that will be printed there for all to see, but what about the original license it is based on (and worse, what if that original license is actually still in use!), or those 'from-SA' uplifts that require unravelling potentially years of purchase history to properly determine entitlement. All best avoided by having a routine practice supported by a specialized system in the first place ...
If it seems that your vendors are unwilling (they'll say unable) to accept a termination for convenience clause these days, you're not alone. Often this will be justified by citing their companies accounting rules and practices aligned to the 2014 revenue recognition changes post Enron where they'll refer as below:
What they don't refer to is the fact that where termination charges are provided full contract revenue can be recognised:
Of course the "substantive" qualification is the issue - just how substantive should it be? Well there are no firm guidelines in that respect, other than simply compensating a supplier for services or deliverables provided up to the effective date of (early) termination will not be regarded as substantive. Guidelines only advise that "judgment has to be applied with consideration given to quantitative and qualitative factors". Government contracts typically require a termination for convenience clause and will state (in part) something similar to the below:
Having negotiated the termination for convenience clause we're now comfortable that all is good right? Well no, there are further issues to contend with. If (and thats a big 'if') the matter gets to court there would likely be consideration as to whether the contract was 'illusionary' based on the very right to terminate at will, or that the termination was not enacted in 'good faith', or even as far as not following the termination right explicitly which opens the door to damages! So what other options are there? Well that of course depends on what exactly is being contracted, but consider the following:
Key to all of the above is explicit language that clearly defines the criteria by which the clauses can be invoked - when things break down to termination your vendor will not be overly receptive to subjective positions, ambiguities, or plain old opposing points of view. And while the lawyers are endlessly debating the virtues of limitations of liability and insurances and everything else basically immaterial just ask yourself when you actually last went to court, and then ask what typically goes wrong with your contracts - invariably its performance based and for that, you just need an appropriate provision for ... ... a hasty, unequivocal exit, at the lowest possible cost!Thinking to drop some Oracle product from maintenance to save some funds?... think again.You'd of course think that dropping product from your annual maintenance renewals would be treated as a simple removal of the line item and its associated cost - why wouldn't it be - you're keeping those remaining as-is so what's the problem?
Now this gem of a policy states: In the event that a subset of licenses on a single order is terminated or if the level of support is reduced, support for the remaining licenses on that license order will be priced at Oracle's list price for support in effect at the time of termination or reduction minus the applicable standard discount. Wait? ... What?? Yep, just because you were so brash as to drop maintenance on product you no longer needed, whatever you're retaining on that order is going to be repriced - and by reprice they of course don't mean down! Oh but the good news is in the next sentence: Such support price will not exceed the previous support fees paid for both the remaining licenses and the licenses being terminated or unsupported, and will not be reduced below the previous support fees paid for the licenses continuing to be supported. So rest assured loyal Oracle customer - any repricing will not exceed what you were already paying, it'll just match it. So those dollar savings that you put forward saying 'we're gonna drop product x, y, and z from the next renewal and save bucket-loads' is probably the opposite - depending on whats left you might end up paying exactly what you were before!
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.
A New And WeLcome Direction in Consolidated, Direct, Licensing InformationMicrosoft announced the 1st June 2019 as the date at which the new 'Licensing Terms Site' will replace the current downloadable document versions of the Product Terms (PT) and Online Service Terms (OST) (although at date of this publication it is still stating "under construction and for preview use only.") Not only is this intended to consolidate the myriad of licensing documents and material rife across Microsoft sites, but according to the FAQ (available here) will also ease navigation through filters available by program and product, and also introduce a new 'compared-to' function which allows users to compare changes (albeit post 1st June 2019) to 'current' use rights going forward - a useful utility! So what does it look like? - the landing screen as below (see it for yourself here): A quick test run found the site easily navigable, presenting targeted information based on your selection in the familiar format of the Product Terms structure. Of course it can't solve the 'knowledge complexity' invariably attached to licensing - you basically still need to know what you are looking for, and then be able to apply what you find to your own situation. A quick delve into the SQL Server section highlights the information then available by edition: All in all though a timely advance in the overall licensing landscape that would be welcomed across other vendors with similarly broad and complex license terms and models, which makes us wonder ... ... is it too much to hope for a cross-industry standard?
You've been there right ... in a meeting, time for the mandatory introductions, and the chair says "now from Procurement we have ..." ... so you shake your head (not visibly) and dutifully introduce yourself, thinking "They still have no idea!" So lets get a few things straight. Sourcing isn't Procurement. Sourcing ultimately involves Procurement, but other than that, it's quite different. And while we're on the subject, what's with 'Category Management?' Really?? ... to our thinking, 'Category Management' is just an unnecessary classification - sure - we work in categories, be it IT, Marketing, Stationary, Travel ... whatever, but it's the Sourcing label that defines the function. Well then, if it is different, what is Sourcing ? Sourcing, fundamentally is a discipline (much like, and in fact premised on, Project Management) - it has methodology, it has process, it has discipline, and it has rigour (for example, CIPSA). Not that Procurement doesn't - but Procurement ultimately follows the framework that Sourcing puts in place. Rather than straight 'buying' a good Sourcing practitioner will firstly work closely with the business to ensure there is an understanding (and proper framing and presentation) of requirements, development of a Market Strategy (who to approach, and how it should be constructed - RFI, RFP, RQT ...) , all backed up by a practice of relevant and credible assessment and evaluation (and that means no less than an objective, defensible process qualified by accurate data and irrefutable artefacts), followed by the subsequent qualification of supply (being full and complete due-diligence), with expert negotiation and agreement of (favourable!) contractual terms, plus induction of this new supply (and if you're a regulated institution, don't forget your obligations here - your license could be at stake). So where is Procurement in all of this? Procurement then steps in to make sure the ongoing acquisition of contracted products or services occurs within the framework of the Sourcing arrangements that have been put in place, tracking the metrics, monitoring the costs, measuring delivery - keeping the Supplier to their commitments. But let's hear from the practitioners out there - all you Sourcing and Procurement people doing the job day in / day out - where would you classify your role, what differentiates your function, how might you describe what you do? We're keen to hear your view - share your thoughts ...
It's there in the agreement, you can bet on it. Indirect Access. Whether it's disguised as 'qualified users, or 'devices', or perhaps 'multiplexing', it's prohibited. And that means you need to be sure that the access you're providing to your licensed systems is correct and compliant. The simple way to think about it is that if it's related to a proprietary system, or sourced from a proprietary system, any access must be properly authorised. And that means properly licensed. So whether it's via an API, an interface, or extracts, you need to ensure that you're compliant with the terms of your agreement - to not be can prove very problematic, and potentially very costly. Take the recent finding (Feb 2017) in favour of SAP UK over DIAGEO Great Britain which you can view at http://www.bailii.org/ew/cases/EWHC/TCC/2017/189.html in a remarkably readable form for a crown judgement. The core of the matter was the "Named User" metric by which DIAGEO licensed its SAP installation, and the development and use of functionality within Salesforce (known as Gen2 or Connect) that enabled DIAGEO customers and distributors to places orders, check stock availability and prices, see invoices and select delivery. Through various interfaces back to SAP, Connect provided the necessary data, lists, and workflow to those end customers and distributors 24x7 negating the need for a call centre to receive and process requests. Despite DIAGEO asserting that the use of Connect by customers was essentially no different to when they contacted and were processed through the call centre, the judge saw otherwise and ruled that such access constituted use of the SAP system. The implications are yet to be seen, however in summary the damages were considered by the judge as below: "In summary, usage by Gen2 sales representatives is not authorised usage under the Agreement. SAP is entitled to additional licence and maintenance fees, the level of such fees to be assessed in the quantum phase of the trial, if not agreed, by reference to the nature and extent of the usage and SAP's price list." So, should we be concerned? Absolutely. If you're unsure of the your license grants or metrics, the terms of your agreements, or the compliance of any periphery/accessing systems, you need to take stock and run a full assessment exercise across your domain.
To be unaware is to be in danger. |
<
>
Archives
April 2022
|