LXD now re-licensed and under a CLA
stgraber.orgthe main reason there's a version 2 of the apache license is to ensure that it's clearly legal to incorporate apache-licensed code into gpled systems such as this new version of lxd
it is correct that the ubuntu company cannot prohibit people from copying and modifying stephane's code, or indeed the entire previous version of lxd, under the terms of the apache license. but they can certainly keep using his code in new versions of lxd under agpl
in fact, apple can use stephane's code in a proprietary lxd derivative if they want to. that's what the apache license is designed to permit
if you want to prevent people from using your code in a more-restrictively-licensed fashion, don't use the apache or other bsd-like licenses; use a copyleft license like the agpl. and don't sign a cla
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.
The reason they need the CLA is to exempt themselves from the burdens of the AGPL license, however.
It's not much work to use Apache 2.0 in a proprietary (or AGPLv3) project. Unlike the AGPLv3 it doesn't impose many burdens or the project using it.
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.
I know, you mentioned companies disliking AGPL.
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
I wonder if the answer here is LGPL?
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.
i'm not entirely clear on what you're saying
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
you're right about 'jeez' and i've removed it
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.
agreed, once further modifications accrete
> 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).
According to
https://softwarefreedom.org/resources/2007/gpl-non-gpl-colla...
it does both with minor caveats.
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 look like Stéphane has a direct problem with Canonical or anyone else using his code - it’s why he licensed it under Apache in the first place. He’s mostly calling attention to the attempt to relicense as AGPLv3 some code that Canonical has no authority to relicense.
The fact that contributions to LXD are now under AGPLv3 and require signing canonical’s much maligned CLA are concerns but I think the author nuances them well : it’s unfortunate (in his pov - me, I always prefer a Copy left license) but well within Canonical’s rights.
(Edit: Stéphane beat me by a minute and explains his own position better than I could ;)
Looks like Canonical also messed up the licensing in their package: https://forum.snapcraft.io/t/incorrect-license-information-f...
"As a result, Canonical cannot release LXD under the AGPLv3 license and likely never will be able to. LXD is now under a weird mix of Apache2 and AGPLv3 with no clear metadata indicating what file or what part of each file is under one license or the other."
IANAL but that's not true? You can take Apache2 and relicense it under AGPL? You can take "less copyleft" license and make it "more copyleft".
https://www.gnu.org/licenses/license-list.en.html#apache2
It's entirely kosher in my opinion, and the entire thing agpl, with no "weird mix" or whatever
Lawyer here
"IANAL but that's not true? You can take Apache2 and relicense it under AGPL? You can take "less copyleft" license and make it "more copyleft"."
No you can't. That's also not really what is happening here in the link you list.
This gets complicated very quick (and 90% of HN comments in this thread are already sort of wrong), but the short version is:
When you aggregate existing works into a larger work, you can license the larger work in any way that is compatible with the existing works.
Apache2 is compatible in that sense - i can include an apache work in a larger aggregate work licensed a different way.
However, that does not relicense the original works that you are aggegating. For the Apache2 portion of that work - even when part of a larger work, I can still exercise whatever rights Apache2 gives me for the Apache2 version of that work.
The aggregate work itself would also have very little copyright protection, even if you AGPLv3 it.
The only copyright you newly get in the aggregate work is selection, arrangement, etc.
Which means the degree to which you are licensing anything at all is ... quite small.
The easy way to think about it is: even if you release a larger AGPLv3 work containining Apache2 pieces, you could not sue people for taking the Apache2 piece of it, and using it under Apache2. Even if they explicitly use your copy of it, etc.
More than that, people could take all of your aggregate work pieces and use them under their licenses, and you could not stop them.
This already happens - RHEL et al.
You can legally say "this whole code is AGPLv3, based on works by these people under Apache". You cannot be legally obliged to say which parts are Apache and which parts are not.
That makes no sense; that would make releasing the binaries and putting them under copyright illegal too as there is no source code.
Someone can still come and cherry-pick the old Apache code, yes. But you (canonical in this case) don't have to say which parts are which, and as the project goes on and new work is added it will be pretty hard to do.
That's basically what LibreOffice did with OpenOffice.org code...
Your point is why I've always said that the "you can't relicense" people are playing a smoke and mirrors sideshow, and trying to skate by on technicalities.
No you can't literally make it the case that the code that used to be licensed as Apache is now licensed GPL. On the other hand you are free to convey that code under the terms of the GPL, without clearly specifying to others exactly which lines of code are Apache, except insofar as that license requires you to to do so. And you're free to create a combined work that the GPL (or another compatible license) applies to, and require a CLA for contributions to that combined work. In fact the Apache 2.0 license says you're free to "provide additional or different license terms ... for any such Derivative Works as a whole" (my emphasis).
But nobody ever thought you can "change the license" in that overly-literal sense, so far as I know. It's not what people who say "relicensing" mean in the software world, and the lawyers who talk as if we did completely miss the point.
> You cannot be legally obliged to say which parts are Apache and which parts are not.
This is not strictly accurate, in that you can't remove existing copyright statements from the source form of the work, under Apache 2.0:
> 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
That would presumably include copyright statements placed on the original source files, if those exist. But you aren't obligated to do the work of explaining to others exactly which source lines have which copyright, as Apache does not obligate you to do so.
I've long wondered if it might make sense if I ever write something substantial that I want to open source to license most of the individual functions under a permissive license such as BSD, but license the program as a whole as a collective work or compilation under something more restrictive like GPL.
The idea is that if someone finds that I've got a nice sort function or a nifty argument parser that they would find useful I'm happy for them to copy it no strings attached, but I don't want someone just taking my whole program and making a closed fork of it.
> However, that does not relicense the original works that you are aggegating.
What does this claim even mean? I don't think that anybody thinks including Apache code in their GPL project would retroactively relicense the code of the Apache-licensed project that they probably had nothing to do with, written by someone they may have ever met. Is this what you're confirming?
> The aggregate work itself would also have very little copyright protection, even if you AGPLv3 it.
> The only copyright you newly get in the aggregate work is selection, arrangement, etc.
That's not really how code works. The old code is mixed with the new code, and the combination (I've always thought) is going to have all of the restrictions of both (all) licenses involved.
If I take a public domain book containing un-trademarked characters, write 20 additional chapters for it, and do a 20% rewrite on the original chapters, are you saying that my book wouldn't be copyrightable? Sounds like the GPL.
"What does this claim even mean? I don't think that anybody thinks including Apache code in their GPL project would retroactively relicense the code of the Apache-licensed project that they probably had nothing to do with, written by someone they may have ever met. Is this what you're confirming?"
The comment i replied to literally said that - that you can always relicense things less permissively. Which is wrong. Sure, maybe they meant it in the colloquial sense, but you simply can't have meaningful discussions about any of this without being precise.
"That's not really how code works. The old code is mixed with the new code, and the combination (I've always thought) is going to have all of the restrictions of both (all) licenses involved."
You certainly realize how arrogant it sounds to tell someone "that's not how code works"?
I'm quite aware of how code works. No, it will not have the restrictions of all the licenses involved, just because you mix it, because it can't. It may be hard to figure out what the restrictions are, but just because you mixed it all together doesn't change a darn thing. You still have no meaningful separate copyright in the mix, and the licensing is controlled by the pieces.
Read again what you claimed is obvious above, and you will see why.
The only restrictions come into place to the degree you create derivatives of existing works or code. What degree that happens varies widely. What is protectable there, varies widely.
It is totally irrelevant how much chaos you create through mixing - it does not change licensing, just makes it harder to figure it out.
Court cases that involve open source with lots of differently-licensed code often spend amazing amounts of time trying to actually separate the pieces and figure out what rights people have to them.
If Canonical took code from Incus, wouldn't they also need to include their NOTICE file if they have one as required by the Apache license? Would not including that file constitute removal of copyright management information?
I'm curious as to what qualifies as "taking code". If you copy some code and change variable names, do some minor refactoring or reformatting, is that considered the same code?
It'd be considered a derivative work.
They can freely include Apache2 licensed code in an AGPLv3 project without having to re-license the entire project under Apache2 as it's not a copyleft license. However this doesn't make the code they included AGPLv3, that code remains Apache2 and must be declared as such.
Licenses don't typically allow licensees to re-license code. You can use Apache v2 code in a proprietary or AGPL product and redistribute binaries or other source code derived from it under any other license, but you can't change the license of the original code: anyone can still use it under the Apache license.
Conversely, a copyright holder may re-license code. Depending on the exact terms of the old license, this may mean that you are no longer allowed to use it under the old license (at least, not unless you got it from someone who legally obtained it back when it had the old license).
So, if the code is not relicensed, you can theoretically download a bundle that claims it's AGPLv3, select the portions that are licensed under Apache, and incorporate those into your proprietary product without providing any access to your sources, and be legally in the clear.
> Licenses don't typically allow licensees to re-license code.
This still doesn't make any sense. Permissive licenses are designed to allow code to be relicensed freely, hence the term "permissive." There may be a few catches, like having to include attribution or a copy of the old license, but if those were significant, the code wouldn't be open source.
How could that interpretation be compatible with the fact that if the author and copyright holder relicenses the code, you can ignore them if "you got it from someone who legally obtained it back when it had the old license." LGPL projects are "someone."
> So, if the code is not relicensed, you can theoretically download a bundle that claims it's AGPLv3, select the portions that are licensed under Apache, and incorporate those into your proprietary product without providing any access to your sources, and be legally in the clear.
Very theoretically. It's very unlikely that the Apache code will sit in the AGPL project forever unmixed with new, AGPL'd, code. Since the new code is not under a permissive license, it can't be relicensed to Apache.
Think about it like this. If I redistribute a BSD licensed piece of code released by the OpenBSD project, I have to include a note saying that "this product includes code from the OpenBSD project". If I allow others to redistribute my code, I still have to require those others to include this notice. I can't take the OpenBSD project's code and redistribute it under a license that says "you don't have to give any attribution".
However, as the copyright holder, the OpenBSD project can decide to relicense their code under a new license that says "no attribution is required". They can even do so selectively: they can sell you code under this license, but keep distributing the one with attribution required to others. The provenance of a copy of code becomes important in these cases, since different copies may have different license terms attached.
The MySQL project was doing exactly this before the Oracle acquisition, this is not a theoretical idea. You could get the code for free under the terms of the GPLv2 (or 3?), or you could buy a commercial license from them that allowed you to redistribute the binary with any modifications without sharing source code.
Does it not?
>
2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
Is sublicensing something different from relicensing?
As far I understand it means you should use the same license for the reused parts of that code
> You can take "less copyleft" license and make it "more copyleft".
Only if licenses are compatible. But Apache 2 is AGPL-compatible so
> It's entirely kosher in my opinion
Yes, I think so too.
However, they need to make it clear which parts are under Apache 2.
It is if you own copyright for that code, then you can re-license. It seems Canonical didn't ask the permission of contributors that haven't signed their CLA, so Canonical have no right to change the license for that code
> However, they need to make it clear which parts are under Apache 2.
The only thing they needed to do is to add the statement that parts of the code that were written before LXD 5.20 remain Apache 2.0
what IS weird though is the go exosystem thing.
in go ecosystem, copyleft is very much not the norm.
People might not realise that by just adding copyleft dependency to go.mod, the entire project becomes effectively agpl as it has the code built-in.
If you add a dependency without understanding the license that dependency is released under, you should stop doing that. That counts for every license, and particularly if there is no license.
It goes transitively though.
Some popular go packages grab tens (sometimes over hundres, but not as much as in node world) dependencies.
NOBODY checks the license all the transitive dependencies in go world.
What should or should not happen is one thing, this is the reality
edit: oh but that lead me to google this
neat
Yes, that's why (apart from the Cyber Resilience Act) license scanners and SBOMs are a thing.
Linux containers project. Foreshadowing of this move at https://linuxcontainers.org/lxd/
Time to support the fork
Interesting, it looks like Incus is the fork (announced in October)? I've really wanted to try LXD but it was infected with Snap and the other Canonical baggage.
What i need is straightforward way to run/manage VMs with the ability to have a couple of hosts in a HA setup to failover VMs on an NFS share. libvirt does this just about, but it's pretty painful to use, and the stack needed for Proxmox/oVirt feels too complex.
As far as I could tell LXD did what i want.
https://linuxcontainers.org/incus/try-it/ give it a try :)
Well, I'm sold, and that demo sandbox is cool.
LXD is available via ordinary .deb's as of the Debian 12 release earlier this year, FYI.
I mean, it was time to support the fork from the day it was forked, but now is good too...
AGPL: The radioactive license when you don't want anyone to use your "open" source. (Google, Meta, and more cannot and will not use AGPL code at all.) This change to LXD harms VPSes and any company that uses LXD in SaaS.
Will not, possibly. Cannot is inaccurate -- they could, but they choose not to.
IIRC Microsoft and AWS do use AGPLv3 code, at least in the form of offering hosted Grafana. Seems to me that if MSFT can make peace with the license, then there's little good reason for other BigCorps to shun it.
Lots of stuff is under AGPL and does just fine. Mastodon is a current example.
Canonical avoid and may profit from this, because they are in a position to relicense all the AGPL code (thanks to the CLA or having written it in the first place). If you do want to make changes and keep those changes proprietary, throw money at Canonical and they will probably give you a license that lets you.
When you don't want Amazon, Google etc to earn big money on your work. Actually not even that, they could if they played fair and contributed back all changes they make. But they don't want to play fair.
You're completely ignoring the harm to small business and individuals and putting unreasonable demands for money by collective punishment. If you don't want to release open source, then never release it. Pretending to be open source and simultaneously demanding money is resentment, sour grapes, and trying to have it both ways. Maybe you've seen what happens most often when FOSS projects relicense or go closed source: they die.
Who demanded money? Using AGPL is demanding code. (The modifications users of your code made.)
This does typically not affect small companies. They don't have the resources to make significant changes to the code, so there is nothing they would need to contribute back. And they don't employ lawyers forbidding them to use AGPL.
It's funny you mention the "harm" a license like AGPL causes. How did that work out for, e.g., MinIO? Would it be unreasonable for them to demand you need to actually attribute them and also keep your attributions open if they open up their work for you? Ig it is but only if you demand to get their work from free without acknowledging that may also be entitled to some demands of their own.
> This change to LXD harms VPSes and any company that uses LXD in SaaS.
No, it likely (IANAL) means VPS companies using copyleft code have to share their code in turn.
Except, you're demanding the unreasonable and the insane which is the problem.
So you have a file function foo is Apache, bar calls foo. Isn't bar a derivative work of foo? Someone from canonical rewrites foo changing 4 of 7 lines. In this version is foo now canonical's contribution or still the original contributor?
A: Is it accurate to say that there is no metadata regarding who owes what because it would take millions and a trial to decide?
B: Is it accurate to say that this uncertainty is basically as good as owning the whole thing in this case because it is impossible to use it other than either under the terms of the AGPL or some commercial license from Canonical? You are obviously blameless for using the Apache code.
C: Does the inherent confusion mean that if similar features are committed to the mixed proprietary/AGPL branch the inherent complexity of deciding who owns what would make using the open source branch a minefield. EG evilcorp with a substantial budget could simply shut down the open source branch with threats of ruinously expensive lawsuits and false but not obviously false claims of infringement.
D: If A B C does this mean that ANY permissively licensed project which is partially owned by a party which presently contributes substantially to the labor could in effect take an open source project proprietary by first making it the path of least resistance to continue with their fork and later the only choice.
Short answer: No in most cases.
You can't create confusion and then sue people over the confusion. This is the purpose of copyright notice - you have to make it clear enough who owns rights to avoid various defenses.
As for your function question: Copyright was created mostly for books, remember.
As such, it gets weird quickly when applied to code.
For example - i write a book, and on page 236, it says at the top "the text of this page is copied from the folowing book <some book>" and then copies it inline.
This is probably infringement.
If i instead write a book, and on page 236, it says at the top "for the text of this page, please see page 194 of the following book <some book>" and does not copy it inline.
This is not infringement.
Now, could you currently convince a judge how shared library vs static library linking works, and that it matters? Maybe. Moreso than you could a decade ago.
> bar calls foo. Isn't bar a derivative work of foo?
I think it isn’t. Function signatures are fair use (under certain conditions, as established in Google v. Oracle), so just calling a function isn’t enough to declare your code a derivative work.
The combined work however is of course a derivative work of foo and is subject to its license terms, so if you want to be able to distribute it, you have to allow abide by them (i.e. release source code for both foo and bar if foo is AGPL, even though bar can be Apache or MIT or something; and you can’t use a more restrictive license that AGPL for bar).
If you want you can reimplement foo yourself though – then you can distribute bar together with your implementation under any license you like.
(IANAL)
LXD is container technology, right? I've used Docker for years now (in my home lab.) I took a stab at using Podman a couple times but the friction was too high (and my motivation to switch too low.)
How does LXD compare to Docker? Should I be interested in it or just continue with Docker for the handful of containers I'm using (Gitea, Checkmk, MariaDB, Mosquitto.) The license is not interesting to me unless there's a technical advantage. (And for my personal use the license is probably moot anyway.)
Host OS would be Debian, if it matters.
Thanks!
> How does LXD compare to Docker?
They have different use cases.
Docker runs single applications/daemons.
LXD runs a whole Linux system by spawning an init process which takes care of spawning and managing other processes that compose a system.
A great security feature of LXD is that these child systems are run in user namespaces and don't have root privileges in the host. Docker runs with full root privileges, and malicious code can easily escape the container and take over the host.
LXD is containers but presented much more like a traditional VM, without so much of the Dockerfile type stuff. If you just want VMs but more lightweight, it's great for that and has less footguns and cruft. If you actually want to make use of the docker-type features then it's not really designed for that.
LXD is more of a stateful flavor of containers. Or at least that is how it started.
Nowadays it is literally a VM management system, like Ovirt (but without a GUI). They added QEMU/KVM support quite a while ago now.
LXD has a web gui now. It is fairly basic right now but it is there.
Oh cool! I know there were unofficial ones floating around.
Incus has a demo of that UI (rebranded) accessible through their online demo: https://linuxcontainers.org/incus/try-it/ (there's a "Web UI" link once started)
LXC/LXD is similar to Jails. You have a directory with a whole distribution and a config file with a few details such as network setup and bind mounts.
It is much simpler than Docker. I think it's a better starting point if you want to learn about containers.
Just last week I tried LXC on Debian, but there was a conflict with iptables. I had more success with Ubuntu.
> It is much simpler than Docker
Quite a bold statement, very much depends on the task and user's background.
For one, running things across your team members, team consisting of mixed Windows, Macos, Linux workstations/laptops, you can't rely on LXD be easily accessible (the same for Jails of course).
Running quick tests, one-shot tasks like
Is easy peasy - friend of mine being SEO guy, could do this. No chances this can be done with LXD (jails of course is even worse for UX/DX - it's requires FreeBSD)docker run --rm -v "$(pwd):/sitespeed.io" sitespeedio/sitespeed.io:30.9.0 https://www.mysuperstartup-website.io/
So does this mean that LXD will replace libvirt in the next Ubuntu release? I'm running 23.10 on this machine right now (because the hardware is too new to run anything more stable), and it's still got libvirt.
LXD is separate from libvirt, I don't think one affects the other. The only thing common between LXD and libvirt is that both use qemu to run virtual machines.
It's time for someone else to replace Canonical, that's all I can read from this. We can expect more of this rubbish in the future.
Dear me, I thought CLA is a new type license.
Perhaps the title need to also include AGPLv3, the type of license LXD is changing to.
> However, if you were altering LXD in any way, then you will need to familiarize yourself with the AGPLv3 license as unlike Apache2, it does require any changes be made available under the AGPLv3 even if you don’t expose your users to your modified binaries.
This is a fascinating argument...
You're saying that you cannot add compatibly licensed code into APLv3 software (that you don't also have a more permissive license to modify/own the copyright to) without violating the AGPLv3.
I think it also follows that you can't legally modify AGPLv3 software containing bits of compatibly licensed code unless you also have more permissive rights to it or your fully strip out the compatibly licensed code?
I have to say, I'm reading the AGPLv3 and it seems like a reasonable conclusion, at least if you also distribute ("convey") it. In particular the clause that says "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy [...]" would seem to imply this.
I'm not sure what your argument is. "compatibly licensed code" is doing a lot of heavy lifting, and because you don't define that term, your post reads as little more than FUD.
Yes, you cannot distribute GPL'ed software if you don't have a license to distribute the source to the whole work. That's not unique to the Affero GPL, that's equally true for GPLv2 and GPLv3. But that's not a problem with respect to "compatibly licensed code" because that wording implies that said code is compatible with the constraints of the GPL.
To reiterate the argument, one of the constraints on conveying modified versions of AGPLv3 is the text I quoted at the end - that the entire conveyed version be licensed under the AGPLv3.
Supposing OPs arguments are correct that third parties don't have the right to relicence apache licensed code... you can't do that?
By "compatibly licensed" I meant nothing more or less than "licensed under a license such as Apache 2".
I'm not a lawyer though. I'm not saying this interpretation is correct. In fact I'm somewhat dubious of it because it is obviously contrary to the purpose of the AGPLv3, and I believe the people who wrote the license were in fact lawyers. That doesn't mean they couldn't have made a mistake though, and I would describe my current honestly come by opinion of the AGPLv3 as "uncertain and doubtful".
Non-copyleft code already explicitly allows itself to be included and distributed under different licenses. Even closed-source programs are allowed to contain OSS-licensed code as long as the proper attribution and legal notices are preserved. The first TCP/IP stack for Windows was ported from one of the BSDs, and shipped as part of the proprietary OS; does that count as a "relicensing" of the original code?
Taking a look at the official license text, the AGPL makes an explicit distinction between the license on the work as a whole, and specific licenses covering parts of the source: https://www.gnu.org/licenses/agpl-3.0.en.html
> 5.c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged
Emphasis mine. This does indeed refer to the work as a whole, but it also allows for specific exceptions. Section 7 makes two interesting claims:
> If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.
So if parts of the source code are under the Apache license (which grants additional permissions beyond the AGPL), those permissions remain valid when used outside the AGPL-licensed work.
> When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it.
So yes, it appears you are not required to preserve these additional license freedoms when distributing the source code. But this claim is immediately followed by an enumeration of the standard OSS clauses - right of attribution, preservation of legal notice, and disclaimer of liability - so all the legal requirements posed by the original license are covered.
So if Ubuntu were to choose to do so, it is free to remove the Apache 2 license (but not its legal notice, for that it needs permission from the original copyright holders) from any copies they distribute, and still be compliant with the original license.
because it is obviously contrary to the purpose of the AGPLv3
It isn't contrary to that license: the purpose of the GPL (and by extension, the AGPL) is to ensure that the source code remains free. It does so by imposing additional restrictions on distribution on top of what is required by MIT/BSD/Apache licensed code. Removing clauses that allow to take (parts of) the code and make it proprietary isn't contrary to the purpose of the AGPL -- it is however contrary to the (supposed) intentions of the original copyright holders who presumably chose their license for a good reason.
Note again that this isn't really different from what the GPLv2 allowed to do (from https://www.gnu.org/licenses/old-licenses/gpl-2.0.html):
> 2.b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
I remember this same discussion happening 20 years ago with the players being the Linux kernel and *BSD driver code; strictly speaking, Linux developers could take BSD driver code, preserve the legal notice, and distribute the complete code under GPLv2 and still be compliant with the BSD license. In practice, people honoured the original license and I'm sure you can still find dual-licensed BSD/GPL parts in some places in the kernel tree.
Is this FUD? [edit: it's not, see the replies - I kept my original comment below because that's what people answered to, but I no longer agree with it]
---
The linked announcement says
> Going forward, any contribution to LXD will be made under AGPLv3 by default. The author of a change remains the copyright holder of their code (no copyright assignment).
Emphasis mine. No copyright assignment.
So, Canonical now contributes in AGPLv3. The project is now AGPLv3 as well, with some parts in Apache 2. Contributors may contribute in Apache 2 if they wish but probably won't bother. They still own their code.
The author is pissed off because he can't build custom versions without redistributing the modifications and can't sell services to companies afraid of the AGPL anymore.
https://ubuntu.com/legal/contributors/agreement for the details.
In short, you don't lose your own copyright but you grant them a license to do whatever they want including re-license as they wish without having to ever consult you, allowing for your code to be used within their closed source projects under any license they wish.
Ah, right, it's not a copyright assignment, but there is a CLA. Confused the two concepts, rookie mistake. So yeah, not good. I will edit my comment. I would even say that not mentioning the CLA and mentioning the absence of copyright assignment in the announcement is quite dishonest.
Yes it is indeed
My best wishes for your fork!
> Contributors may contribute in Apache 2 if they wish but probably won't bother.
They couldn't make a contribution under Apache 2 that is a derivative of AGPLv3 code. It will have to be bound by the licenses of both at the same time (or be based on a clean-room implementation of the AGPL code additions -- good luck with git merge)
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:
>The author is pissed off because he can't build custom versions without redistributing the modifications
Incus is a full fork, and Canonical has apparently been taking changes back from it as well as is often the case with such forks where both sides get value from each other. It's perfectly understandable for some folks to be bummed if that's no longer the case, and there is nothing evil about the Apache2 license. There's plenty of history that in OSS going back to the beginning, no need for insinuations or attacks. Shouldn't throw around "FUD" at core authors just because they're a touch blindsided.
----
0: https://github.com/canonical/lxd/pull/12665/commits/eb5c773d...
Yep, you are right. See the followups. My characterization was indeed unfair. I confused copyright assignment and CLA, and understood "no copyright assignment" as "no CLA", which is of course wrong.
And for me this totally reverses the situation, AGPL + CLA means "We can make it proprietary tomorrow, and only we can do it".
[deleted]
You, too, are wrong. From Canonical's actual announcement:
> Canonical has decided to change the default contributions to the LXD project to AGPLv3 to align with our standard license for server-side code. All Canonical contributions have been relicensed and are now under AGPLv3. Community contributions remain under Apache 2.0.
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:
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...
It is correct; the binary is AGPL, and Snap is a binary distribution method.
Nope, the binary is under both licenses. Just because they are compatible doesn't mean you can ignore the terms of one of them.
I sometimes “editorialize” license names for Lunni Marketplace, too. [1]
I think it’s fine: the binary is under both licenses, but one requires you to publish a notice and the other requires you to publish a notice and all source code for both parts. Since you want to know what “license burden” you’ll have to bear when you’re looking for an app in a distribution platform like this, I think it’s fair to just specify the more restrictive license.
(IANAL)
Thanks for the correction. Seems like the headline was incorrect in a different way.
The submitted title was "Canonical re-licenses LXD under AGPLv3, slaps a CLA on top". I've changed it to the article's title, in keeping with HN's rule: "Please use the original title, unless it is misleading or linkbait; don't editorialize." - https://news.ycombinator.com/newsguidelines.html
If the current title isn't accurate, and anyone can suggest a more accurate and neutral one, we can change it again.
Lxd as a whole is certaily now only available under the AGPLv3 license. Some parts are also available under the Apache 2.0 license. And Canonical are bound by that agreement to tell you such; but it is still factual to say you have to agree to the AGPLv3 to distribute it.