My reading is that there is no requirement for batch processing at all. As long as the software itself (as defined by the usual viral GPL linking rules) does not support something that can be interpreted as "network interaction", you can wrap it however you want into a network app, and the license has absolutely no effect on you because, as designed and implemented, and unlike most believe, it's a pure copyright license and cannot control what you do with the software (even though the FSF would love to make everyone believe otherwise, since otherwise they'd realize how broken it is).

In practice, of course, the AGPL wording of "supporting remote interaction through a computer network" is hilariously vague and broken, and completely untested in court, so who knows what that means. Is an app that does standard stdin/out processing considered to "support" network interaction because you can plug it into a bog-standard inetd? Does an X11 GUI app support "network interaction" since the X11 protocol does? What about Wayland, does the existence of waypipe change anything? Does the existence of ssh mean that any command-line app counts as supporting network interaction? And how is this any different for, say, a Python WSGI web-app, which in fact cannot support network interaction on its own without a supporting WSGI web server?

No matter how you slice (heh) the answer to these questions, AGPL falls flat by either completely failing to protect anything by allowing endless workarounds to the networking requirement (on one end), or by requiring even the simplest of apps to have functional and always up-to-date source offers for all user (or even non-user) interaction, thereby making vast amounts of AGPL software out of compliance if they have more than one contributor (on the other).

Practical AGPL reminder: You are safe as long as you do not contribute to or modify AGPLed software, and as long as you don't use Gentoo or other source-based distros. As long as you follow those rules, you can install and use and serve over the network AGPLed software without fear of violating that broken license, and you don't have to care about the existence or lack thereof of a source offer mechanism, since you aren't touching the code yourself.

Most distros that ship AGPLed software as pre-built packages probably violate the AGPL themselves, but that's not your problem, it's theirs. However, on source-based distros, the ebuild/etc might patch the AGPLed software on installation, and if it does that it almost certainly fails to add or update the source offer mechanism as required by the license, making you, the user, responsible for violating it since you initiated the actual modification that is out of compliance.

(I'm only half joking, there is a legitimate distinction here!)

@marcan Well for Gentoo you can somewhat respect it https://gitweb.gentoo.org/repo/proj/guru.git/tree/www-apps/pleroma/pleroma-9999.ebuild#n59 (currently won't work for eapply_user but probably could be addressed with copying the patches to a browsable directory).

Also AGPL is quite an annoying problem in terms of code reuse since you can't really move the code from server to a library without that being a serious headache (and good luck doing something like a clean-room reimplementation for another license).

@lanodan @marcan I don't think it's really Gentoo specific at all. The issue is how you communicate any patches used at all or the specific (packaging) version -- do you inject it in all responses? add a custom field? what if no such field exists (protocol is an established one and someone just wrote some new AGPL impl)? The same problems exist with, say, Debian and whatever their patches may or may not be.

@thesamesam @lanodan The difference is that with Debian/etc, the person committing the license violation is whoever applies the patch and builds the binary, which is not the end user. With Gentoo, the end user is applying the patch, so they are committing the license violation.

Of course, the brokenness of the AGPL affects everyone. I'm just describing how it doesn't affect end-users of binary distros, but it does end-users of source distros.

@lanodan @marcan Of course, there's a specific issue with /etc/portage/patches but I expect this to be somewhat minimally used for services anyway. And it's really a small issue in comparison to the other bit I mention IMO.

@lanodan @thesamesam And this is why the AGPL is completely broken.

@thesamesam @lanodan I'm talking about AGPL software that Gentoo applies patches for directly in upstream portage and does *not* do any license URL updates for, which I know for a fact used to happen (the one particular package I personally used and knew of is now retired, but I'm sure other cases exist if you dig around).

@marcan "or by requiring even the simplest of apps to have functional and always up-to-date source offers for all interaction, thereby making vast amounts of AGPL software out of compliance"

most SPAs are out of compliance in the same way because they use MIT-licensed libraries but don't include the copyright notice in their minified Javascript

@val I thought there was a standard for this, something about the first comment being special and not minified?

@marcan The AGPL protects your software from being used by corporations in the exact same way as everyone giving a wide berth to the person screaming in the street with delusions of grandeur.

@return0 Beautiful.

@marcan @val yeah i think a number of minifiers will keep comments that start with an exclamation point

@marcan @lanodan I think one starts to get into interesting definitions of "application" there. I'm not convinced that it's somehow magically different because Debian did the building if I'm running that service, especially if I was then made aware of this problem. If Debian did on-demand builds, would that be different?

@charlotte @marcan I see it sometimes for React's license, but that's pretty rare for others.
For example the first JS file on Reddit (https://www.redditstatic.com/videoplayer.XCrwE8Bi5A4.js) visibly contains dashjs (or at least http://cdn.dashjs.org/v2.4.0/jsdoc/module-FactoryMaker.html) but has no comment

@marcan i wonder is there another license that has the same spirit of the agpl but less ambiguously worded in legal terms

@delta @marcan Copyleft licensing is fundamentally incompatible with usage-based restrictions, so no. You'd AFAIK need an EULA to do that.

@vjon @delta Correct. Doing what the AGPL claims to do / people believe does is fundamentally at odds with the Free Software Definition. You'd have to use a license that is, by that definition, not Free Software (or change the Definition).

@erincandescent @flameeyes The issue isn't fundamentally legal, it's social. Regardless of what the law says about reading contracts, in the FOSS world, we consider a license that does not restrict your usage of the software as a pure copyright license, and one that does as an EULA.

The AGPL is, in fact, written so as to be a pure copyright license.