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.
It's indeed still open source, but was moved from Apache 2.0 to AGPLv3 and from not having any requirements to contributions to requiring all contributors sign a CLA.
So it's definitely still open source, but the changes they made allows them to still look and import any change from Incus that they wish, whilst preventing us from looking at any LXD code without risk of tainting ourselves...
Thanks for the correction. I kind of remember this as a more hostile thing done by Canonical at the time but this fork announcement from that time does not support that view either. Perhaps I am misremembering the little I do remember.
My number one reason for moving away from using LXD in production after this change is that LXD is only available through snap, which caused multiple downtimes in the cluster because of the forced updates.
Exactly. And depending on whether you are installing it with snap or other package managers, like pacman in arch, it'll actually use differently folders for configs, so if you are writing automation for say automatically manage remotes without relying on the cli, you'll have to account for that. Better to just use Incus whenever possible.
https://github.com/canonical/lxd it's AGPL-V3