Yeah, most enterprise deployments of Incus use OIDC for authentication and then OpenFGA for authorization with permissions typically synchronized with something like AD/Entra.
TLS certs remain used for some role account type stuff and as a break glass type of access for when OIDC is unavailable and there's an emergency. A nice characteristic of TLS certificates is that they can be generated safely in a HSM which you can then dump into a safe, works well in the corporate world, much better than passwords for this kind of thing.
It's very very different between the UI and Incus itself :)
The Incus teams are low level system engineers who develop in Go or C.
The UI is a pile of typescript which none of us really want to understand/touch any more than strictly needed.
The Incus UI is a soft fork (really just a small overlay) on top of the LXD UI to adjust for the API differences between LXD and Incus and for fixing the few big gripes we had with the LXD UI. Because both projects are under the same license, we can actually just follow what happen in LXD UI and pull in code from it.
Incus is a very different beast. The whole reason the project had to be started is because of Canonical's series of changes which eventually led to a re-licensing of LXD to AGPLv3. With Incus remaining Apache 2.0, none of us can even look at the LXD code without risking being "tainted". We cannot import any code from LXD since that license change and we never have. However LXD has no problem with importing Apache 2.0 code into an AGPLv3 codebase, which they have quite actively been doing.
In short Incus is a hard fork of LXD, we don't look at any LXD code or even at their issues or release announcements (mostly because it's not useful for those two). That means that everything that happened in Incus since December 2023 has been completely independent of LXD.
The Incus UI is a soft fork of the LXD UI, it's rebased every time they push a new version out and our goal is to keep the delta as small as possible as it's something we want to spend as little time on as we possibly can. It's also why we always package it as "incus-ui-canonical" to make it very clear as to what it is.
There are also other UIs out there that could be used, sadly last I checked none came close to the feature coverage of the LXD UI or they had dependency on external components (database, active web servers, ...) whereas what we want is a UI that's just a static javascript bundle which then hits our REST API like any other client.
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...
Of course following the move and going AGPLv3 would solve the project contribution issue.
In fact it'd back Canonical into an interesting corner as Incus would be allowed to freely take LXD changes, but the opposite would not be possible unless they let go of the CLA.
It certainly would put Incus in a great situation, if it wasn't for the fact that we think keeping the Apache2 license is the right thing to do. The Go packages provided by Incus are used in hundreds of other codebases, a switch to AGPLv3 would cause those codebases to have to follow which would only lead to reduced adoption for Incus and a lot of pain in the Go ecosystem as a whole.
And then there is the fact that many large companies, including some that have been relying on LXD in the past, have policies specifically against the consumption of AGPL code. One prime example of that would be Google, which last I checked make up more than 50% of the LXD user base thanks to LXD being used on Chromebooks for the Linux shell feature.
Overall, the thing I hate most with this change is that it's going to make what was otherwise a pretty cordial relationship between the two projects now turn into a very stressful one where we need to basically be careful not to look at each other's stuff...
It may seem that LXD and Incus were straight up competitors, but in reality, we were doing behind the scenes debugging together, sending each others' link to pull requests and specifications, ... this effectively all ends today and it's a shame.
They changed COPYING from Apache2 to APGLv3 without introducing any SPDX headers or similar to denote what is Apache2 and what isn't. So yes, while AGPLv3 is compatible with Apache2, it doesn't grant anyone the right to relicense code.
Anyone is allowed to take my Apache2 code and do what they wish with it so long as it remains Apache2, you can't just go and replace the license text from one license to another and call it good, that code is still Apache2.
Anyone is welcome to use my code in a proprietary piece of code, indeed the Apache2 license allows it.
What it doesn't allow is for my code to be re-licensed to AGPLv3 nor can they grant themselves a license to do whatever they want (their CLA).
So indeed they could keep importing Incus bugfixes and new features into LXD, but that code would need to have an exception carved out in their current contribution requirements as the code would not come from an author that has signed the Canonical CLA nor would it be under the AGPLv3 license.
They would also need adequate tracking of this so they don't accidentally assume that the code belongs to them and that they can re-license it as they wish for other projects. Also anyone who stumbles onto that code in the LXD codebase should be properly informed that they can include that code in a non-AGPLv3 project as that bit of code is Apache2, not AGPLv3.
It is used for Crostini. Specifically, ChromeOS uses corssvm to run a virtual machine in which it runs LXD and then creates containers inside of that VM through it.
Google has sent the occasional bugfix, usually for pretty complex issues (hard to hit race and the like) but weren't involved in project maintenance or even very actively talking to us. We'd usually bump into the Crostini folks at conferences once or twice a year and just talk over dinner.
The LXD project had over 300 contributors over the years which while not up to par with insanely large projects like Kubernetes or Linux is still pretty respectable.
So achieving similar level of contributions to a fork would already be pretty nice. It's hard to predict the community reception of the fork though and whether that will lead to more contributions than has been seen in the past when the project was backed by Canonical or if there being two active codebases will result in a reduced set of contributors to both.
It doesn't. The LXD team does make and support the snap, but LXD itself doesn't depend on it at all.
The majority of LXD users are actually on ChromeOS which is Gentoo based and uses a LXD ebuild package. Debian has a native .deb package too, so does ArchLinux, Alpine, OpenSUSE and a few others.
LXD however does need some special code to handle being run as a snap, that part can become a bit annoying to account for and test at times.
As mentioned, this isn't my fork, it's a fork made by Aleksa who's been the long time LXD packager for OpenSUSE as well as someone very involved within the container space, both userspace (runc, umoci, containerd, ...) and in the Linux kernel space.
I've just been helping out getting it to actually be functional and providing a bit of a laundry list of things I'd do differently should I be starting LXD from scratch now, which a fork like this now makes possible.
TLS certs remain used for some role account type stuff and as a break glass type of access for when OIDC is unavailable and there's an emergency. A nice characteristic of TLS certificates is that they can be generated safely in a HSM which you can then dump into a safe, works well in the corporate world, much better than passwords for this kind of thing.