So Canonical has now gone ahead and relicensed #LXD to AGPLv3 (kinda) and added a CLA!
https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/
@stgraber Heh, looking at the relicense PR and the first change it to change AUTHORS to "Unless mentioned otherwise in a specific file's header, all code in this project is released under AGPLv3.", and thinking "oh, have they then documented the APL2 contributions in each specific file?"
(Narrator: no, they didn't)
@foo Of course they didn't. They then released LXD 5.20 with that change in it, so who knows what the license of LXD 5.20 actually is nowadays!
And to add to the fun, Canonical has changed the LXD package license to just "AGPLv3" which is obviously incorrect.
I filed a complaint here: https://forum.snapcraft.io/t/incorrect-license-information-for-the-lxd-snap/38121
@stgraber Their announcement just says "changing the Default", but yeah, encourage people to not sign CLA's!
@purpleidea COPYING in the repo is AGPLv3 and there's no sign of SPDX headers or other metadata to indicate what code is under Apache2...
@stgraber look to commit where they changed it? If they removed your copyrights that's not allowed.
@stgraber IANAL, but if one combines AGPL-3.0 with Apache-2.0, the resulting *binary* can only be distributed under the terms of the AGPL-3.0. This is how "GPL compatible" licensing works.
https://www.apache.org/licenses/GPL-compatibility.html
Disclaimer: IANAL.
The only thing in your hand "against" Canonical right now is that they're not fully complying with the Apache license as it requires prominent notices when files are changed.
You licensed your work under the Apache license. You therefore gave anyone (including Canonical) the irrevocable right to use it in code bases with other licenses (even proprietary ones!) as long as the original terms are still followed for that code.
That's why #copyleft licenses exist.
@Atemu I have no problem with my code being used in other projects regardless of their license, that's the whole reason why we picked the Apache2 for the project.
However as you pointed out, they can't actually re-license the code, those bits will forever remain Apache2 and they need to include the license and have proper notices in the code.
For new contributions, if they want to keep taking from Incus, they will need to bypass their own requirements as it's currently AGPL-only and CLA-only.
@stgraber Regarding some of the tech news coverage of this, I keep seeing "fork of LXD" mentioned. But if the founders and most active developers of a project rename and move it, I cannot see that as a fork. It has simply been renamed. LXD continuing separate development means it is a fork of Incus, not the other way around. I think the language here is important.
@kees That's definitely an interesting point of view and one that I'd agree with now.
Incus was forked by @cyphar who's been the long time packager of LXD in OpenSUSE, so at that time, it certainly was a fork of LXD. However after the decision was made to move it to the Linux Containers project and have the other maintainers join in, we indeed now find ourselves with all the original LXD folks behind Incus, effectively flipping the table on who's a fork :)
Same license description was in the homebrew change and was merged recently.