Service with rich configuration abilities under AGPL License

Question

I’m trying to understand limitations of ‘programs’ licensed under AGPL, and the more I read, the more I confused. I’d very appreciate if someone can help me with 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. Program itself is a rest service. Source code consists of:

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

B) modules that implement access to infrastructure

C) 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 appropriate interface without updating\building the whole product (something like plugin support)

D) 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 basing on config files. Default config files are almost empty and service does nothing. 3-rd party can update config files according to their needs

E) In addition, service is available as 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; service is ASP .NET service; module means class library visual studio project

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

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

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 of (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 own business logic modules into docker container business logic and inject them into solution. Must they publish module’s source code?

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

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

5. The same case as #3, but instead of using it in own product, 3-rd party want 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 internal application available inside corporation’s network only. Does it changes answers below?

Thank you.

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.