自由但受束縛—Java 陷阱

作者：Richard Stallman

編者按

自本文首次發表以來，Sun 公司（現為 Oracle 的一部分）已將其大部分 Java 平台參考實作重新授權於 GNU 通用公共許可證之下，現在有一個用於 Java 的自由開發環境。因此，Java 語言本身不再是陷阱。

但是，您必須小心，因為並非每個 Java 平台都是自由的。Sun 公司持續發行非自由的可執行 Java 平台，其他公司也這樣做。

Java 的自由環境稱為 IcedTea；Sun 公司釋出的原始碼包含在其中。因此，那才是您應該使用的。許多 GNU/Linux 發行版都附帶 IcedTea，但有些包含非自由的 Java 平台。（2015 年 10 月新增註：在許多 GNU/Linux 發行版中，Java 的自由實作被稱為 OpenJDK。）

為了可靠地確保您的 Java 程式在自由環境中順利執行，您需要使用 IcedTea 開發它們。理論上，Java 平台應該是相容的，但它們並非 100% 相容。

此外，還有名稱中帶有「Java」的非自由程式，例如 JavaFX，並且還有您可能會覺得誘人但需要拒絕的非自由 Java 套件。因此，請檢查您計劃使用的任何套件的授權條款。如果您使用 Swing，請務必使用隨 IcedTea 提供的自由版本。（2015 年 10 月新增註：一個名為 OpenJFX 的 JavaFX 自由替代品已經發布。）

除了這些 Java 特有的細節之外，這裡描述的一般問題仍然很重要，因為任何非自由的函式庫或程式設計平台都可能導致類似的問題。我們必須從 Java 的歷史中吸取教訓，以便我們能夠在未來避免其他陷阱。

另請參閱： JavaScript 陷阱。

2004 年 4 月 12 日

如果您的程式是自由軟體，基本上就是符合倫理道德的，但有一個陷阱您必須警惕。您的程式，雖然本身是自由的，但可能會受到它所依賴的非自由軟體的限制。由於這個問題在今天的 Java 程式中最為突出，我們稱之為 Java 陷阱。

如果一個程式的用戶擁有某些關鍵的自由，那麼它就是自由軟體。粗略地說，它們是：執行程式的自由、研究和更改原始碼的自由、重新發布原始碼和二進位碼的自由，以及發布改進版本的自由。（請參閱自由軟體定義。）任何給定原始碼形式的程式是否為自由軟體，僅取決於其授權條款的含義。

該程式是否可以在自由世界中使用，是否可以被想要生活在自由中的人們使用，這是一個更複雜的問題。這不僅僅由程式本身的授權條款決定，因為沒有任何程式可以獨立運作。每個程式都依賴於其他程式。例如，一個程式需要被編譯或直譯，因此它依賴於編譯器或直譯器。如果編譯成位元組碼，它就依賴於位元組碼直譯器。此外，它需要函式庫才能執行，並且它也可能調用在其他進程中運行的其他獨立程式。所有這些程式都是依賴項。依賴項可能是程式完全運作所必需的，或者它們可能僅對某些功能是必需的。無論哪種方式，程式的全部或部分都無法在沒有依賴項的情況下運作。

如果一個程式的某些依賴項是非自由的，這意味著程式的全部或部分無法在完全自由的系統中運行—它在自由世界中是無法使用的。當然，我們可以重新發布該程式並在我們的機器上擁有副本，但如果它無法運行，那也沒什麼用。該程式是自由軟體，但它實際上被其非自由的依賴項所束縛。

這個問題可能發生在任何種類的軟體、任何語言中。例如，一個僅在 Microsoft Windows 上運行的自由程式在自由世界中顯然是無用的。但是，如果運行在 GNU/Linux 上的軟體依賴於其他非自由軟體，那麼它也可能是無用的。過去，Motif（在我們擁有 LessTif 之前）和 Qt（在其開發者使其成為自由軟體之前）是造成這個問題的主要原因。大多數 3D 顯示卡只有在非自由驅動程式的情況下才能完全運作，這也會導致這個問題。但是，今天這個問題的主要來源是 Java，因為編寫自由軟體的人們常常覺得 Java 很性感。他們被對該語言的吸引力蒙蔽了雙眼，忽略了依賴項的問題，並落入了 Java 陷阱。

Sun 公司的 Java 實作是非自由的。標準 Java 函式庫也是非自由的。我們確實有 Java 的自由實作，例如 GNU Java 編譯器 (GCJ) 和 GNU Classpath，但它們尚未支援所有功能。我們仍在追趕。

如果您在 Sun 公司的 Java 平台上開發 Java 程式，您很可能會在不知不覺中使用 Sun 專有的功能。當您發現這一點時，您可能已經使用了它們好幾個月，而重新完成這項工作可能需要更多個月。您可能會說：「重新開始工作太麻煩了。」那麼您的程式將會落入 Java 陷阱；它將在自由世界中無法使用。

避免 Java 陷阱的可靠方法是在您的系統上只安裝自由的 Java 實作。那麼，如果您使用自由軟體尚未支援的 Java 功能或函式庫，您將立即發現，並且您可以立即重寫該程式碼。

Sun 公司繼續開發額外的「標準」Java 函式庫，幾乎所有這些函式庫都是非自由的；在許多情況下，即使是函式庫的規範也是商業機密，而 Sun 公司針對這些規範的最新授權禁止發布任何低於完整規範的實作。（請參閱 Java 規範參與協議 和 J2ME™ Personal Basis Profile Specification 作為範例。）

幸運的是，該規範授權確實允許以自由軟體的形式發布實作；其他收到該函式庫的人可以被允許更改它，並且不需要遵守規範。但是，該要求的效果是禁止使用協作開發模型來產生自由實作。使用該模型將需要發布不完整的版本，這是那些已經閱讀規範的人不被允許做的事情。

在自由軟體運動的早期，不可能避免依賴非自由程式。在我們擁有 GNU C 編譯器之前，每個 C 程式（無論是否自由）都依賴於非自由的 C 編譯器。在我們擁有 GNU C 函式庫之前，每個程式都依賴於非自由的 C 函式庫。在我們擁有 Linux，第一個自由核心之前，每個程式都依賴於非自由的核心。在我們擁有 BASH 之前，每個 shell 腳本都必須由非自由的 shell 直譯。我們的第一個程式最初不可避免地會受到這些依賴項的阻礙，但我們接受了這一點，因為我們的計劃包括隨後拯救它們。我們的總體目標，一個自託管的 GNU 作業系統，包括所有這些依賴項的自由替代品；如果我們達成了目標，我們所有的程式都將被拯救。事實就是如此：借助 GNU/Linux 系統，我們現在可以在自由平台上運行這些程式。

今天的情況有所不同。我們現在擁有強大的自由作業系統和許多自由程式設計工具。無論您想做什麼工作，您都可以在自由平台上完成；即使是暫時的，也沒有必要接受非自由的依賴項。今天人們落入陷阱的主要原因是他們沒有考慮到這一點。解決這個問題最簡單的方法是教導人們認識到它，並且不要落入其中。

為了使您的 Java 程式碼免受 Java 陷阱的危害，請安裝自由的 Java 開發環境並使用它。更一般地說，無論您使用哪種語言，都要睜大眼睛，並檢查您的程式碼所依賴的程式的自由狀態。驗證一個程式是否為自由軟體的最簡單方法是在自由軟體目錄中查找它。如果一個程式不在目錄中，您可以根據自由軟體授權條款列表檢查其授權條款。

我們正在努力拯救被困的 Java 程式，所以如果您喜歡 Java 語言，我們邀請您幫助開發 GNU Classpath。使用 GCJ 編譯器和 GNU Classpath 嘗試您的程式，並報告您在已實作的類別中遇到的任何問題也很有用。但是，完成 GNU Classpath 需要時間；如果繼續添加更多非自由函式庫，我們可能永遠不會擁有所有最新的函式庫。所以請不要將您的自由軟體置於束縛之中。當您今天編寫應用程式時，請從一開始就將其編寫為在自由設施上運行。

另請參閱

深夜陽光下的奇異事件