# 选择一个许可证
当选择为项目应用一个许可证时,如果可能,请尽量选择一个而不是建一个新的。选择已有的许可证有两个原因:
-
熟悉度。如果你使用最流行的三,四个许可证之一,人们会感到在使用代码前不需要阅读这些法律条款,因为他们之前已经阅读过了。
-
质量。除非你有一个可以支配的律师团队,否则你很难得到一个法律坚实的许可证。这里说的许可证时大量思想和经验的产品;除非你的项目确实有不同寻常的需要,你不太可能做的更好。
关于应用这些许可证的某个到你的项目,见[Chapter 2, *起步*](# "Chapter 2. 起步")的[the section called “如何为你的软件应用许可证”](# "如何为你的软件应用许可证")。
### MIT / X Window System License
如果你的目标是希望代码能被最大可能数量的开发者和衍生作品使用,而且你对这些代码用于私有程序不太在意,选择MIT / XWindow System许可证(这样命名是因为它是麻省理工学院发布的X Window System代码的许可证)。该许可证的基本信息是“你可以任意的自由使用这些代码。”它与GNU GPL兼容,而且简短、简单和易于理解:
~~~
Copyright(c) <年份> <版权所有者>
现授予的权限,免费向任何人索取该软件和相关的文档文件
(“软件”),以处理软件,没有任何限制,包括但不限
于使用权,复制,修改,合并,出版,发行,授权,和/或销
售软件的副本,并允许的人提供的软件是这样做,但须符合
下列条件:
上述版权声明和本许可声明中应包括所有副本或实质性部分
的软件。
该软件是“按原样”提供,不做任何保证,明示或暗示,包
括但不限于适销性,针对特定用途的适用性和非侵权的。在
任何情况下,作者或版权持有人对任何索赔,损害赔偿或其
他责任,无论是在一项行动的合同,侵权或其他因出于或有
关的软件或利用等交易必须软件。
~~~
(取自[http://www.opensource.org/licenses/mit-license.php](http://www.opensource.org/licenses/mit-license.php)。)
### GNU General Public License
如果你不希望你的项目代码用于私有程序,或者如果你对代码是否用于私有程序毫无在意,请选择GNU GPL([http://www.fsf.org/licensing/licenses/gpl.html](http://www.fsf.org/licensing/licenses/gpl.html))。GPL可能当今世界上是最广泛使用的自由软件许可证;这种快速的识别性本身就是GPL的主要优点。
当编写代码库时,也就是说代码主要被用于其他程序,请考虑清楚GPL设置的这个限制是否与你的项目目标一致。在某些情况下—例如,当你试图取代另一个完成同样功能的竞争私有库时—如果以可以将其混入私有程序的许可证方式分发代码会有一些战略意义,即使你并不想这样做。自由软件基金会甚至为这种情况设计了一种替代GPL:*GNU Library GPL*,不久之后更名为*GNU LesserGPL*(大多数人一直使用首字母缩写*LGPL*)。LGPL比GPL有更宽松的限制,可以与其他非自由代码轻松的混合。然而,它也有一些复杂,需要花一些时间理解,所以如果你不会继续使用GPL,我建议你使用MIT/X样式的许可证。
### GPL是自由还是不自由?
选择GPL的一个后果就是会有—小的,但不是无限小—的可能卷入GPL是否为真正“自由”的争论中,考虑到它为你如何处置代码设置了一些限制—也就是代码不能以其他任何许可证分发。对于某些人,这些限制的含义是GPL比诸如MIT/X的宽松许可证有“较少的自由”。这种争论会一直在继续,当然,因为“更多的自由”比“较少的自由”更好(毕竟,谁不喜欢自由?),下面是这些比GPL更好的许可证。
这种争论是另一场圣战(见[Chapter 6, *交流*](# "Chapter 6. 交流")的[the section called “避免圣战”](# "避免圣战"))。避免参与,至少不要在项目论坛。不要试图证明GPL更自由或是更不自由,或者比其他许可证更自由。相反,强调你的项目选择GPL的原因。如果许可证的可识别性是一个原因,说出来。如果是为了强制衍生作品的自由许可证,也说出来,但是拒绝陷入这是否会使代码更自由的讨论。自由是一个复杂的主题,如果术语继续用于作为事实的掩饰,这种讨论毫无意义。
因为这是一本书,而不是邮件列表讨论,然而,我必须承认我从没有理解“GPL是不自由的”论据。GPL设置的唯一限制是防止人们设置*进一步*限制。说这样不自由对我来说就像是在说失去法律保护的奴隶制减少了自由,因为它防止了某些人拥有奴隶。
(噢,如果你陷入了这样一场争论,不要使用激烈的类比来提升自己的证据。)
### 那BSD许可证呢?
有大量开源软件使用*BSD许可证*(或者有时*BSD样式的许可证*)分发。原始的BSD许可证用于Berkeley软件分发版本,是加利福尼亚大学分发的Unix实现的重要部分。该许可证(完整的文本在[http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6](http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6)的2.2.2)与MIT/X许可证有相似的精神,除了这个条款:
> *所有提及该软件特性或使用的宣传材料必须包含如下致谢:该产品包含加州大学Lawrence Berkeley实验室的软件。*
这个条款的出现不仅使得最初的BSD许可证不兼容,也设置了一个危险的先例:其他组织也在*他们的*自由软件中设置了类似的广告条款—用他们自己组织的名称代替“加州大学,Lawrence Berkeley实验室”—软件分发商面对了一个日益增长需要显示什么的负担。幸运的是,许多使用这种许可证的项目注意到了这个问题,并删除了这个广告条款。在1999年,甚至加州大学也放弃了这个条款。
结果是修订的BSD许可证,仅仅是删除广告条款的原始BSD许可证。然而,这个历史使得“BSD许可证”有一些暧昧:它指的是原始的还是修订的版本?这就是我倾向于MIT/X许可证的原因,本质上是相同的,但不会面对这种不明确。然而,也有一个选择修订的BSD许可证而不是MIT/X许可证的原因,也就是BSD有这个条款:
> *在经过特定的预先书面许可之前,<组织>的名称和贡献者的名称都不可以用于支持或提升此软件衍生的产品。*
不清楚如果没有这个条款,软件的接受者是否拥有使用许可者的名称的权利,但这个条款清除了这个可能的疑问。对于担心商标控制的组织,修订的BSD许可证可能比MIT/X更好。大体来说,一个自由主义的版权许可证并没有暗含了接受者可以使用或削弱您的商标的权利—版权法和商标法是两个不同的东西。
如果你希望使用修订的BSD许可证,这里有一个模板[http://www.opensource.org/licenses/bsd-license.php](http://www.opensource.org/licenses/bsd-license.php)。
- 前言
- 为什么写这本书?
- 谁应该读本书?
- 资料来源
- 致谢
- 免责声明
- 1. 介绍
- 历史
- 现状
- 2. 起步
- 从你拥有的开始
- 选择许可证并应用
- 设置风格
- 通告
- 3. 技术基础设施
- 一个项目需要什么
- 邮件列表
- 版本控制
- Bug跟踪
- IRC / 实时聊天系统
- RSS供稿
- Wikis
- 网站
- 4. 社会和政治的基础架构
- 慈善独裁者
- 共识为基础的民主(Consensus-based Democracy)
- 写下所有的内容
- 5. 金钱
- 参与的类型
- 长期雇佣
- 作为一些个体出现,而不是一个整体
- 公开你的动机
- 钱不能让你可爱
- 契约
- 资助非编程活动
- 市场营销
- 6. 交流
- 人如其文
- 避免常见的陷阱
- 刺儿头
- 处理成长
- Bug跟踪系统中无对话
- 公开性
- 7. 打包、发布和日常开发
- 版本号
- 发布分支
- 稳定发布版本
- 打包
- 测试和发布
- 维护多发布线
- 发布和日常开发
- 8. 管理志愿者
- 从志愿者中获取最多
- 像分担技术任务一样分担管理任务
- 转化
- 提交者
- 荣誉
- 分叉
- 9. 许可证,版权和专利
- 术语
- 许可证的方面
- GPL和许可证兼容性
- 选择一个许可证
- 版权分配和所有权
- 双许可证模式
- 专利
- 深入资源
- A. 自由版本控制系统
- B. 自由Bug跟踪系统
- C. 为什么我要关注车棚的颜色?
- D. 报告bug的样例指导
- E. 版权