Introduction The LXD team would like to announce the release of LXD 5.20! Thank you to everyone who contributed to this release! LXD change to AGPLv3 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. We follow the Software Freedom Law Center guidance in relation to this. Going ...
Look, I’m usually first in line to shit on Canonical, but I can’t get mad at them adopting AGPL. This is objectively the best license for server software. Incus should also switch to AGPL for all Canonical code, and seek to have contributors license their code as AGPL as well.
I will however point out the hypocrisy and inconsistency of it, because the Snap server is still proprietary after all of this time. If this is their “standard for server-side code” then apply it to Snaps or quit lying to us.
The full details are complex but I’ll give you the basic gist. The original GPL licenses essentially say that if you give somebody the compiled binary, they are legally entitled to have the source code as well, along with the rights to modify and redistribute it so long as they too follow the same rules. It creates a system where code flows down freely like water.
However, this doesn’t apply if you don’t give them the binary. For example, taking an open source GPL-licensed project and running it on a server instead. The GPL doesn’t apply, so you can modify it and do whatever, and you aren’t required to share the source code if other people access it because that’s not specified in the GPL.
The AGPL was created to address this. It adds a stipulation that if you give people access to the software on a remote system, they are still entitled to the source code and all the same rights to modify and redistribute it. Code now flows freely again, and all is well.
The only “issue” is that the GPL/AGPL are only one-way compatible with the Apache/MIT/BSD/etc licenses. These licenses put minimal requirements on code sharing, so it’s completely fine to add their code to GPL projects. But themselves, they aren’t up to GPL requirements, so GPL code can’t be added to Apache projects.
It requires that you make available the full source code to anyone who you give binaries too (like the GPL), but also requires you make available that source to users of the software over a network. So, someone could not make a proprietary fork of AGPL software to sell exclusively as a service. In order to provide that service you have to also be willing to provide the source, including changes, which would allow users to then choose to run that service themselves instead of being forced to pay the provider.
I don’t understand how AGPL allows Canonical to make and sell proprietary copies of this software without violating their license. That’s the only way your scenario could happen. If you’re aware of a situation where a company can do this, I’d love to learn.
I don’t understand how AGPL allows Canonical to make and sell proprietary copies of this software without violating their license. That’s the only way your scenario could happen.
“To release a nonfree program is always ethically tainted, but legally there is no obstacle to your doing this. If you are the copyright holder for the code, you can release it under various different non-exclusive licenses at various times. […] the GPL is a license from the developer for others to use, distribute and change the program. The developer itself is not bound by it, so no matter what the developer does, this is not a “violation” of the GPL.”
Look, I’m usually first in line to shit on Canonical, but I can’t get mad at them adopting AGPL. This is objectively the best license for server software. Incus should also switch to AGPL for all Canonical code, and seek to have contributors license their code as AGPL as well.
I will however point out the hypocrisy and inconsistency of it, because the Snap server is still proprietary after all of this time. If this is their “standard for server-side code” then apply it to Snaps or quit lying to us.
Can you explain to a person who knows little about licenses, such as myself, what makes AGPL so good?
The full details are complex but I’ll give you the basic gist. The original GPL licenses essentially say that if you give somebody the compiled binary, they are legally entitled to have the source code as well, along with the rights to modify and redistribute it so long as they too follow the same rules. It creates a system where code flows down freely like water.
However, this doesn’t apply if you don’t give them the binary. For example, taking an open source GPL-licensed project and running it on a server instead. The GPL doesn’t apply, so you can modify it and do whatever, and you aren’t required to share the source code if other people access it because that’s not specified in the GPL.
The AGPL was created to address this. It adds a stipulation that if you give people access to the software on a remote system, they are still entitled to the source code and all the same rights to modify and redistribute it. Code now flows freely again, and all is well.
The only “issue” is that the GPL/AGPL are only one-way compatible with the Apache/MIT/BSD/etc licenses. These licenses put minimal requirements on code sharing, so it’s completely fine to add their code to GPL projects. But themselves, they aren’t up to GPL requirements, so GPL code can’t be added to Apache projects.
It requires that you make available the full source code to anyone who you give binaries too (like the GPL), but also requires you make available that source to users of the software over a network. So, someone could not make a proprietary fork of AGPL software to sell exclusively as a service. In order to provide that service you have to also be willing to provide the source, including changes, which would allow users to then choose to run that service themselves instead of being forced to pay the provider.
I see, thanks
deleted by creator
Obviously their own code can be sold at their discretion. It’s not about libre software.
They would have used a license like SSPL or the newer BSL for that. AGPL keeps it open. They got that going for them and about nothing else.
No, the copyright owner can sell proprietary versions however they like. Outside contributions are required to sign Canonical’s CLA. Read https://github.com/canonical/lxd/blob/main/CONTRIBUTING.md#license-and-copyright before making claims.
I don’t understand how AGPL allows Canonical to make and sell proprietary copies of this software without violating their license. That’s the only way your scenario could happen. If you’re aware of a situation where a company can do this, I’d love to learn.
The FSF made an FAQ page for a reason: https://www.gnu.org/licenses/gpl-faq.html#ReleaseUnderGPLAndNF
“To release a nonfree program is always ethically tainted, but legally there is no obstacle to your doing this. If you are the copyright holder for the code, you can release it under various different non-exclusive licenses at various times. […] the GPL is a license from the developer for others to use, distribute and change the program. The developer itself is not bound by it, so no matter what the developer does, this is not a “violation” of the GPL.”
Canonical read the FAQ, many people here didn’t.
Wow! I learned something. To return the favor, life would be better for you if you were less rude in the way you convey information.
People making unsubstantiated claims are the rude ones, not the ones making factually correct statements without fluff.