受LXD转向AGPLv3许可证影响的Incus项目

Incus项目是LXD容器和虚拟机管理器的分支，今年8月出现，作为对Canonical收购LXD的回应。除了新功能之外，最新的LXD 5.20版本还引入了一个重大转变：它从现有的Apache2许可证转移到AGPLv3。

Canonical决定将LXD项目的默认贡献更改为AGPLv3，以与我们的服务器端代码标准许可证保持一致。所有的规范贡献都已重新获得许可，现在属于AGPLv3。展望未来，对LXD的任何贡献将默认在AGPLv3下进行。 

然而，此举给Incus项目带来了重大挑战。但在继续之前，由于它们都是开源许可证，因此有必要为我们的受众澄清它们的主要区别。

AGPLv3是一个强大的左拷贝许可证。如果在服务器上修改并分发程序或运行修改后的版本，则必须在AGPLv3下发布整个源代码。这是为了确保所有用户都能从修改中受益，即使软件是作为服务在网络上运行的。

同时，Apache2是一个更宽松的开源许可证，因为您可以使用、修改和分发许可软件，而无需在同一许可证下发布您的修改。因此，它之所以受到青睐，是因为它能够集成到专有和开源项目中，而不需要强大的版权保留要求。

修订后的LXD许可证政策的影响

LXD的许可证政策从Apache2向AGPLv3的转变对最终用户几乎没有影响。该软件仍然是开源的，每个人都可以免费使用。然而，如果您开发并将包含LXD的软件分发给其他人，这并不适用。

正如我们已经提到的，与Apache2相比，AGPLv3许可证有更严格的要求，尤其是在共享修改和衍生作品方面。不愿意遵守这些要求的公司和开发人员可能需要重新考虑使用LXD或寻找替代品。

与此同时，LXD向AGPLv3的转变对Incus项目的未来提出了一些不确定性。首先，LXD和Incus之前的合作和相互贡献似乎已经结束。

Incus打算坚持其目前依赖Apache2的许可政策，使其几乎不可能使用AGPLv3保护和许可的项目的源代码。

另一方面，LXD项目不能继续依赖Incus带来的修复，因为不同许可证政策的混合带来了重大的法律挑战。因此，这两个项目之间的差异和不兼容性只会从此扩大。

最后但同样重要的是，引入规范CLA（贡献者许可协议）进一步增加了LXD项目的复杂性。贡献者现在必须同意CLA的条款，其中通常包括授予项目维护者对贡献代码的某些权利的条款。

总的来说，情况很复杂，没有明显的解决办法。一些人认为Canonical有意反对Incus项目，LXD许可政策的转变令人惊讶和意外。因此，我们将密切关注这种情况如何发展。