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...
perhaps add installation instructions in the README? Most people already know they need the binary to run that command. For those who don't, I don't recommend you baby them because next thing you know, they've downloaded the wrong binary and it doesn't run.
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.
I guess you already thought carefully about all this, but wouldn't you actually prevent them from reusing your code (in a closed version) if it were released under (A)GPL?
Because if you keep releasing your code under Apache 2, you prevent yourself from taking their code while allowing them to take yours. You could lose at this game.
If you released under AGPL, you would reverse the direction. They would not take your code without the CLA but you'd be fine with taking theirs.
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.
i don't know about you, but i have no interest in subsidizing bad policies of large companies with my leisure time, much less my work time that they're not paying me for. maybe those large companies should either abandon those policies or develop their own software without our help. or pay us
i agree with Proven's [dead]ed comment that "Free software doesn't exist to reward developers and contributors." in the sense that the reason it's good for free software to exist is that it rewards users, not developers and contributors
on the other hand, the events which cause it to exist are that developers and contributors write it, so in that sense it does exist because it rewards developers and contributors in some sense
different people find different things rewarding. perhaps some people do find it rewarding to subsidize large companies with bad internal policies. but i don't
Still permissive enough for the goals of Incus and for anyone using it as a component. You can even use the LGPL code in the AGPL build of LXD fine. But if they want to release a proprietary build containing the LGPL code, the LGPL code needs to be held at a bit of arms length, so it could be used as a library in proprietary code for example, but couldn't have patches intermingled and incorporated wholesale into it.
are you saying they're permitted to use your code in a proprietary piece of code but not in an agplv3 piece of code?
if that's not what you're saying, what is the difference between the latter and what they are in fact doing? are they removing your apache2 license headers or something?
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.
i think the apache2 license actually permits modifications of the code to be licensed under a different license, including microsoft's eula or the agpl, and doesn't require the original licensing to be preserved for the individual source files (like the mpl) or for the modifications to be kept separate, as a patch (like perl's artistic license), and this was an intentional choice on the part of the apache2 drafters
however, it seems to me that the copyright and license headers (if any) on the individual pieces of code you wrote must be preserved, as well as (as you say) the overall copyright notice:
> You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works
Is there some part of the Apache 2 license that insists that people using Apache 2 licensed code in a project clearly mark what code is Apache 2 and what code is under some other license? Of course not.
Nobody is relicensing the code on other people's computers. If you downloaded code under Apache 2, somebody other than you incorporating that same code into their AGPL project won't relicense the code on your computer, but it certainly will relicense the code on theirs.
> Is there some part of the Apache 2 license that insists that people using Apache 2 licensed code in a project clearly mark what code is Apache 2 and what code is under some other license? Of course not.
yes, there is
i quoted the relevant part of the apache 2 license in my sibling comment above
> You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works
Leaving the notice files in is in no way "marking which code is Apache 2 and which code is under some other license."
edit: this entire discussion evaporates if we abandon the idea that somebody would (or could) go through an AGPLv3 project that incorporated Apache 2 licensed code, and pull out just the Apache 2 code to use in another project. The only way to do that would be to download the Apache 2 licensed code from its original source and diff it against the AGPL project in order to distinguish the code you can use from the code you can't.
It doesn't make any sense. There's no sane preference for copy-pasting from the AGPL project rather than the original code that you've obtained under Apache.
i guess you could comply by leaving the apache 2 license in there but then not say which files it applies to, but then you'd be licensing the whole work under the apache 2 license
i don't think you can comply by just removing the apache 2 license
LGPLv3 is more restrictive than Apache 2. The point as that every source file will be under LGPLv3, because it will be Apache 2 code mixed with LGPLv3 code.
The Apache 2 code will remain Apache 2 code, but in a pointless way.
For the "relicensing" it will have to preserves license information, e.g.
> (C) new guy AGPL license text
> Also incorporates work with the following license
> (C) stgraber apache license text
In practice that is the same as being AGPL licensed because doing otherwise would violate new guy's license.
For the CLA nobody ever suggested they can do "whatever they want". What seems entirely possible however is for them to offer an entirely apache2 licensed version (the original version is apache2 and, only at their discretion, so are all future changes) as well as an AGPL licensed version.
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.
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.
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.
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.
While snaps are the more common way for people to install LXD, there are RPMs for LXD. I maintain the openSUSE ones and I believe there are ones for the RHEL/CentOS/Fedora family as well. Obviously, once incus is ready for packaging, I'll start packaging it for openSUSE as well.
At least on Fedora I've always found the RPMs either lagged pretty far behind version wise (at least the COPR repos, I can't remember if I tried the OpenSUSE ones or not? But I generally try not to use OpenSUSE RPMs due to differences that crop up between SUSE and RHEL families packages), and the snap version basically didn't work for all but the most basic cases.
I'd love an actually up to date RPM compatible with the RHEL family.
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.