Maybe I need to read the AGPL again. I remember interpreting it as saying that if your service was dependant on the component then the license applies to the code for the rest of the service.

There is a lot of corporate knee-jerk for the AGPL ; there are many different interpretations for it and when you ask different people what you can exactly do and not do, they will tell you that they are not a lawyer.

Which is why companies I work with cannot tolerate it anywhere, they just won't consider it. I think people who want to explain these things should do it on the base of use-cases instead of vague wording.

So;

- I start a AGPL system in a container and talk to it via the exposed API, I don't tell anyone I'm using it -> yes/no?

- I start a AGPL system in a container and talk to it via the exposed API, I put in the About page that i'm using it -> yes/no?

etc. But i'm sure if anyone does respond to this, it will start with IANAL and there still is nothing to base anything on. I know, this is the reason a lot of SaaS startups use the license; it's not clear enough what I can / cannot do. And companies cannot build businesses on that, so they just don't use it, making the solution effectively closed. I'm sure a lot of help is missed because of it; for instance, if I would be using something like this, I would (as required) feed my work back to the project, but now the lawyers of my company don't allow me to use it at all, so nothing gets fed back.