I am not a lawyer, but I think this is getting a bit out of hand. I mean granted, GPL does definitely have some gray area, but the gray area that GPL has is being wildly exaggerated. The main thing about GPL that is called into question is its virality, but the virality of AGPL is exactly the same as GPL.

For GPL, the main question is what constitutes linking. Let's read the text.

> The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

This does leave some room for interpretation, but the intent is pretty clear to laypeople: when you want to distribute a GPL-derived work, you have to distribute the source code in such a way that users are able to build install and run it, including any required subprograms. What this DOES NOT do is implicate other unrelated programs. A program that e.g. merely communicates with a database is not intended to be implicated here.

The thing about this that I think is important is that the GPL can only concern things that are plausibly possible to consider derivative works of the software, being a copyright license. Obviously, as a layperson, I do not know exactly what nuances and what range of opinions exist on what a "derivative work" actually entails. That said, it doesn't seem to be that controversial on it's face. I found this explanation from Adam Blaier of Brown and Blaier Attourneys and Councelers at Law[1]:

> Derivative works are new, original works based upon one or more existing works. In software and computer programs, this includes lines of code. Creating a software derivative work involves modifying the source code of an existing computer program either by revising it or translating it into another computer language. Simply linking to the existing original code in a library program without modifying it does not create a derivative work. Using a plug-in or a device driver also does not create a derivative work, even if you look at the program’s source code to determine how to use the plug-in or device driver.

Note that in this interpretation, merely linking to a program does not create a derivative work. In theory that would actually make a lot of GPL linking exceptions unnecessary, if I understand correctly. I presume that the FSF would disagree.

To me, that's the real gray area.

> It's worth noting this is google's take on it AGPL is here:

I worked at Google and went to their legal classes (the ones you have to take when you join.) It's FUD bullshit. Google's "legal stances" are motivated by their desires to uphold some kind of status quo. They leaned really hard on this when it came to their IARC and open source policies, and when I asked (multiple times) why they simply couldn't just be less strict than the law (since obviously, they do not have to choose to hoover up as much intellectual property from their employees as possible; they could always, y'know, decide a reasonable divide and put it into the contract) I never got a reasonable answer even one single time. I can't imagine, for the life of me, that this concept never occurred to anyone at Google. And you may think I'm being unreasonable, but every. single. time. this came up, there was a sob story about how they have to do it. They told people this, and most of them presumably just believed it without realizing it's totally within their power to just not handle copyright assignment that way if they don't want to.

So then why is Google so heavy on AGPL FUD? Simple. They don't want people to use AGPL. They want people to use Apache 2 because then they can do whatever they want with it. AGPL does technically pose some risks, but the risk is not that a judge is going to rule that the entirety of google3 has to be released under the AGPL license or something stupid like that. (Don't get me wrong, they can't use AGPL in their main monorepo, that'd be a terrible idea even with automation that ensures license compliance. But, the idea that they can never use AGPL ever at all is pure comedy. Sincerely.) Google's stance on AGPL is about as convincing to me as Nintendo's stance on the legality of emulators.

And don't think I'm some sort of stupid Stallman zealot, I use ISC license on nearly everything I release, because I simply don't give a shit. However, I find this degree of buying into FUD a little disgusting.

[1]: https://brownandblaier.com/blog/derivate-works-and-software/

I do remember reading the endless comments on licensing on GPL/LGPL/BSD on slashdot.

> Simply linking to the existing original code in a library program without modifying it does not create a derivative work. Using a plug-in or a device driver also does not create a derivative work, even if you look at the program’s source code to determine how to use the plug-in or device driver.

This is clearly debatable. Tainted linux kernels are a thing. It's one thing if you distribute a kernel with a proprietary driver (nvidia comes to mind here). It's another thing if you ship a GPL kernel, and another if the user decided to taint their own kernel with a driver with a proprietary license.

The combined program here is the Kernel and the Nvidia drivers. You can't get around it even though the NVidia drivers are "weakly" linked into the kernel.

The question is at what point is "linking" established? During compilation? During dll loading? Or when you hit a rest endpoint?