IIRC, only if it's statically linked. If it's on the disc as two different binaries that only talk to each other through the OS at runtime, then no, MK8 isn't required to be GPL.

(It's the same principle that allowed Apple to include GCC with Xcode before LLVM came along.)

GPL code you CANNOT link in anyway without your code being infected by the GPL license terms, dynamically or statically. You CAN invoke tools written in GPL just not the code (unless that GPL license has something like a classpath exception).

The are also exceptions for libraries provided by OS. (Which is why you can GPL code on Windows which links a proprietary libc from Microsoft).

Apple gets away with calling GCC because it's a different application being invoked by it's natural interface in the same way that Xcode invokes git internally. (And also why people use the libgit2 project when they need to call git as a library which licensed under LGPL with the classpath exception).

Now LGPL is an entirely different story. LGPLv2 was intended that you be able to replace dynamically linked libraries in an application. The changes you made the library must be open sourced and I should be able to replace that library as a user.

In theory you satisfy the requirements of the LGPL license if you wanted to statically link though if provide the objects and archives of your code if you wanted to statically link with LGPL code, but doing this was not really well defined in the license as valid. In LGPLv3 they clarified this is totally valid and allowed.

The interesting thing is that LGPL was a license best written for C libraries at dynamical library level and breaks down in a few cases for different languages. It also breaks down where you have inlining and code getting embedded from headers that would break the ability in some cases for you to be able to change the library and relink. Implementation details of vtables, etc can get embedded too that would make it impossible to change the library.

This is why during the GNU Classplath project (to replace the Java Classpath before Java went GPL anyways), they added the "classpath exception" to GPL itself instead of using LGPL. See here for details: https://en.wikipedia.org/wiki/GPL_linking_exception

But what exactly is a "link"? If I write e.g. a piece of software that enables combining and running arbitrary code from any library, GPL or otherwise (think of something like rundll32 on Windows), and use that instead, via parameters that the user somehow has to supply in order to get the right libraries and symbols, does that also become GPL? I can thus use any GPL (or otherwise) library in the same way that Xcode uses GCC.

This and other "how long is a piece of string" type of issues is why I think licensing is overall a horrible ridiculous convoluted mess.

Linking is simply a simplification of "what defines a derivative work" that FSF think helps developer. It is by no means final, and one can always hope that the court system will find the definition of derivative work at some other point.

I would however call it a bad bet to incorporate someone else code into a proprietary product, on the off chance that the general known line of "linking" can be invalided by the courts. The lack of case files should be a strong hint towards that.

Thanks for the correction!

Someone downvoted this, I assume they mean to say it's incorrect? Can they or someone else elaborate?

I didn't downvote, but it's incorrect. They're confusing the GPL (which requires release regardless of static or dynamic linking) vs LGPL (which allows no release if only dynamically linked).

Ahah, maybe :)

However, the SBC codec library is LGPL, not GPL-only. Notice COPYING.LIB along the COPYING!

Just the main sbcdec and sbcenc are pure GPL, and they are not very long files, so it's likely they rewrote those parts.