开源：自由、责任与选择

这个想法的影响并不局限于编程。它直接关系到技术最终掌握在谁手里、知识如何流通、改进能否为他人带来好处，以及在情况变化时还剩下哪些选择。

开源不是「一切都免费」的承诺，也不是「维护不需要投入」的承诺。它刻意守护的是另外一些东西——特定的自由。正因为如此，您不必整体信任他人的成果，而可以在已经完成的工作之上继续搭建。

要理解它为何重要，最快的路径是先弄清楚：什么是开源，它是怎样发展起来的，它带来什么责任，以及为什么至今仍有人愿意公开自己的成果。

源代码是软件面向人的形态：开发者用编程语言写下的指令，在它们被转换成机器执行的形式之前的样子。能否拿到源代码，区分了「只能使用的软件」与「可以被研究的软件」。如果没有可读的形式，您只能观察它的行为；如果有，您就可以——自己动手，或委托他人——弄清它为什么这样运行、通过网络发送了什么、缺陷在哪里、改动应当落在何处。

开源既不是对软件开发方式的描述，也不是「代码恰好能被看到」的状态。它是许可证赋予软件的一组许可，而这组许可应当包含什么，有被广泛采用的定义。

该定义由 Open Source Initiative 维护，并被用来判断哪些许可证属于开源。它要求的内容包括：软件可以自由地再次分发；源代码以真正要修改它的程序员所使用的形式提供；可以创建并分发修改版与衍生作品；许可证不限制谁使用、用于什么目的；并且不依赖某项特定技术或界面形式。这个定义以 Debian 的准则为基础整理而成，也正因如此，「开源」不是一个听上去不错的口号，而是一个含义明确的词。

同一个词在不同语言里既表示自由，也表示零价格，于是产生混淆。自由软件中的「自由」指的是不受限制，而不是不要钱。两者偶尔会重合：Apache-2.0 不要求任何费用，因此相当一部分开源软件可以免费获得。但这是两个不同的问题。

让开源软件正常运行需要时间、技能和开销：准备托管、安装更新、应对安全问题、回答使用者的问题。许可证要求的不是付费，而是一份实际的工作。把这两件事分开看，选择软件时才会真正清醒。

像 Apache-2.0 和 MIT 这样的宽松许可证给出的授权范围很宽，附加条件很少。您可以用于任何用途、修改并再次分发，也可以放进收费的服务里。条件通常只有一条：保留您收到的版权与署名声明。

像 GNU GPL 这样的著佐权（copyleft）许可证给出同样的自由，但对分发附加条件：当您分发副本或修改后的版本时，由此产生的结果也必须沿用同一性质的许可证。这样，自由就不会在下一个使用者那里消失。

这不是「宽」与「严」的区别，而是作者想要守住什么。两类都是被承认的开源许可证，也都把义务与分发绑定在一起。如果您只是自己使用，并不会产生任何义务。

许可证给出的是许可，而不是能力。网站可以迁移到另一个服务商，但如果您拿不到代码仓库的访问权、不清楚正在使用哪些配置，也不了解部署流程，那么实际上是搬不动的。

当域名、托管账户和构建配置都登记在他人名下时，文件副本几乎没有用处。所以「网站可以迁移」这句话不是用来相信的，而是用来核实的。Foundation 把这两件事分开对待：许可由许可证永久授予，而实际能力依靠代码仓库、配置、资源和运维文档的组织方式来保障。

共享软件的历史比互联网更久。20 世纪 50 年代到 60 年代，软件在科研现场与大型计算机周边成长，使用者通过用户组交换代码。那时软件常被视为硬件的一部分，而不是一件独立商品。

当软件开始与硬件分开销售、使用者拿到源代码的机会变少时，情况发生了变化。20 世纪 70 年代末到 80 年代，程序属于受版权保护的成果这一点在法律上更加明确，按许可协议分发成为常态。1976 年比尔·盖茨就当时爱好者版 BASIC 的复制发出公开信，是「习以为常的共享开始被视为未经许可的复制」的一个早期例子。共享仍然可行，但需要先取得许可——今天的开源就是对这种局面的回答：不是回到过去，而是让分享的自由变得合法而可靠。

1983 年，理查德·斯托曼宣布 GNU 项目，目标是做出一个可以自由使用、研究、修改和分发的完整操作系统；1985 年成立 Free Software Foundation 并发表 GNU 宣言，把理由放在使用者的自由而不是技术上。这个项目留下了 Emacs、GCC 编译器、调试器、函数库和命令行工具，但影响最大的是许可证：1989 年发布第一版、1991 年发布第二版的 GNU General Public License 用版权来保障自由——任何人都可以使用和修改，但分发修改后的版本必须沿用同一许可证。这种做法被称为著佐权，它把自由从呼吁变成了法律条件。

1991 年，林纳斯·托瓦兹公开了自己出于兴趣编写的内核，并邀请他人提出意见和改进。它与已经存在的 GNU 工具结合在一起，构成了完整的系统，也就是 GNU/Linux。

重要的不只是结果，还有做法。开发在互联网上公开进行：改动发送到邮件列表，在公开场合讨论，是否采纳也公开决定。这种方式后来也进入日常工具：2005 年编写的版本控制工具 Git，最初正是为了管理内核开发。

这种方法能建成严肃的基础，是由实际使用证明的。Linux 系系统运行在世界上相当一部分服务器上，是手机的底层，也用于个人电脑。因为修改与再分发的自由，即使最初发起的人不再继续，这项工作也可以被研究、调整和接手。

1998 年 1 月，Netscape 宣布将公开浏览器 Navigator 的代码，同年 3 月代码发布，Mozilla 项目由此开始；这件事让企业开始关注开放式的开发方式。

同年 2 月，长期参与自由软件的人士在加州帕洛阿尔托聚会，选定了新的名字「开源」（open source）：同样的价值，需要一个不会让人误解为免费的说法。同年成立了 Open Source Initiative，其定义以 1997 年已有的 Debian 准则为基础整理而成。为什么需要新名字？开放式开发有切实的好处，连不关心伦理争论的企业也判断得清，而在 1998 年，需要说清的正是这一点。

自由软件与开源常被视为同一件事，在日常实践中几乎也确实如此：它们使用同样的许可证，产生同样的结果。区别在侧重。自由软件的传统把使用者的自由本身当作目的，视为伦理问题；开源这一侧则强调实际收益——开放式开发能做出更好、更值得信任的软件，而这个说法在职场里容易被接受。Apache-2.0 与 GNU GPL 被双方共同承认。对有立场的人来说，这个分歧是真实的；但对使用者而言，值得记住的不是争论，而是实际后果：能做什么、不能做什么，由软件所附的许可证决定，而不是由名字决定。

开源项目通常从一个很小的个人事件开始：某人遇到一个问题，就地写出解法，然后发现别人也在遇到同样的问题。常见的理由还有学习、希望自己的工作派上用场、以及得到同行认可。

对组织来说，理由更实际。被许多方使用的库，共同维护比每家公司重写一遍更省成本。此外还有吸引优秀人才、影响自己所依赖的标准的方向，以及公共资金产出的软件本应人人可用这一层理由。

还有一个更宽的理由：关键的基础如果只依赖一家公司并不健康。把代码和许可证公开出来，情况变化时，这项工作就能由别人接着做下去。

写第一版代码所花的时间，只是全部工作的一小部分。大部分时间用于阅读缺陷报告、回答使用者提问、更新依赖、应对安全问题、重写文档、准备发布，以及确认更新没有破坏原有的用法。

对许多人重要的项目，常常只由很少几个人支撑。依赖一个人是现实的风险：他停下来，工作也就停下来。

因此，看起来简单的支持就能产生明显效果。清晰的报告缩短修复所需的时间；回答其他使用者的问题减少重复提问；资金支持让人能把确定的时间投入这项工作，而不是只能做别的活之间剩下的部分。

开源许可证不附带质量保证。Apache-2.0 与其他宽松许可证一样指明：软件按「现状」提供，不附带任何担保。它也没有要求维护者修复某个缺陷、回答问题或提供商业支持。

换来的是自己动手的自由：自己修、委托其他开发者、替换不合适的部分。Foundation 也按同样的思路构建，所以这里不会承诺并不存在的服务。

自由伴随责任。用哪个版本、什么时候更新、怎样验证备份，都由您决定。明确的选择比守不住的承诺更有用。

参与的方式很多，也不必是开发者。缺陷报告、改进建议、文档修订与翻译、在公开讨论中帮助他人、提供代码与测试，都很有价值。资金支持是其中一种方式，而不是唯一方式；更多内容见「参与贡献」与「支持 Foundation」两个页面。

Apache-2.0 是宽松许可证，在企业中广为人知，而且不要求您公开自己的成果。它授予全球范围、免费、非独占且不可撤销的版权许可：已经获得的授权不能被事后收回。此外，它明确写入了来自贡献者的专利授权。较短的宽松许可证往往对专利只字不提，而 Apache-2.0 把这件事说清楚；对于重视使用者独立性的项目，这种明确本身就是优势。条件不多且务实：分发软件或修改版时，要附上许可证副本、标注修改过的文件，并保留收到的版权、专利、商标与署名声明。

这在实践中给网站带来什么？许可只是事情的一半。真正的独立性依靠：您能访问的代码仓库、带类型与校验的配置、以文件保存的内容、可替换的资源、任何人都能读的运维文档，以及不必询问 Provelopment 就能执行的公开部署流程。Foundation 的设计让这两半一起成立；至于什么归谁所有，详见「所有权与迁移」页面。

而且没有任何许可证能免除运维成本：网站需要更新、监控与验证。这些工作或者由您自己做，或者由您选定的开发者做，或者由收取费用的服务商做。这不是开源的缺陷，而是工作的实际样子。