2025年11月07日·1 分钟
理查德·斯托曼与自由软件：改变代码的思想
探讨理查德·斯托曼的自由软件哲学、GNU 项目与 GPL，以及它们如何重塑许可、开发者权利与开源生态。
探讨理查德·斯托曼的自由软件哲学、GNU 项目与 GPL，以及它们如何重塑许可、开发者权利与开源生态。
软件不仅是技术产品——它还是一组权限。谁能运行它、复制它、与朋友分享它、修复 bug，或在其上构建新东西？这些问题的答案更多来自许可而不是代码本身。随着软件成为工作、通信和研究的核心，围绕“你被允许做什么”的规则开始像功能一样塑造创新。
理查德·斯托曼（常称 “RMS”）重要，是因为他让这些规则无法被忽视。在 1980 年代早期，他目睹了一个变化：越来越多程序以无源代码形式发布，用户被告知只能按照他人的条款使用软件。斯托曼将这看作不是一个小不便，而是用户和开发者自由的丧失——他通过提出一套明确的原则和法律工具来保护这些自由做出回应。
本文关注斯托曼的思想及其实际后果：自由软件定义、GNU 项目、copyleft 和 GNU 通用公共许可证（GPL）——以及它们如何塑造现代开源生态和软件许可规范。
这不是一篇传记，也不是关于编译内核或管理仓库的技术深潜。你不需要编程背景就能跟上阅读。
斯托曼既有影响力也有争议。本文目标是保持事实性与可读性：他主张的是什么、出现了哪些法律机制、企业和开发者如何适应、以及哪些争论仍在继续——让你看到他的工作为何仍然影响日常的软件选择。
“自由软件”容易被误解，因为“自由（free）”听起来像价格标签。理查德·斯托曼用“自由”来指自由——用户控制他们所依赖软件的能力。
如果一个程序是免费但你不能检查它、修改它或分享它，它在斯托曼关心的意义上仍然可能是“不自由”的。
自由软件由四项基本权限定义：
这些自由关乎主体性：你不仅是工具的消费者——你可以成为可以验证、适配和改进它们的参与者。
没有源代码，自由 1 和 自由 3 不可能实现。源代码是人可读的指令。没有它，软件更像一个密封的电器：你可以使用它，但无法理解它在做什么、在坏掉时修复它，或将它适配到新需求。
源代码访问也关乎信任。它使得独立审查成为可能（用于隐私、安全和公平性），并在原始开发者停止维护时使得继续维护变得可行。
把它想象成餐厅的一道菜。
这就是核心思想：自由软件关乎用户保持对其计算环境的控制所需的自由。
在“软件许可”成为大多数人关心的话题之前，很多编程文化——尤其是大学和研究实验室——运行在一种假设上：如果你能改进一个工具，你就分享改进。源代码随软件流动，人们通过阅读彼此的工作学习，修复通过非正式协作传播。
当软件成为一种商品时，这种文化开始改变。公司（甚至一些机构）开始把源代码视为竞争优势。分发附带“不可共享”的条款，程序不再附带代码，保密协议变得常见。对于习惯集体解决问题的开发者来说，这种转变不仅令人不便——更像是一项规则改变，使得社区问题解决在法律上变得风险重重。
最常被引用的起源故事之一发生在 MIT 的 AI 实验室。斯托曼描述过一台新打印机到来且其软件仅以二进制形式分发、没有源代码的情形。实际问题很世俗：实验室想修改程序以处理比如提醒用户卡纸或更智能地路由打印任务。在早期“黑客”规范下，会有人打补丁并分享修复。在这里，他们不能——因为看不到也不能修改源代码。
把这件事放在合适的比例上：并不是某台打印机单独创造了一个全球运动，而是它提供了一个清晰、易于理解的例子——人们依赖的工具正变得无法被用户修复。
对斯托曼来说，核心问题不仅仅是技术访问，而是合作自由的丧失。如果你不能研究程序，你就无法真正控制它。如果你不能分享改进，社区就会分裂，每个人最终私下重造修复。
这种动机塑造了随后出现的许可创新。斯托曼不愿依赖善意或非正式规范，他想要规则来保全使用、研究、修改和分享软件的能力——这样一来，合作在软件变得有商业价值时就不会被随意撤回。
斯托曼的重要举措不仅是写一篇宣言，而是发起了实际的工程工作。1983 年他宣布了 GNU 项目，目标雄心勃勃：构建一个完整的操作系统，任何人都可以使用、研究、修改和分享，并且与 Unix 兼容，以便人们可以运行熟悉的程序和工作流。
操作系统不是一个程序——而是一整套。GNU 致力于创建使电脑可用的所有日常组件，包括：
通俗地说：GNU 在构建管道、布线和开关——而不仅仅是一台电器。
到 1990 年代早期，GNU 已经产出大量“用户空间”组件，但一个关键部分滞后：内核（直接管理硬件和系统资源的部分）。当 Linux 在 1991 年出现时，它恰好填补了这一空白。
这就是为什么今天许多流行系统将 GNU 组件 与 Linux 内核 结合起来——常被称为“GNU/Linux”。
GNU 通过构建可运行的基础让自由软件理念变为现实。哲学解释了为什么自由重要；GNU 提供了使自由变得实用、可复制和可扩展的工具。
Copyleft 是一种许可策略，旨在不仅使软件在首次发布时自由，而且在未来版本中也保持自由。如果你收到被 copyleft 保护的代码，你可以使用、研究、修改和分享它——但当你分发改动版时，必须把同样的自由传递给他人。
Copyleft 听起来像“反版权”，但它实际上依赖于版权法。作者利用其版权在许可中设置许可规则：“你可以复制和修改，但如果你再分发，必须保持相同的许可。”没有版权，就没有法律机制来强制这些条件。
把它当作跟随代码的规则：
目标是防止斯托曼担忧的那种模式：有人拿走社区工作的成果、改进它，然后把改进封闭起来。
宽松许可（如 MIT 或 BSD）通常允许你几乎对代码做任何事，包括在闭源许可下再分发修改版。Copyleft 许可（如 GNU GPL）仍然允许广泛使用与修改，但要求再分发的派生版本保持相同的 copyleft 条款——从而在下游保留自由。
GNU 通用公共许可证（GPL）通过把“共享”变成可执行的规则而不是善意，使软件许可发生了改变。在 GPL 出现之前，你可以收到源码、改进它，然后把闭源版本发布出去，让用户无法研究或修改。GPL 颠倒了这种动态：它通过在再分发时附加条件来保护用户的自由。
从实务角度看，GPL 授予用户为任何目的运行程序、阅读并修改源码、分享原版或修改版的权利。
如果你再分发 GPL 软件（尤其是作为产品分发），你必须把这些相同的自由传递下去。通常这意味着：
GPL 的义务主要在你向他人分发软件时触发——发运二进制、出售带有软件的设备、或把副本交给客户。如果你为私人内部使用修改 GPL 代码并不对外分发，通常不必公布源码。
你不需要法律理论来理解大意：如果你的程序以某种方式合并了 GPL 代码（例如把它链接进应用），结果通常会被视为衍生作品，必须以 GPL 分发。仅仅运行一个 GPL 程序，或作为独立进程通过标准接口与之通信，通常不同。
GPLv2 是经典且广泛使用的版本。GPLv3 增加了对专利交易和“tivoization”（硬件阻止修改软件）的保护。LGPL 为库设计：在某些条件下允许专有程序链接库，而库本身仍保持自由。
自由许可（尤其是 GNU GPL）不仅“允许”共享——它们保护了研究、修改与再分发软件的权利，使这些权利难以被撤回。对开发者来说，这意味着你的改进可以以相同条款继续为他人所用，而不是被吸收进闭源产品且社区无法受益。
在 GPL 下，你可以：
这也是为什么 GPL 常被称为“可执行的互惠”。如果有人分发了受 GPL 保护的程序（或衍生作品），他们不能添加阻止下游用户进行相同种类修改与分享的限制。
当你分发软件时，这些权利伴随着义务：
这些责任并非陷阱——它们是防止协作变成单向提取的机制。
团队应将许可合规视作发布卫生的一部分。跟踪：
简单的软件物料清单（SBOM）和可重复的发布检查表可以在律师介入前预防大多数问题。
在代码层面，“自由软件”和“开源”常指相同的许多项目。分歧主要在于为何共享重要。
自由软件运动（与理查德·斯托曼和自由软件基金会相关）把软件自由视为伦理问题：用户应有运行、研究、修改和分享软件的权利。重点不只是更好的工程——而是保护用户自治。
开源方法强调实际结果：更好的协作、更快迭代、更少 bug、通过透明度提升安全性。它倾向于把开放作为一种更有效的开发模型来推介，而不要求团队采取道德立场。
1998 年，开放源码倡议（OSI）推广“open source”一词以使该理念更具商业吸引力。“自由软件”经常被误解为“零成本”，一些公司对围绕权利与伦理的论述感到抗拒。“开源”给组织一种表达方式：“我们可以这样工作”，而不显得意识形态化。
许多自称开源的项目使用 GNU GPL 或其他 copyleft 许可，而也有项目选择 MIT 或 Apache 等宽松许可。法律文本可以完全相同；向贡献者、用户和客户讲述的故事不同：一种说法是“这保护你的自由”，另一种是“这减少摩擦并提高质量”。
如果团队优先保证下游用户保有相同自由，倾向于自由软件的表述并考虑 copyleft。
如果优先考虑最大化采用（包括那些可能不愿接受互惠义务的公司），开源表述与宽松许可可能更合适。
如果既想广泛协作又希望改进能回流，使用开源语言以提升亲和力，同时选择 copyleft 以实现预期结果。
自由软件并不等于“没人赚钱”。它指的是用户拥有运行、研究、修改和分享代码的自由。许多公司围绕这些自由建立健康收入——通常通过为组织真正挣扎的事情收费：可靠性、问责与时间。
一些常见且被验证的模式：
现代的一个变体是快速生成并运行应用的平台。例如，Koder.ai 是一个通过聊天帮助团队构建 Web、后端和移动应用的 vibe-coding 平台，同时支持导出源代码。快速迭代与代码所有权并存，与软件自由背后的价值观天然契合：能够在需要时检查、修改并迁移你的软件。
许可选择会影响谁捕获价值：
“商业”描述的是如何销售；“自由软件”描述的是用户的权利。公司可以出售自由软件、收取支持费，同时尊重软件自由。
在采用或押注某个 FOSS 项目之前，问自己：
GPL 与“FOSS”经常被讨论，但一些反复出现的误解使得事情模糊——尤其是对于只想发布产品而不想无意违反许可的团队。
并不是。公有领域意味着没有版权拥有者强加条件——任何人都可以无限制地重用作品。
GNU GPL 是与“无约束”相反的。作者保留版权并授予广泛使用、修改与分享的许可——但前提是你遵守 GPL 的条款（最著名的是在分发覆盖二进制时分享源代码）。
公开代码可以有助于安全，但并不保证安全。一个开源项目仍可能：
安全来自于积极维护、审计、负责任的漏洞披露和良好的运维实践——而不是许可标签本身。
人们常把 GPL 称为“病毒式”，暗示它会不受控地扩散到所有接触到的东西上。这是带有偏见的比喻。
它通常指的是 copyleft：如果你分发 GPL 代码的衍生作品，你必须以 GPL 提供相应源码。这个要求是故意的：它在下游保留用户自由。这不是“感染”；这是一个你可以选择接受或通过换用不同代码来避免的条件。
经验法则：义务主要在分发时触发。
关键时刻，应基于代码如何结合与分发来做精确判断，而不是仅凭假设。
理查德·斯托曼是一个有争议的人物。可以在承认这一点的同时，清晰地讨论与他相关的思想和许可所带来的持久影响。
一个有用的出发点是把两种讨论区分开：
第二类可以用原始资料（许可文本、项目历史、采用模式）进行讨论，即便人们对第一类意见不一。
一个反复出现的批评并非针对许可，而是治理：项目如何做决策、谁有权威、当创始人、维护者与用户意见不合时如何处理。自由软件社区一直在争论：
这些问题很重要，因为许可设定了法律条款，但并不能自动带来健康的决策机制。
另一个持续的讨论关注包容性与社区规范：项目如何设定尊重行为的期望、如何处理冲突、对新手是否友好。有些社区强调正式的行为准则；另一些则偏好最小规则和更非正式的调节。没有一种方法天然“正确”，但这些权衡是真实且值得讨论的。
在评估斯托曼遗产时，有助于把主张基于可验证事实：GPL 要求什么、copyleft 如何改变合规实践、这些思想如何影响后来的许可与机构。你可以批评、支持或保持观望——但应追求精确、尊重并明确你在批评的具体对象。
斯托曼对日常团队最大的实际贡献是一个明确的问题：你想在下游保障哪些自由？ 回答它会把“选择许可”从一种感觉变成一个决策。
如果不确定，根据目标决定：采用（宽松）对比 互惠（copyleft）对比 库友好互惠（弱 copyleft）。
如果你使用 AI 辅助开发（包括基于聊天的平台如 Koder.ai），这份清单尤为重要：你依然会发布真实的依赖、真实的产物和真实的许可义务。速度并不会免除责任——它只会让可重复的合规流程更有价值。
把它做得无聊且可重复：
有关更深入的比较，参见 /blog/choosing-an-open-source-license 和 /blog/gpl-vs-mit-vs-apache。
“自由软件”指的是自由，而不是价格。
一个程序可以是 $0 但仍然不自由，如果你不能检查、修改或分享它。自由软件关注的是运行、阅读、修改和重新发布你所依赖软件的权利。
定义基于四项权限：
如果缺少其中任何一项，用户就会失去对软件的控制，协作也会变得更困难。
因为没有源代码，你几乎不可能研究或修改软件。
源代码访问带来：
Copyleft 利用版权法要求在你再发布时“同样共享”。
你可以使用、修改，甚至出售软件，但如果你分发了修改版，必须以相同许可提供对应的源代码，从而保证接收者享有同样的自由。
GPL 授予广泛权利（运行、阅读、修改、分享），并在分发时要求互惠。
如果你分发了 GPL 覆盖的二进制文件，通常需要：
通常不需要。
对 GPL 软件来说，义务通常在分发时触发。如果你在公司内部修改 GPL 代码并且不对外分发，通常不必发布这些修改。
（存在边缘情况——这只是经验法则，不构成法律建议。）
取决于代码如何组合。
通常：
在关键时刻，应先判断具体集成方式再决定合规路径。
它们针对不同关注点：
根据你想要的互惠强度（强互惠、弱互惠或库友好）来选择。
通常不会（在 GPL 下）。
如果你在自己的服务器上运行 GPL 软件，用户只是通过网络使用它，这通常不被视为“分发”，因此 GPL 的源码共享义务一般不会触发。
如果你希望网络使用也要求共享源码，可以考虑 AGPL 并据此评估你的部署模型。
会的——许多公司基于自由/开源软件赚钱，方式并非限制用户权利。
常见模式包括：
许可选择会影响策略：宽松许可有利于采纳；copyleft 有助于防止封闭分支并支持基于互惠的商业模式。