4

I am working on a central application (AGPL3+) that will control and/or provide access to multiple secondary applications, mostly on other servers. It is trivial for me to provide the source for the central application.

Do I need to provide the source for the secondary applications? (This would be tricky since I don't package them, but I can probably provide a best-effort link.) If not, is there a "rule of thumb" for determining when a secondary application is not secondary, and actually a component of my AGPL application? (Or is it exactly the same as determining dependency/linkage with the GPL?)

Illustrative examples

Is it true that in each of the following scenarios I am not obliged to share the source of the secondary application:

  1. I decide serve the central application with a web interface, using an IIS/Windows stack (proprietary license) plus a custom library I made (my contribution/modification).

  2. The central application adds accounts to a Prosody chat server (Expat/MIT license) that I have modified, and reports on the volume of chat data you have generated. (Users access the Prosody server with the XMPP client of their choice.)

  3. The central application adds accounts to a fictional password manager (GPL3+ licensed) that I have modified, and reports on the number of passwords you have stored. (Users access the password manager via its own web interface.)

  4. Finally, the central application interacts with some other AGPL3+ application that I have modified, here I am obliged to share that source.

Improve this question
6
  • 1
    The key question is how do your various bits of code interact with together and how these are served to the users and which parts are AGPL and if they are modified or not. Is Prosody AGPL-licensed? There is no blanket answer IMHO, only specific ones.
    – Philippe Ombredanne
    Oct 17, 2017 at 10:28
  • A small observation - When you say "my copyright" on software that you modified, I believe this is actually shared or joint copyright. The original authors still have a claim to that software too.
    – airfishey
    Oct 17, 2017 at 14:05
  • 1
    You did not explain how you interact with the AGPL-licensed code: function calls in process? rest API calls? forking a command in a process?
    – Philippe Ombredanne
    Oct 18, 2017 at 7:00
  • You've told us what your code interacts with other components to do, but that's immaterial to the licensing issue. What Philippe (and the rest of us) need to know is how it interacts. Eg, in case 3 above, does it interact with the password manager by invoking the PM binary through userspace? Does it invoke features of the PM system through its library, which is linked into your application? Is some kind of shared-memory space used? Though it's not definitive, these details are understood by many to give the best guide to what is and is not a derivative work.
    – MadHatter ♦
    Oct 29, 2017 at 8:25
  • thanks for all these comments, I've realized what I'm actually asking is opensource.stackexchange.com/q/6704
    – lofidevops
    Apr 8, 2018 at 8:00

1 Answer 1

Reset to default
3

You do not need to provide the source to applications that you merely communicate with over the network. If your application is linked to another codebase (the definition is the same in both the GPL and AGPL), then you need to provide the source as usual.

In most cases, this simply means that you can regard your application as running on the user's machine. Anything you would have to provide if it were running on their local machine under the GPL, is what you must provide if they are accessing it over a network.

Improve this answer

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.