當自由軟體依賴於非自由軟體時

作者：Richard Stallman

當一個程式是自由軟體（自由指的是自由的意義），這表示它給予使用者 四項自由，讓他們可以控制程式的行為。在大多數情況下，這足以使程式的發行合乎道德規範；但並非總是如此。在特定情況下，可能會出現額外的問題。本文描述了一個微妙的問題，即升級自由程式需要使用非自由程式。

如果自由程式的使用不可避免地依賴於另一個非自由程式，我們就說這個自由程式被「困住」了。它的程式碼是自由軟體，您或許可以將其程式碼片段複製到其他自由程式中，並獲得良好且符合道德規範的結果。但是您不應該執行這個被困住的程式，因為這會導致您將自由權讓給另一個非自由程式。

秉持自由軟體原則的人不會明知故犯地製作一個被困住的程式。然而，許多自由程式是由那些並非特別支持這些原則，或者不理解這個問題的人或公司開發的。

對非自由程式的依賴可能有多種形式。最基本的形式是當所使用的程式語言沒有自由實作時。我在 1980 年代為 GNU 系統編寫的第一批程式，包括 GNU Emacs、GDB 和 GNU Make，都必須使用 AT&T 的非自由 C 編譯器進行編譯，因為在我編寫 GCC 之前，沒有自由的 C 編譯器。幸運的是，這種問題大多已成過去；現在我們幾乎擁有所有用於編寫自由軟體的語言的自由編譯器和平台。

我們可以透過將程式翻譯成另一種語言，或發布該程式所用語言的自由實作來解除這種束縛。因此，當完整的自由 Java 實作變得可用時，這就將所有自由 Java 程式從 Java 陷阱 中解放出來。

這種依賴在概念上很簡單，因為它源於特定時間點的情況。在時間點 T，自由程式 P 在沒有非自由程式平台 Q 的情況下無法執行。借用語言學中的術語，這種關係是「共時」的。

最近，我們在資料庫程式中看到了另一種依賴關係，在這種情況下，您可以在自由世界中建構和執行程式的任何給定版本，但從版本 N 升級到版本 N+1 需要非自由程式。

這種情況發生是因為資料庫的內部格式從版本 N 變更為版本 N+1。如果您一直在認真使用版本 N，您可能已經有一個大型的現有資料庫，其格式為版本 N。要升級到版本 N+1 的資料庫軟體，您需要重新格式化該資料庫。

如果您應該這樣做的方式是執行專有資料庫重新格式化程式，或是使用開發人員的服務 SaaSS（服務即軟體替代品），則資料庫軟體就被困住了——但以一種更微妙的方式。資料庫程式的任何單一版本都可以在沒有非自由軟體或 SaaSS 的情況下使用。當您嘗試長期繼續使用該程式時，問題就出現了，這需要不時地升級它；如果沒有某些非自由軟體或同等物，您就無法以這種方式使用它。這個資料庫程式跨越時間而被困住——我們可以稱之為「歷時性地被困住」，借用另一個語言學術語。

例如，程式 OpenERP（後來更名為「Odoo」），雖然是自由軟體，但卻是歷時性地被困住的。GNU Health，我們用於營運醫療診所的自由套裝軟體，最初使用 OpenERP。在 2011 年，GNU Health 開發者 Luis Falcón 發現升級到下一個版本的 OpenERP 需要將資料庫（充滿病患的醫療數據）發送到 OpenERP 的伺服器進行重新格式化。這就是 SaaSS：它要求 GNU Health（一家診所）的使用者將其自身的運算和數據委託給 OpenERP 的公司開發者。Falcón 沒有屈服，而是重寫了 GNU Health 以改用 Tryton。

使用 SaaSS 本質上等同於執行具有窺探功能和通用後門的專有程式。該服務可能會保留使用者重新格式化的資料庫副本。即使我們可以信任運營該服務的公司永遠不會有意向任何人展示任何形式的數據，我們也不能確定它不會被各國情報機構或安全漏洞破解者（請不要稱他們為「駭客」）存取。

當一個程式歷時性地被困住時，要將其從陷阱中解放出來，需要的就不僅僅是一次性的程式設計工作。相反，這項工作必須持續進行，每次資料格式發生變化時都要進行。啟動一個長期承諾繼續這樣做的專案並不容易。向公司施壓，要求他們停止嘗試困住使用者可能會更容易——透過拒絕被困住的程式，直到他們這樣做為止。鑑於解放程式的難度，您最好遠離它。

有可能在沒有非自由軟體的情況下試用歷時性地被困住的自由程式，但如果您打算做的不只是涉獵，您就必須避開真正使用它。企業和個人都會找到沒有這種問題的優良自由替代品；避免陷阱所需要做的只是識別它。