Live data from Hacker News

LXD now re-licensed and under a CLA

stgraber.org

51–60 of 102 posts

Re: LXD now re-licensed and under a CLA

#51
post #38

Earlier quoted context omitted.

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…

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

Re: LXD now re-licensed and under a CLA

#52
post #40

Earlier quoted context omitted.

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.

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.

Re: LXD now re-licensed and under a CLA

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

[deleted]

Re: LXD now re-licensed and under a CLA

#54
post #50
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 "compatib…

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

Re: LXD now re-licensed and under a CLA

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

Re: LXD now re-licensed and under a CLA

#56

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.

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

Re: LXD now re-licensed and under a CLA

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

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

Re: LXD now re-licensed and under a CLA

#58

Earlier quoted context omitted.

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.

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

Re: LXD now re-licensed and under a CLA

#59

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

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

Re: LXD now re-licensed and under a CLA

#60

Earlier quoted context omitted.

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.

Nope, the binary is under both licenses. Just because they are compatible doesn't mean you can ignore the terms of one of them.
Post reply on HN