Oracle ASFU License Model – Learn About The Limitations

What is an Oracle ASFU License?

• What is it? The Oracle ASFU (Application Specific Full Use) license is a resellable model for Oracle OEM partners.
• How can it be used? ASFU licenses are specifically designed to be used with third-party applications.
• What’s the cost? Oracle offers heavy discounts on the ASFU license model. (60 %+)
• Need Oracle Technical Support? You must use the Independent Software Vendor (ISV) for Oracle support.
• What about audits? With the ASFU license model, end customers are not liable for Oracle audits related to license compliance.

Oracle’s software licensing can be complex, with multiple license models designed for different scenarios. One such model is Oracle’s Application Specific Full Use (ASFU) license.

This guide explains an ASFU license’s function and comparison to other Oracle license types in plain business language. It also provides practical tips for buyers, legal teams, and stakeholders on making informed decisions about ASFU licenses.

What is an Oracle ASFU License?

Oracle ASFU (Application Specific Full Use) is a special type of Oracle license sold through independent software vendors (ISVs) or OEM partners, typically at a significant discount (often 60% or more off list price).

Unlike a standard Oracle license you’d buy directly, an ASFU license is bundled with a specific third-party application.

In other words, the license only allows Oracle software (such as an Oracle Database or middleware like WebLogic) in conjunction with a particular vendor’s application. The end customer (business) is the license owner, but the usage is contractually tied to the vendor’s solution.

Key characteristics of ASFU licenses:

• Sold via ISVs/OEMs: An Oracle partner (the ISV) purchases the ASFU license from Oracle and resells it to you as part of their software package. You, the end customer, appear as the license owner even though you obtained it through the vendor.
• Restricted Use: The Oracle software can only be used with the specific application you bought. For example, suppose you buy a payroll system that includes an Oracle Database under an ASFU license. That database can be used only for that payroll system’s operations, not for any other purpose or other applications.
• Heavy Discount: Oracle heavily discounts ASFU licenses (often ≥60% off regular pricing) to the ISV. This makes the overall solution cost lower for the end customer than buying a full Oracle license separately.
• Support via Vendor: If you need technical support for Oracle software, you should contact the ISV (application vendor), not Oracle. The ISV is responsible for first-line support and will interface with Oracle as needed. (Oracle charges the ISV a reduced support fee of ~19% of the license price for this arrangement.)
• Audit Liability on Vendor: Oracle will not audit you (the end customer) for compliance with the ASFU licenses. Instead, Oracle can audit the ISV that provided the license. If there’s non-compliance with the license, the ISV – not your company – is on the hook.

These features make ASFU licenses appealing when buying enterprise software solutions: you get Oracle technology baked into a product at a lower cost and with simplified support/audit obligations.

However, the trade-off is the strict limitation that the Oracle software can only be used as part of that specific solution.

How Does ASFU Licensing Work?

In an ASFU licensing model, there’s a three-party relationship: Oracle, the ISV (Independent Software Vendor), and you (the end customer). The process works as follows:

Diagram: Oracle sells discounted ASFU licenses to an ISV partner, who bundles it with their application and resells to the end customer. The Oracle software (e.g., Database) is licensed only within the vendor’s application.

1. ISV Partnership: The vendor developing the application becomes an Oracle partner (part of the Oracle PartnerNetwork) and signs a distribution agreement with Oracle to offer Oracle software licenses with their product. Oracle grants them the right to resell licenses under the ASFU model.
2. Oracle Sells to ISV: The ISV purchases Oracle licenses in bulk or on demand under ASFU terms, at a steep discount. The ISV might choose a licensing metric (e.g., per processor or user) similar to standard Oracle licenses, or opt for a royalty model where they pay Oracle a percentage of their sales instead of counting users/processors.
3. ISV Sells to Customer: You, the customer, buy the ISV’s software solution. The ISV provides the necessary Oracle software (database, etc.) under an ASFU license as part of that purchase. The cost for that license is usually embedded in what you pay the vendor. You get paperwork showing you as the license owner, but with ASFU usage restrictions attached.
4. Usage and Support: You deploy the vendor’s application, and the included Oracle software is installed alongside it. All usage of Oracle is governed by the ASFU terms, meaning it should be exclusively for that application’s functionality. If you need support on the database or Oracle component, you can contact the vendor, who may have their support team and a backchannel to Oracle if needed.
5. Audits and Compliance: Oracle’s contractual relationship for that license is primarily with the ISV. Oracle may audit the ISV to ensure they correctly sell and manage those licenses. As the end user, you are generally not directly audited by Oracle for that ASFU component, as long as you haven’t misused it beyond the agreed scope.

Real-world example: Many SAP enterprise customers run an Oracle Database under an ASFU license that comes with their SAP software. In this case, the database is licensed only for use with SAP.

The customer benefits from a lower-cost Oracle DB license bundled with SAP, which (as the ISV) supports the database. However, if the customer later decides to use that Oracle database for a different application or custom development, they would violate the ASFU terms.

To repurpose it, they’d need to contact Oracle (usually via the vendor) to upgrade the ASFU license to a full-use license for a fee.

Oracle ASFU License Terms

Below is a screenshot of the ASFU Oracle license terms  (Oracle Distribution agreement). You can find copies of this publicly available:

Oracle ASFU licenses come with specific terms and conditions that limit how they can be used:

• Specific Use: The ASFU license can only be used with the specific software solution or application defined in the agreement. For instance, if an ISV builds an application that uses the Oracle Database, the license only allows that application to use the Oracle Database.
• Integration Limitations: Oracle ASFU licenses can be used to integrate with non-Oracle applications. However, the connection must be made through an API provided by the ISV.
• Contractual Boundaries: Terms are clearly defined in a contract between Oracle and the ISV. The license is strictly limited to the ISV/OEM application for which it was acquired.

Example: Many SAP users use Oracle databases under ASFU licenses. These databases are strictly used for SAP operations, meaning they can’t be repurposed for other applications. However, users can migrate/upgrade their licenses to full use and reuse them for other applications.

Restrictions and Limitations of ASFU Licenses

By design, ASFU licenses come with strict restrictions to ensure the controlled use of Oracle software.

Here are the main limitations to be aware of:

• Tied to a Specific Application: An ASFU license can only be used with the specific application package named in the agreement. You cannot use the included Oracle software for any other purpose. For example, suppose your ASFU license is for an Oracle Database to support an HR system. In that case, you can’t build a reporting app or a new module outside the HR system that also uses that database, unless the data access is read-only (more on integration below).
• No Unrestricted Integration: The Oracle database or software under ASFU should not be freely integrated with other external applications. Direct connections from third-party software or custom scripts are typically disallowed. The only allowed external access is usually through published interfaces of the main application (for instance, via the ISV’s application API or a controlled ODBC/JDBC connection). This ensures you’re not bypassing the application and essentially using the Oracle software as a general-purpose database.
• No Custom Development on Oracle: You cannot develop new custom applications or add-ons that directly utilize the Oracle software (database, middleware, etc.) outside of the vendor’s application context. All usage must relate to the vendor’s solution. In practice, this means you shouldn’t create new schemas, databases, or extensive custom code on the Oracle platform unless it’s within the confines of the provided application.
• Data Usage Restrictions: Storing or processing third-party data (data from unrelated systems or for other purposes) in the Oracle database under an ASFU license is prohibited. The data in that database should be only what the sanctioned application uses. For example, you shouldn’t use the database to warehouse data for another system.
• Technical Deployment Constraints: Oracle software installation in an ASFU context is often tightly controlled. In some cases (especially similar models like embedded licenses), the database might be required to install in a silent mode with no user configuration and be managed only through the ISV’s application interface. While ASFU is a bit more flexible than a purely embedded license, you still may have limited direct access to administrative functions. Typically, all administrative tasks (like patching, user management, backups) should be done in coordination with or through the vendor’s tools, to avoid breaking the license terms.
• No Mixing of License Types: You should not mix ASFU licensed Oracle software with other licenses in the same environment. For instance, you shouldn’t let an Oracle ASFU database instance be accessed by another fully-licensed Oracle tool or vice versa, as it blurs the allowed usage boundaries. Doing so can create compliance issues (e.g., Oracle might consider it full-use if mixed). Keep ASFU deployments isolated to their specific purpose.

In summary, ASFU licenses lock down Oracle technology to a narrow, application-specific usage. Think of it as Oracle software on a short leash – it can do powerful things, but only within the allowed area.

The benefit is cost savings; the trade-off is loss of flexibility. If your business needs to use that Oracle software more broadly, you’ll likely need to convert it to a different license type (with additional cost).

ASFU vs Other Oracle License Types

Oracle’s ASFU model is just one of several licensing approaches.

Understanding how ASFU compares to other common Oracle license types, such as Full Use licenses, Embedded (ESL) licenses, and Oracle’s Partner Network (OPN) licenses, is helpful.

Each has different levels of usage freedom, cost, and obligations. Below is a comparison in plain terms:

ASFU vs Full Use License

A Full Use license is the standard Oracle license most businesses are familiar with – it allows you to use the Oracle software for virtually any purpose with no application-specific restrictions.

Here’s how ASFU differs from a Full Use license:

• Scope of Usage: An ASFU license is application-specific – it can be used only for the pre-defined application/use case. A Full Use license, on the other hand, lets you use the Oracle software for any project or application your business needs, without limitation. In other words, Full Use is unrestricted, whereas ASFU is restricted to one context.
• Pricing/Discount: Because of the usage limits, ASFU licenses are heavily discounted (often around 60 %+ off). Full Use licenses are sold at Oracle’s standard list prices (with maybe only standard volume discounts). So, Full Use is more expensive, reflecting its broader usage rights.
• Technical Support: With ASFU, support is provided by the ISV (vendor) as the first line – you typically do not deal with Oracle support directly. In contrast, a Full Use license usually includes the option to buy Oracle’s support services (typically ~22% of the license price annually), and you get support straight from Oracle’s support team. Some customers find vendor support for ASFU can be more tailored, but in other cases, it may be slower if the vendor has to escalate issues to Oracle.
• Audit Liability: If you’re using an ASFU license, Oracle will audit the ISV, not you, for license compliance (assuming you haven’t taken the Oracle software outside the allowed use). With Full Use licenses, your company is directly responsible for compliance and can be audited by Oracle’s License Management Services. In a Full Use scenario, if Oracle finds you out of compliance (e.g., using more processors or options than licensed), you must resolve it (often by purchasing more licenses or paying penalties). With ASFU, that direct audit risk is removed from your plate – it’s one of the vendor’s responsibilities (though you still must stick to the agreed usage).

Bottom line: Full Use licenses offer maximum flexibility but at a higher cost and direct accountability. ASFU licenses offer cost savings and simplified compliance at the expense of flexibility.

If you are sure an Oracle product will only ever be used for one specific solution, ASFU can be attractive. A Full-use license is the safer bet if you need the freedom to use Oracle technology for various purposes.

ASFU vs Embedded (ESL) License

Oracle’s Embedded Software License (ESL) is another license model often mentioned alongside ASFU. It’s even more restrictive than ASFU.

Here’s the difference:

• Visibility and Access: Oracle software (e.g., database) is deeply embedded in the ISV application and has an embedded license. End customers typically have no direct access to Oracle software at all. The database might operate in the background, and you, as the user, might not even realize Oracle is under the hood. You usually cannot log into or configure the database; all interactions happen through the vendor’s application interface. ASFU is less strict – you might have limited access to the Oracle admin console or database if needed (for example, to run a query or backup). However, you should not step outside the vendor’s application boundaries.
• Usage Restrictions: Both models limit usage to a specific application, but ESL tends to enforce this technically, for instance, requiring silent installation and no ability to use the database for anything else. ASFU, while contractually restricted, might not have the software technically locked down as tightly. The principle, however, is the same: ESL and ASFU are 1:1 licenses for a particular application at a particular customer. ESL is the more locked-down flavor (often described as “Oracle inside” a black-box solution).
• Support Requirements: A key difference is that Oracle technical support is not mandatory for ESL licenses, since the idea is that the ISV fully supports it. In ASFU, Oracle expects the ISV to be first-line support but still charges the ISV for support maintenance (which the ISV may bundle into what you pay). Practically, this means ASFU licenses always have an Oracle support stream via the partner, whereas ESL might not – the ISV could choose not to take Oracle support at all for an ESL deployment (and possibly handle everything themselves).
• Discount Level: Because of greater limitations, ESL licenses come with an even steeper discount (up to ~90% off list price). Oracle uses ESL to penetrate markets by making it very cheap for vendors to include Oracle in their products. ASFU discounts are typically big (50-65%) but not as high as ESL.
• Upgrade Path: Generally, ESL licenses cannot be upgraded or converted to Full Use. They are a dead-end street regarding license mobility—if a customer wants to start using Oracle outside the embedded app, they’d likely need to buy new licenses from scratch. ASFU at least offers a path: You can usually upgrade an ASFU to a Full Use license by paying the difference or a fee to Oracle (often negotiated via the ISV). This upgrade path provides some flexibility if your needs outgrow the original application.

In summary, an embedded (ESL) license is for when Oracle is completely behind the scenes with a solution, and the customer won’t touch it. ASFU is a middle ground – tightly bound to one solution, but the customer knows Oracle’s presence and has some rights/responsibilities.

Both save money compared to Full Use, but ESL saves the most (with the most restrictions).

ASFU vs OPN (Oracle PartnerNetwork) License Usage

It’s important to clarify the difference between an ASFU license and the Oracle PartnerNetwork (OPN) licenses that vendors might use during development or demos.

OPN is not a license type sold to customers, but rather a program for Oracle partners:

• Purpose: OPN licenses are free development and demonstration licenses that Oracle provides to its partners (ISVs) as part of the partner program. They allow an ISV to develop their application using Oracle software and show it to potential customers without incurring license fees, as long as they stay within OPN rules. ASFU licenses, by contrast, are what ultimately get sold for production use at an end customer’s site (with a fee).
• Limitations: OPN-provided licenses can only be used to develop or demonstrate a solution intended for multiple customers. They explicitly cannot be used for a production deployment for a specific customer or even for developing a one-off solution for a single client. Once an ISV has a paying customer and delivers the solution, they must transition to an ASFU or Full Use license for that deployment. Using OPN free licenses in a delivered solution is a violation (and Oracle audits do catch this). ASFU, on the other hand, is the proper license that covers a delivered solution for one customer.
• Internal Use: OPN development licenses cannot be used for the partner’s internal business operations (like running their company’s databases)—they’re strictly for building or supporting the partner’s product. ASFU licenses are not for the partner’s internal use but for the end customer’s use under restricted terms.
• Conversion to Sale: Think of it this way: an ISV might use OPN licenses while building and testing their software. But when they sell their software to you and include Oracle technology, that package will come with an ASFU license (or embedded license, etc.) as the formal license for use. If you hear a vendor mention they have an “OPN license,” it means they are an Oracle partner using Oracle software under partnership terms. Still, when you go live, you should ensure that your deployment will be properly licensed under ASFU or another appropriate model.

In short, OPN licenses are a tool for ISVs (free for development). In contrast, ASFU licenses are what end customers receive (paid, for production) when Oracle technology is part of a third-party solution.

The two shouldn’t be confused – OPN usage is a temporary/non-production state, and ASFU is the official licensed state for the product.

(Another related model is Oracle’s Proprietary Application Hosting (PAH) license, which is used when an Oracle partner hosts their application for multiple customers in a SaaS-like model. PAH licenses differ from ASFU because they cover one partner using Oracle in a multi-client environment (one license for many end customers).

In contrast, ASFU is one license per customer deployment. PAH is beyond the scope of this article, but is worth noting if your vendor offers a cloud service rather than on-premise software. If your product is worth $100,000, they may need to pay Oracle a fixed percentage of this as a royalty.

Pros and Cons of ASFU Licensing for Customers

When considering an ASFU license as part of a software purchase, weighing the benefits against the drawbacks is important. Here are the key advantages and disadvantages of ASFU from an end-customer perspective:

Pros of ASFU:

• Significant Cost Savings: ASFU licenses are much cheaper than full Oracle licenses – discounts of 50-70% are common. This means the overall solution you’re buying can be more affordable. You’re essentially getting enterprise-grade Oracle technology at a bargain price. For budget-conscious projects, this is a major upside.
• Bundled Convenience: The Oracle software comes packaged with the application. This one-stop solution can simplify procurement and deployment—you don’t have to negotiate with Oracle separately or purchase a database license; the vendor handles it for you. It also ensures the product works out-of-the-box with the included database or middleware since the vendor has optimized it.
• No Direct Audit Exposure to Oracle: Oracle’s license audits are famous (and sometimes infamous) in the industry. With ASFU, you, as the customer, are generally not directly subject to Oracle audits for that usage. Oracle will audit the vendor if anything. This can reduce your compliance anxiety – you likely won’t get an unexpected audit letter from Oracle about the embedded database in your purchased app. (Of course, you still need to follow the rules, because the vendor could be audited.)
• Vendor-Managed Support: You have one throat to choke – the vendor – for any issues. If the application has a problem, whether it’s in their code or the underlying Oracle database, the ISV’s support team is your contact. The ISV can often provide more specialized and integrated support since they understand how Oracle is used within the application context. This can simplify troubleshooting; you’re not caught between Oracle and the vendor blaming each other.
• Simplified License Management: Since the license is only usable for one purpose, there’s less risk of accidentally using Oracle in ways that violate the license. The scope is narrow and clear. You don’t have to track Oracle usage across your organization for this license – it’s confined to the one system.

Cons of ASFU:

• Restricted Flexibility: The biggest drawback is the lack of flexibility. You’re locked into using the Oracle software only for the vendor’s application. If your needs change – say you want to run analytics on the same database or repurpose the hardware for another project – you can’t do that with the ASFU license. You’d have to return to Oracle (likely via the vendor) to upgrade and pay more. This can be limiting if you like to maximize the use of your IT assets. You have a Ferrari engine under the hood, but you can only drive it on one specific track.
• Dependency on Vendor for Support: While having the vendor as the support contact can be a pro, it can also be a con if the vendor’s support is lacking. If the ISV doesn’t have strong database expertise or is slow to respond, you can’t go directly to Oracle for help (at least not without involving the vendor). You rely on the vendor to liaise with Oracle if there’s a deep issue. This could sometimes slow down problem resolution compared to having Oracle support directly available.
• Upgrade Costs and Complexity: If you ever need to convert the ASFU to a full-use license (for more freedom), there will be additional costs (license upgrade fees). These costs might be higher than if you had originally traditionally licensed Oracle, since Oracle knows you’re effectively removing a restriction, and they will charge for that. Also, navigating the upgrade might require contract changes or new purchase orders, which adds complexity to your licensing management.
• Limited Customization: You can’t customize or extend the Oracle environment beyond what the vendor’s application allows. For example, you might not be able to create new database users, schemas, or use certain Oracle features that aren’t used by the application (some options might even be contractually off-limits). If your tech team likes to tinker or optimize the database, they may find it frustrating that the license forbids them from doing so (unless explicitly allowed through the app).
• Vendor Lock-In: Because the Oracle license is tied to the application, it reinforces your lock-in to that vendor’s solution. If you ever consider switching to a different software, you can’t easily repurpose the Oracle license elsewhere. You might have a shelfware license or need to negotiate a transition. It’s not a standalone asset you control; it’s part of the vendor’s package.

To decide if an ASFU license is right, consider the long-term plans for the software and your Oracle usage. If the application is self-contained and you don’t foresee needing that Oracle software outside of it, ASFU’s cost savings are very attractive.

If there’s a chance you’ll want to do more with Oracle or you want more direct control, weigh that against the savings.

Practical Tips and Recommendations

Whether you are a licensing buyer, a legal reviewer, or a business stakeholder, here are some practical tips to navigate Oracle ASFU licenses effectively:

For Business Buyers / IT Managers:

• Ask the Right Questions Upfront: When purchasing a software solution with an Oracle ASFU license, ask the vendor exactly what you can and cannot do with the embedded Oracle software. Make sure you understand the limits. For instance, confirm that you can’t use that database for anything outside the vendor’s application. This clarity will prevent you from inadvertently violating terms later.
• Plan for the Future: Consider your future needs. If there’s any chance you’ll need to use an Oracle database beyond this application, discuss options with the vendor. Vendors may offer an upgrade path to a full-use license later, but it will cost extra. It might be worth negotiating future discounts or caps on that upgrade cost as part of the purchase. If the application is mission-critical, ask what happens if the vendor goes out of business or you stop using the application – can you convert the license to continue using Oracle (perhaps to extract your data)?
• Understand Support Arrangements: Since you’ll rely on the vendor for Oracle support, evaluate their support capabilities. Do they have Oracle-certified DBAs on staff? What are their support hours and SLAs for critical issues? A cheaper license is no good if support is a weak link. Ensure the vendor’s support contract with you covers the Oracle components adequately (e.g., patching, security updates, performance tuning).
• Keep ASFU Environments Isolated: Keep the Oracle software provided under ASFU isolated from your other Oracle environments to maintain compliance. Don’t, for example, connect an ASFU-licensed database to a separate reporting tool that isn’t part of the vendor’s app unless it is done via an API allowed as per the contract. Treat it as an appliance: it does what it came to do, nothing more. This will help avoid accidental license breaches.

For Legal / Contract Reviewers:

• Document the Usage Terms: Ensure the contract (either the purchase order, EULA, or an attached document from Oracle) explicitly states the usage restrictions of the ASFU license – i.e., what the “application specific” scope is. The contract between Oracle and the ISV (often called an ASFU or distribution agreement) might not be fully visible to you, but your agreement with the vendor should reflect those key points so you know what you’re agreeing to. For example, it should name the application and clarify that the Oracle programs will be used only for that application.
• Liability and Audit Clauses: It’s wise to include language that shifts any Oracle compliance liability to the vendor, since Oracle authorizes them. The vendor should warrant that they are providing the Oracle licenses validly and will handle any Oracle audits. As a customer, you want assurance that you won’t be left holding the bag if something is mislicensed. Similarly, clarify that if Oracle revokes the ISV’s rights or changes terms, your usage rights will continue (or you’ll be made whole).
• Support and Updates: The contract delineates how Oracle software patches and updates will be provided. Will the ISV give you all the necessary security patches for the database? How quickly? Since you can’t download patches from Oracle directly (you’re not a direct Oracle customer for that license), the contract should obligate the vendor to keep the Oracle component updated and compliant with Oracle’s support policies. Also, ensure the contract covers what happens with support fees – if you pay an annual maintenance fee to the vendor, does that include Oracle’s support fee? (Usually yes, but it’s good to spell out so you’re not double-charged.)
• Exit Strategy Clauses: If possible, negotiate an exit or transition clause for the Oracle licenses. For example, if you terminate the software vendor’s product, can you buy the Oracle license out to continue using the database with your data? Or at least be allowed a read-only period to extract data? Oracle ASFU licenses typically end when the application is no longer used, but having clarity in the contract can help avoid data lock-in. You might not get Oracle usage rights beyond the app, but you can negotiate assistance or rights to convert to a full license at a pre-agreed rate if needed.

For General Business Stakeholders (and ISVs):

• Assess Total Cost of Ownership: From a business perspective, don’t just look at the initial discount. Consider the total cost over the application’s life. The cost benefits are clear if the vendor’s solution (with ASFU) will likely serve you for many years without change. But if there’s any scenario where you’d need to break out of the ASFU model (like integration with other systems or scaling beyond one application), factor in those potential costs (like license upgrades or new licenses) into your long-term budgeting.
• Monitor Compliance Internally: Even though Oracle won’t audit you directly for ASFU, maintain good software asset management practices. Keep records of your ASFU licenses and ensure your IT staff know their boundaries. The worst time to discover a compliance issue is during a crisis or when the vendor gets audited unexpectedly. By keeping usage in check proactively, you protect your company from disruption (and make life easier for the vendor).
• Leverage the Vendor Relationship: Use that to your advantage because the vendor effectively stands between you and Oracle. For instance, if you need more Oracle capacity for the application (say, moving from a test environment to production, or scaling users), talk to the vendor – they can often get additional ASFU licenses at similar discounts. It might be simpler and cheaper than going to Oracle for a separate license. Also, if Oracle announces a change (say a new version or a pricing change), ask your vendor how it affects you. They should advocate on your behalf.
• If You Are an ISV (Vendor): Choose the right model (ASFU vs ESL vs Full Use resale) based on your solution’s needs. If your customers want flexibility or direct DB access, ASFU is preferable over ESL. Keep your Oracle distribution contract broad to cover future versions or modules of your software without needing amendments. Remember, you carry the compliance risk, so keep track of how each customer uses the Oracle licenses you provided, and educate them to stay within bounds. Providing clear guidelines to your customers will help you avoid audit issues down the line.

Read Oracle ASFU Licenes FAQs.

FAQs on Oracle ASFU License

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

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit