Understanding Oracle’s ULA

As Fiscal Year 2015 drew to a close for Oracle on 30 May last year, those enrolling in the company’s annual Partner Kick-Off on 25 June were given a clear hint at the vendor’s sales strategy for Fiscal Year 2016.

There is an unsurprising focus on gaining new market share (applications, Oracle Cloud etc.) while future-proofing the company’s existing customer base.

From a licensing pint of view, this future-proofing comes in the form of encouraging customers to sign multi-year agreements, spearheaded once again by the ULA agreement.

Definition of the ULA agreement

On paper, the ULA (Unlimited License Agreement) is a licensing agreement for a period of between 2 and 5 years (generally 3 years) granting the customer unlimited rights to use the software set out in the contract (or almost unlimited: see below).

It is therefore worth explaining an initial basic distinction between the different types of ULA:

  1. The “Capped ULA”: this is a ULA allowing unlimited use of the software up to a certain maximum number of deployments. Beyond this limit, the number of additional licenses required is negotiated on the basis of the existing license base and the time remaining on the contract. This paradoxical-sounding option of an agreement that is both “unlimited” and “capped” at the same time is starting to disappear.
  2. The “Uncapped ULA”: this is a ULA allowing unlimited use of software covered by the contract, free of any cap or threshold.

In the remainder of this article, we will focus on the “uncapped” version of the ULA.

An Unlimited License Agreement (ULA) can apply either to Oracle “Technologies” (database, infrastructure and middleware solutions) or to “Applications” (business applications: ERP, CRM, etc.). In either case, the ULA licensing metrics remain the same as for a conventional Oracle contract (OLSA):

  • NUP/Processor licensing for Technologies
  • Component/Enterprise: per user and per-use pricing for Applications

Building and negotiating a ULA

The process for putting together a ULA is as follows:

  1. Specify the period of the contract (straightforward in principle)
  2. Specify which software will be included in the contract (also straightforward: the organization simply “shops” for the solutions required to meet their current and future needs– at least in terms of a fairly imminent future). This software may be included to meet new requirements or may already be part of an existing Oracle contract.
  3. Specify an up-front fee for this software, determined by Oracle (and hence negotiated by the customer!) on the basis of the organization’s existing asset base along with an estimate of the state of the infrastructure on termination of the contract (and this is therefore where things get slightly trickier when it comes to ULA deployment).
  4. For solutions purchased to meet a new business need: building in corresponding yearly SULS subscriptions throughout the period of the ULA
  5. For existing solutions, prior to signing the ULA, ensuring their yearly SULS subscriptions are re-instated for the entire duration of the ULA
  6. On termination of the contract, the customer retains their full entitlement to use solutions deemed to be “certified” by Oracle. Certified solutions are those deployed and running at the time of the contract termination audit (a notion we will return to later).

ULA

 

Specifically, this means that at least the following must be considered when negotiating a ULA:

  • The process for terminating the contract effectively constitutes an audit of your infrastructure and provision should be made for this as part of the contract management process.
    • It is therefore crucial to understand how this certification process works: what information is required by Oracle? What kind of information will be reported by the LMS scripts? Can you perform “mock” audits in order to detect any discrepancies between software use covered by the contract and use of software that is not yet covered?
    • The outcome of Oracle’s audit is based on permitted use for solutions that are deployed and executed in situ, meaning that by default, they exclude access rights to any non-executed solution (e.g. passive DRP solutions, staging areas, etc.). It is therefore important to consider this criterion in the plans you make for the contract termination process.
  • You should also ensure that you have answers to the following questions (this list is of course non-exhaustive):
    • Do we have a good handle on how our needs for Oracle technologies/licenses will grow over the next three/four/five years? (given that this is a process for dealing with growing demands)
    • Do we need to plan for negotiating technologies that are not covered by the ULA agreement (e.g. database options and additional management packs)?
    • What maintenance budgets do we need to plan for/negotiate at the end of the ULA period? How about if our licensing requirements increase/decrease?

It is also worth bearing in mind why the ULA scheme exists from Oracle’s point of view. For the vendor, it serves as a means to:

  • To retain a minimum guarantee of maintenance revenues at a time when the market has been hit by an economic downturn and there is a decreasing need from existing customers to license additional processors and cores, given recent trends towards consolidation of infrastructure (be it via on-premises, hosted or cloud solutions).
  • To gain a share of the middleware and applications market: once they have entered into a ULA agreement, it makes sense (and there is a trend in this direction) for customers to deploy new projects over Oracle solutions included in the contract in order to maximize the financial benefit of the agreement. The main purpose of the ULA is therefore to “close the door” to Oracle’s potential competitors.
  • For both software vendor and customer, the ULA can also provide a neat solution in the event of any compliance issues, as all of the solutions listed in the agreement can be re-integrated.

Finally, from a business intelligence point of view, it can be worthwhile for customers who have not yet chosen between technologies (e.g. Oracle vs. Microsoft) to consider EAP (or NEAP) licensing from Microsoft at the same time. This type of agreement combines some of the licensing mechanisms of the ULA and applies them to the vendor’s current application stack: RDBMS, BI, ETL, development applications and environments. This is a good way of comparing technologies and licensing going forward!

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.