一个可持续的开源软件系统
更新日志
免责声明：本系统仍在开发中。我期待阅读（并采纳！）您的（建设性！）反馈，并希望将其发展成为一个任何人都能轻松使用的完整模型。此外，我并非律师。即便我是，我也不是您的律师。请勿将本文内容视为法律建议或任何法律依据。如果您想确保其合法性，请咨询您的律师。最后，我与 License Zero 没有任何关联。我撰写本文是因为我认为它开发了一些很棒的工具，可以帮助我们实现目标。
在阅读其他内容之前，请注意：本文主要关注开发者工具，并非旨在直接用于库、数据库或操作系统等其他领域。它涵盖编译器、代码检查工具、包管理器、打包工具以及其他各种此类工具。我希望通过更加专注于特定类型的软件，我们能够提高成功的几率。
这并不是说这个模型不能应用于其他用例。只是我不会在这里讨论其他用例的影响，而且在这些用例的实现过程中可能会遇到一些意想不到的复杂性。
整个系统概述
由于本文旨在作为参考文章，因此这里将整个模型放在一起。点击各个链接，即可查看每个步骤的详细说明！
- 将 Parity 许可证应用于您的项目。
- 将 Apache 2.0 许可证应用于您项目的第三方贡献。
- 建立一个赞助/众筹平台，并确保它有一个级别，可以向赞助商授予许可。
- 将赞助者许可应用于您的项目。
- （可选）使用其他 License Zero 许可证处理其他许可。
- 请阅读本文，了解为什么要做这件事。
- 当以上收入足以养活你时，就可以辞掉现在的工作了。恭喜你，你现在拥有了一份成功的自由软件事业！
模型详解
我提出的模型旨在引导我们的社区回归自由软件模式——也就是采用所谓的Copyleft许可——并以此为资金来源，向维护者支付报酬。这种工作流程与Red Hat或MongoDB等公司使用的许可模式本质上并无不同，但它更加具体，更适合由一到两位开发者维护的小型项目，并且也适用于“开发工具”的维护者，而大多数大型开源公司使用的许可并未涵盖这一用户群体。最后我会对整个模型进行总结，但首先，我想先介绍一下这一切背后的动机。
平价许可证
将 Parity 许可证应用于您的项目。
该模型的第一步是使用强版权许可——类似于 AGPL，但在这种情况下，我更喜欢Parity License，因为它堵住了“devtools 漏洞”——也就是说，它对使用你的开发工具（linter、编译器/转译器、编辑器等）的任何人，而不仅仅是“链接”你的工具的人，或者在 Affero GPL 的情况下，“使用你的服务”的人，都强制执行相同方式共享的要求。
要应用许可证，只需将许可证文本LICENSE-PARITY复制到工具根目录下的一个文件中即可。如果您使用的是能够识别SPDX 许可证表达式的包管理器（例如 NPM 和 Cargo），则要查找的 ID 为Parity-6.0.0.
考虑到目前有很多小型团队开发的开源项目实际上是开发者工具，我认为这是一个亟待弥合的关键差距。Parity License 的另一个优点是它对人类来说更易于阅读，甚至明确地考虑到了那些最初不了解许可条款的人，只要他们在了解条款后开始遵守，就可以获得宽恕。我个人最喜欢这个许可的另一个原因是，它允许其他人使用比 Parity 本身更宽松的许可来发布自己的软件，因此它不像其他 copyleft 许可那样具有“病毒式传播”的特性。
我们希望通过这项许可决定达到什么目的？
- 确保自由软件社区中的每个人都能自由使用我们的软件，前提是他们也共享自己的软件。
- 打开许可协议的大门，让那些想要编写专有软件的个人和公司必须以某种方式做出贡献。
- 堵住任何可能允许专有用户绕过这些规定的使用漏洞。
第三方贡献
将 Apache 2.0 许可证应用于您项目中的第三方贡献。
当然，一旦我们开始处理以授予专有许可为目的的 copyleft，我们就会遇到整个模型中最棘手的部分：确保人们仍然可以为你的项目做出贡献。
作为一名非法律专业人士，我只能就此给出一些模糊的建议，但我个人的理解是，如果想要实现这种工作流程，项目中的每一个贡献者都必须同意几种方案中的一种：
- 同意以宽松的许可证（如 MIT 或 Apache 2.0）许可其所做的更改。
- 同意授予您向第三方授予私人许可的权限，同时保留其自身的版权。
- 将他们的版权转让给你。
最终选择哪一个取决于你，但你必须确保这一点明确无误，例如，通过在你的文档中注明CONTRIBUTING.md，或者通过贡献者许可协议。
就本文而言，我们将采用第一种方案：第三方贡献代码采用Apache 2.0许可。Apache 2.0 是一种非常宽松的许可，与 MIT 和 BSD0 许可非常相似，但它还包含授予专利许可的条款，这在当今被认为非常重要。
所以，请复制许可证文本，并将其放入LICENSE-APACHE项目根文件夹中一个名为 `<filename>` 的文件中。如果您使用的是带有 ` license<field>` 字段的包管理器，则其新的 SPDX 表达式为 `<exception> Parity-6.0.0 AND Apache-2.0:<fieldname ...
如果您想采用其他方法，或者即使对于 Apache 许可协议，您仍然希望使用 CLA，您可以访问Project Harmony获取一些模板，甚至还有一个协议选择器。您还可以为您的 GitHub 代码库设置一个CLA 机器人，以自动完成签署过程。
等等，你可能会问，这一切不都是为了可持续性和软件自由吗？为什么贡献者要付出这么多却得不到任何回报？我的回答是，你不应该在没有某种补偿的情况下接受贡献者提交的重要的补丁。一旦你从这套系统中获利，我认为将部分收益分配给那些为你的项目提交重要修改的贡献者是合乎道德的做法。更进一步，你应该让定期贡献者成为项目的正式合作者，并与他们更公平地分配赞助和许可协议的收益。具体细节取决于你——以及他们。
众筹平台
建立一个赞助/众筹平台，并确保它有一个级别，可以向赞助商授予许可。
根据你的团队情况，你有以下几种选择：
- 如果你是项目的唯一核心开发人员，我建议你注册GitHub Sponsors或Patreon（如果这两个平台都不可用的话）（截至撰写本文时，Sponsors 仍处于测试阶段，由于 GH 正在解决各种问题，赞助帐户正在逐步发放）。
- 如果你在一个团队中，我建议使用像OpenCollective或类似的工具。
你应该设置一些基本的赞助等级，并提供相应的奖励。例如，提供一定时长的支持服务、在README文件中将他们添加到“感谢名单”中，甚至将他们的logo醒目地展示在你的项目网站上。尽情发挥创意吧！
不过，最重要的是要决定哪个层级允许用户在闭源环境下使用你的软件。由于这本质上是一种订阅模式，我建议你考虑到这一点，设定一个合理的层级。
赞助人许可证
将赞助者许可应用于您的项目。
请下载赞助者许可协议并填写完整，然后将其放入PATRONAGE.md项目根目录。
这段法律条款将授予任何希望将您的软件用于专有用途的人以个人订阅许可。需要注意的是，这些许可仅限单个开发者使用，且仅在赞助商终止赞助后才有效。
但如果您想向某人或某个实体授予批量许可呢？或者想让朋友或友好项目一次性获得许可条款的全面豁免呢？这就需要额外的许可了。
处理其他许可事宜
使用其他 License Zero 许可证处理额外的许可事宜。
现在，还有几个重要的许可场景我还没提到。如果你只想给朋友或合作伙伴一次性豁免许可该怎么办？如果是出售单次购买许可呢？或者向企业批量出售企业许可呢？是的，在这种情况下，你需要更专业的许可方案。
License Zero 工具已经涵盖了其中一些用例，所以我建议您前往安装他们的工具，并用它来尽情地授予豁免和私人许可证！
再次重申：我与 License Zero 没有任何关联，我这么做纯粹是因为我认为他们的工具和授权方式是实现我目标的最佳途径。因此，我非常乐意为他们提供支持！
好了，就这些！你完成了！去创造一些精彩的东西吧！祝你编程愉快！
一些背景信息
自由开源软件的兴起、GitHub 的风靡、以语言为中心的包管理器所催生的生态系统，以及企业对开源的接受和参与，共同造成了一种极其不可持续的局面：对于庞大的开发者群体（无论是专业人士、业余爱好者还是学生）而言，自由分享源代码和工作成果已成为常态而非例外。以至于在许多以前以闭源为常态的场景下，我们现在也理所当然地认为源代码是可用的。开源的梦想（正如开源促进会所定义的那样）实际上已经实现。
但这又把我们引向何方呢？
沉浸在受欢迎的快感中，沉浸在其他人自愿使用我们的代码来取得伟大成就的兴奋中，我认为我们有点得意忘形了，忘记了关心最重要的事情：我们自己和我们的福祉。
自由软件，正如自由软件基金会（FSF）和其他自由软件倡导者所定义的那样，为解决部分问题提供了答案：通过创建一个自由软件的世界，在这个世界里，某些权利得到相互保障，我们就能确保社区的长期可持续发展，并抵制企业剥削。这通过软件许可来实现，这种许可在许多方面对企业利益不利，但对软件开发社区却十分友好：“只要你帮我，我也会帮你。”
可惜的是，OSI及其努力扼杀了当时这种模式日益增长的受欢迎程度，我认为这对我们的社区造成了巨大的损害。
你看，虽然许多开发者（以及雇用他们的公司）都乐于使用通过 GitHub、NPM、Ruby Gems 和各种其他分发方式免费提供的软件，但维护者们却在开源可持续性危机中濒临崩溃：维护者们精疲力竭，被日益庞大的社区对他们通常只能在“业余”时间参与的项目的需求压得喘不过气来，同时，他们还会因为任何试图实施更可持续模式的尝试而受到惩罚，例如最近基于广告的资金争议。
不知为何，维护者们总是被要求无偿地从事一份几乎相当于全职工作的工作，或者依赖于一些最终只会让那些足够受欢迎的人受益的慈善捐助，例如众筹和赞助平台。请记住，工作就是工作，即使是开源项目也不例外，强迫他人为你无偿工作最终是不道德的。
经过一段时间的思考和对各种可能性的考察，我认为我已经找到了一种改善现状的方法：让维护者能够证明他们投入时间在项目上的合理性，同时继续确保源代码的免费可用性，而无需依赖陌生人的慷慨捐助。也就是说，从“施舍”转变为“公平交易”。
更新日志
- 更新了原有的贡献者许可协议 (CLA) 部分，建议第三方贡献使用 Apache-2.0 或类似的宽松许可协议，以简化整个流程。CLA 文档仍然保留，供有兴趣采用此方案的用户使用。