Disclaimer: IANAL. This is a particularly interesting use of AGPL because it appears to contain a RESTful HTTP server built-in. To my knowledge, with the way

Disclaimer: IANAL. This is a particularly interesting use of AGPL because it appears to contain a RESTful HTTP server built-in. To my knowledge, with the way AGPL works, there are some interesting wrinkles: - It is only intended to “trigger” when distribution occurs under some legal copyright law definition of “distribution.” - It allows commercial use of unmodified and modified instances of the licensed code, as long as you provide the modified code, just like GPL. - Being a copyright license and not a contract (at least not intentionally,) it only is “viral” to derived works and not aggregate works. So, depending on what you define a “derived work” as, some interactions between AGPL and non-AGPL code may be kosher. Where this gets interesting to me is wherever you draw the line for derived works. For example, Ghostscript’s developers have a page regarding this subject: https://www.ghostscript.com/doc/current/Commprod.htm https://www.ghostscript.com/doc/current/Commprod.htm Particularly: > The application calls GPL Ghostscript in a way that allows an ordinary user to substitute another program for GPL Ghostscript. (Typically this requires use of a shell script or batch file, or a system call like "exec".) More precisely, if the user deletes from the computer system all the files in the GPL Ghostscript directories, and replaces the GPL Ghostscript executable with another program with the same name and conforming to the same documentation, the application will continue to work with it. One implication of this is that the GPL Ghostscript documentation must specify all properties of GPL Ghostscript on which the application relies; for example, if GPL Ghostscript has been modified by the addition of command line switches or language elements such as new operators, the documentation must describe any such additions that the application uses. If your AGPL application exposes a trivial JSON API, could you not write another application that simply supports a compatible interface, have it take an endpoint URL at runtime, and then just setup the software on another server and point to it? Although your software could be non-AGPL and maybe even closed-source, it could in theory be swapped out for any compatible service, including a simple noop implementation. Assuming the author(s) retain the copyright for all contributions so far, they are obviously able to use the program without worrying about said licensing restrictions. But if you flip it around and someone else also runs a SaaS where they distribute the source as per AGPL restrictions, they could then offer said services and presumably it would not be possible for AGPL to have “virility” to spread outwards further. I can’t think of any reason this scenario wouldn’t work the same if done on internal networks by a single entity. There is perhaps no particular takeaway here. In fact, maybe this was even intended to be a potential use case. However, I worry that this loophole may not be being considered: > If you want to use check-if-email-exists to develop commercial sites, tools, and applications, the Commercial License is the appropriate license. With this option, your source code is kept proprietary. Purchase an check-if-email-exists Commercial License at https://reacher.email/pricing https://reacher.email/pricing. While it is obviously true that directly integrating the library into an application would indeed constitute a derived work, I am skeptical, based on what I know, that using a fairly generic REST API would necessarily constitute this. I’m always a fan of open source as a model for better software development, but I do think that one really needs to be careful that it’s actually what they want. AGPL is a very interesting beast and there seems to be a lot of subtleties with regards to its implications in edge cases.