一些项目希望通过双许可证模式资助自己，也就是私有衍生作品向所有者支付使用代码的版权，但代码对于开源软件依然免费。很自然，代码库比独立应用更适合这种方式。精确的条款各不相同。通常其属于自由的许可证为GNU GPL，因为它已经禁止了他人在未经版权持有者允许前，将覆盖的代码组合到他们的私有产品中，但是有时一些自定义许可证起到相同的效果。前者的一个例子是MySQL许可证，这里有描述http://www.mysql.com/company/legal/licensing/；后者的例子是Sleepycat软件许可证策略，描述在http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html。

你或许有些疑惑：为什么明明GNU的GPL规定代码必须在较少约束的条款下发布，而版权持有者还可以提供私有许可证。答案是GPL的条款是版权持有者为所有其他人设置的；而所有者可以自由的决定是否对其本身应用这些条款。对此，一个好的理解方法是想象版权所有者在桶里有无数份软件的拷贝。每次它从桶中取出一个发送到世界上时，它可以决定是采用GPL，私有或其他许可证。这并不是仅仅与GPL或其他任何开源许可证相关，它仅仅是版权法所赋予的权利。

双许可证的吸引力在于，为自由软件项目提供了一种可靠的收入来源。不幸的是，它也可能干扰开源项目本身的一般动力性。问题是任何为代码作出贡献的志愿者现在开始为两个不同的实体贡献：代码的自由版本和私有版本。当然，贡献者会乐于贡献自有版本，因为这是开源项目的标准，如果是为他人的半私有收入贡献，她会感到可笑。由于双许可证的这一事实加剧了这种尴尬，版权所有者确实需要从所有贡献者收集正式的，签署的版权授权，从而才能保护自身之后不会受到不满的贡献者对于从私有收入中获取自己份额的指控。收集这种授权文件的过程意味着贡献者要严酷的面对这一事实，他们在为别人赚钱而工作。

不是所有的志愿者会因此而困扰；毕竟他们的贡献也进入了开源版本，这是他们的兴趣所在。虽然如此，双许可证是版权持有者赋予自己，而项目中的其他人所没有的特权的一个例子，而且一定程度上会引起一些紧张，至少对某一些志愿者。

在实践中，我们看到许多基于双许可证软件的公司确实没有真正平等的开发社区。他们只能从外部获得很小规模的bug修正和清理补丁，而通过内部源做大量艰苦的工作。例如，Zack Urloker，MySQL的副主管告诉我，公司通常最终会雇佣最活跃的志愿者。因而，尽管产品本身是开源的，使用GPL许可证，它的开发还是或多或少受到公司的控制，虽然也可能有人确实不满意这个公司把持着这个软件而分叉这个项目。一定程度上，这种威胁迫使公司政策的内容，但在也有一定几率，MySQL没有发现在开源世界或之外存在着接受的问题。