3.3 性解放的理论，清教徒的实践^a

尽管历经种种变革，业界对于“自由软件”与“开源”的定义仍形成了广泛共识。而这一共识最直观的体现便是各类开源许可证，所有许可证均包含核心共性条款。

在 1997 年，这些共同要素被提炼为《Debian 自由软件指导方针》，该文件后续演变为开源定义（OSD，http://www.opensource.org）。依据 OSD 的方针，开源许可证必须保障任意一方拥有无条件修改开源软件、并二次分发修改版本的权利。

因此，OSD（以及遵循OSD的许可证，如 GPL、BSD 许可证和 Perl 的艺术许可证（Artistic License）^b）背后隐含的理念是：任何人都可以二次开发任何代码。没有什么能阻止五六个不同的人拿着任一开源产品（例如，FSF 的 gcc C 编译器）、复制源代码，带着它们朝不同的演化方向各自发展，却都宣称自己的版本才是正统。

这种项目分化被称为分支（fork）。分支的核心特征是衍生出多个相互竞争、日后无法代码互通的项目，进而割裂潜在的开发者社区。（有些现象表面上类似分支，但实则不然，例如各种不同 Linux 发行版的涌现便是典型。这类伪分支虽然可能形成独立的项目，但主体代码高度共用，各方能够充分共享开发成果，因此无论从技术还是社区层面看，都不构成浪费，也不被视为分支。）

开源许可证并没有任何限制分支的条款，更不用说伪分支了；甚至可以说，许可证在无形中默许并助长了这两类行为。但在实际场景中，伪分支十分普遍，真正的项目分支却极少出现。大型项目一旦发生分裂，必然伴随项目更名，相关方也会公开展开大量辩解。在诸如 GNU Emacs/XEmacs 分裂、gcc/egcs 分裂，以及 BSD 各派生团体的多次分裂等案例中不难发现：分裂者都感到自己是在违背一个相当强大的社区规范。¹

实际上（并且与“任何人都可以二次改动代码”的一致性理论（consensus theory）^c相矛盾），开源文化有一套体系完备、却大多不成文的权属惯例。

这些惯例规定了谁可以修改软件、在什么情况下可以修改，以及（尤其重要的是）谁有权将修改后的版本二次分发给社区。

文化中的禁忌会让其中的规范格外突出。因此，我们在此总结一些重要的禁忌，对后文将大有裨益：

• 社区对创建项目分支有着强大的舆论压力。除非迫不得已，同时需要大量公开为自己申辩开脱，并为新项目更名，否则分支不会发生。

• 未经项目协调者配合就向外推送代码改动，会遭到社区反感。除非是在一些特殊情况下，例如本质上微不足道的移植修复。

• 未经本人明确同意，不得将某人的名字从项目记录、贡献者名单或维护者名单中删除。

在本文的剩余部分，我们将详细审视这些禁忌和权属惯例。我们不仅要探究它们如何运作，还要分析它们背后揭示了开源社区哪些深层运作逻辑与激励机制。