Is he correct? That you can't have GPL files in your project without all code adhering to it? I thought it has to be linked static. So just calling a GPLed js library likely wouldn't be enough. I think the law is muddy here and not clear at all, even if the code is directly bundled.
There are multiple aspects here. In short, any kind of linking or equivalent process definitely makes your code a combined work with the GPL parts; the "safe" way of using the code are more like calling a GPL process like `system("ls -l")`.
First, if you are distributing modified code or code compiled from GPL sources, in any way, you must advertise that fact clearly, and extend an offer to the original sources plus your compilation methods to anyone who recieves this from you. This is true regardless of whether your work constitutes a combined work.
Then, if you are distributing a work that includes GPL parts and parts that you don't want to release under the GPL, you have to check specifically how the GPL parts are used. The relatively safe boundary is calling GPL binaries as separate processes, especially over a network - if this is the only way you are using the GPL code, it's probably OK to keep your other parts under an incompatible license.
If you are using the GPL parts any more closely, such as calling functions from a GPL library directly through an FFI, or worse, linking to that library, then you are almost certainly building a combined work and all of your own code has to be released under the GPL if you wish to distribute the GPL parts.
Even if you are calling the code only as a separate process, the amount and type of communication you use matters - if you are exchanging extremely complex and specific data structures with the GPL process, rather than just a few command line switches and parsing some yes/no answer, then your work may still constitute a combined work and have to be entirely distributed under the GPL.
GPL is called a viral license. Any project that you add GPL code to must be licensed under GPL (and made available to others under the GPL guidelines). That's why many commercial companies don't include GPL code - see Apple.
LGPL is typically meant for code packaged as a standalone library called from other, possibly non-GPL, code. You can distribute and call LGPL code from your code but your code does not have to be GPL/LGPL-licensed.
I believe the intent of LGPL was to have free LGPL versions of libraries where only popular non-LGPL libraries existed before. Any changes made to LGPL source code must be released under the usual LGPL/GPL guidelines, i.e. you can't make changes to LGPL code, release it in your project, yet keep the changes to yourself.
What Apple does not ship is GPLv3 code. GPLv3 had two major changes around patents and "tivoization". The tivoization clause in particular forces changes that break Apple's security model for their hardware, and is probably the core reason they do not ship GPLv3 software.
Note that the anti-tivoization provisions only apply to software that is sold with the hardware. If Apple wanted to use GPLv3 software in apps that you have to purchase separately the anti-tivoization provisions would not be a problem.
This points to one area of Apple's use of GPL code. Apple doesn't want code licensed under GPL v3+ so they're sticking with the GPL v2 codebase (and custom-backporting bugfixes?). Apple uses Bash v3.2, GNU Bash is at v5.2.
GCC was replaced with LLVM in Xcode 4.2, and GDB was replaced with LLDB in Xcode 4.5 and GDB removed in Xcode 5.0. see https://en.wikipedia.org/wiki/Xcode
If the GPL code is an integrated part of your code, then you've created a derivative work, a "work based on the Program" as the GPL calls it. In this case your work must also be licensed as GPL.
>5. Conveying Modified Source Versions.
>You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
>[...]
>c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
It seems to be the case here since, as the top comment by RraaLL says, they've included GPL-licensed JavaScript from uBO in their extension.
I think you might be thinking of the LGPL, where it’s fine to use a piece of code if you dynamically link to it (and maybe something about providing relinkable object files, but I’m not too clear about that). The GPL, on the other hand, mandates that any code that interacts with GPL’d code must be GPL’d, unless it can be easily replaced or such and such (i.e. your non GPL code calls a GPL binary via fork & exec or the like).
I’m not an expert in this sort of thing, so a more knowledgeable person may chime in.
But if you create a plugin that calls (via mv2 api?) a separate GPL-licensed JavaScript file to block all ads on the page, and then use your own closed-source code to add your own ads in step 2, is it really integrated or just two separate programs bundled together?
The mere act of communicating with other programs does not, by itself, require all software to be GPL; nor does distributing GPL software with non-GPL software. However, minor conditions must be followed that ensure the rights of GPL software are not restricted. The following is a quote from the gnu.org GPL FAQ, which describes to what extent software is allowed to communicate with and be bundled with GPL programs:[74]
What is the difference between an "aggregate" and other kinds of "modified versions"?
An "aggregate" consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets, and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
The FSF thus draws the line between "library" and "other program" via 1) "complexity" and "intimacy" of information exchange and 2) mechanism (rather than semantics), but resigns that the question is not clear-cut and that in complex situations, case law will decide.
I don’t know about that hypothetical case, but from what the redditors are saying, it looks like the Honey team are directly including and calling upon the GPL’d code, which I’d say constitutes derived work.
For that specific hypothetical, I’d say it would function as a derived work, but others would be able to answer better.
