The AGPLv3 is not an "EULA", as you don't need to agree to it merely to use the software.
All "EULAs" I've read (not many) require you to agree to the terms merely to use the software and also forbid pretty much everything but limited personal usage.
I haven't looked deeply into the Gentoo dspam case, but it appears that dspam has been modified by the Gentoo developers via patches, so they are obliged to provide the complete source code under the same license for the software for everyone they convey it to, which they have done by conveying the source code only.
The relevant part of the AGPLv3 is: "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"
If YOU were to run `emerge dspam`, YOU haven't modified the program, rather the Gentoo developers have - the fact that the patching process happens prior to the compilation stage is irrelevant.
I'm not exactly sure as to the workings of dspam, but it appears to scan received emails for spam and mark emails as spam or not.
As a result, I don't see any remote user interaction - as users seem to interact with unrelated SMTP daemon software while sending the email even at corner cases (i.e. SMTP via netcat).
It seems that only once the user network interaction has ended, that dspam is able to scan the email and determines if it's "spam".
It appears that if you were to install dspam on your personal email server used only by you, you could make any private modifications you want, as there are no "users interacting with it remotely through a computer network", aside from only you in certain cases, but you already have the source code.
The same is probably true for installation on a email server used by multiple users over a network, if all users only interact with unrelated STMP and/or POP3 software.
Although, if you were to setup a "spam detection SaaSS system", where users directly interact with dspam's "spam" detection features, then section 13 does indeed apply and you need to offer the corresponding source code to all users if YOU modify it.
@jernej__s >The problem is that if you put NextCloud (or any other AGPLv3-licensed program) on the internet, you yourself have to provide the source code of your running instance to anybody who accesses it. How do you achieve that? I don't see a problem with that myself, but you don't even need to provide the source code unless YOU modify it.
If you've made a modification to NextCloud, I don't see why you wouldn't be able to make a quick additional modification by slapping a link into the footer of the HTML pages.
A lot of AGPLv3 programs (like mastodon) have a modification notice as an automatic feature - it takes only a few minutes to paste a link to the source into the relevant section.
@christian@Suiseiseki The problem is that if you put NextCloud (or any other AGPL-license program) on the internet, you yourself have to provide the source code of your running instance to anybody who accesses it. How do you achieve that?
@jernej__s@Suiseiseki I fail to understand the problem here. Isn't the solution to stop using distros that don't provide the source code for their AGPL patches?
@Suiseiseki The point of AGPL is that any end-user of the software has the right to the source code of the program they're using, even if it's running on a remote server. It doesn't matter that the patching here was done by the distro – since you're running the program, you're the one that has to provide the exact source of the running program, otherwise that'd be a loophole anybody could use to avoid complying with AGPL.
And while marcan's post was about dspam, where it's questionable if its use even counts as end-users having interacted with it, there are a lot of web apps, where the end-user interaction is obvious (eg. NextCloud).
@christian@jernej__s The reason there hasn't been a lawsuit that is relevant to section 13 is that there hasn't been any business foolish enough to try at avoiding complying with the AGPLv3 yet.
The GPLv3 wasn't tried in court for many years, as for years, accidental or intentional copyright infringers were wise enough to just comply.
Eventually a big enough fool came along that wanted to bring their copyright infringement to court and they lost.
Many following fools have tried time and time again and lost.
The AGPLv3 was written with the help of (by?) a good lawyer so I have no reason to doubt that section 13 wouldn't be upheld in court.
@jernej__s@Suiseiseki Sounds like an straw man interpretation to me. Do you know of any examples where such a claim have been tried in court, in any country?
@christian@Suiseiseki You have to do it within the program itself (according to the strict AGPL interpretation, you have to offer the source code as the very first thing when any user accesses the program running on your server). And no, NextCloud does not do this, and neither does any other AGPL program I've come across – it's a mess.
marcan had a great twitter thread on this (with a bunch of examples), but it's unfortunately gone.
@jernej__s@Suiseiseki Sorry, I guess I'm stupid - but again, I don't see the problem.
You refer the interested users to a place where the source can be downloaded? Your own repo, the official or the repo of the distro that is shipping mods.
I've never used Nextcloud - but I assume that it have the required notices in interactive parts of the system?