lxd

AFAIK LXD is still opensource, as are most if not all products from Canonical. I think the fork is because LXD when it was moved to Canonical made the community uneasy because of the way that they would integrate with Ubuntu lifecycle and tooling. https://github.com/canonical/lxd it's AGPL-V3

Please correct me if I'm wrong, but the post also links the "add Canonical CLA check #12665" [0], and my understanding is that "retain copyright" here is like a typical forum agreement where you going forward must agree to a perpetual worldwide unlimited license to Canonical that they can use as they please per [1]: >In effect, you’re giving us a licence, but you still own the copyright — so you retain the right to modify your code and use it in other projects. You explicitly do retain ownership, so you can then take that same code and contribute it elsewhere under any license you wish. The same author could contribute the same patch to both the LXD and the Incus fork. But some might object to being required to allow Canonical to specially license as they want. So your characterization seems unfair, and then gets kind of nasty at the end:

You're both kinda correct. What Stephane was complaining about is the whole Snap package for lxd has been marked as AGPL, and that's not correct. Check in the store, down, in the license info section: https://snapcraft.io/lxd Edit: also, from what I see in the commit, it doesn't make much distinction between what's AGPL and what not. https://github.com/canonical/lxd/pull/12663/commits/b8ff449d...

I hope this doesn't affect LXC negatively. LXC and LXD share plenty of contributors. https://github.com/lxc/lxc/graphs/contributors https://github.com/canonical/lxd/graphs/contributors I use an "unprivileged LXC container" setup on several Debian bullseye hosts. It works fantastic, and each LXC container feels like a real server. Compare that to Docker's "one-container-one-process" philosophy, reinventing the wheel by awkwardly composing multiple containers.