Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LXD now re-licensed and under a CLA

stgraber.org

Post reply on HN
Print view View original

41–50 of 102 posts

Re: LXD now re-licensed and under a CLA

#41

Post by shp0ngle »

jorams wrote: post #19
shp0ngle wrote: post #17

Earlier quoted context omitted.

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

https://github.com/google/go-licenses

Re: LXD now re-licensed and under a CLA

#42

Post by kragen »

stgraber wrote: post #29
kragen wrote: post #21

the 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 ne…

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 requireme…

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?

Re: LXD now re-licensed and under a CLA

#43

Post by michaelmrose »

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.

Re: LXD now re-licensed and under a CLA

#44

Post by phatfish »

stgraber wrote: post #30
phatfish wrote: post #26

Earlier quoted context omitted.

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 comp…

https://linuxcontainers.org/incus/try-it/ give it a try :)

Well, I'm sold, and that demo sandbox is cool.

Re: LXD now re-licensed and under a CLA

#45

Post by stgraber »

kragen wrote: post #42
stgraber wrote: post #29

Earlier quoted context omitted.

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 requireme…

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.

Re: LXD now re-licensed and under a CLA

#46

Post by stgraber »

jraph wrote: post #38
stgraber wrote: post #29

Earlier quoted context omitted.

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 requireme…

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 you…

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.

Re: LXD now re-licensed and under a CLA

#47

Post by forinti »

HankB99 wrote: post #39

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…

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.

Re: LXD now re-licensed and under a CLA

#48

Post by rcxdude »

HankB99 wrote: post #39

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…

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.

Re: LXD now re-licensed and under a CLA

#49

Post by kragen »

stgraber wrote: post #45
kragen wrote: post #42

Earlier quoted context omitted.

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 ca…

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

from https://www.apache.org/licenses/LICENSE-2.0

Re: LXD now re-licensed and under a CLA

#50

Post by tremon »

gpm wrote: post #37

> 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 lic…

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.

Post reply on HN