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:

• any reasonable costs incurred by the Contractor that are directly attributable to the termination;

thus (1) putting the onus of quantifying the charges on the supplier, and (2) vanquishing their argument for full revenue recognition.

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 ...

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. ​

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!

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. 

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:​​​