1.2. 基金会文档

在项目发起的几年之后，Debian 确定了需要遵循自由软件项目形式的原则。这个慎重而积极的决定使得项目有序而稳定的成长并且确保了所有的成员向同一个方向前进。要成为一个 Debian 的开发者，任何的候选人必须承诺并且证明他们能够支持并且坚守建立在项目的基础文档上的原则。

开发程序被不断的争论，然而这些基础文档被广泛的接受，因此很少更改。Debian 的组织架构也为这些稳定性提供了额外的保证：任何修订案都需要获得四分之三的有效多数的同意才能获得通过。

1.2.1. 对用户的承诺

这个项目同样也有一份“社会契约”。这样一个文本在这个项目中只是为了一个操作系统的开发而存在的么？答案很简单：Debian 为用户工作，更广泛的来说，是为了这个社会。这份契约总结了这个项目所承担的承诺。让我们从更详细的细节中来学习它们：

  1. Debian 将始终是 100% 的自由软件。

    准则一：Debian 是并且还将继续保持完全由自由软件组成。另外，所有由 Debian 项目开发的软件与它自身都会是自由软件。

    视角 在软件之外

    第一版的 Debian 社会契约告诉我们“Debian 将会始终保持100%的自由软件”。软件这个词的弃用（在2004年正式启用的1.1版社会契约中）指出了实现自由的愿景，不仅仅是在软件上，也同时在 Debian 期望与操作系统一起提供的文档和其它的要素中。

    这个改变，仅仅是作为对编辑的影响，事实上，由数不清的影响，特别是要移除一些成问题的文档。此外，在驱动中使用固件的增长带来了问题：许多是非自由的，然而在适当的操作与固件的通信中又是必需的。

  2. 我们会回馈自由软件社区。

    任何被整合到发行版中的由 Debian 项目贡献的改进都会被反馈到作者（称为“上游”）。通常的，Debian 会与社区合作而不是独立工作。

    社区 上游作者，或是Debian开发者？

    术语“上游作者”指的是工作中的作者/开发者，是编写与开发软件的人员。另一方面，“Debian 开发者”使用更直观的工作来使软件加入到 Debian 包中（术语“Debian 维护者”更为适当一些）。

    在实践中，区分往往不是那么的清晰。Debian 维护者可能会写一个补丁，这样的工作可以使所有人都受益。通常来讲，Debian 鼓励负责 Debian 中对应软件包的人员同时参与到“上游”开发工作中去（然后，他们也就变成了贡献者，而不是仅仅被限制为一个程序使用者的角色）。

  3. 我们不隐藏问题。

    Debian 不是完美的，事实上，每天我们都会发现需要修复的新问题。我们将始终对公众开放完整的缺陷报告数据库。人们在线提交的报告也会尽快对其他人可见。

  4. 用户和自由软件是我们优先考虑的事。

    这个承诺更加难以定义。Debian 规定，如下，当必须要作一个带有一定偏向的决定时，会抛弃那个对开发来说更为方便而会损害用户体验的方案，选择一个更加优雅的方案，即使它会更加的难以实现。这意味着用户与自由软件的利益将会被优先考虑。

  5. 不符合我们的自由软件规范的作品。

    Debian 接受并且理解用户可能需要使用一些非自由软件程序。这就是 Debian 允许混合使用了项目中的部分基础架构与非自由软件的程序可以被安全的再次分发的原因。

    社区 是支持还是反对 non-free 区块的呢？

    维护一个允许容纳非自由软件的体系的承诺（如“non-free”章节，请看侧边栏关键词 main, contrib 和 non-free 存档）总是 Debian 社区中的辩论的主题。

    反对者指责这相当于让人们远离自由软件，同时这也与只服务于自由软件的原则相背。支持者总是声称大多数的非自由软件包都是“几乎是自由的”，仅仅是被一两条恼人的限制性条件所限制（最常见的就是禁止软件的商业使用）。通过在非自由分支中分发这些软件包，我们相当于间接的向作者解释，如果这些软件包能被包含在主分区中，便可以被更多的人所知并且使用。因此，我们是在礼貌而委婉地提出希望他们能够为了达到这样的目的而改变其许可证。

    经过2004年首次不成功的尝试后，对不自由分区的彻底移除已经不太可能再次提上日程了。其中一个有很重要的原因，是这个分区包含了许多仅仅是因为不满足主分区新的要求而被移动至此的重要文档。对GNU计划所提供的某些软件文档来说尤其如此（特指Emacs和Make）。

    non-free软件分区就这样一直存在，并成为了与自由软件基金会之间不时产生摩擦的导火索。这也是基金会拒绝正式推荐Debian作为自由软件操作系统的主要原因。

1.2.2. Debian 自由软件指导方针

这个参考文档定义了哪些软件是“足够自由”而可以包含于 Debian 中。如果某个程序的许可证与这些原则相符合，它便能被收录在 main 部分中；如果有所冲突，但是至少允许自由分发的话，它可能被收录于 non-free 部分。正式地来说，non-free 不是 Debian 的组成部分；它属于向用户提供的额外服务。

这些条文不仅仅是Debian的选择标准，也成为了有关自由软件方面的权威解释，同时，它也作为“开源”的基础定义。因此，它成为了“自由软件”概念最早的正式定义之一。

GNU通用公共许可协议、BSD许可协议和还有艺术许可协议，这些都是传统自由软件的许可协议，它们遵循自由软件指导方针中所提到的9个要点。在下面的链接中你会找到发布在Debian网站上的这些许可协议的文本。

→ http://www.debian.org/social_contract#guidelines

  1. 自由的再次发行。

    Debian组件的许可协议不得限制任何一方将此软件作为含有若干不同来源的程序的一套软件集合中的一个组件用于销售或者捐赠。该许可证不得向诸如此类销售行为的销售方索取专利费或者其它费用。

    回到起点自由许可协议

    GNU通用公共许可协议，BSD许可协议，以及Artistic许可协议，虽然它们各不相同，但是它们都符合Debian自由软件指导方针。

    GNU 通用公共许可协议，由自由软件基金会（FSF）使用并推广，是最为常见的许可协议。它的主要特点是，它同样适用于任何被重分发的衍生作品：一个程序，如果它以使用了由 GNU 通用公共许可协议许可的代码，那么它在分发时也必须遵从 GNU 通用公共许可协议的条款。因此，它禁止了软件在私有软件中的任何重用行为。这对想要重用 GNU 通用公共许可协议许可的代码，却使用了不兼容的许可协议的软件造成了严重问题。例如：有时候无法将一个以另一个自由软件协议分发的程序和以 GNU 通用公共软件许可协议分发的库进行链接。另一方面，这一许可协议在美国法律中相当稳靠：自由软件基金会的律师们参与起草了该许可协议，也时常迫使违规者与自由软件基金会签订和解协议以避免法庭诉讼。

    → http://www.gnu.org/copyleft/gpl.html

    BSD许可协议是最为宽松的：任何操作都被允许，包括将修改后的由BSD许可协议许可的代码使用在私有软件中。微软甚至也使用过BSD许可协议的代码：他们基于BSD内核中的TCP/IP层源代码在Windows NT中实现了同样的功能。

    → http://www.opensource.org/licenses/bsd-license.php

    最后，艺术许可协议则在这两种协议间达成了某种妥协：允许在私有软件中使用未经修改的代码，但是任何修改的部分则必须公开。

    → http://www.opensource.org/licenses/artistic-license-2.0.php

    这些许可协议的完整文本可以在任一Debian系统的/usr/share/common-licenses/中找到。

  2. 源代码。

    程序必须包含源代码，并且必须允许以已编译二进制文件形式和源代码的形式分发。

  3. 衍生作品。

    许可协议必须允许代码修改和衍生作品，并且必须允许这些作品以和原软件相同的许可协议条款进行分发。

  4. 作者源码的完整性。

    仅当许可协议允许：为了在构建程序时修改代码，“补丁文件”可随源代码一同分发，那么在此种情况下，许可协议可以限制分发修改过的源代码。许可协议须明确地说明准许分发由修改过的源代码构建成的软件。它可能会要求衍生作品使用与源软件不同的名字或版本号。这是一种妥协。Debian社团鼓励所有的作者不要限制任何文件的修改，不论是代码还是二进制文件。

  5. 不歧视个人或群体。

    许可协议禁止歧视任何个人或群体。

  6. 不歧视各领域的贡献者。

    许可协议不应限制任何人把程序应用于任何领域。例如，不应规定程序不能应用于商业领域或基因研究领域。

  7. 许可协议的分发。

    程序附带的权利必须适用于程序的再散布无需加上其他的授权。

  8. 许可协议不应限定于 Debian。

    属于程序的权利，不应取决于该程序是否是 Debian 的一部分。如果某个程序是从 Debian 中提取出的，而又没有基于 Debian 进行分发或者应用于 Debian，但是根据该程序许可协议的条款，所有程序的使用者，包括程序被再分发之后的使用者，依然都享有该程序在 Debian 系统中相同的权利。

  9. 许可协议禁止损害其他软件。

    许可证禁止限制那些和软件许可一起分发的软件。例如，许可证禁止要求在同一媒介上分发的所有其他程序都必须是自由软件。

    回到基础著佐权

    著佐权的原则在于使用著作权来保障作品及其衍生品的自由，而不是如同专有软件的情况那样限制使用的权利。它也是对“著作权”术语的文字游戏。Richard Stallman 从他的喜欢说双关语的朋友给他写的一封信那里获得了这一灵感，信的内容是这样的：“著佐权：所有权利反转”。著佐权强制保护原始作品（通常是程序）或者修改的作品版本分发的最初的自由。如果某一程序的代码是基于著佐权发布下的程序衍生而来的，那么它就不可能作为专有程序再被分发。

    最广为人知的著佐权许可证，当然是 GNU 通用公共许可证以及它的衍生版本，GNU 宽通用公共许可证 (GNU LGPL) 和 GNU 自由文档许可证 (GNU FDL)。不幸的是，著佐权许可证通常来说是不互相兼容的。因此，最好只使用其中一个。

社区 Bruce Perens，一位有争议的领导者

Bruce Perens 是继 Ian Murdock 之后的 Debian 项目的第二位领导者。他的多样化和独裁化管理方式饱受争议。尽管如此，他依然是 Debian 项目的重要贡献者。特别是他编写的著名的 “Debian 自由软件指导方针” (该方针源自于 Ean Shuessler 的想法) 对于 Debian 项目帮助很大。随后，Bruce 又据此编写了著名的“开源定义”，并且移除了所有的 Debian 引用。

→ http://www.opensource.org/

当他离开项目时，是挺让人伤心的。然而 Bruce 依然和 Debian 保持着紧密的联系，因为他继续在政治界和金融界推广此发行版。他偶尔也出现在电子邮件列表中，表达他对 Debian 的建议以及其支持 Debian 的新举措。

最后的轶事，布鲁斯负责为 Debian 的各版本 ‘代码’ 命名。(1.1 — 抱抱龙, 1.2 — 巴斯, 1.3 — 宝贝, 2.0 — 小猪扑满, 2.1 — 玩具狗, 2.2 — 蛋头, 3.0 — 胡迪, 3.1 — 绿色队长, 4.0 — 玩具黑板, 5.0 — 望远镜, 6.0 — 三眼仔, 7 — 吱吱, 8 — 翠丝, 9(待发布) — 紫色章鱼, 10 (待发布) — 臭小子, 不稳定版 — 席德)。都取材自玩具总动员电影里的角色。皮克斯动画工作室推出完全以电脑动画构成的这部电影，领导 Debian 的布鲁斯当时在此工作室任职。’席德’ 此代码较特别，代表 不稳定 版。在电影里，是隔壁的男孩，总是打破玩具 — 所以不要太靠近 不稳定 版。另一方面，其英文名字 Sid 也可代表 ‘Still In Development’ 发展中的缩写。