> to publish all of your source code if you make any changes to the product
Specifically, this is the text [0]:
> 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
There are a few companies who try to make it sound like if you interact with an AGPL program over a network then your client code is now infected with the AGPL, but I'm not at all sure how they arrived at that conclusion unless it was willful misinterpretation.
Under the mainstream view, you only have to publish the source code for the AGPL work that you modified, which for 99.9% of users is fine but isn't great for a reseller.
The main barrier isn't the actual text of the license, it's that AGPL is still untested in court and there are companies who will try to make it mean something different than its apparent meaning, so legal departments are liable to get antsy. But lawyers are likely to get antsy about self-hosting under these other licenses as well.
> To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.
While the AGPL might be untested, copyright isn't, and I don't think any copyright lawyer would say that "calling over the network" is adapting "the work in a fashion requiring copyright permission".
> There are a few companies who try to make it sound like if you interact with an AGPL program over a network then your client code is now infected with the AGPL
Of course not, or
1. Any web browser would have to be open sourced, and
2. That would be the consequence of an action taken by a third party (eg: me) and not by the parties that created the web app and the web browser.
If the client talks to service A, which talks to AGPL service B, I assume that would count as having to "prominently offer the source code for service B". No? If that's true, then it becomes a real pain to track all the places where an end user could indirectly come in contact with service B.
If that's not how to interpret the license then wouldn't a simple API gateway or proxy circumvent it?
> then it becomes a real pain to track all the places where an end user could indirectly come in contact with service B
Easy solution: then you just publish your patches for anyone to get. Or just anyone with a login to your SaaS. If you haven't changed anything then they can just get the original source themselves.
If the AGPL is exactly as you say, I don’t see why this would be a problem for a re-seller. For a pure re-seller I don’t think the value add is provided by modifying the software.
E.g. take the example that Amazon hosts the service and integrates with their internal services etc for logging, storage, load balancing etc. If they only have to distribute the modified source, then their internal service APIs will be leaked. This is probably fine most of the time, but what if the API reveals too much of the secret sauce (very unlikely, but possible so necessary for legal CYA, or extra approvals every time you want to modify the AGPL code). In a more devil’s advocate reading, the following stands out (IANAL, just conjecturing):
> all the source code needed to generate, install, and (for an executable work) run the object code
Do I need to include my super secret storage engine X because my modification requires that I use it? Let’s say I write the code in a way that it is an optional dependency, but because of a programming mistake, a single version goes out where it becomes a non-optional dependency, do I now have to include it (for the users of that version)?
In an even more contrived case, let’s say I integrate it with a vendor closed source program X. The virality is impossible to satisfy, unless I negotiate an AGPL license for X.
> 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
Intimate data communication is pretty vague. Imagine the AGPL is a database, and I write a custom storage engine. Naively that seems pretty intimate to me.
Either correctly or incorrectly (because it’s never been tested), the perceived virality of AGPL is probably a major reason, regardless of the actual intent.
The two parts you quote apply just as much to the GPL as to the AGPL. And virtually every company today uses GPL software in some fashion.
Also, AWS did offer at least one AGPL service, managed MongoDB. They still offer it, Mongo just changed their license precisely because the AGPL didn't protect them from Amazon in the way they were hoping.
Well, it doesn’t matter as much for GPL because there are no requirements over the network, which means no requirements for SaaS (which is exactly what AGPL addresses).
And also, software distribution is different. Typically, you don’t bundle dependencies and instead install them with e.g. a package manager or system library (at least on Linux), so the separation is clearer because you don’t need to distribute the GPLed code to your user (in many cases).
> Amazon offered at least one AGPL service
Are you sure? I only found DocumentDB (which only promises MongoDB compatibility). There’s also a comment by an Amazon employee that suggests Amazon never provided hosted MongoDB when it had AGPL or SSPL [1]. Further down that thread, it also suggests that AGPL at Amazon is possible, but requires extensive review beyond other open source.
> take the example that Amazon hosts the service and integrates with their internal services etc for logging, storage, load balancing etc. If they only have to distribute the modified source, then their internal service APIs will be leaked.
No. What URLs the logs are sent to is just a config option - probably not even for the hosted software, probably for the kubernetes pod - not source code. If the logging exporter has to speak a magical protocol to send to Amazon's internal logging, that's Amazon's problem - they can either write a shim service to translate the protocol and then they have to publish nothing, or they'd have to publish their changes that allows talking to the magical internal logging protocol.
> Do I need to include my super secret storage engine X because my modification requires that I use it
If you are hosting the software with your super secret storage engine, then you have to be ready to provide the modified software code to anyone who uses it. If all your users are internal then cool you get to keep it internal - though there's no restrictions on who they can send that code to.
You modified the code to improve it for a use case. The whole point of AGPL is that you if you start distributing that modification then you don't get to keep it a secret and prevent it from being upstreamed.
The original project might not even be interested in your changes if it's only for some super specific use case.
In my example, the URLs are not the issue. What I was trying to say, which you actually ended up agreeing with is that they would have to publish the changes that allowed talking to the internal protocol. All I added to that, is that is perhaps not something that they want to share (logging is just an example, big companies have a lot of internal infrastructure for debugging, tracing, monitoring etc).
Re: distributing modifications
You’ve missed the point in my second example. The API portion is covered by my first example. My second example is about possible virality due to the concept of required dependencies.
If I have a special remote storage backend that requires speaking a custom protocol (which is used widely across my existing infrastructure) and I change AGPL code to require it, it is reasonable that I have to publish the source code for talking to the custom protocol (again, covered in the first example).
What is new about this, is that if my version of the binary requires a backend that uses the custom protocol, then just publishing the version of the AGPL software that speaks the API is not enough to be able to run it (because it won’t work without a backend that speaks that protocol). According the provisions for intimate data transfer and executability, it is possible to interpret the license as requiring the backend, which is NOT a part of the AGPL software that you have pulled in as a dependency to be AGPL as well. I assume this is where the concerns about virality beyond the original project arise.
Distributing modifications is reasonable, possibly needing to distribute everything the binary ends up talking to over the network is the concern.
No, you're just willfully misinterpreting these clauses
> 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
If you don't change the source code and you instead write a shim service for it to talk to a special logging protocol, you haven't dynamically linked anything, you haven't changed source code for shared libraries, and you haven't messed with source files.
And even if you tried to argue that "talking over a network" is "dynamically linking" which would be just a completely made-up definition of dynamic linking that would never stand up, it still would not count as something that the original "work is specifically designed to require".
Specifically, this is the text [0]:
> 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
There are a few companies who try to make it sound like if you interact with an AGPL program over a network then your client code is now infected with the AGPL, but I'm not at all sure how they arrived at that conclusion unless it was willful misinterpretation.
Under the mainstream view, you only have to publish the source code for the AGPL work that you modified, which for 99.9% of users is fine but isn't great for a reseller.
The main barrier isn't the actual text of the license, it's that AGPL is still untested in court and there are companies who will try to make it mean something different than its apparent meaning, so legal departments are liable to get antsy. But lawyers are likely to get antsy about self-hosting under these other licenses as well.
[0] https://www.gnu.org/licenses/agpl-3.0.en.html