1

Says AGPLv3:

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 by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

This requirement is known as the "remote network interaction" requirement, after the title of the section where it occurs. In AGPL discussion, there is a corresponding "remote network interaction" design problem, based on three fragments:

  1. "all users interacting with it remotely through a computer network": Because users are usually represented by user agents, this means that even automatic requests need to be satisfied
  2. "(if your version supports such interaction)": This paragraph only is engaged if the software is designed to take advantage of the AGPL's anti-SaaS features
  3. "some standard or customary means of facilitating copying of software": Most vendors don't have such customs

In many fora, this "remote network interaction" requirement is discussed as an obstacle to practical enforcement of the AGPL. The reasoning is simple: Software isn't designed with the AGPL in mind, and thus is not able to fully utilize its protections. As a thought experiment, however, let's imagine some software which intends to fulfill the requirement:

  • The Program shall be a package manager which transmits packages and source code via peer-to-peer connections
  • All interoperable versions of the package manager, including modified versions, communicate with a single common protocol which features signature-based authentication
  • Specifically, when two peers communicate, they request zero or more signed bundles of data from each other
  • There is a unique way to request that a peer deliver a signed bundle for its own source code, the Corresponding Source, using its own key
  • A peer publishes a package by explicitly licensing and signing a bundle and then agreeing out-of-band to have other peers request the freshly-signed bundle

Now, suppose that the Program is licensed under AGPLv3 and that its subroutine for signing bundles requires them to be licensed under AGPLv3 as well. Then we have placed any user into the following position: If they modify the Program, their modified version must reply to requests for the Corresponding Source of their version by transmitting a self-signed bundle with the Corresponding Source. In terms of enforcement, have we enforced the AGPLv3 in a manner which solves the "remote network interaction" problem?

One reasonable complication is that this all should probably be not "AGPLv3" but "AGPLv3 or later".

An objection which is reasonable but not quite right is to point out that users cannot be forced to use AGPLv3 merely in order to participate in the ecosystem. To be pedantic, users can be required to use AGPLv3 in order to publish packages, but not merely to author packages; further, this can be an extremely one-sided arrangement, as in the automatic licensing clauses in terms of service offered by YouTube or GitHub.

4
  • 3
    Can you elaborate what is meant with the "remote network interaction" problem? – Bart van Ingen Schenau Jun 23 at 11:54
  • Added a paragraph to explain the context. In short: How to prevent forkers from simply removing the code-delivery bits? Well, what if the software doesn't do anything but code delivery? – Corbin Jun 23 at 15:26
  • 1
    @Corbin They're allowed to make a version that doesn't interact over the network. This version is still AGPLv3 licensed and if someone adds network interaction again later, they have to offer the source code. I don't understand what the problem is. – user253751 Jun 29 at 16:47
  • @anon: For context, see my previous exploration leading to AGPL. The hope is that corporations would be disincentivized to ever use code delivered through this package manager. – Corbin Jun 29 at 17:26
2

In AGPL discussion, there is a corresponding "remote network interaction" design problem, based on three fragments:

[...] 3. "some standard or customary means of facilitating copying of software": Most vendors don't have such customs

I guess this is the point where most people see the core of the design problem, and that is because the requirement is being interpreted incorrectly.

The AGPL does not require an in-app facility to download the source code of the application. The requirement is that you offer access to the source code and that you do so in a manner that is recognized by a software developer as a mechanism to obtain source code.

There are numerous ways to satisfy that requirement, including providing a link to a publicly accessible repository or providing a link to a zip file or tar-ball with the sources.

What would not satisfy the requirement is that people would have to send HTTP requests like GET /index.php with a specific content type to avoid the file being interpreted by the server. That is not a customary means of copying software.


If they modify the Program, their modified version must reply to requests for the Corresponding Source of their version by transmitting a self-signed bundle with the Corresponding Source. In terms of enforcement, have we enforced the AGPLv3 in a manner which solves the "remote network interaction" problem?

You cannot enforce the AGPL requirement of providing access to the source code with technical means.

If I modify the Program and choose to honor the protocol requirements of responding to that special command with the Corresponding Source of my version of the Program, then I comply with the requirements of the AGPL.

But, if I modify the Program to drop support for that protocol and use a different protocol, then that modification is fully allowed by the AGPL. Within the new way(s) of interacting with the Program, I now have to find a way to tell my users how to obtain the Corresponding Source to satisfy the requirements from the AGPL. If I don't, then the only way to enforce compliance is through legal means.

3
  • I think that our understanding of your last paragraph is key. I am imagining that the program's functionality is direly broken in that case; imagine if Nix could not use existing binary caches. (Or cryptocurrency forks, etc.) Such a change is legally allowed but would exclude the forkers from the community. – Corbin Jun 24 at 16:00
  • 3
    That's because the aim of the (A)GPL isn't to maintain a "community", at least not via technical means - in fact, the ability to fork and create a new separate community when you don't like the old one is one of the fundamental freedoms of any open source software. – Philip Kendall Jun 24 at 16:16
  • 1
    @Corbin Yes, you're allowed to take an open source network application and change the protocol. Why wouldn't you be allowed to do that? – user253751 Jun 29 at 16:48

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.