4 ms·

Your whole understanding of the GPL is a mis-categorization of its behavior. The GPL does not "aggressively applies itself to full code bases that adopt it", t

by temac 6y ago

Your whole understanding of the GPL is a mis-categorization of its behavior. The GPL does not "aggressively applies itself to full code bases that adopt it", that sentence is even completely meaningless. I can't even find the beginning of what you wanted to convey regardless of the side I attempt to take it. If a "code base adopts the GPL", then yes ok "it" adopts it, is there a problem? Why would anything attempt to "aggressively" apply the GPL licence to a code base that adopted the GPL? If it is rather than the GPL aggressively applies itself up to the point code bases that adopt it are fully converted to it but were not before, then that still makes no sense obviously because 1. a license is not sentient and won't attempt to aggressively do things by itself, but also 2. because code under other licences exists in code bases and systems containing code licensed under the GPL -- some under licences compatible with the GPL, other under licences not even compatible with the GPL. To finish with that characterization, please provides the plenty of examples that should surely exists of projects that had to switch to the GPL against their "will" because of its supposed "infectious" or "cancerous" nature (not just dual licence or use some compatible licence, switching). And then please provides among this list, the list of the projects where it happened for another reason than lack of due diligence by the copyright holders of pieces of code supposedly "infected" or tainted with "cancer" against their will. A final note: there at least 2 more ways (that are not open-sourcing) if somebody did a mistake and based a work on GPL licensed code but should not have done that because the conditions of the GPL are not appropriate for it: rebase the project on non-GPL licensed software; or stop it - or at least stop its distribution. Nobody will even manage to "retroactively" 100% force you to open-source proprietary software. And nobody can force you to change an open-source licensed code compatible with the GPL to the GPL itself, I don't even see what would be the point of asking to do that change.

meetups323 6y ago
Not the parent, but here's an example of the converse: VS Code does not play any videos because it does not bundle ffmpeg because doing so would "infect"/burden it with heaps of GPL requirements. https://github.com/microsoft/vscode/issues/100599 https://github.com/microsoft/vscode/issues/100599, https://ffmpeg.org/legal.html https://ffmpeg.org/legal.html
munk-a 6y ago
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.

by temac 6y ago

meetups323 6y ago

Not the parent, but here's an example of the converse: VS Code does not play any videos because it does not bundle ffmpeg because doing so would "infect"/burden it with heaps of GPL requirements. https://github.com/microsoft/vscode/issues/100599 https://github.com/microsoft/vscode/issues/100599, https://ffmpeg.org/legal.html https://ffmpeg.org/legal.html

munk-a 6y ago

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.