Acquisitions & Divestments: the impact on your Oracle licenses

If your business regularly acquires or divests entities, or is planning to engage in one of these activities, it’s important to remember to pay attention to all your software assets, particularly Oracle licensing. This is because the agreements you have with Oracle may document who—which entity—in your organization is permitted to use the products you’ve bought the rights to use.

It is also possible that your agreement makes no reference to divestments or acquisitions at all.

What does this mean?

So for example, if you have a standard online agreement, this may state that you cannot assign, give or transfer the programs to other individuals or entities.

Think about it. Perhaps you’re a long-standing Oracle customer. Perhaps the agreement you signed up to in the past is still the agreement you place orders against now. If you check one of your support renewals, you will probably find it quotes an agreement by name and/or number—something like OMA-12345 or TOMA-54321. This is the agreement that sets out the framework against which you can use Oracle products, including the ‘who’. It might also tell you where you’re licensed, such as world-wide or USA only.

If you’ve recently divested or acquired an entity, these changes should be reflected in your agreement(s).  

There may be clauses that detail how acquisitions or divestments should be handled. Typically, an entity you divest will have 90 days to continue using the products bought under your agreement, after which they must purchase their own licenses. Remember that licenses will not be novated with a divestment unless they are in the divested company name. If you acquire an entity, you should have their details added to the list of businesses that can use and/or purchase Oracle products under your agreement.

These changes need to happen as formal communication to Oracle, and you’re required to do so in order to remain compliant with the terms of the agreement.

As noted above, this is particularly important when you acquire a new business because without a change in the terms, the new business should not use any licenses you’ve purchased. If you’re merging a new entity with your existing business, you may assume they will have access to your business critical infrastructure and thus the Oracle products that support it. But this is only allowed if your agreement specifically says so. In addition, if your Oracle estate is licensed by the number of users you have, such as in a Software as a Service (SaaS) environment, bringing in a new business will inflate those numbers and your licensing should adjust accordingly.

To add to the complexity, new entities may bring their own licensing and agreements with them into your business. However, you may likewise not be allowed to access their products due to the same types of clauses.

If you have deployed enterprise metrics in your Oracle estate (for example ‘$m in revenue’) then these will also need to be assessed with any business changes as they are likely to increase or decrease with your expansion or contraction.

You can see how an entity reshuffle effects more than just your business revenue, and why it’s very important to examine and update your agreements to reflect the current ownership structure.

Where to start?

At Inoapps, we’ve seen many different iterations of these agreements, often made complex by changing rules and historical negotiations between customer and vendor. Below is a modest list of suggestions of where you might start if you have concerns. This is by no means an exhaustive list!

1. The first place to look is in your support renewals. Make a note of any agreements they reference. Sometimes the agreement text will be repeated as an addendum to the support renewal.
2. If there are multiple agreements referenced, try to put them in date order and attach the support renewals to each one. This will help you understand the progress of your agreements and the changing terms in each.
3. Once you have a list of the agreement references and—hopefully—have tracked down the relevant paperwork, you’re then looking for clauses with headings such as Customer Definition, Assignment or Divestment.
   
   
   • Customer Definition clauses may detail the parent organization and sometimes make reference to Majority Owned entities who are allowed to use the programs purchased under the agreement.
     • Majority Owned should have its own definition. This is typically greater than 50% ownership of any acquired entity.
     • There may also be an appendix that lists the entities. If it exists, check it and update it if necessary.
   • Assignment clauses may detail the restrictions for entities acquiring you and assignment rights if these are met.
     
     
   • Divestment clauses set out the terms for the divestment process, including the number of days before license rights terminate and who—whether you or the divesting entity—is responsible for communication to Oracle.

How Inoapps can help

At Inoapps, we have extensive experience assisting our customers with getting on top of complex licensing and subscription agreements. We are also Oracle Partners, accredited in the Joint Partner Engagement program and the Oracle Partner Software Asset Management (VSAM) Service.

Inoapps is here to help you regain visibility, take control and expand your licensing knowledge around your Oracle software assets. If you’d like to know more about our Oracle Licensing and Subscription services, visit our web page, or reach out—our Oracle licensing experts are on hand to help you get to grips with your challenges.