oracle isv licensing / Oracle negotiations

Negotiating Oracle ESL, ASFU, and PAH Agreements

Negotiating Oracle ESL

Negotiating Oracle ESL, ASFU, and PAH Agreements

Executive Summary:

This article provides a strategic guide for CIOs, CTOs, and procurement leaders to negotiate Oracle licensing agreements for ISVs, specifically Oracle’s ESL, ASFU, and PAH license models.

It covers achieving the best discounts (like ESL’s 90% off), managing cost components such as support fees, choosing optimal metrics (Processor vs Named User Plus), and securing favorable contract terms.

Enterprise IT and Vendor Management professionals will learn practical tips to maximize value in deals involving Oracle embedded or hosted licenses, ensuring their organization gets the needed Oracle technology at the lowest TCO (Total Cost of Ownership) and with acceptable risk.

Oracle ISV Licensing Agreements – An Overview

When an independent software vendor or service provider includes Oracle technology in their solution, they enter into special licensing agreements with Oracle.

From a negotiation standpoint, these agreements differ from standard Oracle contracts because they often involve steep discounts, royalty structures, and multi-party considerations (Oracle, the ISV, and end customers all have interests).

Key Oracle ISV license programs include Embedded Software License (ESL) for bundling Oracle in products, Application Specific Full Use (ASFU) for reselling Oracle tied to one application, and Proprietary Application Hosting (PAH) for offering Oracle-based software as a service.

For CIOs and procurement heads at ISVs, negotiating these agreements with Oracle is about balancing cost vs. restrictions.

For enterprise customers working with an ISV, negotiation might involve ensuring the vendor’s contract passes on benefits and protections.

In both cases, understanding Oracle’s pricing levers and terms is crucial:

  • Oracle offers two financial models to ISVs: a heavily discounted license up-front (like ESL’s 90% discount on list price) or a royalty model where the ISV pays Oracle a percentage of revenue or a fee per user/unit sold. Deciding which model is better depends on cash flow and growth projections.
  • Support fees and obligations need clarity: Will the ISV maintain Oracle support? Is the end customer expected to pay for any support? Negotiating who pays the 22% annual support (and on what basis) can significantly impact long-term costs.
  • Metrics like Processor vs Named User Plus (NUP) licensing can change cost dynamics. A savvy negotiator will choose the metric that yields the lower cost for their use case and ensure any minimums (like Oracle’s NUP minimums per processor) are accounted for.

Overall, Oracle ISV agreements require negotiating price and contract terms that define usage scope, reporting requirements, and liabilities.

Oracle ESL Compliance Best Practices: A Guide for CIOs and ITAM Professionals

Pricing Models: Up-Front Discount vs Royalty-Based Licensing

Oracle typically structures ISV deals in one of two ways – pay once for discounted licenses or pay as you go with royalties.

Understanding these can help you pick the most cost-effective option:

  • Deep Discounts on List Price: This is common for ESL and many ASFU agreements. Oracle provides a massive discount (e.g., 90% off) on its standard price list for licenses the ISV will embed or bundle. The ISV then usually pays for a block of licenses up-front (or as they place orders tied to end-customer deals) at this reduced rate. Negotiation tip: Push Oracle for the highest possible discount tier. Oracle’s motivation is to win adoption of its technology in your solution, so they often start at 80% and can go to 90% or even 95% for very strategic partnerships or large volume commitments. Also, clarify if the discount applies uniformly to all Oracle products you might use (database, middleware, etc.). Sometimes, different products have different maximum discounts; negotiate each to the maximum allowed.
  • Royalty or Revenue Share Model: Instead of buying discounted licenses outright, an ISV can negotiate a royalty model (commonly used in PAH and some ESL deals). Here, you report usage (such as number of end users, transactions, or revenue from your solution) and pay Oracle a fee per unit or a percentage. Negotiation tip: Aim for a royalty rate with a deep discount when modeled out. For example, if your solution is $100K and includes an Oracle database, a 10% royalty to Oracle is effectively $10K per sale. Compare that to the cost if you had bought a discounted license. Royalty models can be great for cash flow (you pay as you sell, not up front) and for scaling with your business, but ensure the definition of “royalty base” is crystal clear (net revenue vs gross, etc.). Also, negotiate caps or volume breakpoints – e.g., the royalty rate drops after a certain number of units sold.
  • Hybrid Approaches: Some agreements might involve a small up-front license purchase plus lower ongoing royalties. Be open to creative structures. For instance, you might buy a few licenses now (at a discount) and agree to royalties for additional deployments beyond that. This can please Oracle (some immediate license revenue) and you (lower variable cost as you grow).

When evaluating these models, forecast your expected growth and customer base. Suppose you expect to sell many units quickly.

In that case, an up-front discount purchase might yield better margins (assuming you negotiated a high discount and can amortize the cost over many sales).

A royalty model reduces risk if your sales are uncertain or ramping slowly. Always run cost scenarios for best-case, expected-case, and worst-case sales to see which model protects you financially.

Read Comparing Oracle ESL, ASFU, PAH, and Full Use Licenses.

License Metric Selection: Processor vs Named User Plus (NUP)

Choosing the right licensing metric is a crucial negotiation point that can dramatically affect costs:

  • Processor Licensing: Oracle’s processor license lets you cover unlimited users on a server by counting hardware cores (with a core factor). ISVs often prefer processor licenses if many end users will use their solution or if it’s impractical to count users. Negotiation considerations: Ensure you understand Oracle’s Core Factor Table. For instance, Intel x86 cores have a 0.5 factor, so two 8-core CPUs = 8 processor licenses. Negotiate how you will true-up if your customers choose different hardware. Some ISVs negotiate a standard reference architecture for licensing purposes or an allowance for a server of a certain size. If you embed by processor, confirm if you need to license all potential deployment environments or only what’s used – clarity here can avoid over-buying.
  • Named User Plus Licensing: NUP licensing might be cheaper if the user counts per deployment are limited. Oracle requires a minimum number of NUP per processor (often 25 NUP per Oracle processor for Enterprise Edition database on most server types). Negotiation considerations: NUP licensing could be far cheaper than processor licensing if your solution naturally limits the number of users (for example, an analytics tool for a fixed team of 50 users). However, NUP could become a management headache if the solution could be widely accessed or if user counts might grow unpredictably. Negotiate flexibility: an ISV agreement might allow you to license NUP proportionally to actual users of your solution, even if below Oracle’s typical minimums. If you meet some thresholds, this custom term can save costs in smaller deployments. Always include the Oracle-defined minimums in your pricing calculations to avoid surprises. For example, even if a customer has five users, if the environment has at least one processor, Oracle’s standard rules normally need 25 NUP minimum; your deal with Oracle as an ISV could potentially allow exceptions for tiny deployments – ask for it if relevant.
  • Unlimited or Pool of Funds: In some large ISV negotiations, Oracle might offer an unlimited use for development/testing or a pool of funds model (a prepaid amount that can be applied to licenses). If your product might use various Oracle components (database, WebLogic, etc.), consider negotiating a bundle or pool license to simplify tracking. For instance, a fixed annual fee covers all needed runtime licenses up to a certain limit. This is complex but can be beneficial for broad partnerships.

Key tip: Align the metric with your product’s value metric. If you sell your software per-user, trying to license Oracle per processor could misalign costs (e.g., a small user count on a hefty server could cost more in Oracle licenses than you charge the client!).

Conversely, if you sell per appliance or server, a processor metric aligns well.

Oracle is often flexible during negotiations if you present a logical model for licensing that maps to how you do business; they want their cut in a way that grows as you grow, but doesn’t stifle your sales.

Managing Support Costs and Obligations

Oracle’s annual support fee (typically 22% of license price) can be a significant long-term cost.

Negotiating how support is handled in ISV agreements can save money and avoid confusion:

  • Skip or Minimize Oracle Support for ESL: One advantage of ESL is that you are not required to buy Oracle support for those runtime licenses. Many ISVs choose not to purchase support (especially if they got a large discount on licenses), instead relying on their expertise and Oracle’s free patch downloads for partners. If you go this route, negotiate access to critical patches. Oracle often provides partners access to patches for development purposes; ensure you have that, or that the versions you embed will have necessary updates available. For customers: if you’re negotiating a contract with a vendor using ESL, inquire about how they handle support and updates – you might negotiate clauses about timely patching (for security, etc.), since you can’t go to Oracle directly.
  • Oracle Support in ASFU/PAH Deals: With ASFU, Oracle usually charges support on the net license fee. Here, negotiate the support base price. If you have a 50% off list on the license, ensure Oracle calculates the 22% support on the discounted price (they should, but it’s worth confirming). Try to lock that support percentage – Oracle standard is 22%, but sometimes in custom deals, you might negotiate a slightly lower percentage or cap support cost increases year over year. If you, as the ISV, are handling support and need Oracle as backup, consider negotiating a partner support package instead of full support for each license, if available. In some cases, Oracle has embedded support agreements. Explore if that exists to reduce costs.
  • Include Support in Your Pricing to Customers: As an ISV, decide whether you bundle the Oracle support (and your support) into one maintenance fee for the customer. From a negotiation perspective, if you’re absorbing Oracle’s support cost, you’ll factor it into your pricing model. If you intend to pass it along (transparently or hidden), ensure the customer isn’t double-charged. Some procurement folks will spot an Oracle support line item – if they do, explain that it’s part of the licensing, or better, roll it into your single support fee for simplicity.
  • Updates and New Versions: Negotiate how new Oracle versions are handled. If Oracle releases a major new version of the database, do your embedded/ASFU licenses allow you to upgrade at no additional cost? Generally, if you’re under support, yes. If you opt out of support (ESL scenario), you might be stuck on the version you licensed for a long-term solution, which can be risky. Consider at least maintaining support on a few licenses for development purposes so you can get new versions and test them. If you are a large partner, you might negotiate a clause that you can upgrade to newer versions as they come out, even without a separate purchase (Oracle’s standard support entitles you to that, but without support, licenses are technically only for the version at purchase). This can be a point to discuss if you foresee needing new Oracle features.

In summary, pin down the support plan. The “hidden” cost often eclipses the initial license fees over a 5-10 year period.

A 90% license discount is great, but if you pay 22% of the list price every year in support, you’ve paid more in support than in licenses after five years! If you don’t need Oracle support, avoid it entirely (and be prepared to self-support).

If you need it, negotiate the fairest terms possible and include those costs in your total cost analysis.

Key Negotiation Strategies for Contract Terms

Beyond pricing numbers, the contract terms of an Oracle ISV agreement or a procurement contract with an ISV can have big implications.

Here are vital areas to focus on:

  • Define the “Application Package” Broadly (for ISVs): When signing an ESL or ASFU agreement with Oracle, you have to specify the application that Oracle will be used with (via the APRF). Negotiate flexibility into this definition. For example, avoid naming a specific module or version; describe it generally (e.g., “XYZ Healthcare Analytics Platform and its successor versions”). Oracle will want some specificity, but they understand you may update your product – ensure the language allows reasonable evolution without needing a new contract. Some partners purposely keep descriptions vague to allow using the license in adjacent functionalities. Don’t be so vague that Oracle rejects it – find a balance and get Oracle’s agreement in writing for any ambiguity.
  • Volume Commitments and Targets: Oracle might request a minimum license purchase or revenue commitment over time in exchange for high discounts. Negotiate these carefully. If they want $1 million in Oracle license revenue over 3 years, ensure it’s realistic. You could negotiate a smaller commitment or include phases (e.g., half is contingent on a new product launch). Also, try to include an escape hatch – what happens if you don’t meet the target? Preferably not a retroactive price increase (avoid any clause where Oracle can claw back the discount). Instead, maybe future purchases revert to a slightly lower discount tier. Keep penalties mild.
  • Audit and Reporting Terms: Oracle may require periodic usage reporting under PAH or royalty deals. Negotiate the frequency and detail so that it’s not too burdensome. If possible, aggregate data to protect customer specifics. Also, clarify audit procedures: Oracle might reserve the right to audit your records to ensure you reported correctly. Ensure standard audit clauses (reasonable notice, during business hours, confidentiality of your customer data, etc.). If you’re negotiating as a customer with an ISV, consider an audit clause; you might want the right to audit the vendor to ensure they comply with Oracle (because if they fail and Oracle pulls the license, your service could be at risk). It’s uncommon, but it’s worth considering in the contract with the vendor for critical services.
  • Termination and Exit: In your contract with Oracle (as an ISV), address what happens if either party terminates. Typically, suppose you or Oracle terminate the agreement. In that case, existing customers can continue using the embedded licenses (Oracle often grants perpetual end-user rights for those instances, known as “distributed licenses”). Ensure such clauses exist to protect your customers. From the enterprise customer side, if you’re buying a product with an embedded license, ask: What if we stop using the vendor’s software? Usually, your right to use Oracle also ends. There is no easy fix, but it’s good to know. If it’s mission-critical data, you might negotiate escrow or a buy-out option to convert to a full use license if needed (rare, but some savvy customers have asked for the right to buy Oracle licenses at a predefined rate if the vendor relationship ends).
  • Geography and Cloud Use: If your software might be deployed in the cloud or various countries, ensure the Oracle agreement allows it. Some older Oracle partner agreements had restrictions like “not in public cloud” (Oracle once frowned on AWS deployments under these programs without consent). Oracle has eased up, but deploying on certain cloud platforms may require an amendment or prior approval. Negotiate upfront that you can deploy in any customer environment, including leading public clouds (AWS, Azure, etc.) under the agreed licensing model. This avoids returning to Oracle for permission later, which could delay deals. If you’re a customer, ask the ISV if the solution can run on your preferred environment and if their Oracle license covers that (for example, if you want to run their appliance on VMware, are they handling the licensing correctly? They may need to license the whole cluster or have an Oracle-approved hard partitioning method. It’s good to flush this out in negotiations so you don’t hit implementation issues.

Real-World Pricing Scenario Example

To illustrate the cost differences, let’s consider a scenario and compare an ESL vs an ASFU vs a Full Use approach:

Scenario: An ISV sells a supply chain application using Oracle Database Enterprise Edition. They target large deployments on a server with 16 CPU cores.

Each client will have about 100 named users using the system.

  • ESL Model: Oracle list price for Enterprise Edition per processor is $47,500. With an ESL 90% discount, the ISV pays about $4,750 per processor. Using Oracle’s core factor (0.5 for modern Intel CPUs), 16 cores = 8 processors to license. Total Oracle cost under ESL = 8 * $4,750 = $38,000 (one-time). Support is optional; assume the ISV opts out and handles it themselves, so no annual Oracle support cost. The ISV might bundle this cost into the customer’s product license fee.
  • ASFU Model: Oracle list for eight processors = $380,000. Let’s say Oracle gives a 50% discount for ASFU. Cost = $190,000. Support at 22% of $190K = $41,800 per year. The end customer license would be $190K up-front (perhaps charged via the ISV) plus annual support (often passed through or included in maintenance fees). If instead licensed by NUP: 16 cores require a minimum of 25 NUP per core (400 NUP). List price per NUP ~$950, 400 * $950 = $380,000 (same as processor). 50% off -> $190K, support $41.8K/yr. Either way, the cost was similar because the user count was high relative to Oracle’s minimums.
  • Full Use Model: If the customer had to buy full-use licenses themselves, at least it’s $380,000 for eight processors. Even if they negotiate 20% off with Oracle, that’s $304,000. Support 22% of $304K = $66,880/yr. Over 5 years, that’s $304K + $334K in support = $638,000 total spend to use Oracle for that application. Compare that to ESL’s one-time $38K (no support) or ASFU’s $190K + support (which over 5 years might total ~$190K + $209K = $399K). ESL is the cheapest, ASFU is in between, and full use is the most expensive.

Key insight: An ISV can make their solution far more affordable by negotiating the right model and discount. Enterprise customers should appreciate these differences: a solution priced at $500K that includes an ESL Oracle license might save them a huge Oracle bill versus if they had to do it themselves.

Conversely, if a vendor isn’t offering much discount on an ASFU (or is charging you the list price for Oracle within their price), you might negotiate that, knowing Oracle likely gave them 50% off, which means there is room for the ISV to pass savings on to you.

Transparency can be tricky here, but savvy customers will sometimes separate the cost: “How much of your price is for Oracle licenses?” and then deal with that portion knowing the market rates.

Ensuring Favorable Terms in ISV Oracle Contracts

Finally, some general negotiation best practices to wrap up:

  • Engage Oracle Contract Specialists or Advisors: Oracle’s licensing and business practices are complex. If you’re an enterprise negotiating directly with Oracle for an ISV deal (or an ISV negotiating your partner agreement), consider consulting an Oracle licensing expert or attorney familiar with Oracle contracts. They can spot non-obvious risks (like partitioning rules, compliance traps, etc.) and suggest better wording.
  • Total Cost of Ownership View: Don’t fixate only on the initial discount. Look at 5+ year total cost, including support, potential true-up costs if you exceed some metric, and worst-case compliance costs. Negotiate to minimize those: e.g., cap the price of additional licenses if you need more in the future (perhaps your agreement can lock the 90% discount for 3 years so Oracle sales can’t renegotiate each time you need more licenses). For support, try to cap annual increase (Oracle usually has a 0-4% increase cap in their policies – ensure your deal follows that, so they don’t hike support exorbitantly later).
  • Document Everything: If Oracle reps make verbal promises (e.g., “We typically won’t audit for that” or “We’ll allow that usage”), get it in writing in the contract or an official email/letter. Oracle’s contracts count in an audit or dispute. The same applies when negotiating with an ISV vendor – ensure the contract you sign reflects any concessions or understandings you reached in conversation.
  • Be Willing to Walk (or Escalate): Oracle deals can sometimes stall if the rep isn’t meeting the discount or terms you need, you’re dealing with. Don’t be afraid to escalate within Oracle – engage your Oracle account manager or even higher-ups, especially if your product could bring significant future Oracle business. If you’re a customer dealing with an ISV, be prepared to push back on the ISV’s quote by involving Oracle if needed (as a tactic, sometimes customers say, “We might just license Oracle ourselves under our enterprise agreement,” which can prompt the ISV to come back with a better embedded license deal rather than lose the sale).
  • Legal Review of Oracle’s Policies: Ensure you (or your legal team) review Oracle’s standard Oracle License and Services Agreement (OLSA) or whatever contract will govern the licenses. Even in embedded scenarios, the ISV’s contract with Oracle will mirror what the end user can or cannot do. Look for any unusual clauses. For instance, Oracle’s cloud or virtualization policy – if your solution will run on VMware, Oracle’s stance could make you license all physical hosts. If that’s relevant, negotiate a solution (like using Oracle-approved hard partition tech, or a clause that limits your obligation). These technical licensing policy points can be huge; they might dictate your architecture choices. Bring them up during negotiation to avoid a scenario where you inadvertently agree to something that complicates your deployment later.

By focusing on these aspects during negotiations, both ISVs and enterprise customers can ensure maximum value from Oracle licensing arrangements while avoiding common pitfalls that lead to inflated costs or compliance problems.

Recommendations

For strategic negotiations involving Oracle ESL, ASFU, or PAH licenses, consider the following advice:

  • Do Your Homework: Before negotiating, research Oracle’s price lists, typical discounts, and policies. Know that ESL can get ~90% off and ASFU ~50% off, so you have benchmarks in mind.
  • Choose the Right Model: Align the licensing model (ESL vs. ASFU vs. PAH) with your business case. Negotiate with Oracle for the model that best balances cost and flexibility; they might steer you one way, but ensure it fits your needs.
  • Negotiate Beyond Price: Scrutinize contract terms like usage definitions, audit rights, and termination clauses. Sometimes, a slightly higher price is worth it if you gain much better terms (e.g., a broader usage clause or a cap on future costs).
  • Maximize Discounts and Lock Them In: Push for the maximum discount or lowest royalty rate possible, and try to lock that rate for future expansions. If you expect to grow, ensure your deal scales (e.g., no need to re-negotiate pricing every year).
  • Address Support Costs Upfront: Decide if Oracle support is needed in your scenario. If not, negotiate the ability to forego it (especially under ESL). If yes, ensure support fees are based on discounted prices and consider multi-year support discounts or caps on increases.
  • Opt for Simplicity: A complex licensing scheme can lead to mistakes. Negotiate for simpler models where possible. For example, if you can license per processor instead of tracking hundreds of users across clients, that simplicity can prevent costly compliance errors later.
  • Protect Your Interests in Writing: Ensure all negotiated points are captured in the final agreement or an amendment. For ISVs, that means the Oracle Partner agreement and ordering documents. That means the contract or SOW with the ISV detailing the licensing responsibilities for enterprise customers.
  • Consult Experts for Big Deals: In major negotiations (enterprise-level agreements or OEM deals), bring in Oracle licensing specialists or advisors. The cost of advice is small compared to potentially paying millions more due to a bad term.
  • Plan for “What-If” Scenarios: Negotiate considering future scenarios: What if your product usage spikes massively (can you get more licenses at the same rate)? What if Oracle changes its policies? What if your customer wants to move to cloud X? Try to include flexible provisions or at least an acknowledgement of these possibilities to avoid being stuck later.
  • Maintain a Strong Vendor Relationship: Finally, remember that negotiation is part of a longer relationship with Oracle (and your customers). Aim for a win-win: you want Oracle to feel invested in your success (so they’ll support you with good terms ongoing), and you want your customers to get a fair deal that makes them comfortable choosing your Oracle-powered solution. A constructive negotiation sets the tone for that partnership.

FAQ

Q1: Oracle offers me an ESL deal with an 80% discount. Can I negotiate it to 90% or more?
A1: Yes, Oracle’s ESL discount is negotiable, especially if your product could drive significant Oracle usage. Many ISVs have secured around 90% of Oracle’s list prices for ESL deals. Come prepared with justification: projected volume of licenses, how including Oracle will expand Oracle’s market presence, etc. Oracle might have tiers (e.g., 80% standard, 90% for strategic). If they resist, consider offering something in return, like a commitment to a certain license volume or a success story reference. Also, ensure you’re talking to the right level of Oracle management – sometimes higher approval is needed for >80% discounts.

Q2: What is the typical percentage in a royalty model, and can I cap my payments to Oracle?
A2: Royalty percentages can vary widely (from single digits up to maybe 20% of your license revenue, depending on the value Oracle provides in your solution). Something like 10-15% of your software license fee might be typical for a critical database, but not the only component. Yes, you can negotiate caps or tiers. For example, 15% of revenue until $X is reached, then 10% thereafter. Or an absolute dollar cap per year (which might be hard to get, but you could negotiate a cap for effective discount – e.g., “royalty will not exceed what an equivalent 90% discounted license cost would be for that usage”). The key is aligning the royalty so it doesn’t affect your profits as you scale. Always model worst-case: if you sold far more than expected, can you live with that percentage going out to Oracle?

Q3: In my agreement, how do I decide between licensing per processor or per user (NUP)?
A3: It depends on your solution’s deployment and pricing model. Choose the metric that most closely follows how you charge your customers. Licensing Oracle per user (NUP) may align costs to revenue if you charge per user. But watch out for Oracle’s minimums and the fact that “Named User Plus” counts all individuals who use the software (no concurrent licensing concept – every named individual or device counts). NUP could cost more due to minimums if your typical deployment is on heavy servers with relatively few users (like 100 users on a 16-core machine, as in our example). Processor licensing is simpler for broad or unlimited user scenarios. You can also negotiate a custom metric with Oracle – occasionally, Oracle might allow “per application instance” licensing or other creative metrics in an ISV deal, but that’s less common now. It usually boils down to processor vs NUP. Do the math for small, medium, and large customer scenarios and see which metric yields a lower cost in each, then negotiate for the metric that is consistently advantageous or at least not ruinous in the worst case.

Q4: We’re an ISV. Can we bundle Oracle Database Standard Edition instead of Enterprise Edition to save money?
A4: Possibly, yes. Oracle Database Standard Edition (SE2) has a lower list price and different licensing rules (licensed per socket up to certain limits, and no NUP minimums like EE). If your application doesn’t need Enterprise Edition features or will run on servers within SE2’s limits (max two sockets, and SE2 will use at most 16 threads), using SE2 under an ESL or ASFU could drastically cut costs. Negotiate accordingly – the 90% discount can apply to the Standard Edition’s lower price. Just be mindful: SE2 has no extra cost options but lacks partitioning, advanced performance features, etc. Ensure it meets your technical needs. However, this is a clever way some ISVs optimize: develop on Oracle SE2 to avoid the massive cost of EE. Oracle is usually fine if the use case fits SE2’s licensing constraints. So, discuss the edition during negotiations and lock down which edition (or both) you’re allowed to deploy.

Q5: As a customer, how can I ensure I’m not overpaying for the Oracle component when I buy from an ISV?
A5: This can be delicate, since ISVs often wrap the cost into their product price. However, you can request a breakdown or at least some transparency. Ask the vendor: “Is there an Oracle license included, and if so, is its cost separate or embedded in your fee?” You can also compare options: if the vendor offers a BYOL option (use your own Oracle license), get pricing for that versus including Oracle. You might negotiate that difference if they charge significantly more for the Oracle-included version than what you estimate Oracle licenses should cost (given known prices/discounts). Many enterprise procurement teams will negotiate a discount on the overall solution anyway – just ensure that Oracle fees don’t negate any such discount. Sometimes, you can leverage your Oracle relationship: e.g., tell the ISV, “We have a good discount with Oracle, maybe we can use our licenses” – this might prompt the ISV to reduce their price rather than complicate the deal. In short: do independent research on Oracle pricing (list prices are public; your Oracle rep can tell you, or consultants) and use that knowledge in the negotiation to avoid an excessive markup on the embedded licenses.

Q6: Should I watch for “hidden” costs in Oracle ISV agreements?
A6: A few potential hidden costs/pitfalls include: support indexation (Oracle’s support renewal cost can increase annually – ensure it’s capped at 3-4% or CPI), byte density or multiplexing rules (Oracle doesn’t allow you to reduce user counts via multiplexing, e.g., if your app uses a service account to connect to Oracle, you might still need to count end users behind it; clarify how user counting will work to avoid a surprise that Oracle demands licenses for all end users even if indirectly connected). Also, for testing and development licenses, if you’re an ISV, your agreement might not automatically cover your internal dev/test environments. Negotiate some free or low-cost licenses for those purposes; otherwise, you might inadvertently be out of compliance using production licenses for testing. For PAH, watch for cloud deployment costs – Oracle’s policy for authorized cloud environments might count vCPUs differently (e.g., 2 vCPUs = 1 Oracle processor for AWS/Azure as per Oracle’s cloud licensing rules). If you host on a public cloud or negotiate special terms, ensure you account for that. All these are details to iron out in the contract.

Q7: How long are Oracle ISV agreements valid, and do prices change when renewing?
A7: Typically, an Oracle partner licensing agreement (ESL/ASFU) might be a multi-year term (e.g., 3 years, aligned with OPN membership terms). Some are evergreen, with annual cancellations possibly made by either party. It’s important to clarify the duration. If there’s a term, clarify what happens at renewal; Oracle may reserve the right to adjust discounts or terms. You should negotiate a renewal clause that fixes certain terms or gives you enough notice to adjust. Ideally, you want continuity for existing customers: ensure any already distributed licenses remain valid perpetually for those end users, even if the agreement lapses (usually the case). As for pricing, Oracle might try to renegotiate if your volume is much lower than expected. Try to avoid a clause that automatically re-prices based on volume shortfall. Lock in the discount in the initial term. If you perform well, it’s unlikely Oracle will raise prices on you in renewal – they wouldn’t want to jeopardize ongoing business – but it’s not guaranteed. Thus, plan to renegotiate or shop around (though for databases, there’s no direct replacement to go to if you’re locked into Oracle tech).

Q8: We want our customers to choose between Oracle and another database. Can Oracle still give us an ESL deal if Oracle is optional in our product?
A8: Oracle’s big discounts often assume you’re committing to use Oracle as the embedded database in most or all deployments. If you present it as “Oracle is just one option,” they might not grant the highest discount because there’s no guaranteed volume. To negotiate in this scenario, you could present projections of how many customers you expect on Oracle vs others, and perhaps agree to a smaller discount that could increase if adoption grows. Or, you might consider a pool of funds agreement: e.g., buy a chunk of Oracle licenses at 85% off to use as needed, and if you use them all, get more at that rate. Oracle will try to convince you to standardize on them (for obvious reasons). If your strategy is multi-database, you might not get as favorable terms as a pure Oracle shop, but you can still negotiate a workable arrangement. From a customer perspective, if an ISV offers multiple databases, sometimes they charge extra for the Oracle version – customers should weigh the performance/features of Oracle vs that cost. It may be negotiable as well.

Q9: Can I negotiate my contract’s “10-day rule” or other specific policies?
A9: Typically, Oracle’s standard policies (like the failover 10-day rule or the requirement to license all processors in a cluster, etc.) are not explicitly detailed in ISV contracts – they refer to Oracle’s standard licensing rules. You generally cannot change those universal policies via your ISV agreement; Oracle doesn’t usually create a unique policy just for one partner. However, you can sometimes get clarifications or acknowledgments in writing. For example, suppose your product requires a high-availability setup. In that case, you might get Oracle to acknowledge that a secondary server will be used for failover and clarify how it must be licensed. They might restate the 10-day rule or agree to treat a standby differently if you incorporate it into the royalty calculations. It’s worth discussing during negotiation so you have mutual understanding. For things like virtualization, Oracle likely won’t bend (they won’t, for instance, allow soft partitioning exceptions in a contract), so instead you negotiate your deployment approach (maybe use Oracle Linux KVM with hard partition, which Oracle accepts, rather than VMware if you want to reduce licensing scope). In summary, you can’t easily change the rules, but you can negotiate how to comply cost-effectively and ensure the contract doesn’t counter those strategies.

Q10: What if Oracle changes its licensing programs or discontinues ESL/ASFU? How to protect our company?
A10: Oracle’s licensing programs have evolved (for example, they have replaced generic hosting with PAH). In your contract, you could include a clause that if Oracle discontinues the specific program, you get a reasonable transition period under the old terms or automatically transition to the most equivalent new program without losing your discount. Getting Oracle to commit too far into the future is hard, but having a line about “Oracle will use good faith to provide a comparable alternative” is better than nothing. Also, focus on securing perpetual usage rights for what you distribute, so existing customers are safe even if the program ends. If you’re an enterprise customer, ensure that if the ISV’s arrangement changes, it doesn’t suddenly burden you with new requirements. Usually, the ISV would absorb any changes mid-contract. Keep an eye on Oracle announcements and maintain a dialog with Oracle as a partner/customer so you can anticipate changes. Ultimately, having flexibility (and not over-committing to buying a huge number of licenses upfront that you might not use if things change) is wise. Negotiate in manageable increments and revisit as needed rather than locking yourself into something inflexible for 10+ years.

Do you want to know more about our Oracle License Management Services?

Please enable JavaScript in your browser to complete this form.
Name

Author

  • Fredrik Filipsson

    Fredrik Filipsson brings two decades of Oracle license management experience, including a nine-year tenure at Oracle and 11 years in Oracle license consulting. His expertise extends across leading IT corporations like IBM, enriching his profile with a broad spectrum of software and cloud projects. Filipsson's proficiency encompasses IBM, SAP, Microsoft, and Salesforce platforms, alongside significant involvement in Microsoft Copilot and AI initiatives, improving organizational efficiency.

    View all posts