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
"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.
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...
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.
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.
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.
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.
>
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?
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.
> 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
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.
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.
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.
No, it likely (IANAL) means VPS companies using copyleft code have to share their code in turn.
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
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'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.
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.
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?
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.
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 ;)
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!
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.
Nowadays it is literally a VM management system, like Ovirt (but without a GUI). They added QEMU/KVM support quite a while ago now.
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.
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
docker run --rm -v "$(pwd):/sitespeed.io" sitespeedio/sitespeed.io:30.9.0 https://www.mysuperstartup-website.io/
---
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.
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.
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)
>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...
And for me this totally reverses the situation, AGPL + CLA means "We can make it proprietary tomorrow, and only we can do it".
> 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.
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...
If the current title isn't accurate, and anyone can suggest a more accurate and neutral one, we can change it again.
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.
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.
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)
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.
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.
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".
Perhaps the title need to also include AGPLv3, the type of license LXD is changing to.