# GPL和许可证兼容性
私有不兼容与私有兼容许可证的最尖锐区别,也就是GNU GPL与其他许可证的区别。因为GPL作者的主要目标是提升自由软件,他们故意使它们的许可证不可能让GPL代码混入私有程序。具体说来,在GPL的要求中(见[http://www.fsf.org/licensing/licenses/gpl.html](http://www.fsf.org/licensing/licenses/gpl.html)的全文)有这样两点:
1.
所有衍生作品—也就是任何包含非琐碎量GPL代码的作品—也必须在GPL下分发。
1.
对于原始作品或衍生作品的分发没有其他附加的限制。(另一种表达是:“你不可以为接受者设置一些超过这里列出的进一步限制。 ”)
通过这些条件,GPL成功的让自由传播。一旦某个程序在GPL下设置版权,它的再次发布条款会像*病毒*—传播到与之组合的代码中,有效的使GPL化的代码无法用于闭源程序中。然而,同样的条款也使GPL与其他自由许可证无法兼容。一个常见的方式是其他许可证设置了一个需求—例如,需要以某种方式提及原始作者的荣誉条款—与GPL中“不得设置进一步的限制不兼容...”。从自由软件基金会的角度,这种二阶的后果是理想的,至少没有值得后悔的。GPL不仅仅保持你的软件的自由,也有效的推动*其他*软件强制自由。
这是否是提升自由软件地位的好方法这个问题是互联网上一场持久的圣战(见[Chapter 6, *交流*](# "Chapter 6. 交流")的[the section called “避免圣战”](# "避免圣战")),我们不做深入分析。重要的是GPL兼容性是我们选择许可证时的一个重要问题。GPL是最流行的开源许可证;在[http://freshmeat.net/stats/#license](http://freshmeat.net/stats/#license)大约是68%的份额,而第二高的许可证则只有6%。如果你希望你的代码可以自由的与GPL的代码混合—这里有大量GPL的代码—然后你必须选择一种GPL兼容的许可证。大多数GPL兼容的开源许可证也是私有兼容:也就是说,在该许可证下的代码可以用于GPL程序,也可以用于私有程序。当然,混合的*结果*不会互相兼容,因为一种是GPL,另一种则是闭源作品。但是真正相关的是衍生的作品,而不是你一开始分发的代码。
幸运的是,自由软件基金会维护了一个与GPL兼容或不兼容的许可证列表,位于[http://www.gnu.org/licenses/license-list.html](http://www.gnu.org/licenses/license-list.html)。本章讨论的许可证都会展现在这个列表中,兼容的和不兼容的。
- 前言
- 为什么写这本书?
- 谁应该读本书?
- 资料来源
- 致谢
- 免责声明
- 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. 版权