Without an answer to that if you use this and you need to make any change to it (even a tiny bug fix), you're basically opening yourself up a pile of legal issues.
"Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."
So, if you make any modification to the program, you also have to "prominently offer all users interacting with it remotely through a computer network" [a copy of the source].
Which it doesn't currently do, so do you have to add a header to every request with a download link, or what? Without any clarification from the authors they can choose to interpret the license however they like.
Even clarification may not help, the vague term is still there in the license. A legal department may suggest you avoid such a license. Usual I am not a Lawyer disclaimer applies.
If I understood it correctly, if you change the code of SŌZU, you need to open-source not only your fork, but everything that can be reached/connected to by SŌZU.
Google has a policy against using APGL internally, nor in your company equipment[0].
The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license.
I don't think this true, the idea is that it triggers the same-license requirement even for network accessible code.
Where normal GPL only triggers that when the code is distributed, which allowed the SAAS loophole to exist.
As for the spreading to other programs part, yes that's the entire point, if you use free code, anything built on it should be free too, to continue giving to the Free/open Eco system.
Because the backend servers/containers/pods are immutable, every deployment creates new backends (that have new IPs) and then kills the old backends. This requires changing the proxy config at runtime. In the old days the backends would be mutable and would be updated in-place, keeping their IPs, so you could leave the proxy config alone.
Is it irony? Immutable data structures in languages like Haskell work the same way, copies are made and then the older ones are garbage collected. Seems like the same definition applies here.
Immutable doesn’t mean it cannot be updated. It just means that updates are happening without touching the same copy. This CoW-ish style is what they’re selling.
With IP Tableflipping [1], you can have live reloads & upgrades without losing a single packet and it is not web/proxy server dependent. Also, HAProxy has live reloads and upgrades from 1.8 by transferring socket connection from the old to the new instance. [2]
For all wondering sozu against other reverse proxy, sozu is capable of shifting traffic to a new backend without killing a single tcp connection. That’s extremely useful for real time video application.
I met the dev team (mostly French) a couple of times, they are super nice people!
Any decent reverse proxy should be able to shift traffic to new backend keeping old connections open. Nginx can, though combination of long tcp connections and frequent reloads would cause it to keep a lot of processes waiting for old connections to finish.
Without an answer to that if you use this and you need to make any change to it (even a tiny bug fix), you're basically opening yourself up a pile of legal issues.