3

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 ?

  • 1
    Why did you replace " (if your version supports such interaction) " with " ... " in your quote from the license? It seems to be relevant. – Glenn Randers-Pehrson Jan 30 '16 at 18:20
  • Just for compactness because the direct link to the section in question was given anyways. However, I've edited the question. You think I should quote the complete section 13 or even the full license here ? – gollum Jan 30 '16 at 19:45
  • @GlennRanders-Pehrson can you elaborate on the relevance you mentioned? Is it not obvious that a vnc server supports user interaction over a network? Thanks. – gollum Jan 30 '16 at 20:06
  • 1
  • I'm a bit confused (and this same confusion is possibly what made @GlennRanders-Pehrson suggest including the parenthetical in your question): your title and your first paragraph indicate you assume that the program does not qualify for the terms in section 13 (since you say it is not interactive) but then you ask at length about how to fulfill them. Am I misunderstanding your first paragraph? – apsillers Feb 1 '16 at 19:18
3

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

  • Wow, excellent answer. Very much appreciated! So someone who modifies the source really has to add the functionality to display the offer if it does not exist yet? I wonder how one could do that with an AGPLv3 licensed dns server ... ;) – gollum Feb 1 '16 at 22:33
  • 1
    @gollum That's a fair question. I'd point out that a network service can't actually display anything to the user -- "displaying" is possible only for programs running directly on the user's machine. A network service may have a relationship (per some protocol) that should cause a client to display something, but it's possible that a client has a relationship with a network service (such as with DNS) where there is no network response that corresponds to a client-side display. – apsillers Feb 2 '16 at 18:36
  • 1
    @gollum As a separate issue, also with DNS, I don't know if DNS even supports free-text comment-like information in responses; it might not allow responding with any information not directly related to resolving host names. In that case, including source-access information seems completely impossible, since it would require a violation of the software's relevant network protocol. – apsillers Feb 2 '16 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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