Question

有三种处理自由代码和文档版权所有权的方法，许多人为此做出了贡献。第一种是完全无视版权的问题（我不建议如此）。第二种方法是从项目中工作的每个人那里收集一个贡献者许可证协议（CLA），明确项目对使用个人贡献的权利。这通常对大多数项目已经足够了，更好的是在一些司法权中，CLA是可以通过email发送的。第三种方法是从贡献者那里获得真正的版权协议，这样项目（例如一些法律实体，通常是非盈利）就是所有东西的版权所有者。这通常是无懈可击的方法，但也是贡献者的负担；只有少数项目坚持如此。

请注意，即使在集中式的版权所有权时，代码^[30]还是自由的，因为开源许可证并没有给版权持有者可以将所有代码的拷贝收回所有的权利。所以即使作为法律实体的项目突然转向开始将所有的代码使用限制许可证发布，也不会给公共社区带来什么问题。其他开发者可以简单的根据最新的代码拷贝开始一个分叉，并当作没发生任何事情一样继续。因为他们知道他们可以这样做，大多数被问及签署CLA或版权协议时会非常合作。

无为而治

大多数项目从来没有从他们的贡献者那里收集过CLA或版权协议。相反，只要代码是合理清除，而且贡献者愿意将其组合进项目，他们就会接受代码。

在通常情况下，这是正常的。但是偶尔会有人决定因版权侵害而诉讼，声称他们是问题代码的所有者，而且他们从没有同意这些代码由项目使用开源许可证分发。例如，SCO团队向Linux团队这样做的，细节见http://en.wikipedia.org/wiki/SCO-Linux_controversies。当这些发生时，项目没有文档说明贡献者正式的赋予使用这些代码的权利，可能会导致一些法律辩护。

贡献者许可证协议

CLA可能是在安全性和便利性之间提供了最好的折衷。一个CLA通常是一个发送给开发者填写并发回项目的电子表格。在大多数司法中，邮件提交已经足够。或许需要安全电子签名；可以咨询律师找出对你的项目最合适的方法。

大多数项目使用两个些许不同的CLA，一个针对个人，一个针对公司贡献者。但是在两种类型中，核心的语言是相同的：贡献者赋予项目"...永久的、全世界的、非独占的、免费的、特许自有、不能取消的版权许可证，可以用于重新制作、准备衍生作品、公开显示、公开操作、发放从属证书和分发这些贡献和此类衍生作品。"再次强调，你应当有一个律师确认CLA，但是如果你能了解所有这些程序，那样会很好。

当你从贡献者那里请求CLA时，请确认强调你不是要求真正的版权授予。实际上，许多CLA使用这些语句来提醒读者：

这仅仅是一个许可证协议；它不会转移版权所有权，也不会改变因任何目的使用自己贡献的权利。

下面是一些例子：

• 个人贡献者CLA：

  • http://apache.org/licenses/icla.txt

  • http://code.google.com/legal/individual-cla-v1.0.html

• 公司贡献者CLA：

  • http://apache.org/licenses/cla-corporate.txt

  • http://code.google.com/legal/corporate-cla-v1.0.html

版权转移

版权转移的含义是贡献者将自己的贡献赋予给项目版权所有权。理想情况下，需要书面完成并传真或邮寄给项目。

一些项目坚持完全的协议，因为如果开源许可证的条款需要强制时，一个单独的法律实体拥有整个代码基的版权会非常有用。如果没有单个实体有这样的权利，所有贡献者需要合作，但问题发生时可能某人没有时间或无法找到。

不同的组织对于收集授权的严苛程度不同。有一些仅仅是某个贡献者在公共邮件列表中的简单非正式陈述—类似“我这里将我的在该项目的代码授权，使用其余代码相同的许可证条款。 ”至少有一个我交流过的律师认为这样已经足够，大体推测，可能是因为它发生在一个版权授权已经非常普通和预期的方式，而且因为它代表了项目一方对于确保开发者真正意图的诚意努力。另一方面，自由软件基金会则进入对立的极端：他们要求贡献者物理上签署并邮寄一份文件，包含版权授权的正式描述，有时仅针对一份贡献，有时针对当前和未来的贡献。如果开发者被雇佣，FSF也会要求雇员签署这个东西。

FSF的偏执狂可理解的。如果某人违反了GPL关于将他们的软件组合到私有程序的条款，FSF会需要与之在法庭上斗争，他们希望他们的版权在这种情况发生时可以无懈可击。因为FSF是许多流行软件的持有者，他们认为这是真实可能的。无论你的组织是否有只有你所决定的需要类似的小心谨慎，请咨询律师。通常情况下，除非一些特别的原因需要你的项目拥有完全的版权授权，你可以直接采用CLA；他们对每个人都很简单。

---

^[30] 之后我使用的“代码”指的是代码和文档。