不要签署CLA

绝大多数开源项目都附带有CLA或Contributor LicenseAgreement，并且要求您在合并补丁之前先进行签名。这些协议通常要求您超越软件提供的权利，而应根据软件分发的许可进行贡献。而且您永远不应该签署一个。

自由和开源软件许可将显式自由授予三类：维护者，用户和贡献者。一个重要的自由是对软件进行更改并将这些更改分发给公众的自由。自然的做法是为上游项目做出贡献，这应该是一个值得感谢的项目。 CLA以此来代替这种感激之情，企图以某种方式屈服于这些自由，这可能会违背许可证的规定，但与精神背道而驰。

CLA是贡献者对该项目的真诚贡献的唯一途径。许多人（包括我本人）在我的贡献将帮助服务于永久永久性开源的项目的前提下，为开源项目做出了贡献，而CLA为项目维护者提供了一种规避这一点的手段。 CLA实际用于的目的是使项目维护者能够以更加严格的软件许可来重新许可您的工作，包括并使其完全封闭。

我们已经看到过这种情况。考虑Redis Labs的崩溃，他们采用了非免费的1反常用条款2，并使用其CLA来筹集任何外部贡献。作为对社区投入大量时间用于软件的感谢，他们从软件的底层撤出了软件，并将其重新设计为使用淫秽的非免费产品来赚钱。开源是对社区的承诺。一旦完成，就无法收回。如果您有退出舱门，那么您将无法获得与开源项目相关的收益。您可能会争辩说，根据自己的意愿去做自己想做的事情，但是将其开源是对这项权利的明确放弃。

对您而言，对您来说是对的：如果您正在为开源做贡献并且希望保持这种状态，则不应签署CLA。当您向项目发送补丁时，您将向他们提供与他们相同的权利。关系是平等之一。这是一个健康的平衡。签署CLA时，您将给予他们不平等的权力。如果您不愿再提出真诚的补丁程序，那么很容易将项目分叉并在单独的地方进行更改。每个开放源代码许可都授予您这项权利，而且操作简便。任何想要使用您的工作的人都可以在上游软件上应用您的补丁。不要签署您的权利！

那Apache FoundationCLA呢？此CLA是更好的CLA之一，因为它不会将您的作品的版权转让给ApacheFoundation。我没有第1和3-8条的内容。但是，术语2的范围太广，我不会签署此CLA。

Linux内核开发人员证书来源如何？我在此赞扬Linux内核的方法。它涵盖了他们的基础，同时仍在大力保护补丁所有者的权利。这是一条简短的声明，几乎没有法律效力，也很少鼓吹同意它（只需在您提交的消息中添加“签名人”）。我赞同。

称我为小人物，但当我的目的是从公地中删除软件时，我不能真诚地称其为“公有条款”。 ↩︎