AGPLv3 §13 and non-interactive software

Question

See AGPLv3 §13 (Remote Network Interaction).

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version ...

Assume I'd want to write a VNC server. It is clear that the user does not directly interact with the software but rather with the applications displaying on the framebuffer which is serverved by the software.

However, it is still technically possible for the software to inject some text/information (e.g. for some seconds on the first connect) into the framebuffer being encoded that "prominently offers all users interacting ... the corresponding source".

As far as I understand this requirement for the source code offer only applies if the program was modified - right?

So would I have to ship this functionality (injecting a prominent message in the framebuffer) in the source so that someone who modifies the code has an easy way to activate this framebuffer overlay in order to comply with the license?

If not, how could someone modifying the source comply with the license?

Since this overlay might be quite annoying It should not be required for users who e.g. install a debian package. But Linux distributions normally do make modifications to source codes, hence thez would have to enable this nag screen - right ?

If so, do modifications like security patches or other distribution specific patches (like path changes etc.) count as modifications ? If that is the case, how would one make an exception that distribution specific patches must not trigger the "prominent offer" requirement ?

Answer 1

You'll find a similar issue in the GPL FAQ:

For software that runs a proxy server licensed under the AGPL, how can I provide an offer of source to users interacting with that code?

For software on a proxy server, you can provide an offer of source through a normal method of delivering messages to users of that kind of proxy. For example, a Web proxy could use a landing page. When users initially start using the proxy, you can direct them to a page with the offer of source along with any other information you choose to provide ...

Although a proxy server is quite different from a VNC server it is a perfect example to understand the license authors' intention: Use any available means to display the offer of source.

So as you've correctly pointed out it is possible for a VNC server to display (actually draw) a message and therefore someone who modifies the code is obliged to use this functionality for the offer of source.

My advice is that you implement this feature in your official version and add an option (via config file) to disable this feature. Something like this:

# This program is distributed under the terms of the AGPLv3.
# If you have modified the program, your modified version must prominently offer
# all users interacting with it an opportunity to receive the corresponding
# source of your version.
# See http://www.gnu.org/licenses/agpl-3.0.en.html#section13 for details
# 
# YOU MUST NOT DISABLE THE FOLLOWING OPTION UNLESS YOU HAVE NOT MODIFIED THE
# SOURCE CODE
#
SHOW_SOURCE_OFFER=TRUE
SOURCE_CODE_LINK=http://link.to.your/sourcecode.tar.gz 

Answer 2

So would I have to ship this functionality (injecting a prominent message in the framebuffer) in the source so that someone who modifies the code has an easy way to activate this framebuffer overlay in order to comply with the license?

Strictly speaking, no, you do not. As the original author and copyright holder, you are under no obligation to add a prominent offer of source code.

If not, how could someone modifying the source comply with the license?

They may do so by adding such a feature themselves. If you feel that requiring downstream modifiers to write such a feature this unfairly onerous, then you are welcome to write it yourself. You are in no way legally required to do so, though. (Note also that such a feature would probably only need to be written once, since after the first source-offer mechanism was added to your code by a downstream project, others could just use that in the future).

do modifications like security patches or other distribution specific patches (like path changes etc.) count as modifications?

Generally, the any change that is not eligible for copyright (e.g., in the U.S., it may fail to contain a "modicum of creativity") does not create a derivative work under copyright. therefore, purely mechanical changes like alterations to file paths or connection settings do not create a derivative work and do not constitute "modifying the program". If you are unconvinced by this argument, you could also make the configuration option a separate data file and explicitly license it differently from the other files. This file would be just data to the AGPL program, not part of the AGPL program itself.

Security fixes are quite another matter. Since they substantially change the behavior of the program, they are probably eligible for copyright and would constitute modifying the program. The easy imperfect fix is to push the security patch up to the original project and then receive it as a new (unmodified) version of the project. However, this requires a cooperative and responsive maintainer on the original project. Failing this option, the only possibility for a recipient is to modify the program with the security patch and write functionality to share the new source (if no such functionality already exists).

how would one make an exception that distribution specific patches must not trigger the "prominent offer" requirement?

I cannot think of any permission that would cleanly allow security patches without allowing general changes, because the notion of a "security patch" is a nebulous subset of all possible patches. You can't say, "patches must not substantially change the behavior of the software," because often the entire point of a security patch is to change the behavior of the software (i.e., so that it doesn't behave insecurely anymore).

As mentioned above, changes that are insufficiently creative to qualify for copyright probably already fail to trigger the "if you modify the Program" condition.