Most CTOs understand GPL. Fewer understand AGPL. And that gap in understanding creates real legal and strategic risk for any company running open-source code behind a network service.
The Gap GPL Left Open
GPL requires you to share source code when you distribute software. The key word is "distribute." If you run GPL-licensed code on a server and users interact with it over the network, you haven't distributed anything. You've used it internally. No obligation to share your modifications.
That's the SaaS loophole. And it's exactly what AGPL-3.0 was designed to close.
What AGPL Changes
AGPL adds one critical clause: if users interact with your modified AGPL software over a network, you must make your source code available to them. "Network use" triggers the same obligations that "distribution" triggers under GPL.
The Practical Impact
If you're evaluating open-source dependencies for a hosted product, AGPL-licensed components require careful consideration. Using them means either sharing your modifications or isolating the AGPL component behind a clean service boundary.
The question isn't whether AGPL is fair — it's whether your engineering team knows it's in the dependency tree before your legal team finds out the hard way.
What to Do
Audit your dependencies. Know which licenses are in your stack. Have a policy for AGPL components before you discover one in production. This is a CTO-level decision, not something to leave to individual developers making package choices.