Canonical published a new version of the container management system lxd 5.20, which is noteworthy Change license for the project and introducing the need to sign CLASS on the transfer of property rights to the code when accepting changes to LXD. The license to the code added to the LXD employees of Canonical has been changed from Apache 2.0 to AGPLV3, and the code of third-party participants, for which Canonical does not have property rights, remains under Apache 2.0. Since Canonical does not have the ability to change the license to the entire LXD code, the project will now be delivered under mixed conditions – part of the code for AGPLV3, and part for Apache 2.0. The transition to a new license is explained by the desire to unify a license with other Canonical server products, which use AGPLV3.
The code of old issues as before, remains available under the Apache 2.0 license, but all of the changes introduced into the overlocrated components will be published only under the AGPLV3 license, which will not allow the InCUS to transfer changes from LXD without transferring its code base to the AGPLV3 license. Apache 2.0 and AGPLV3 licenses have unilateral compatibility, which boils down to the fact that the code under the Apache 2.0 license can be included in the code under the AGPLV3 license, but not vice versa. Change means a complete termination of cooperation between LXD and InCUS projects, since the transfer of changes from LXD to Incus is interfered with a new license, and from Incus to LXD, the need to sign CLA, which Incus developers do not intend to sign.
AGPLV3 license feature is the introduction of additional restrictions for applications that ensure the functioning of network services. When using AGPL components in the operation of network services, the developer is obliged to provide the user with the source code of all changes made to these components, even if the software underlying the Service does not apply and is used exclusively in the internal infrastructure to organize the service