LXD now re-licensed and under a CLA(stgraber.org) |
LXD now re-licensed and under a CLA(stgraber.org) |
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 ;)
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
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.
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.
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.
Perhaps the title need to also include AGPLv3, the type of license LXD is changing to.
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".
---
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.
> 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.
"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.
No, it likely (IANAL) means VPS companies using copyleft code have to share their code in turn.
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)
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/
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".
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.
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.
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.
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.
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.
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
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.
yes, there is
i quoted the relevant part of the apache 2 license in my sibling comment above
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
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.
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.
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)
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.
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 don't think you can comply by just removing the apache 2 license
you're right about 'jeez' and i've removed it
The Apache 2 code will remain Apache 2 code, but in a pointless way.