[skrtskrt]

> 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.

[ratorx]

Re: logging URLS

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.

[skrtskrt]

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".