Live data from Hacker News

LXD now re-licensed and under a CLA

stgraber.org

81–90 of 102 posts

Re: LXD now re-licensed and under a CLA

#81

Earlier quoted context omitted.

Licenses don't typically allow licensees to re-license code. You can use Apache v2 code in a proprietary or AGPL product and redistribute binaries or other source code derived from it under any other license, but you can't change the license of the original code: anyone can still use it under the Apache license. Conversely, a copyright holder may re-license code. Depending on the exact terms of the old license, this…

Does it not? > 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 somet…

As far I understand it means you should use the same license for the reused parts of that code

Re: LXD now re-licensed and under a CLA

#82
post #16

"As a result, Canonical cannot release LXD under the AGPLv3 license and likely never will be able to. LXD is now under a weird mix of Apache2 and AGPLv3 with no clear metadata indicating what file or what part of each file is under one license or the other." 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.or…

> You can take "less copyleft" license and make it "more copyleft". 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.

It is if you own copyright for that code, then you can re-license. It seems Canonical didn't ask the permission of contributors that haven't signed their CLA, so Canonical have no right to change the license for that code

> 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

Re: LXD now re-licensed and under a CLA

#83

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.

Lots of stuff is under AGPL and does just fine. Mastodon is a current example.

Re: LXD now re-licensed and under a CLA

#85

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.

Will not, possibly. Cannot is inaccurate -- they could, but they choose not to.

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.

Re: LXD now re-licensed and under a CLA

#87

Earlier quoted context omitted.

Lawyer here "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, y…

> However, that does not relicense the original works that you are aggegating. 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…

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

Re: LXD now re-licensed and under a CLA

#88

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…

LXD is available via ordinary .deb's as of the Debian 12 release earlier this year, FYI.

Re: LXD now re-licensed and under a CLA

#89

"As a result, Canonical cannot release LXD under the AGPLv3 license and likely never will be able to. LXD is now under a weird mix of Apache2 and AGPLv3 with no clear metadata indicating what file or what part of each file is under one license or the other." 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.or…

Lawyer here "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, y…

If Canonical took code from Incus, wouldn't they also need to include their NOTICE file if they have one as required by the Apache license? Would not including that file constitute removal of copyright management information?

Re: LXD now re-licensed and under a CLA

#90
post #51

Earlier quoted context omitted.

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

i agree with Proven's [dead]ed comment that "Free software doesn't exist to reward developers and contributors." in the sense that the reason it's good for free software to exist is that it rewards users, not developers and contributors

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

Post reply on HN