[jlokier]

I think 'toxic' in the case of AGPL means that companies who would like to run privately-modified versions of your AGPL software on their servers for end-users to use (remotely) don't want to share their changes.

If your priority is strictly that you want everyone to benefit from improvements that are made, AGPL isn't toxic.

On the other hand, it might limit what improvements are made in the first place, because companies that don't want to share won't adopt the software and make those improvements.

So the dilemma is one of priorities. If you want widespread adoption by companies, you have to license in such a way that companies can keep private modifications, because that's their priority. (Unless they are an open source company, and I would be surprised if those have a problem with AGPL.)

There is a secondary dilemma where companies worry about where the line is between 'private modification' and 'mere aggregation'. It's understandable that companies who think their crown jewels are the network services they provide, would worry that using AGPL software as part of their services might be found to be so closely related to the AGPL software that it's a derivative of it, making the whole thing is subject to AGPL release terms. Especially if engineering gets a bit sloppy about copying and pasting.

Some companies ban GPL software, not just AGPL.

[TomVDB]

Your assumption that a company’s priority is to not share is a possibility, but it is a worst case one, and one that is IMO less of a concern for a programming language: keeping bug fixes or even new language features to themselves may very well be a net negative. A buggy reference language implementation for external users will turn them off from using it, and make it harder to hire experienced users or benefit from improvements by others.

For such a case, the fear of using AGPL is much more likely one of accidental contamination, such as an employee copying a piece of AGPL licensed code into a completely different, unrelated project.