Oracle GlassFish Server Licensing
Executive Summary:
Oracle GlassFish Server is a Java EE application server originally developed as an open-source project, with Oracle later offering a commercial edition for enterprises requiring support.
This advisory provides IT asset management (ITAM) professionals with an overview of Oracle GlassFish Server licensing, covering the dual open-source and commercial model, licensing metrics and costs, the impact of Oracle’s support policy changes, and best practices for staying compliant while optimizing costs.
With Oracle shifting focus away from GlassFish (in favor of WebLogic Server), enterprises need to proactively manage their GlassFish licensing and plan their strategy to avoid compliance issues and unnecessary expenses.
Oracle GlassFish Server Overview and Editions
Oracle GlassFish Server originated from Sun Microsystems’ open-source GlassFish project (the reference implementation of Java EE).
After acquiring Sun, Oracle provided Oracle GlassFish Server as a commercially supported edition alongside the free open-source edition.
Understanding this dual distribution model is crucial:
- GlassFish Open Source Edition: Free under an open-source license (now managed by the Eclipse Foundation). There are no Oracle support or guaranteed patches for this edition – use is at your own risk. Organizations must self-support or rely on community fixes. It’s best suited for development environments or non-critical applications where full support is not essential.
- Oracle GlassFish Server (Commercial Edition): Oracle’s officially supported edition, requiring a paid license and support contract. It includes Oracle’s technical support, regular security patches, and additional enterprise features (like a clustering load-balancer plugin and advanced admin tools). This edition is designed for mission-critical production deployments that demand vendor-backed support and maintenance.
Licensing Models and Cost Structures
Oracle GlassFish Server licensing follows Oracle’s standard metrics, offering two ways to license the software based on your usage pattern – per processor or per Named User Plus (NUP):
- Processor-Based Licensing: You license the server based on the number of processor cores on which GlassFish is running. Oracle’s core factor table is used to determine how many processor licenses are needed per core (for example, many Intel CPUs have a 0.5 core factor, so two cores count as one license). This model permits unlimited user access once the processors are licensed, making it ideal for high-traffic or public-facing applications where counting individual users is impractical.
- Named User Plus (NUP) Licensing: You license based on the number of distinct users who access the GlassFish server (including both direct and indirect access). This model can be cost-effective for smaller, internal user bases. Oracle requires a minimum of 10 NUP licenses per processor, regardless of the actual user count, to ensure a baseline level of licensing on any server. NUP licensing is suited for controlled environments (departmental apps or testing servers) with a known user count.
Below is a summary of key Oracle GlassFish Server licensing metrics and costs:
| Licensing Metric | License Cost (USD) | Notes |
|---|---|---|
| Processor License | ~$5,000 per processor | Unlimited users per licensed processor. Use Oracle’s core factor (e.g. a 0.5 factor means 2 cores = 1 license). |
| Named User Plus (NUP) | ~$100 per named user | Count unique users. Minimum 10 NUP per processor required. Suitable for limited, known user groups. |
Note: These are Oracle list prices; enterprise agreements may differ.
Annual support fees, which grant access to patches and updates, are about 22% of the license cost and are in addition to the license prices above.
For example, licensing a single 8-core server via the processor model would cost roughly 4 processor licenses × $5,000 = $20,000 (since 8 cores at a 0.5 factor require four licenses), plus approximately $4,400 per year in support.
In contrast, a small deployment with 25 users could be licensed for approximately $2,500 using NUP (25 × $100, meeting the 10-per-processor minimum) plus approximately $550 per year in support.
Choosing the right model (processor vs. NUP) is therefore important to control costs based on the size of your environment and user count.
Oracle’s Support Policy Change and Its Impact
In 2013, Oracle made a strategic shift that significantly affected Oracle GlassFish Server licensing and support.
Oracle announced it would stop releasing new commercial versions of GlassFish after version 3.x, effectively discontinuing Oracle’s support for GlassFish in favor of its flagship WebLogic Server.
Key outcomes of this policy change:
- No Oracle Support for New Versions: GlassFish 4.0 and later (Java EE 7/8 and beyond) have been released only as open source, with no Oracle-supported commercial edition. Oracle ceased selling new GlassFish licenses for those versions. This means if you’re running GlassFish 4 or newer, Oracle will not provide patches, fixes, or support contracts for those servers. Enterprises running these versions must rely on community updates (or lack thereof), which increases security and stability risks.
- End-of-Life for Older Versions: Existing customers on GlassFish 2.x/3.x received support up to 2017 under Oracle’s lifetime support policy. After 2017, only indefinite “Sustaining Support” remained available, which provides basic assistance but no new patches. In practice, this marked the end of life for fully supported GlassFish in Oracle’s product line.
- WebLogic as the Replacement: Oracle’s official recommendation for customers was to migrate to Oracle WebLogic Server for a fully supported Java EE application server. However, WebLogic licenses are roughly twice as expensive per CPU as GlassFish was, and the platform is more complex. Migrating to WebLogic can significantly increase costs and operational complexity, so it requires careful justification and planning from both IT and financial perspectives.
- Third-Party Support Options: In the void left by Oracle, third-party vendors have stepped in to support GlassFish installations. For example, Payara Server is a fork of GlassFish that offers professional support and regular updates. This provides a middle path for organizations: you can continue using the GlassFish technology stack with vendor support – just not from Oracle. ITAM teams should weigh the cost and benefits of these third-party support contracts versus the alternatives (such as migrating to a different application server or continuing on unsupported open source). In many cases, third-party GlassFish support can be more affordable than a WebLogic migration, but it introduces a new vendor relationship to manage.
Compliance Risks and Common Pitfalls
Managing Oracle GlassFish Server licenses requires careful attention to avoid compliance issues and unexpected costs.
Some common licensing pitfalls to watch out for include:
- Miscalculating Processor Counts: Always use Oracle’s official core factor table when counting CPU licenses. Failing to apply the correct core factor (for example, counting physical cores without the 0.5 factor on Intel chips) can lead to under-licensing (non-compliance risk) or over-licensing (unnecessary cost).
- Ignoring NUP License Minimums: Even if a server has only a few users, Oracle’s policy requires at least 10 Named User Plus licenses per processor. A common mistake is licensing only a small number of users without meeting the minimum requirement. Ensure you always license the greater of the actual number of users or the 10-per-processor limit to stay compliant.
- Using Oracle Patches Without Entitlement: If you don’t have an active support contract for Oracle GlassFish Server, you are not entitled to Oracle’s proprietary patches, updates, or even certain binary distributions of GlassFish. Applying Oracle-issued patches or using the Oracle commercial binaries in production without a license violates compliance. Organizations should strictly separate any Oracle-provided software (for which they lack licenses) from their environments, and stick to the open-source builds if they haven’t paid for support.
- Deploying Commercial-Only Features on Open Source: Some features (for example, the GlassFish HTTP load balancer plug-in or the High Availability Database (HADB) for clustering in GlassFish 2.x) were available only to commercial licensees. Ensure that if you are only using the open-source edition, you haven’t deployed add-ons or components that require a commercial license. If such features are required, consider obtaining a support contract (from Oracle or a third-party provider) that covers them, or remove those components to avoid compliance exposure.
- Forgetting Java SE Licensing Impact: Oracle’s GlassFish Server license historically included the right to use Oracle Java SE (the Java Virtual Machine, or JVM) as part of the bundle. If you drop your Oracle GlassFish support, be mindful that you may need to license Java SE separately for your servers if you continue using Oracle’s JDK in production. Many enterprises have been caught off-guard by Java SE licensing changes. It’s best practice to review the Oracle dependencies (such as the JVM) tied to your GlassFish environment and ensure that they remain licensed or are replaced with alternatives (e.g., OpenJDK) if you forego Oracle support.
Avoiding these pitfalls comes down to diligent license management.
Regularly audit your GlassFish deployments, maintain documentation of how licenses were calculated, and educate your technical teams on these rules.
Oracle’s audit teams can inquire about any of the above, so having evidence of compliance (correct counts, only authorized software in use, etc.) will save you from penalties.
License Management Best Practices
Even as Oracle steps back from GlassFish, enterprises should apply strong license management practices to remain compliant and control costs.
Key best practices include:
- Perform Regular Internal Audits: Periodically review all GlassFish instances to confirm their licensing status (processor vs. NUP) and ensure the counts align with your entitlements. An internal audit after any significant infrastructure change (like a hardware refresh or virtualization move) is especially important.
- Maintain Detailed Records: Keep an up-to-date inventory of GlassFish deployments. Document the edition (open-source or commercial), version, host hardware (CPU type and cores), and the number of users or processors licensed for each instance. This documentation makes it easier to demonstrate compliance during an audit and helps you track any requirements for additional licenses.
- Educate and Inform Stakeholders: Ensure that developers, system administrators, and procurement officers understand Oracle’s GlassFish licensing terms and conditions. Simple steps, such as reminding teams not to download and run Oracle’s GlassFish installer in production without approval, or to report when a new server is deployed, can prevent accidental license violations.
- Plan for Change: Develop a roadmap for how your organization will handle GlassFish going forward. If you plan to stay on GlassFish without Oracle support, decide how you will get critical patches (open source community or third-party support). If you anticipate migrating to another platform, start budgeting and training for that transition. Being proactive will minimize rushed, last-minute decisions that often result in higher costs.
By following these practices, organizations can maximize the value they get from GlassFish (which, as an open-source technology, can be very cost-effective) while minimizing the risk of audit surprises or support gaps.
Recommendations
Practical Tips for Oracle GlassFish Server Licensing:
- Choose the Right License Model: Match the licensing model to your usage. Use processor-based licenses for high-volume or externally-facing servers, and NUP licenses for smaller, internal user groups. This ensures you’re not over-paying for an unlimited license when you have only a few users (or vice versa).
- Apply Core Factors Rigorously: Always apply Oracle’s core factor rules when counting processor licenses. Double-check the core counts and factors whenever you upgrade or change hardware to avoid licensing errors.
- Meet Minimum User Requirements: If you opt for Named User Plus licensing, note that Oracle’s minimum requirement is 10 users per processor. Always purchase at least the minimum NUP licenses for the processors in use, even if your actual user count is lower, to remain compliant.
- Track Deployments and Usage: Maintain an internal registry of all GlassFish installations, including details such as CPU cores and user counts for each. Having this visibility makes it easy to see if you are within your licensed limits and helps flag when additional licenses might be needed (for example, if a new project dramatically increases user counts).
- Avoid Unauthorized Patches: Do not apply Oracle’s GlassFish patches or updates if you don’t have a valid support contract. Running an Oracle-patched GlassFish binary without entitlement is a compliance violation. If you require a critical fix and lack Oracle support, consider seeking community patches or exploring third-party support options instead of using Oracle’s intellectual property without a valid license.
- Consider Third-Party Support: Evaluate the option of third-party GlassFish support vendors (like Payara) as an alternative to migrating off GlassFish. They can provide fixes and support at a potentially lower cost than an Oracle solution. This can extend the life of your GlassFish-based applications without incurring WebLogic-level expenses.
- Budget for Transitions: If your organization plans to phase out Oracle GlassFish (due to its support status), allocate budget and resources for that transition. Whether it’s moving to WebLogic, JBoss, or another platform, or refactoring applications to cloud services, plan those projects in advance. Early budgeting and planning can also give you leverage in negotiations (e.g., Oracle might offer discounts on WebLogic if they know you are considering leaving GlassFish).
- Engage Oracle (and Experts) Proactively: Don’t wait for an audit to communicate with Oracle. If you have GlassFish licenses and are uncertain about compliance or future support, engage Oracle or an independent licensing advisor proactively. They might help clarify your position or offer solutions (for instance, Oracle sometimes provides credit for unused GlassFish support towards other products if you negotiate during a renewal or migration).
Checklist: 5 Actions to Take
- Inventory Your GlassFish Deployments: Document all instances of GlassFish in use (including version and whether it’s the open-source or Oracle edition). Record the hardware details (CPU count/type) and the purpose of each instance (dev, test, production).
- Verify License Compliance: For each production deployment, calculate the required licenses (using core factors for processors or counting Named Users). Compare this to your purchased licenses or support contracts. If there’s a shortfall, take action – either procure additional licenses or adjust the deployment. If there’s an excess, you might save costs by decommissioning unused servers or negotiating a lower support rate.
- Assess Support Coverage: Check which GlassFish servers have active support (either from Oracle or a third-party provider) and which do not. For any mission-critical system running without support, evaluate the risk and consider obtaining support or planning an upgrade. Ensure that no one applies Oracle’s patches to unsupported systems.
- Educate Your Team: Brief your developers and IT administrators on the basics of GlassFish licensing. Make sure they understand, for example, that using Oracle’s GlassFish installer in production requires a license, or that scaling an application to a new server impacts license needs. Establish an internal policy to review licensing whenever there’s a change to the GlassFish environment.
- Plan Your Go-Forward Strategy: Determine how your organization will manage GlassFish over the next 1-2 years if you intend to stay on GlassFish (without Oracle’s direct support). Set up either internal processes or third-party support to manage updates and security patches. If you plan to migrate to a different server (like WebLogic or another Java EE platform), create a timeline and budget for that project. Review this plan with both IT and procurement stakeholders so everyone is aligned.
FAQ
Q: Is Oracle GlassFish Server free to use?
A: GlassFish Open Source Edition is free to download and use in any environment. However, the Oracle GlassFish Server commercial edition is not free – it requires purchasing a license (and typically an annual support contract) to use it in production with Oracle’s support. In summary, you can run GlassFish without paying Oracle if you use the open-source version, but then you won’t have Oracle’s support or proprietary updates.
Q: How is Oracle GlassFish Server licensed in an enterprise?
A: Oracle offers two licensing metrics for GlassFish in enterprises: per processor (counting the CPU cores on servers, with Oracle’s core factor adjustments) or per Named User Plus (counting each user who accesses the system, subject to a minimum of 10 users per processor). You choose the model that is more cost-effective for your scenario. For example, a public-facing server might be licensed by processor, whereas NUP could license an internal application for 20 users. The licenses also entitle you to use related components, such as the GlassFish Message Queue and Java SE, under the terms of the agreement.
Q: What happened to Oracle’s commercial support for GlassFish?
A: Oracle ended commercial support for GlassFish after version 3.x. They did not release a supported Oracle GlassFish Server 4.0 or any later version. Oracle provided patches and updates for older versions for a while (premier support ended in 2014, with extended support until 2017); however, no new fixes have been provided since then. Oracle now positions WebLogic Server as its supported Java EE application server. So, as of today, Oracle will not sell you a new GlassFish support contract for the latest versions – you must either use an old version (with only sustaining support available), switch to WebLogic, or seek third-party support if you need help with GlassFish.
Q: What are our options if we rely on GlassFish in production?
A: If you still use GlassFish, you have a few options moving forward. One is to continue with the open-source GlassFish without Oracle support, accepting the risks and potentially contributing to or relying on the community for fixes. The second option is to obtain support from a third-party vendor, such as Payara, which provides its own distribution and support for GlassFish-derived servers. This offers professional assistance and regular patches. The third option is to migrate to another application server – for example, Oracle WebLogic (if you want to stay with Oracle and Java EE) or JBoss EAP/WildFly, TomEE, etc. Alternatively, you can even shift the application to a cloud platform. Each option has trade-offs in terms of cost, effort, and risk, so you should evaluate them based on your business requirements and the criticality of the applications.
Q: How can we optimize costs associated with GlassFish licensing?
A: To optimize costs, start by right-sizing your licenses: use the licensing metric that results in the lower cost for each deployment (avoid paying for unlimited processors if you only have a handful of users, and vice versa). Keep track of unused licenses – if servers are decommissioned, see if you can cancel or reallocate those support contracts to avoid waste. Consolidate workloads where possible, so you need fewer total server licenses (while adhering to Oracle’s policies on virtualization). Additionally, consider whether you truly need Oracle’s support for each deployment; non-production environments may be sufficient with the free, open-source edition. And finally, if Oracle’s support costs become too high, consider comparing them with third-party support options or open-source self-support to determine if you can meet your needs at a lower price.
