GSS資安電子報0195期【什麼是OpenJDK? 是否合法及安全呢？】

Duke，Java的吉祥物，也是OpenJDK專案中的一個項目

       然而，好景不常，到了2010年甲骨文收購昇陽，同時也接收OpenJDK專案，但是卻又極度冷落這個專案。甚至一直到2018年四月才推出該專案的Windows與MacOS建構，因此若是在這段期間接觸OpenJDK的使用者，便會有OpenJDK什麼都沒有，支援度非常低的錯誤印象。但實際上，這只是Oracle冷落自己的OpenJDK社群，事實上有許多公司與社群使用這些公開的原始碼建立自己的組件，例如曾是最多使用者的AdoptOpenJDK，或是各雲端廠商發布自己的JDK。同時也因為昇陽已開放Java原始碼，因此事實上現在的Oracle Java SE與Oracle OpenJDK都是相同原始碼建構而成的實作參考(Reference Implementation)，只是採用不同的授權而已。

不過在2006年原始碼剛開放之初， Java 7的時期，有些Java程式碼授權是與GPL不相容的，例如，Java Web Start，導致這些不相容的套件不能包含在OpenJDK專案，這可能是江湖謠傳OpenJDK不能取代Java SE的主因。然而山不轉路轉，強大的社群仍實作出這些遺失的額外套件。同時，這些未包含在OpenJDK專案的部分，也逐步從JSR中去除，而不再是Java特性的一部分。如剛才提到的Java Web Start，他有社群製作的IcedTea-Web，能夠完全替代Java Web Start，而Java Web Start也已在Java 11中移除。

那OpenJDK專案缺少了那些套件呢? 分別是Applet Browser Plugin、Java Web Start、JavaFX以及打包於Java SE內的商用授權字型。除了字型之外，這些缺少的特性都已經是Deprecated或Deleted的套件，因此未來再也不會看到這些「不法份子」了。

GPLv2含Classpath Exception與Oracle No-Fee Terms and Conditions

       因為OpenJDK專案一開始便是昇陽公開Java SE的原始碼而來，因此與Oracle Java SE之間不存在仿製、侵權、反組譯之類的法律問題，甚至可說是使用相同原始碼來源，以不同授權釋出的建構而已，然而Java使用者要注意不同的授權所相對應的責任問題。Oracle Java SE便採Oracle No-Fee Terms and Conditions商業授權，只允許個人免費使用，若要商業應用便要收費。也因此許多企業紛紛棄用Oracle Java SE，轉向OpenJDK。至於OpenJDK採GPLv2含Classpath Exception，與一般的GPLv2相比，GPLv2含Classpath Exception允許開發者的程式碼靜態與動態連接Java函式庫，而不需要強制遵守GPLv2，這讓許多社群願意使用Java進行開發，例如Apache得以開發許多Java殺手應用，同時以Apache授權釋出。

然而，OpenJDK畢竟是GPLv2為主的授權，就算允許例外，也難保會不會有「誤用」導致所有程式碼全部被GPL污染的狀況，進而被要求公開原始碼。這時小心選用保證不會有汙染，且有賠償的OpenJDK建構便顯得重要。

OpenJDK安不安全? 看看CVE-2019-2699

2019年4月23日，NVD公布編號CVE-2019-2699的Java漏洞，這是一個高達9分的高風險漏洞，達成手法略微複雜，不過一旦成功，便有可能對Java SE與其所有相關套件造成破壞，因此必須要盡快修補。然而這個漏洞的重要性不單只於它本身造成的攻擊，更重要的是時間點。這是Oracle 宣布任何Java SE的商業應用必須收費之後所出現的第一個重大CVE，同時該修補也在第一個收費版本8u212中釋出。因此不願意付費的Java SE使用者企業，只能停留在8u202之前的版本。這對維護資訊安全是極差的決定，最好還是大刀闊斧，轉移到安心可靠，持續維護的OpenJDK還比較安全。
目前Java有兩種版本號碼推進模式，Java 8 之前每一個大版本號碼都是長期支援，相同版號特性會相同，如Java7, Java8，安全更新採整包替換的方式，每季固定推出新的關鍵更新(CPU)，如2022年一月推出的8u321。CPU只更新關鍵組件且有經過完整的回歸功能檢查，因此使用者不需要太多額外回歸測試便可直接替換。Java 9之後版本號碼每半年+1，更新時若沒有注意，可能碰到Java特性變更的問題(如某項功能被Deprecated)，這時就要選擇有LTS的版本，會如同Java 8一樣提供更新，如java 11.0.14，一樣也是採整包替換的方式。
同時，JSR規定不同供應商所提供相同版本號碼(含update小版號)的Java建構特性都必須要一致，基於大家的來源都是OpenJDK專案，甚至不可諱言的原始碼可能有相當程度的重疊，因此出現在Oracle Java SE的漏洞，有可能其他OpenJDK建構也會有，不同供應商所建構的OpenJDK偶而也有自身特有的漏洞，因此供應商是否持續維護是很重要的一個要點。

免費Java是否適合您

如果問到使用什麼Java環境，得到的回答是OpenJDK，就好像是問使用什麼作業系統，回答Linux一樣。事實上，Java目前至少有超過8家廠商提供免費的建構，包括Oracle與Azul。既然有這些選擇，為什麼要付費？為什麼不直接部署一個免費OpenJDK就好？使用免費的OpenJDK會有多大風險？

評估一個OpenJDK建構以及其供應商是否可用並不單只做安裝與回歸測試，請多考慮以下幾點：

• 這些供應商的支援能力和維護記錄
• 季安全更新記錄是否依慣例正常釋出(Java的安全更新慣例，一般每季釋出一次)，且是否有確保回歸性能而不需要使用者每次部屬都需要完整回歸測試
• OpenJDK 發行版是否經過TCK 測試，亦即是它是否真正相容於所有Java
• 您的智慧財產權是否受到保護

供應商是否能持續且穩定的提供支援是最重要的首要考量，尤其是GPLv2授權本身即說明了不提供品質保固(見GPLv2 ,章節11, NO WARRANTY)。因此誤用了爹不疼娘不愛的OpenJDK建構，也許部屬階段暫時沒有任何問題，碰到任何異常可是求救無門，而且也可能遇到斷炊，社群不再維護OpenJDK。

其次是Oracle對於Oracle Java SE會每季提供季更新，稱之為“關鍵更新”(CPU, Critical Patch Updates)，同時也讓NVD公開該CPU所修補的CVE漏洞們，因此各廠商維護能力是否有辦法跟上腳步也是一個重要的評鑑要素，例如Oracle自己的OpenJDK就不一定跟上Oracle Java SE的腳步釋出更新。

而提供的OpenJDK是否通過TCK相容測試是技術分析時就應該先檢查的項目，選擇有TCK的建構之後再進行啟動測試與回歸測試。最後，由於目前對於GPL的解釋仍有模糊地帶，因此是否對於授權疑慮有明確解釋或保障，也是評估的要點。

Java專家－Azul

Azul，2002年成立於美國加州，是目前Java供應商中唯一100%專注於Java的公司。Azul的商業授權訂閱確保使用者一定能如期取得經過 JCK 測試的季修補，同時也是唯一提供無授權汙染保證的公司，確保您的智慧財產權不受病毒是授權的汙染。全世界已有數以百萬計的 Java 開發人員、數以億計的設備和世界上最受推崇的企業信任 Azul， 將以卓越的功能、性能、安全性、最經濟實惠的價格和最高等級的支援服務，支持著您的Java應用程式的運行。