# 双许可证模式
一些项目希望通过双许可证模式资助自己,也就是私有衍生作品向所有者支付使用代码的版权,但代码对于开源软件依然免费。很自然,代码库比独立应用更适合这种方式。精确的条款各不相同。通常其属于自由的许可证为GNU GPL,因为它已经禁止了他人在未经版权持有者允许前,将覆盖的代码组合到他们的私有产品中,但是有时一些自定义许可证起到相同的效果。前者的一个例子是MySQL许可证,这里有描述[http://www.mysql.com/company/legal/licensing/](http://www.mysql.com/company/legal/licensing/);后者的例子是Sleepycat软件许可证策略,描述在[http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html](http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html)。
你或许有些疑惑:为什么明明GNU的GPL规定代码必须在较少约束的条款下发布,而版权持有者还可以提供私有许可证。答案是GPL的条款是版权持有者为所有其他人设置的;而所有者可以自由的决定*是否*对其本身应用这些条款。对此,一个好的理解方法是想象版权所有者在桶里有无数份软件的拷贝。每次它从桶中取出一个发送到世界上时,它可以决定是采用GPL,私有或其他许可证。这并不是仅仅与GPL或其他任何开源许可证相关,它仅仅是版权法所赋予的权利。
双许可证的吸引力在于,为自由软件项目提供了一种可靠的收入来源。不幸的是,它也可能干扰开源项目本身的一般动力性。问题是任何为代码作出贡献的志愿者现在开始为两个不同的实体贡献:代码的自由版本和私有版本。当然,贡献者会乐于贡献自有版本,因为这是开源项目的标准,如果是为他人的半私有收入贡献,她会感到可笑。由于双许可证的这一事实加剧了这种尴尬,版权所有者确实需要从所有贡献者收集正式的,签署的版权授权,从而才能保护自身之后不会受到不满的贡献者对于从私有收入中获取自己份额的指控。收集这种授权文件的过程意味着贡献者要严酷的面对这一事实,他们在为别人赚钱而工作。
不是所有的志愿者会因此而困扰;毕竟他们的贡献也进入了开源版本,这是他们的兴趣所在。虽然如此,双许可证是版权持有者赋予自己,而项目中的其他人所没有的特权的一个例子,而且一定程度上会引起一些紧张,至少对某一些志愿者。
在实践中,我们看到许多基于双许可证软件的公司确实没有真正平等的开发社区。他们只能从外部获得很小规模的bug修正和清理补丁,而通过内部源做大量艰苦的工作。例如,Zack Urloker,MySQL的副主管告诉我,公司通常最终会雇佣最活跃的志愿者。因而,尽管产品本身是开源的,使用GPL许可证,它的开发还是或多或少受到公司的控制,虽然也可能有人确实不满意这个公司把持着这个软件而分叉这个项目。一定程度上,这种威胁迫使公司政策的内容,但在也有一定几率,MySQL没有发现在开源世界或之外存在着接受的问题。
- 前言
- 为什么写这本书?
- 谁应该读本书?
- 资料来源
- 致谢
- 免责声明
- 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. 版权