4 ms·

I’m trivializing here but for sake of brevity: LGPL allows dynamic linkage without open sourcing your components. GPL requires any linkage to open source your

by dagmx 3y ago

I’m trivializing here but for sake of brevity: LGPL allows dynamic linkage without open sourcing your components. GPL requires any linkage to open source your parts, but allows for process boundary to not be viral. AGPL is the nuclear don’t touch because it is vital to all possible usage types. Again, that’s trivializing because there’s many subtle details that in many cases are intentionally not clarified in the licenses themselves

tsimionescu 3y ago
There is no difference whatsoever between the GPL and the AGPL for software you distribute. The only difference between the AGPL and the GPL relates to software you don't distribute, but that you make available over a network, such as hosting an AGPL web server. The AGPL says that as long as public users interact with this web server, they have the right to get the code and deployment instructions and AGPL rights to be able to run the exact same service themselves, just as if they had downloaded the software. The FSF's (very reasonable) position is that linking to a piece of software makes your software a derivative work, but that launching it as a separate process or accessing it over a network generally doesn't. However, if you exchange very complex internal data structures with this GPL software running in a separate process, whether you do it over a network or through pipes or command line arguments or whatever, then your program is still a derivative work, in their opinion. That is, if you run gcc in a separate process but then mmap() it's memory and search for its entry points and jump to the memory locations of GCC functions in order to generate optimized code for a piece of GCC AST you provide, then your program is a derivative of GCC (according to the FSF, at least) even though GCC is running in a separate process.
- jasonjayr 3y ago
  A few articles I've read suggest that the AGPL terms trigger if you MODIFY AGPL covered code. So if you (1) setup an AGPL service over the network "as-is" with no changes, (2) use the AGPL-covered service from your proprietary code over the network (ie, across a process boundary), then you are in the clear, and your proprietary code can remain closed. If you instead, modify/customize the source of the AGPL-covered service, then you are required to make available your changes to AGPL-covered product under a AGPL license. Is this a correct understanding of the situation? If the product implements a publicly documented protocol to communicate over the network (ie, not "complex internal structures", and/or replaceable with another product), is that permitted?
  - tsimionescu 3y ago
    I am not a lawyer, but my understanding is the same as yours - if you host a proprietary service that has some AGPL components (say, an AGPL authentication service that users interact directly with to get a token, that they then pass to the proprietary parts), then you only have to make sure that the source code for the AGPL part is made available (or not even that if you are using it completely unmodified).
account42 3y ago
> LGPL allows dynamic linkage without open sourcing your components. Also static linkage provided you provide users with the object files so that they can re-link with a modified library. > GPL requires any linkage to open source your parts With the exception of system components. Maybe that is what is causing the confusion because it's not intuitive why you can ship proprietary software that uses glibc but can't ship proprietary plugins for a GPL program. > AGPL is the nuclear don’t touch because it is vital to all possible usage types. That is an absurd viewpoint bordering on FUD. Affero licenses are only a problem if you are trying to work around the license terms. The license does fix loopholes for networked use that allowes SAAS providers to skirt the GPL but it is NOT any more viral than the GPL. Commercial use of AGPL software is absolutely possible - see e.g. cloud providers. Most GPL software probably should be AGPL.
- sokoloff 3y ago
  > The [AGPL] license does fix loopholes for networked use that [allows] SAAS providers to skirt the GPL but it is NOT any more viral than the GPL. One person’s skirting is another person’s complying. Most of what AGPL proponents argue is skirting GPL by SaaS companies seems like straightforward compliance/conformance to me.
- dagmx 3y ago
  Linux dual licenses glibc so that it can be linked without falling under the GPL And I’m not saying that AGPL can’t be used, in the same way I’m not saying other GPL can’t be used. You’re misunderstanding the context of the comment. The comment was in regards to: what are you allowed to do without having to fall under the purview of the license. In that sense, the AGPL specifically exists to close off many areas that the GPL didn’t touch.

by dagmx 3y ago

tsimionescu 3y ago

There is no difference whatsoever between the GPL and the AGPL for software you distribute. The only difference between the AGPL and the GPL relates to software you don't distribute, but that you make available over a network, such as hosting an AGPL web server. The AGPL says that as long as public users interact with this web server, they have the right to get the code and deployment instructions and AGPL rights to be able to run the exact same service themselves, just as if they had downloaded the software. The FSF's (very reasonable) position is that linking to a piece of software makes your software a derivative work, but that launching it as a separate process or accessing it over a network generally doesn't. However, if you exchange very complex internal data structures with this GPL software running in a separate process, whether you do it over a network or through pipes or command line arguments or whatever, then your program is still a derivative work, in their opinion. That is, if you run gcc in a separate process but then mmap() it's memory and search for its entry points and jump to the memory locations of GCC functions in order to generate optimized code for a piece of GCC AST you provide, then your program is a derivative of GCC (according to the FSF, at least) even though GCC is running in a separate process.

jasonjayr 3y ago
A few articles I've read suggest that the AGPL terms trigger if you MODIFY AGPL covered code. So if you (1) setup an AGPL service over the network "as-is" with no changes, (2) use the AGPL-covered service from your proprietary code over the network (ie, across a process boundary), then you are in the clear, and your proprietary code can remain closed. If you instead, modify/customize the source of the AGPL-covered service, then you are required to make available your changes to AGPL-covered product under a AGPL license. Is this a correct understanding of the situation? If the product implements a publicly documented protocol to communicate over the network (ie, not "complex internal structures", and/or replaceable with another product), is that permitted?
- tsimionescu 3y ago
  I am not a lawyer, but my understanding is the same as yours - if you host a proprietary service that has some AGPL components (say, an AGPL authentication service that users interact directly with to get a token, that they then pass to the proprietary parts), then you only have to make sure that the source code for the AGPL part is made available (or not even that if you are using it completely unmodified).

account42 3y ago

> LGPL allows dynamic linkage without open sourcing your components. Also static linkage provided you provide users with the object files so that they can re-link with a modified library. > GPL requires any linkage to open source your parts With the exception of system components. Maybe that is what is causing the confusion because it's not intuitive why you can ship proprietary software that uses glibc but can't ship proprietary plugins for a GPL program. > AGPL is the nuclear don’t touch because it is vital to all possible usage types. That is an absurd viewpoint bordering on FUD. Affero licenses are only a problem if you are trying to work around the license terms. The license does fix loopholes for networked use that allowes SAAS providers to skirt the GPL but it is NOT any more viral than the GPL. Commercial use of AGPL software is absolutely possible - see e.g. cloud providers. Most GPL software probably should be AGPL.

sokoloff 3y ago
> The [AGPL] license does fix loopholes for networked use that [allows] SAAS providers to skirt the GPL but it is NOT any more viral than the GPL. One person’s skirting is another person’s complying. Most of what AGPL proponents argue is skirting GPL by SaaS companies seems like straightforward compliance/conformance to me.
dagmx 3y ago
Linux dual licenses glibc so that it can be linked without falling under the GPL And I’m not saying that AGPL can’t be used, in the same way I’m not saying other GPL can’t be used. You’re misunderstanding the context of the comment. The comment was in regards to: what are you allowed to do without having to fall under the purview of the license. In that sense, the AGPL specifically exists to close off many areas that the GPL didn’t touch.