4

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?

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

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

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

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

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

1 Answer 1

7
  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.
5
  • 2
    I'm with you, except for #6. Whilst the usual GPL provisions are activated by distribution, so that use within a company (single legal person) doesn't trigger them, AGPL s13 is activated by interaction on the part of a user. It's not at all clear to me that individual employees within a company interacting with the company software don't trigger that, though if you have any pointers to professional opinions on the matter I'd be very grateful for them.
    – MadHatter
    Oct 24, 2021 at 21:04
  • @MadHatter Ah, I hadn't realised that subtlety. Edited to be less certain. Oct 24, 2021 at 21:28
  • @MadHatter The term 'user' is consistently used throughout the license language, and not specifically in section 13. Therefore it can be assumed that the same exceptions from requirements w.r.t. publication of source code on an 'Intranet service' for employees apply as if the program was actually distributed within an organization. I believe it would be difficult to argue that the intranet service would be treated differently than company-internal distribution. If different treatment had been intended then explicit wording in the license language would have been required to support that. Nov 2, 2021 at 23:10
  • 1
    @Martin_in_AUT I don't agree. The rights given in ss4-6 are all associated with conveyance of code, not usage; the rights given in s13 are associated with remote interaction. The language is very different. If you'd like to continue this discussion, I'd strongly recommend asking a new question.
    – MadHatter
    Nov 3, 2021 at 6:39
  • @MadHatter I do not want to ask another question, because it already has been asked multiple times and has been answered here and here and here. Nov 3, 2021 at 8:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.