I work primarily developing private commercial software so I need to be very careful about the libraries I pull in and, when dealing with recursive dependency m

I work primarily developing private commercial software so I need to be very careful about the libraries I pull in and, when dealing with recursive dependency management programs (stuff like NPM) making sure that the package manager either blocks GPL licensed code or else verifying licensing on each update. If GPL code makes it into our codebase we need to dedicate additional time specifically to one of the remediations you described - they are doable but they take time, sometimes you'll be able to find a non-GPL licensed equivalent, sometimes you'll need to reinvent the wheel but either way expect some logic to subtly change and re-evaluate all your assumptions. I would agree to the general point that using GPL'd code is entirely voluntary and using AGPL code is generally not an issue for most software projects but I disagree about it being a miscategorization. If I directly use 10 NPM packages and those pull in an additional 60 and one of those happens to pull in lpad which just happens to be updated from MIT to GPL licensing then I need to realize that and then either hackily re-wire the vendored code to not use lpad, possibly hardwire the packages file to force the pre-GPL version, or else drop the package that depends on it and the package that depends on that one and replace the whole component - this could hit multiple packages as well and all because of a single GPL license change. I do dislike the connotations of infect but I think it's a fair term for a quality where one of a thing can cause hundreds of other things to suddenly become unusable, the GPL license can cause an exponential growth of packages unsuitable for general commercial use.