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.
This is wrong in a couple ways. First, Apple ships plenty of GPL code. https://github.com/apple-oss-distributions/bash/blob/bash-13... as an example.
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.
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.
I presume they keep a bash around due to how ubiquitous it is for scripting.
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
>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’m not an expert in this sort of thing, so a more knowledgeable person may chime in.
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.
For that specific hypothetical, I’d say it would function as a derived work, but others would be able to answer better.