一套十年前上線的 ERP、一個銀行介接程式、一台跑報表的伺服器、一個工程師留下來的排程，甚至某些根本沒有人敢動的舊系統，背後可能都還跑著 Java。
問題是：
你知道公司裡到底有多少套 Java 嗎？
更進一步地問：
你知道那些 Java 是哪一家的 JDK、什麼版本，以及現在適用什麼授權條款嗎？
這也是戴米特科技開發 Nomos-J 的原因。
我們真正想解決的，不只是「找出 Java 裝在哪裡」，而是一個正在逐漸浮上檯面的企業治理問題：
Java 已經不能只被當成免費的 Runtime，而必須被當成一項需要管理的軟體資產。
「Java 是免費的」這句話，已經不夠精確
很多資訊人員過去對 Java 的理解很簡單：
Java 不是免費的嗎？
這句話不能說完全錯，但今天已經非常容易造成誤解。
因為我們平常講的 Java，實際上可能指的是不同東西：
- OpenJDK
- Oracle JDK
- Red Hat build of OpenJDK
- Eclipse Temurin
- Amazon Corretto
- Microsoft Build of OpenJDK
- 甚至是多年以前留下來的 Oracle JRE
它們都可以執行 Java 應用程式，但發行者、版本、更新政策、支援方式與授權條款並不完全相同。
尤其 Oracle JDK 的授權模式，在過去幾年已經歷過多次改變。
這件事對企業的影響，比很多人想像得更大。
Oracle JDK 現在到底怎麼授權？
先講一個很重要的觀念：
Oracle JDK 並不是所有版本、所有更新都必須付費；但也不是下載了就永遠可以免費商用。
Oracle 官方目前說明，Oracle OpenJDK releases 採用 GPLv2 + Classpath Exception 開源授權；至於 Oracle JDK，則必須依版本與更新時間判斷實際適用的授權。
以近年的 LTS 版本為例，Oracle JDK 21 曾經採用 Oracle No-Fee Terms and Conditions，也就是常看到的 NFTC。
NFTC 讓企業在許多情境下可以免費使用 Oracle JDK。
因此不少 IT 人員會留下這樣的印象：
「Oracle Java 現在不是免費了嗎？」
問題就出在「現在」。
Oracle 的 NFTC 並不是代表某一個 JDK 版本從此永遠適用同樣的免費條款。
Oracle 已正式說明，JDK 21 在 2026 年 10 月進入授權轉換點。從 2026 年 10 月 CPU 開始，後續 Oracle JDK 21 更新預計改以 Java SE OTN License 提供，模式將與目前 Java 8、11、17 的更新類似。
換句話說：
企業不能只問：
我們用的是 Java 21 嗎？
而應該問：
我們使用的是哪一個發行版的 Java 21？
是哪一個 Update？
這個 Binary 是什麼時候取得的？
現在適用哪一份授權？
這才是真正的 JDK 資產管理。
Oracle 官方授權說明：
Oracle Java SE Licensing FAQ
如果企業需要 Oracle Java 商業支援呢？
Oracle 目前提供 Java SE Universal Subscription。
它的特色之一，是不再單純依伺服器、CPU 或 Java installation 數量計算，而採用 Employee-based metric。
Oracle 官方公開資料顯示，定價從每位 Employee 每月 US$15 起，隨規模增加有不同級距；公開價格最低可到每月 US$5.25，超過 50,000 Employee 則需另外洽詢。
而這裡的 Employee metric，對企業來說是一個非常重要的觀念。
它不是：
「我們只有 20 個 Java 工程師，所以買 20 個。」
Oracle 的 Universal Subscription 是一種企業級的授權模式。Oracle 自己也將其描述為涵蓋 desktop、server 與 third-party cloud 的 enterprise-wide subscription。
因此，一間大型企業真正需要注意的，未必只是「到底裝了幾套 Oracle JDK」。
更大的問題可能是：
一旦組織確實需要 Oracle Java SE Universal Subscription，授權成本的計算基礎可能遠比 Java 使用者數量大。
這也是為什麼 Java 授權問題，不應該等到採購、法務或原廠詢問時才開始盤點。
Oracle Java SE Universal Subscription 官方說明
那是不是應該把 Oracle JDK 全部移除？
也不是。
Oracle JDK 本身是一個成熟的企業級 Java 平台，Oracle 也提供完整的安全更新、技術支援、管理服務與長期支援。
如果企業確實需要 Oracle 的商業支援、特定產品相依性，或者有明確的 Oracle 技術架構策略，那麼購買 Oracle Java SE Subscription 完全可能是一個合理選擇。
真正的問題不是：
Oracle 好不好？
而是：
企業有沒有必要在每一個 Java Workload 上都承擔同樣的授權模式？
如果一套應用程式並沒有 Oracle JDK 特有的依賴，技術團隊就應該進一步問：
這套系統是否可以改用 OpenJDK？
而這正是我們更推薦企業評估 Red Hat build of OpenJDK 的地方。
為什麼我們建議企業優先評估 Red Hat JDK？
Red Hat build of OpenJDK 是 OpenJDK 的企業級發行版本。
OpenJDK 本身是 Java SE 的開源實作，採用 GPLv2 搭配 Classpath Exception；Red Hat 官方也明確指出，Oracle Java SE 的授權條款並不適用於 Red Hat OpenJDK。
這對企業來說非常重要。
因為它把兩件事情拆開了：
Java Runtime 的開源授權
以及
企業所需要的技術支援服務。
企業可以使用 OpenJDK 的開源軟體，同時依照自己的 SLA、維運與資安需求，決定是否採購 Red Hat 的企業支援。
這是一個比較容易被 IT Governance 理解的模式。
Red Hat 並不是「沒有人維護的免費 Java」
有些企業對 OpenJDK 還存在另一個誤解：
免費的東西，出了問題是不是沒有人負責？
這也是我們選擇 Red Hat build of OpenJDK 作為企業遷移建議的重要原因。
Red Hat 長期參與 OpenJDK 專案，也是 OpenJDK 的重要貢獻者。Red Hat Enterprise Linux 本身就是以 OpenJDK 作為 Java Development Kit 與 Runtime Environment。
Red Hat 目前對 OpenJDK 8、17、21、25 等版本提供不同生命週期的支援，例如 Red Hat 官方目前列出的 RHEL 支援時程包括：
- OpenJDK 17：Full Support 至 2027 年底
- OpenJDK 21：Full Support 至 2029 年底
- OpenJDK 25：Full Support 至 2030 年底
部分版本之後還可以進入 Extended Lifecycle Support。
Red Hat 也提供定期更新與 Security Fix，並且與 RHEL、OpenShift、Red Hat Application Services 等企業產品整合。
所以這並不是：
Oracle JDK vs. 一個沒有人管的免費 JDK。
更準確的比較是：
Oracle 的企業 Java 發行與支援模式
vs.
Red Hat 的企業 OpenJDK 發行與支援模式。
Red Hat OpenJDK Life Cycle and Support Policy
Red Hat JDK 還有一個很大的優勢：把授權與 Support 分開思考
這對大型企業尤其重要。
Red Hat 官方說明，OpenJDK support 已包含在多種 Red Hat Enterprise Linux、OpenShift 與 Application Services 訂閱情境中；企業也可以依實際平台與支援需求選擇適合的方案。
也就是說，如果企業本來就大量採用：
RHEL、OpenShift、JBoss 或其他 Red Hat 技術，
Java Runtime 治理可以進一步納入既有的 Red Hat 技術治理架構。
這通常比讓每一個系統自己下載一套 JDK，再多年沒有人知道從哪裡下載、什麼版本、誰負責更新，要健康得多。
問題是：你要先知道自己現在用了什麼
這也是 Nomos-J 出現的原因。
我們在協助企業處理 Java 環境時，發現真正困難的第一步，通常甚至不是「換 JDK」。
而是：
根本沒有人知道現在有哪些 JDK。
一間經營十年、二十年的企業，很容易同時存在：
Oracle JDK 8。
OpenJDK 8。
Oracle JRE 8。
Java 11。
Java 17。
工程師自己下載的 Temurin。
Linux repository 安裝的 OpenJDK。
Container image 裡不知道什麼時候包進去的 JDK。
以及三年前離職的工程師留下來、現在沒有人敢碰的 Java。
這些 Java 分散在：
實體伺服器、VM、開發者電腦、測試環境、Docker Container、Kubernetes、Middleware 與第三方應用系統裡。
所以 Java Governance 的第一個問題從來不是：
要不要買 Oracle？
而是：
我們到底有什麼？
Nomos-J：先把 Java 看清楚，再決定怎麼治理
戴米特科技開發 Nomos-J，就是希望把這個問題系統化。
Nomos-J 的核心不是單純掃描「有沒有 java.exe」。
我們真正關心的是形成一份企業可以採取行動的 Java/JDK 資產清冊：
現在用了哪些 JDK？
是哪一個 Vendor？
是哪一個 Major Version？
是哪一個 Update？
哪些屬於 Oracle JDK？
哪些屬於 OpenJDK？
哪些版本已經老舊？
哪些需要進一步確認授權？
哪些 Workload 可以優先遷移？
哪些系統因為產品相依性暫時不能動？
最終，Java Governance 應該從一句：
「我們好像有用 Java。」
變成：
「我們知道哪裡用了 Java、誰負責、版本是什麼、授權風險是什麼，以及下一步要怎麼處理。」
這才是 Nomos-J 真正想完成的事。
戴米特科技建議的企業 Java 策略
我們通常不建議企業看到授權問題後，就立刻進行全面性的 JDK 更換。
比較合理的方法，是分成三個步驟：
第一步：Discovery
先盤點整個企業的 Java/JDK 資產。
不要先假設自己只有 Oracle，也不要先假設自己沒有 Oracle。
先找出事實。
第二步：Classification
依據 Vendor、Version、Update、用途、環境與系統相依性進行分類。
尤其把 Oracle JDK、舊版本 Java，以及無法辨識來源的 Runtime 列為優先檢視項目。
第三步：Migration
對沒有特殊 Oracle 相依性的 Workload，逐步評估標準化到 Red Hat build of OpenJDK。
需要原廠企業 Support 的系統，可以搭配 Red Hat Subscription。
真的需要 Oracle JDK 的系統則保留 Oracle JDK，並建立正確的授權與採購機制。
不是「全部換掉」。
而是：
把 Java 從無人管理，變成有治理策略。
為什麼是現在？
如果幾年前問一間企業：
你們有多少 Java？
很多人可能會覺得這是一個純 IT Inventory 問題。
但到了 2026 年，這已經同時涉及：
軟體資產管理、授權合規、資安漏洞、生命週期管理，以及 IT 成本。
特別是 Oracle JDK 21 正在 2026 年 10 月進入新的授權階段，現在正好是一個重新檢查企業 Java 策略的時間點。
我們並不認為企業應該因為害怕授權費，而倉促更換 Java。
相反地，我們認為企業應該先回答一個更基本的問題：
我們到底用了什麼？
看清楚之後，再決定哪些應該保留 Oracle JDK，哪些應該升級，以及哪些可以標準化成 Red Hat build of OpenJDK。
這也是戴米特科技開發 Nomos-J 的初衷。
因為真正成熟的 IT Governance，從來不是：
「全部換成免費的。」
而是：
「知道自己用了什麼，而且知道為什麼這樣選。」
對多數沒有特殊 Oracle JDK 相依性的企業 Java Workload 而言，我們認為 Red Hat build of OpenJDK，是目前非常值得優先評估的企業標準化方向。
參考資料
Oracle Java SE Licensing FAQ
Oracle 官方授權 FAQ
Oracle Java SE License Terms
Oracle Java SE License Terms
Oracle Java SE Universal Subscription
Oracle 台灣官方網站
Oracle：JDK 21 授權轉換說明
JDK 21 approaches end-of-permissive license
Red Hat build of OpenJDK
Red Hat Developer 官方網站
Red Hat OpenJDK Life Cycle and Support Policy
Red Hat 官方生命週期政策