当自由软件依赖于非自由软件

作者：理查德·斯托曼

当一个程序是自由软件（自由如自由）时，这意味着它给予用户四大自由，以便他们控制程序的功能。在大多数情况下，这足以使该程序的发行是合乎道德的；但并非总是如此。在特定情况下还会出现其他问题。本文描述了一个微妙的问题，即升级自由程序需要使用非自由程序。

如果自由程序的使用不可避免地依赖于另一个非自由程序，我们称该自由程序被“困住”。它的代码是自由软件，你或许可以将它的代码片段复制到其他自由程序中，并获得良好的道德结果。但是你不应该运行被困住的程序，因为这需要你将自由让给其他非自由程序。

一个坚持自由软件原则的人不会有意地制作一个被困住的程序。然而，许多自由程序是由那些并不特别支持这些原则或不理解问题的人或公司开发的。

对非自由程序的依赖可以采取多种形式。最基本的形式是，所使用的编程语言没有自由实现。我在 20 世纪 80 年代为 GNU 系统编写的第一个程序，包括 GNU Emacs、GDB 和 GNU Make，都必须使用 AT&T 的非自由 C 编译器进行编译，因为在我编写 GCC 之前没有自由的 C 编译器。幸运的是，这种问题大多已成为过去；我们现在拥有自由的编译器和平台，几乎适用于任何用于编写自由软件的语言。

我们可以通过将其翻译成另一种语言，或发布其编写语言的自由实现来将程序从这种陷阱中释放出来。因此，当完整的自由 Java 实现可用时，这使所有自由 Java 程序从 Java 陷阱中解放出来。

这种依赖关系在概念上很简单，因为它源于特定时间点的情况。在时间 T，如果没有非自由编程平台 Q，自由程序 P 将无法运行。借用语言学中的一个术语，这种关系是“共时的”。

最近，我们在数据库程序中看到了另一种依赖关系，你可以在自由世界中构建和运行该程序的任何给定版本，但是从版本 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 本质上等同于运行具有窥探功能和通用后门的专有程序。该服务可以保留用户重新格式化的数据库的副本。即使我们可以相信运行该服务的公司永远不会有意地将数据的任何形式展示给任何人，我们也不能确定它不会被各个国家的情报机构或破坏安全的破解者访问（请不要称他们为“黑客”）。

当一个程序在历时上被困住时，要将它从陷阱中释放出来，需要的不仅仅是一次性的编程工作。相反，这项工作必须持续不断地进行，每次数据格式发生变化时都要进行。启动一个长期致力于继续这样做的工作并不容易。也许可以更容易地通过拒绝被困住的程序来向公司施加压力，让他们停止试图困住用户。鉴于释放程序是如此困难，你最好远离它。

有可能在没有非自由软件的情况下尝试使用历时被困的自由程序，但是如果你打算做的不仅仅是涉猎，那么你必须避开真正使用它。企业和个人都会发现没有此类问题的出色的自由替代方案；避免陷阱所需要的只是识别它。