Service with rich configuration abilities under AGPL License

Question

I’m trying to understand the limitations of ‘programs’ licensed under AGPL, and the more I read, the more I am confused. I’d very much appreciate it if someone can help me with the following questions. I’m trying to keep as less technical details as possible, but I have to provide some for context and to highlight edge cases.

Situation.

Let’s assume there is a program’s source code licensed under AGPL 3.0. The program itself is a rest service. Source code consists of:

1. modules with business logic. Uses inversion of control, very easy to inject new functionality into original logic.

2. modules that implement access to infrastructure

3. modules that configure dependency injection for A and B wrt to provided configuration. Configuration can either use business logic from A, or inject 3-rd party binaries that implement an appropriate interface without updating\building the whole product (something like plugin support)

4. service that configures web interface and configures all above with json-configuration file. Business logic-wise, there is one line call to the module (section #3) that configures everything based on config files. Default config files are almost empty and the service does nothing. The 3rd party can update config files according to their needs

5. In addition, the service is available as a docker image, with default config files (mentioned above).

Just in case, tech stack is .NET; all source code is part of one visual studio solution; the service is ASP .NET service; module means class library visual studio project

A 3rd party wants to use this service. What obligation do they have in the following cases?

1. If 3-rd party pulls a docker image, copy their own configuration files to the image, deploy it to their infrastructure, and use it as part of their public-facing web app. Must they publish configuration files and/or modified docker containers? In other words, can AGPL treat significant configuration changes as software modifications?

License says:

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

So, in this case, config files are needed to run object code properly. On another hand most (if not all) server applications require config files. Does it mean that every service under AGPL requires publishing sources?

2. The same case as #1, but they copy their own business logic modules into the docker container business logic and inject them into the solution. Must they publish the module’s source code?

3. If 3-rd party implements its own service using modules A, B, C without modifications inside of code. But they implement some extra business logic (in a separate module) and inject it into the original logic. Then deploy it into their infrastructure and use it as part of a public-facing web app. Must they publish the source code of their service and extra modules? The key point here is that the original modules aren’t changed\updated. Extra functionality is built on top of existing modules.

4. The same case as #3, but modules A, B, C are available via a package manager (nuget in the current case)?

5. The same case as #3, but instead of using it in its own product, 3-rd party wants to sell the binaries in any form (docker image, nuget packages).

6. The same questions as #3, #4, but they use service as part of an internal application available inside the corporation’s network only. Does it change the answers?

Answer 1

1. No, the configuration files are not part of the work; reading a text configuration file is in general not "intimate data communication".
2. Yes, if the injected modules engage in intimate data communication with the covered work.
3. Yes, ditto; while there is some debate over whether linking creates a derived work in copyright law, the general consensus (and certainly that of the FSF) is that it does.
4. No change - the AGPL doesn't care where you got the other bits of code from, the same requirements apply.
5. No change - the AGPL doesn't care if you sell it or not, the same requirements apply.
6. This is unclear. While using something internally within an organisation is not distribution and therefore the majority of the (A)GPL does not apply, section 13 of the AGPL requires you to make it available to "all users". It is potentially an open question as to whether the users in that case are separate entities entitled to the code, or whether they are part of the organisation.