[p_l]

Yeah, I've read the text.

And it's trivial to be compliant with AGPL in this case without any effective change to the behaviour or problems caused. Yes, there would be source code link somewhere, but it can take 0.01% of the SEO spam and be still compliant.

[frognumber]

There are plenty of examples of BSD-licensed code authors being burnt like this (including original ones from Berkeley, which were an impetus for the creation of the GPL; there were proprietary Unix systems built on top of volunteer-written code competing with the original systems).

Can you point me to any concrete examples of authors of AGPL-licensed code being burnt like this?

Circumventing the AGPL is trivial only on paper. It's hard in any human organization. In practice, parasites usually keep a long distance from the AGPL for reasons which will make sense to you if you sketch out what circumvention means in practice, what it means for org design, and the ROI there (not to mention the social signalling; not all parties are malicious).

[p_l]

AGPL does cause issues in various places, yes. But not in this specific case.

Quickly checking through license text (AGPLv3 as published on FSF website), following steps would have been enough:

1. Ability to view legal notice (does not have to be full, just reasonably visible)

2. A link that opens source of the code

3. AGPLv3 header in source code with notice of who and when modified it

Note that there's no need to explicitly advertise/attribute the creators in any more visible way. AGPLv3 also does not impact code that isn't derivative like all the SEO spam one's blackened heart puts on the site, especially when combined with modern "tag manager".

And we're explicitly talking about pathological cases from the start. To paraphrase oliwarner in this thread[1], we're dealing with people who are deliberately acting dickish.

I'll bypass discussion of BSD-licensed authors being burnt like that, because the legal situation was way more complex (before the GPL came on the scene) regarding a lot of BSD code (shortlist: 1) being derivative of other code 2) in at least one case being explicitly paid-for work with explicit "to be reused freely" conditions on the grant)

[1] https://news.ycombinator.com/item?id=39415042

[frognumber]

.... which would address the author's issue of not having access to the source code.

But you messed up since you proposed a technical solution, where this is an organizational problem. Let me walk you through the more complex issue. The other website follows your steps and is in the clear. However:

* The interactive is more deeply integrated into their web page, whether originally, or through a developer five years later not noticing the AGPL special case.

* OP asks for source code to the full work. The full work is their entire web site in this case.

* The full work happens to include a JavaScript library and a font program which were licensed from a proprietary vendor.

The other website has two options: (1) Negotiate to release the their source code, and worse, their vendor's source code under the AGPL (2) Pay damages.

To avoid this, beyond the steps listed, the other website needs to implement processes and controls to prevent issues like this one. That is where the $$$$$ comes in. Processes are expensive to maintain, much more so than any software.

In general, AGPL code is very safe to use in commercial settings for well-compartmentalized major systems. If I have an AGPL office suite used by my organization, or ed-tech software, that's easy. Used it in a corner like this one, it requires a lot of controls and compliance, which make it prohibitively expensive. AGPL has a few more catches like this. This is why most major organizations tend to require legal review prior to any use of AGPL code.

AGPL tends to be good for several purposes:

1) Establishing open ecosystems. If I do work in civics or education, this can be very important there. If I am making a voting system, for example, I want to guarantee anyone can inspect the system at any level.

2) Dual-licensed systems. Open ecosystem is free. Proprietary pays.

3) Major pieces of well-isolated code, like the aforementioned office suite example, where I don't want freeloaders, and where there isn't an expectation that I will have my code used as a library or piecewise in another system.

4) Places where the goal is more transparency than reuse.

There are a few others too.