理查德·斯托曼与自由软件：改变代码的思想

为什么理查德·斯托曼仍然重要

软件不仅是技术产品——它还是一组权限。谁能运行它、复制它、与朋友分享它、修复 bug，或在其上构建新东西？这些问题的答案更多来自许可而不是代码本身。随着软件成为工作、通信和研究的核心，围绕“你被允许做什么”的规则开始像功能一样塑造创新。

理查德·斯托曼（常称 “RMS”）重要，是因为他让这些规则无法被忽视。在 1980 年代早期，他目睹了一个变化：越来越多程序以无源代码形式发布，用户被告知只能按照他人的条款使用软件。斯托曼将这看作不是一个小不便，而是用户和开发者自由的丧失——他通过提出一套明确的原则和法律工具来保护这些自由做出回应。

本文聚焦什么（和不聚焦什么）

本文关注斯托曼的思想及其实际后果：自由软件定义、GNU 项目、copyleft 和 GNU 通用公共许可证（GPL）——以及它们如何塑造现代开源生态和软件许可规范。

这不是一篇传记，也不是关于编译内核或管理仓库的技术深潜。你不需要编程背景就能跟上阅读。

平衡且易读的视角

斯托曼既有影响力也有争议。本文目标是保持事实性与可读性：他主张的是什么、出现了哪些法律机制、企业和开发者如何适应、以及哪些争论仍在继续——让你看到他的工作为何仍然影响日常的软件选择。

“自由软件”实际是什么意思

“自由软件”容易被误解，因为“自由（free）”听起来像价格标签。理查德·斯托曼用“自由”来指自由——用户控制他们所依赖软件的能力。

如果一个程序是免费但你不能检查它、修改它或分享它，它在斯托曼关心的意义上仍然可能是“不自由”的。

四项基本自由

自由软件由四项基本权限定义：

• 自由 0： 为任何目的运行程序。
• 自由 1： 学习程序如何工作并按需修改它。
• 自由 2： 重新分发副本以帮助他人。
• 自由 3： 发布你修改过的版本，让社区受益。

这些自由关乎主体性：你不仅是工具的消费者——你可以成为可以验证、适配和改进它们的参与者。

为什么必须有源代码访问

没有源代码，自由 1 和 自由 3 不可能实现。源代码是人可读的指令。没有它，软件更像一个密封的电器：你可以使用它，但无法理解它在做什么、在坏掉时修复它，或将它适配到新需求。

源代码访问也关乎信任。它使得独立审查成为可能（用于隐私、安全和公平性），并在原始开发者停止维护时使得继续维护变得可行。

一个简单的类比：食谱 vs 密封食品

把它想象成餐厅的一道菜。

• 专有软件就像买一个密封的即食菜：你可以吃，但不知道配料，不能调整食谱，也不能分享副本。
• 自由软件就像得到食谱：你可以在家做，了解制作方法，为过敏调整，并与你的朋友分享改进版本。

这就是核心思想：自由软件关乎用户保持对其计算环境的控制所需的自由。

斯托曼所反应的问题

在“软件许可”成为大多数人关心的话题之前，很多编程文化——尤其是大学和研究实验室——运行在一种假设上：如果你能改进一个工具，你就分享改进。源代码随软件流动，人们通过阅读彼此的工作学习，修复通过非正式协作传播。

从共享规范到封闭软件

当软件成为一种商品时，这种文化开始改变。公司（甚至一些机构）开始把源代码视为竞争优势。分发附带“不可共享”的条款，程序不再附带代码，保密协议变得常见。对于习惯集体解决问题的开发者来说，这种转变不仅令人不便——更像是一项规则改变，使得社区问题解决在法律上变得风险重重。

打印机故事（作为例子，而非神话）

最常被引用的起源故事之一发生在 MIT 的 AI 实验室。斯托曼描述过一台新打印机到来且其软件仅以二进制形式分发、没有源代码的情形。实际问题很世俗：实验室想修改程序以处理比如提醒用户卡纸或更智能地路由打印任务。在早期“黑客”规范下，会有人打补丁并分享修复。在这里，他们不能——因为看不到也不能修改源代码。

把这件事放在合适的比例上：并不是某台打印机单独创造了一个全球运动，而是它提供了一个清晰、易于理解的例子——人们依赖的工具正变得无法被用户修复。

为什么这催生了新的许可理念

对斯托曼来说，核心问题不仅仅是技术访问，而是合作自由的丧失。如果你不能研究程序，你就无法真正控制它。如果你不能分享改进，社区就会分裂，每个人最终私下重造修复。

这种动机塑造了随后出现的许可创新。斯托曼不愿依赖善意或非正式规范，他想要规则来保全使用、研究、修改和分享软件的能力——这样一来，合作在软件变得有商业价值时就不会被随意撤回。

GNU 项目：构建一个自由操作系统

斯托曼的重要举措不仅是写一篇宣言，而是发起了实际的工程工作。1983 年他宣布了 GNU 项目，目标雄心勃勃：构建一个完整的操作系统，任何人都可以使用、研究、修改和分享，并且与 Unix 兼容，以便人们可以运行熟悉的程序和工作流。

一个完整系统，而非单一工具

操作系统不是一个程序——而是一整套。GNU 致力于创建使电脑可用的所有日常组件，包括：

• 编译器（最著名的是 GCC），用于把源码变成可运行程序
• 核心命令行工具（复制文件、搜索文本、管理进程等基本工具）
• 库和开发工具以支持更多软件的构建
• Shell 与编辑器以便日常在机器上工作

通俗地说：GNU 在构建管道、布线和开关——而不仅仅是一台电器。

GNU + Linux：大多数人的接触方式

到 1990 年代早期，GNU 已经产出大量“用户空间”组件，但一个关键部分滞后：内核（直接管理硬件和系统资源的部分）。当 Linux 在 1991 年出现时，它恰好填补了这一空白。

这就是为什么今天许多流行系统将 GNU 组件 与 Linux 内核 结合起来——常被称为“GNU/Linux”。

基础设施和理想同样重要

GNU 通过构建可运行的基础让自由软件理念变为现实。哲学解释了为什么自由重要；GNU 提供了使自由变得实用、可复制和可扩展的工具。

用通俗语言理解 Copyleft

Copyleft 是一种许可策略，旨在不仅使软件在首次发布时自由，而且在未来版本中也保持自由。如果你收到被 copyleft 保护的代码，你可以使用、研究、修改和分享它——但当你分发改动版时，必须把同样的自由传递给他人。

基于版权的法律工具

Copyleft 听起来像“反版权”，但它实际上依赖于版权法。作者利用其版权在许可中设置许可规则：“你可以复制和修改，但如果你再分发，必须保持相同的许可。”没有版权，就没有法律机制来强制这些条件。

“同样共享”的想法（带简单示例）

把它当作跟随代码的规则：

• 分岔（fork）： 你分叉了一个 copyleft 项目，添加了功能并发布，你必须公布源码并保持相同许可，这样别人也可以分叉你的版本。
• 再分发： 你把程序打包到产品中并交付给客户。你可以收费，但必须向接收者提供源代码和相同的权利。

目标是防止斯托曼担忧的那种模式：有人拿走社区工作的成果、改进它，然后把改进封闭起来。

Copyleft 与宽松许可的区别

宽松许可（如 MIT 或 BSD）通常允许你几乎对代码做任何事，包括在闭源许可下再分发修改版。Copyleft 许可（如 GNU GPL）仍然允许广泛使用与修改，但要求再分发的派生版本保持相同的 copyleft 条款——从而在下游保留自由。

GNU GPL 如何重塑许可

GNU 通用公共许可证（GPL）通过把“共享”变成可执行的规则而不是善意，使软件许可发生了改变。在 GPL 出现之前，你可以收到源码、改进它，然后把闭源版本发布出去，让用户无法研究或修改。GPL 颠倒了这种动态：它通过在再分发时附加条件来保护用户的自由。

GPL 提供什么——以及它要求什么

从实务角度看，GPL 授予用户为任何目的运行程序、阅读并修改源码、分享原版或修改版的权利。

如果你再分发 GPL 软件（尤其是作为产品分发），你必须把这些相同的自由传递下去。通常这意味着：

• 向接收者提供源代码（或有效的获取方式）
• 附上许可文本并保留版权声明
• 在你的修改是分发覆盖作品一部分时，以 GPL 许可这些修改

源代码分发义务（何时适用）

GPL 的义务主要在你向他人分发软件时触发——发运二进制、出售带有软件的设备、或把副本交给客户。如果你为私人内部使用修改 GPL 代码并不对外分发，通常不必公布源码。

通俗的“衍生作品”定义

你不需要法律理论来理解大意：如果你的程序以某种方式合并了 GPL 代码（例如把它链接进应用），结果通常会被视为衍生作品，必须以 GPL 分发。仅仅运行一个 GPL 程序，或作为独立进程通过标准接口与之通信，通常不同。

GPL 变体：v2、v3 与 LGPL

GPLv2 是经典且广泛使用的版本。GPLv3 增加了对专利交易和“tivoization”（硬件阻止修改软件）的保护。LGPL 为库设计：在某些条件下允许专有程序链接库，而库本身仍保持自由。

自由许可下的开发者权利与责任

自由许可（尤其是 GNU GPL）不仅“允许”共享——它们保护了研究、修改与再分发软件的权利，使这些权利难以被撤回。对开发者来说，这意味着你的改进可以以相同条款继续为他人所用，而不是被吸收进闭源产品且社区无法受益。

你获得的权利

在 GPL 下，你可以：

• 放心修改：阅读源码，修改并运行你的版本
• 分享作品：分发原版或修改后的程序
• 基于别人的改进构建：因为接收者必须获得相同自由

这也是为什么 GPL 常被称为“可执行的互惠”。如果有人分发了受 GPL 保护的程序（或衍生作品），他们不能添加阻止下游用户进行相同种类修改与分享的限制。

你承担的责任

当你分发软件时，这些权利伴随着义务：

• 保留版权与许可声明。
• 在 GPL 要求时提供（或声明获取）对应源码。
• 保持许可原样，以便接收者知道他们的权利。

这些责任并非陷阱——它们是防止协作变成单向提取的机制。

合规的实用建议

团队应将许可合规视作发布卫生的一部分。跟踪：

• 你发布的开源组件、
• 它们的版本与许可、
• 你如何提供源码（或书面要约）、
• 以及你所做的修改。

简单的软件物料清单（SBOM）和可重复的发布检查表可以在律师介入前预防大多数问题。

自由软件 vs 开源：价值观分歧

在代码层面，“自由软件”和“开源”常指相同的许多项目。分歧主要在于为何共享重要。

不同的优先级：自由 vs 采用

自由软件运动（与理查德·斯托曼和自由软件基金会相关）把软件自由视为伦理问题：用户应有运行、研究、修改和分享软件的权利。重点不只是更好的工程——而是保护用户自治。

开源方法强调实际结果：更好的协作、更快迭代、更少 bug、通过透明度提升安全性。它倾向于把开放作为一种更有效的开发模型来推介，而不要求团队采取道德立场。

为什么“开源”更易被接受

1998 年，开放源码倡议（OSI）推广“open source”一词以使该理念更具商业吸引力。“自由软件”经常被误解为“零成本”，一些公司对围绕权利与伦理的论述感到抗拒。“开源”给组织一种表达方式：“我们可以这样工作”，而不显得意识形态化。

相同的许可，不同的叙事

许多自称开源的项目使用 GNU GPL 或其他 copyleft 许可，而也有项目选择 MIT 或 Apache 等宽松许可。法律文本可以完全相同；向贡献者、用户和客户讲述的故事不同：一种说法是“这保护你的自由”，另一种是“这减少摩擦并提高质量”。

简单决策指引

如果团队优先保证下游用户保有相同自由，倾向于自由软件的表述并考虑 copyleft。

如果优先考虑最大化采用（包括那些可能不愿接受互惠义务的公司），开源表述与宽松许可可能更合适。

如果既想广泛协作又希望改进能回流，使用开源语言以提升亲和力，同时选择 copyleft 以实现预期结果。

商业模式与现实激励

自由软件并不等于“没人赚钱”。它指的是用户拥有运行、研究、修改和分享代码的自由。许多公司围绕这些自由建立健康收入——通常通过为组织真正挣扎的事情收费：可靠性、问责与时间。

公司如何围绕 FOSS 盈利

一些常见且被验证的模式：

• 支持与服务：付费帮助台、SLA、培训、审计、定制功能和迁移服务。
• 托管与托管产品：出售托管版本，客户为便利、扩展、备份与合规付费。
• 双重许可：同一软件既提供免费许可（通常为 copyleft），也提供付费商业许可给需要不同条款的客户。
• 开放核心（谨慎使用）：保持真正免费的基础，同时出售专有插件。此法可行，但若“免费”部分设计得过于受限，可能侵蚀社区信任。

现代的一个变体是快速生成并运行应用的平台。例如，Koder.ai 是一个通过聊天帮助团队构建 Web、后端和移动应用的 vibe-coding 平台，同时支持导出源代码。快速迭代与代码所有权并存，与软件自由背后的价值观天然契合：能够在需要时检查、修改并迁移你的软件。

为什么许可是策略关键

许可选择会影响谁捕获价值：

• 宽松许可（如 MIT/Apache）使得别人（包括大厂）更容易在专有产品中重用你的代码。这有利于采用，但可能降低你通过独占性变现的能力。
• Copyleft 许可（如 GPL）要求下游再分发者共享修改，这可以劝阻闭源分叉，并支持以服务、认证发行或双重许可为核心的商业模式。

“商业”与“自由软件”并非对立

“商业”描述的是如何销售；“自由软件”描述的是用户的权利。公司可以出售自由软件、收取支持费，同时尊重软件自由。

可持续性清单

在采用或押注某个 FOSS 项目之前，问自己：

• 社区活跃吗（issues、发布、审查）？
• 治理清晰吗（谁做决定，冲突如何处理）？
• 资金可见吗（赞助商、公司支持、基金会）？
• 维护者工作量可持续吗（单点故障/倦怠信号）？
• 安全实践有记录吗（补丁节奏、通告）？

关于 GPL 与 FOSS 的常见误解

GPL 与“FOSS”经常被讨论，但一些反复出现的误解使得事情模糊——尤其是对于只想发布产品而不想无意违反许可的团队。

“GPL 就是公有领域”

并不是。公有领域意味着没有版权拥有者强加条件——任何人都可以无限制地重用作品。

GNU GPL 是与“无约束”相反的。作者保留版权并授予广泛使用、修改与分享的许可——但前提是你遵守 GPL 的条款（最著名的是在分发覆盖二进制时分享源代码）。

“开源就一定安全”

公开代码可以有助于安全，但并不保证安全。一个开源项目仍可能：

• 无人维护，
• 审查不足，
• 漏洞存在多年才被发现。

安全来自于积极维护、审计、负责任的漏洞披露和良好的运维实践——而不是许可标签本身。

所谓“病毒式许可”

人们常把 GPL 称为“病毒式”，暗示它会不受控地扩散到所有接触到的东西上。这是带有偏见的比喻。

它通常指的是 copyleft：如果你分发 GPL 代码的衍生作品，你必须以 GPL 提供相应源码。这个要求是故意的：它在下游保留用户自由。这不是“感染”；这是一个你可以选择接受或通过换用不同代码来避免的条件。

“我能把 GPL 代码用到我的应用或服务里吗？”（高层次）

经验法则：义务主要在分发时触发。

• 内部使用： 在公司内部使用 GPL 软件通常不要求发布改动。
• 打包发货/设备： 如果你分发了 GPL 许可的程序（或衍生品），一般需要提供源码和许可声明。
• SaaS/网络服务： 在服务器上运行 GPL 软件通常不迫使你向用户发布源码。（AGPL 用来填补这一漏洞。）

关键时刻，应基于代码如何结合与分发来做精确判断，而不是仅凭假设。

批评、争议与持续的讨论

理查德·斯托曼是一个有争议的人物。可以在承认这一点的同时，清晰地讨论与他相关的思想和许可所带来的持久影响。

一个有用的出发点是把两种讨论区分开：

1. 关于斯托曼本人和社区行为的争议；
2. 自由软件原则、GNU 项目和 GNU GPL 对软件许可与开发者权利的可测影响。

第二类可以用原始资料（许可文本、项目历史、采用模式）进行讨论，即便人们对第一类意见不一。

治理与“谁说了算？”

一个反复出现的批评并非针对许可，而是治理：项目如何做决策、谁有权威、当创始人、维护者与用户意见不合时如何处理。自由软件社区一直在争论：

• 领导应如何被选出或更换？
• 基金会应是成员驱动、董事会驱动，还是由维护者驱动？
• 何时维护者的“自由”与贡献者的需求发生冲突？

这些问题很重要，因为许可设定了法律条款，但并不能自动带来健康的决策机制。

包容性、行为准则与社区标准

另一个持续的讨论关注包容性与社区规范：项目如何设定尊重行为的期望、如何处理冲突、对新手是否友好。有些社区强调正式的行为准则；另一些则偏好最小规则和更非正式的调节。没有一种方法天然“正确”，但这些权衡是真实且值得讨论的。

把讨论落到实处

在评估斯托曼遗产时，有助于把主张基于可验证事实：GPL 要求什么、copyleft 如何改变合规实践、这些思想如何影响后来的许可与机构。你可以批评、支持或保持观望——但应追求精确、尊重并明确你在批评的具体对象。

实用要点：如何选择许可与贡献

斯托曼对日常团队最大的实际贡献是一个明确的问题：你想在下游保障哪些自由？ 回答它会把“选择许可”从一种感觉变成一个决策。

简单决策树

• 你是否希望他人（包括竞争者）在几乎没有条件下重用你的代码？ 选择宽松许可（如 MIT、Apache-2.0）。
• 你是否希望改进在再分发时保持可共享？ 选择强互惠（copyleft）（如 GNU GPL）。
• 你是否希望共享主要适用于你的库的修改，而允许专有应用链接？ 选择弱互惠（如 LGPL、MPL）。

如果不确定，根据目标决定：采用（宽松）对比 互惠（copyleft）对比 库友好互惠（弱 copyleft）。

负责发布软件的实用步骤

1. 每个项目选一个许可，并在 README 明确声明。
2. 在仓库根目录添加 LICENSE 文件（完整许可文本）。
3. 在组织要求的地方添加版权头。
4. 记录依赖项（直接及重要的传递依赖）及其许可。
5. 如果你分发二进制，准备好所需的声明、源码提供（如适用）与归属信息。

如果你使用 AI 辅助开发（包括基于聊天的平台如 Koder.ai），这份清单尤为重要：你依然会发布真实的依赖、真实的产物和真实的许可义务。速度并不会免除责任——它只会让可重复的合规流程更有价值。

建立轻量的内部合规流程

把它做得无聊且可重复：

• 在构建时生成 SBOM。
• 保持一个 声明 文件模板，随依赖变动更新。
• 在 PR/发布中加入许可审查检查点（即便只是 10 分钟的清单）。

有关更深入的比较，参见 /blog/choosing-an-open-source-license 和 /blog/gpl-vs-mit-vs-apache。