Not every Oracle license is the same license. Full use, ASFU, embedded, hosting, and term are five species with five different sets of rights, often at very different prices. This session teaches the grant language that separates them, the access paths each one permits, the migration economics between them, and prices the same database four ways to show what the words are worth.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the BI tool connected to an embedded database (the classic species breach), the ASFU to full use migration decision, and the hosting versus internal business operations boundary. It closes by pricing the identical database under four different grants, from full list to a fraction of it, so the value of the words is a number, not a feeling.
The full narration of this session, section by section, for reading and reference.
Welcome back, session seven of forty. Last session you learned to read the contract stack. Today we zoom into the licenses themselves, because here's a fact that surprises almost everyone: Oracle sells the exact same software under five completely different kinds of license. Same installer, same binaries, wildly different rights. Full use, application specific, embedded, hosting, and term. The species, as I call them. And your estate almost certainly holds at least three, whether anyone knows it or not, because two of the five arrive through vendors, not through Oracle. Session five's restricted use grant was a preview. Today is the full taxonomy, and by the end you'll add a species column to your entitlement library that closes an entire class of audit findings. Three knowledge checks, all from real audit reports. Let's meet the species.
Five takeaways today. One, you'll name the species on sight: full use, ASFU, embedded, hosting, and term, and know which paper each one arrives on. Two, you'll read grant language properly, there are four scope markers that appear in every grant, and once you can spot them, any license definition takes about a minute to decode. Three, you'll check boundaries, which access paths and workloads each species actually permits, because that's where the findings live. Four, you'll learn the migration paths between species and their economics, including the timing rule that decides whether a migration costs a negotiation or a fortune. And five, you'll classify your own estate, one new column in the library from session six. That column is an afternoon of work and it prevents the single most common class of contract findings. Here's why the species matters so much.
Four numbers. Five, the license species in a typical enterprise estate. Most licensing conversations assume everything is full use. It never is. One, the number of named applications an ASFU license may support. One. The name is printed on the paper, and everything else that touches that database is unlicensed, no matter how naturally it accumulated there. Roughly twenty percent, what a term license costs per year against perpetual list. Sounds cheap, and it is, for genuinely temporary work. Run it past year five and you've paid full price for software you still don't own, and when the term lapses, the right to run it ends entirely. And zero dollars. That's the worth of any restricted license outside its scope. A million dollars of embedded licenses buys exactly nothing the moment you connect to them directly. The species decides the value, and here's the mechanical problem underneath all of it: the software runs identically under every species. Nothing in the product enforces the paper. Which means the only enforcement mechanism is the audit, and the only defense is knowing your species before they check.
The taxonomy, five cards, sorted from widest rights to narrowest, and watch the price fall as the scope narrows, because that's the actual trade. Species one, full use. Bought from Oracle directly, at price list prices, module one's arithmetic. Any application, any internal use. The reference species. Species two, ASFU, application specific full use. You bought it from an ISV, bundled with their product, at a real discount. The catch is in the name: it serves that named application, and nothing else, forever. Species three, embedded, the deepest restriction. The database is buried inside a vendor's product, you may not even know it's Oracle, and the deal is total invisibility: no direct access of any kind, ever, in exchange for the deepest discount on the list. Species four, hosting grants, the rights to serve third parties from your systems. These are negotiated separately, because, critical point coming later, the standard grants cover internal use only. And species five, term licenses, full rights with an expiry date, now mostly one year terms. Here's the practical kicker: the species is printed on your ordering documents, usually in one sentence, and most estates have never once looked. Today, you look.
The species side by side, and read this table as a set of trades. Full use: Oracle sells it, anything internal runs on it, and you pay full price plus support forever. Wide rights, full cost. ASFU: the ISV sells it with their application, meaningfully discounted, and the named application is the entire universe of what it covers. Repurposing it, even slightly, is unlicensed use. Embedded: the ISV sells it invisibly inside their product, cheapest of all, and any direct access, one query, one connection, breaches the scope. Hosting: negotiated with Oracle when you need to serve third parties, because nothing else on this table allows that. And term: Oracle sells it, full internal rights, until the date on the paper, after which continuing to run it is unlicensed from that day forward. Notice the recurring audit logic, it's session five's test generalized: list what actually touches the software, compare it against what the grant permits, and price the gap at list. That test works on every restricted species, and Oracle's auditors run it fluently. The first knowledge check is the most common way it catches people.
Knowledge check one. Your ERP vendor's product includes an embedded Oracle database, that's how it was sold, database included. Your BI team connects Tableau directly to that database to build reports. Licensed? A, yes, the database came licensed with the ERP. B, no, embedded licenses allow access only through the vendor's product, and direct connections need full use licenses. C, yes, as long as Tableau only reads data. Or D, yes, if fewer than twenty five people use the reports. Pause here, and think about what the word embedded restricts.
The answer is B. The embedded license's entire bargain is invisibility. That database exists to serve the vendor's product, full stop, and the moment anything on your side touches it directly, the deal is off, the deployment needs full use licenses, priced at list, cores times factor, module one style. Now the wrong answers, because each one is argued in real audits. A is true right up until the Tableau connection, the database did come licensed, for exactly one purpose. C, read only, fails because access is access, the grant restricts the path, not the verb. And D imports session two's NUP minimum into a question that has nothing to do with metrics, there's no user count that launders a scope breach. Here's why this finding is everywhere: the connection works. The database doesn't know it's embedded, Tableau doesn't ask, and the reports are genuinely useful. Everything functions beautifully right up until the audit reads the paper. The software never enforces the license. That sentence is the whole session.
So let's learn to read the grants themselves. Four scope markers, and at least one appears in every license definition you hold. Marker one, internal business operations. The standard full use scope. Your business, your operations, and, crucially, not a service you sell to others. Flag that phrase, the last knowledge check today lives on it. Marker two, the named application. ASFU grants name the ISV's product, precisely, sometimes down to the version. That name is the scope. New integrations, side workloads, replacement apps, all outside it. Marker three, the access path. Embedded grants restrict how the software may be reached: through the vendor's product, and never directly. Knowledge check one was this marker in action. And marker four, the clock. Term grants carry an end date, and here's what people miss: on that date, the license ends. Not the support, the license. The right to run the software at all. An expired term license still running is unlicensed software, backdated to the expiry. Four markers. When you do this week's homework, you're hunting for exactly these four phrases on your own paper. Now, what happens when your needs outgrow a species. Knowledge check two.
Knowledge check two. You hold two hundred thousand dollars of ASFU licenses that came with your ERP. The ERP's database is healthy and has capacity, and the team wants it to also serve a new custom application. What's the legitimate path? A, just deploy it, it's the same database either way. B, migrate the ASFU to full use through Oracle, or buy full use licenses for the new workload. C, ask the ISV for permission. Or D, nothing needed, if both applications share one server. Pause here. Who granted the ASFU scope, and who can widen it?
The answer is B, widen the license before you widen the workload. ASFU scope is fixed by the paper, and only Oracle sells the wider right. The good news is there's a standard path: ASFU to full use migration, typically priced around the difference between what you paid and full use list, and, like everything with Oracle, most negotiable when it's bundled into a bigger conversation. Now the wrong answers. A is the finding itself, and it's how this always happens, not through malice, but because the database is right there with capacity to spare. C misunderstands ownership: the ISV sold you their slice of Oracle's rights, they cannot widen Oracle's grant any more than a tenant can sell the building. And D, the same server argument, is the hardware fallacy making its third appearance in this course: physical arrangements never substitute for license scope. The rule to keep: plan the species before the workload deploys. Which brings us to the migration economics, because timing is everything here.
The migration paths, four facts. Path one, ASFU to full use. Standard, well trodden, negotiable. Priced near the list difference, and cheapest when folded into a larger deal where Oracle wants your signature anyway, remember that pattern, session eight is entirely about it. Path two, embedded to anything, and here the news is worse: it's effectively a repurchase. The embedded discount was the deepest, so the credit for what you paid is smallest. If a workload might ever need direct access, embedded was the wrong species on day one, which is a purchasing lesson, not a licensing one. Path three, term to perpetual. Technically possible, rarely at good math. If the workload is permanent, buy permanent. Term licenses are for genuinely temporary things: migrations, pilots, bridge capacity. And fact four, the timing rule, the most important sentence today: every migration is cheapest before the new workload exists, and most expensive when an audit finds it already running. Same list prices, opposite leverage. Before deployment, you're a customer planning a purchase. After discovery, you're a finding being settled. The entire value of today's taxonomy is making sure you're always the first kind.
The classification method, five steps, building directly on session six's library. Step one, tag the species. Every license line in the library gets one of five tags: full use, ASFU, embedded, hosting, or term. The information is on the ordering documents you've already gathered, it's usually one sentence per line. Step two, map the scope. For every restricted line, write the named application and the permitted access path right next to it. Now the restriction is visible instead of buried. Step three, check reality. For each restricted deployment, what actually runs on it and connects to it? This is the honest inventory, and BI tools are where you look first, because that's where the surprises are. Step four, flag the clocks. Term end dates go into the renewal calendar now, while they're planning items instead of emergencies. And step five, plan the widenings. Any workload growing beyond its species gets a migration plan before it deploys, priced at customer leverage, not finding leverage. Total effort: an afternoon against the library you already built. Return: the most common class of contract findings, closed. Now the traps, so you recognize them in the wild.
Five species traps, all real, all common. Trap one, the BI tool on the embedded database. Knowledge check one, running in production at companies everywhere, because the connection works and nobody asked whether it was allowed. Trap two, the repurposed ASFU. The ERP's database quietly becomes the company's database, one helpful integration at a time, until the named application is a minority of what it serves. Trap three, hosting on internal grants, a product team ships a customer facing service on licenses scoped to internal business operations. Hold that one, it's the final knowledge check. Trap four, the expired term. The project ended, the renewal lapsed, the software kept running, and every day since expiry is unlicensed use with a clean paper trail proving exactly when it started. Calendar discipline is the entire fix. And trap five, the orphaned ISV. The vendor who sold your ASFU got acquired or disappeared. The restriction survives on your paper regardless, but your migration path just lost its negotiating partner, and untangling it takes longer. Check your restricted sellers while they still answer the phone. Alright, the hosting question, and this one matters enormously if your company builds products.
Knowledge check three. Your product team wants to launch a customer facing SaaS service, built on your existing full use database licenses. Plenty of capacity, licenses fully paid. Licensed? A, yes, full use means full use. B, no, full use covers internal business operations, and serving third parties needs hosting rights, negotiated separately. C, yes, if customers never connect to the database directly. Or D, yes, if you buy enough named user licenses for the customers. Pause here, and re-read the four scope markers. Which one governs this?
The answer is B. Full use is the widest internal species, but the operative word is internal. The grant says internal business operations, and a commercial service you sell to third parties sits outside that sentence, no matter how much capacity you own. The fix exists: hosting rights are negotiable, on your timeline, before launch. What doesn't work: A treats the species name as unlimited, and it never was. C is the multiplexing fallacy from session two wearing a new costume, indirection has never once laundered scope in this course and it doesn't start now. D buys user licenses to solve a grant problem, wrong tool entirely. Here's why I put this question last: it's the trap with the biggest ceiling. A BI tool on an embedded database is a finding. A revenue generating product built on out of scope licenses is a business risk, discovered at the worst possible moment, usually during diligence for funding or acquisition. If your company builds anything customer facing on Oracle, the homework's fourth item is not optional. Let's close with the money view.
One last table, our faithful eight license database, priced under four species, and this is really a purchasing guide in disguise. Full use: three hundred eighty thousand at list, plus twenty two percent support, forever, and it may run anything internal until the end of time. The default, and correctly so, for the general estate. ASFU: meaningfully below full use, through the ISV's deal, and perfect, genuinely perfect, for a single purpose application estate that will never grow sideways. Embedded: the deepest discount on the page, invisible inside the product price, and the right answer for appliance style deployments nobody will ever touch directly. And term: around seventy six thousand a year, the right answer for a workload with an actual end date, a migration bridge, a one year project, and the wrong answer for anything permanent. Four prices, identical software. The discount, every time, is the scope you surrendered. So the closing question for every quote that ever lands on your desk: what did this paper take away? If the answer matches what the workload will actually need, forever, take the discount. If there's any doubt, the widest species is the cheapest insurance you'll ever buy.
Session seven in three sentences. One, identical software ships under five different grants, and the price difference is exactly the scope difference: what may run, who may access, and for how long. Two, restricted species fail silently, the software never enforces the paper, which is why the embedded database with a BI tool attached is a permanent fixture of audit reports. Three, classify once, tag every line's species in the library, and plan every widening before the workload deploys, because migrations price by leverage, and leverage belongs to whoever moves first. Next session is the one everyone's been waiting for: the money. How Oracle actually prices and discounts, what strong outcomes look like by deal size, quarter end dynamics, and how to know whether your deal is actually good or just felt good in the room. Bring your discount percentages from the session six homework, because we're going to benchmark them. See you in session eight.
Homework, about an hour, and it finishes what session six started. One, tag your library. The species column: full use, ASFU, embedded, hosting, or term, for every line. The scope sentences are on the orders you already gathered. Two, find your restricted sellers. Which ISVs sold you ASFU or embedded licenses, and are they still in business, still independent, still answering? Their status affects your migration options. Three, check one access path. Pick your most important restricted database and ask infrastructure what actually connects to it. Start with BI tools, because that's where knowledge check one lives in real life. Four, and this one jumps the queue if it applies: if any product your company sells runs on Oracle, read the grant scope this week. Not next quarter. This week. The words you're looking for are internal business operations, and what you're checking is whether your revenue sits inside them. And five, flag the clocks. Any term licenses anywhere? End dates into the calendar today. That's the hour. Next week, we talk money. See you there.
Five reads, all free on redress compliance dot com. First, how to check your Oracle license position, the entitlement methods from session six, now with species eyes. Second, hidden Oracle audit risks, where the embedded access and repurposed ASFU findings sit in the wider landscape. Third, challenging Oracle audit findings, how scope disputes actually resolve, useful context for the migration timing rule. Fourth, field tested Oracle negotiation strategies, where migration deals fit inside larger negotiations, a preview of next session's territory. And fifth, the Oracle vendor management guide, keeping the species discipline alive between renewals so the classification you build this week doesn't decay. That's session seven. Five species, four scope markers, one timing rule, and a library that now knows what kind of licenses it holds. Next time, the discounting session. See you there.