Earlier quoted context omitted.
Yeah, it's complex: * The article is right that Google IS spreading FUD. They're making legal statements which are probably false to minimize usage of the AGPL outside of Google. * Google came to a sensible conclusion, that THEY shouldn't use the AGPL * Google's articulated reasons don't hold legal water, and following Google's lead and interpretation causes many companies to mislicense their code It's a right tool f…
Maybe I'm misunderstanding. It sounds like you agree that companies with proprietary code can't link GPL libraries, and Google's statements don't suggest any problem for companies which don't care about keeping their code proprietary.
No. This is incorrect. One cannot create derivative works with AGPL code. Linking does not necessarily create a derivative work. Whether or not it does depends on the specific case, and the degree to which the code intertwines. If I have an AGPL back-end and a proprietary front-end for an online photoeditor, that's probably a problem. If I have an AGPL database and a proprietary web app using it, that's generally not a problem.
Even in the photoeditor case, it only becomes a problem at distribution. For an internal tool, AGPL+proprietary is often okay (depending on who the internal team is). AGPL means a consumer-facing web app becomes a problem.
There is a sensible decision path for avoiding linking, but it has nothing to do with this. The arguments are:
1) Engineers aren't lawyers. For a big company, it's easier to have a hard rule (no AGPL) than to train engineers to be lawyers. For small companies, more nuance is okay.
2) AGPL is as much a legal mechanism as a social signaling mechanism. If I'm using a tool not the way the authors intended for me to use -- in an open ecosystem -- that creates its own problems.