Live data from Hacker News

LXD now re-licensed and under a CLA

stgraber.org

21–30 of 102 posts

Re: LXD now re-licensed and under a CLA

#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 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

Re: LXD now re-licensed and under a CLA

#22
post #20
post #11

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

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…

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".

Re: LXD now re-licensed and under a CLA

#25

Earlier quoted context omitted.

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: https://snapcraft.io/lxd 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.

Re: LXD now re-licensed and under a CLA

#26

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.

Re: LXD now re-licensed and under a CLA

#27

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.

Re: LXD now re-licensed and under a CLA

#28

Time to support the fork

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.

Re: LXD now re-licensed and under a CLA

#29
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 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.

Re: LXD now re-licensed and under a CLA

#30

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

https://linuxcontainers.org/incus/try-it/ give it a try :)
Post reply on HN