Can a package manager solve the AGPL "remote network interaction" problem?

Question

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.

Answer 1

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.