I use the AGPL myself, and over the decades become obvious both it and the GPL have a flaw: they don't define when their most contentious aspect (them being "vi

I use the AGPL myself, and over the decades become obvious both it and the GPL have a flaw: they don't define when their most contentious aspect (them being "viral"), is triggered, so most of the time it's a hope and a prayer. I have no doubt Stallman thought the term "derived work" was pretty clear at the time, but the amount of wriggle room it provides in the hands of the wrong people this could be devastating to business. (Think: Oracle trying to stretch the definition of copyright to cover API's.) The occasional rare project does go out of its way to define the demarcation line. For example, the kernel's authors have made it very clear the demarcation line is the user space API, so anything that relies on it is not considered a derived work. I have no doubt that is one of the reasons you find the linux kernel everywhere. But even some top tier GNU projects have similarly clear lines: not only are programs complied with the GCC not considered derived works, programs that statically link the libraries needed by the GCC compiled code are not considered derived either. And so unsurprisingly, using the GCC is not considered dangerous, despite it being GPL. Personally, I'd like to see an [A]GPLv4, that formally defines what is a "derivative work" is or at least provide a list of choices users could include. It could, for example, exclude programs that use output of another when that output is intended to be readable by humans, and it could exclude header files and similar things that define API's. Doing that would remove a lot of the uncertainty about when the GPL is "viral" and when it isn't. As it stands, Google's blanket ban seems like a reasonable response.