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

Richard Stallman 著

当一个程序是自由软件时,意味着它赋予用户 四项基本自由,使用户能掌控程序的行为。在大多数情况下,这足以确保该程序的分发符合道德规范,但并非总是如此。特定情境下可能出现额外问题。本文要探讨的就是一个微妙的问题:当升级自由软件需要使用非自由程序时。

若自由软件的使用不可避免地依赖于某个非自由程序,我们称该自由软件为"受困软件"。其源代码虽是自由的,您也可以将其代码片段移植到其他自由软件中并产生合乎伦理的成果。但您不应运行这款受困程序,因为那将迫使您向非自由程序屈服,放弃自己的自由。

坚守自由软件原则的人不会刻意开发受困程序。然而,许多自由软件是由并不特别支持这些原则、或未能理解问题本质的个人或公司开发的。

对非自由程序的依赖可能以多种形式存在。最基本的形式是所使用的编程语言没有自由实现。我在1980年代为 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 本质上等同于运行一个带有监控功能和通用后门的专有程序。该服务很可能留存用户重构的数据库副本。即便我们相信运营服务的公司绝不会故意向任何人泄露数据,也无法确保这些数据不会被 各国情报机构 或安全骇客(请勿称其为"黑客")获取。

当程序陷入历时性受困时,将其从陷阱中解放出来需要的不是一次性的编程工作,而是必须在每次数据格式变更时持续投入。启动一个承诺要长期维护的项目并非易事,相比之下,向企业施压要求其停止对用户的束缚——通过抵制受困程序直至其改正——或许更为可行。考虑到解放程序的艰巨性,您最好从一开始就远离这类软件。

短暂试用历时性受困的自由程序或许无需非自由软件,但若想深入使用而非浅尝辄止,就必须避开对其的真实依赖。无论是企业还是个人,都能找到没有此类隐患的优秀自由替代品——只要识破这个陷阱,就能轻松规避。