> The law would be more than happy to accept that there exists something that generates a link or git clone command to stand in as a distribution mechanism for

> The law would be more than happy to accept that there exists something that generates a link or git clone command to stand in as a distribution mechanism for the source archive which a competent practitioner could use to derive the program in question. The requirement is for the source code for the corresponding version is what is advertised. The vast, vast majority of AGPLed apps do not have any automatic mechanism to match the currently running version to such offer; if there's an offer at all (which there often isn't, making all forks and branches violations unless they add it first), it's usually a hard-coded link, and then the onus is on the person making changes to first modify that link to point to their version. Yes, there are technical ways in which you can make the AGPL work in a vaguely reasonable way, avoiding this problem by automating your way around it. And nobody implements them. If people understood these requirements and actually implemented those mechanisms, we wouldn't have this problem, and people would also be aware of just how special and non-free the AGPL is because it's imposing requirements on modification beyond what a free software license can. I'm not saying it has to be a source code archive, but if it isn't a source code archive, then you'd better find a way for the app to magically know what git repo hosted elsewhere should be used as the source code offer link, and have it automatically update for any forks/branches and always stay up to date. Having an automatically generated local source code archive, or outright serving the source code of the currently live app (e.g. for interpreted languages) are the only sane ways I can think of of automating compliance with this AGPL requirement. Anything that points to another server or repo isn't going to stay up to date as people make changes, and then you're back to square one.