4 ms·
Yes, this seems like a common misconception with the AGPL. You can embed AGPL things within your stack and not have to open source the things that interact wit
by candiddevmike 4y ago
Yes, this seems like a common misconception with the AGPL. You can embed AGPL things within your stack and not have to open source the things that interact with it (or the software/scripts that is used to deploy it, another common misconception).
If you're trying to use the AGPL to prevent folks from monetizing your shit or to get them to pay you for using it, you're using the wrong license.
- giancarlostoro 4y agoArguably it discourages anyone who wants to use the back-end code to build something proprietary with your own distinct changes. But you're not wrong, say a cloud hosting provider out of China, they wont care about AGPL they'll do what they have to.
- raggi 4y agoThe "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. What is it about the word "deploy" that you used that is materially different from "install" as described in the license text above?
- candiddevmike 4y agoI think you're looking at it too broadly. The AGPL's intent is to extend GPL protection for software available on the network, see the FSF's blog post here: https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-the-agplv3 https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t... > Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program The text you are referencing is present in the GPL too, and it doesn't make GPL code infect adjacent apps.
- josephcsible 4y ago> It's not like the AGPL infects everything on your network, it's limited to the original source. Indeed. By the way, the difference between the AGPL and the SSPL is that the SSPL does infect your entire stack and isn't limited to just the original source, which is exactly why the AGPL is free and open-source but the SSPL is neither.
- raggi 4y agoNow consider the "Tivo" target, which is that the scripts and tools required to deploy the code are things they absolutely want to cover. You didn't answer my question directly though (and nor does the linked article), what is it about deploy in your usage that is materially different from "install" in the text? Do you disagree that the device case is covered? How do you consider a cloudy type environment different, and by what definition and justification? What if I sell the deployment in a box for on-prem, as well as in hosted VMs? Does that change users rights under the license?